Eldrad
-
Posts
23 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Eldrad
-
-
Definitely want this with the winch. Without it's very similar to weak springs.
-
You'd still see a flood of mindless pushers as you do in the current tourney. The issue is that the tournament puts you against drones who have beat 1-10 opponents. For a very small population that'll approximate a spread of quality, but with a large population (as the game appears to have since being early-access on Steam) all of those will likely be pretty close to average/common.
Mindless pushers aren't good. They're just easy to make and therefore the first thing people try and frequently the only thing.
-
It costs 3 blocks (decoupler, fuel tank, and thruster) to do but is generally worth it in my opinion if you have logic and already win tournaments most of the time. It removes a loss condition of random damage/explosions taking out an important piece of logic. Download Jack from the steam workshop to test how you do against damage.
You can generally get away with tying it to a signal which starts out on that isn't on 100% of the time (i.e. don't bother adding a button). But if you really want it to keep heading as far away from the ring as it can you can set all of your fuel tank's empty and full signals to the same thing and get the effects of a button without spending the block.
-
The issues of wanting to handle mixtures of local logic with non local information should be handled more generally and not rely on physical connections.
-
It's not just all the parts that produce an initial signal. There could also an arbitrary number of logic blocks attached to those sensors (e.g. a large number of batteries ANDed together).
Ideally the initial state would be the steady state if one exists or any state within a loop at least if the loop isn't enormous).
-
This sounds like the issue of when the battery is printed it starts giving the signal that it is full, however the login circuits all look at the previous time step (before the battery was printed) when there is no full signal. I believe the next patch has a fix for this, but is it possible your logic is doing something unexpected when the battery is printed but all your sensors are still not receiving the full signal?
-
This has a significant added advantage of allowing us to write more modular code (particularly if these blocks can be nested within each other).
Ideally a single block could be written in one place then referenced by multiple drones. And if updated would be updated for all drones.
-
I believe that would eliminate the problem.
-
With far fewer sensors you should be able to do it in a single (very slow) circumnavigation by going up and down between min and max altitudes.
-
Fly in a pattern that will take you near all the viable hopper locations and stop the pattern when your containers are empty. It's slow but would work.
-
1
-
-
There appear to be significant differences in the evaluation of sumo matches on different hardware (beyond just uniform randomness). I suspect it's due to different numbers of times (and the spacing between) logic/sensors/collisions are evaluated in a match. The result is different drones perform better or worse depending on the hardware of the observer.
There are a couple different ways to address this but they're likely all pretty significant development time. On the other hand I'm concerned the PvP won't sustain interest without everyone being able to observe similar outcomes from the same drone fights.
Supposedly the Bumpercar 6 vs CyberpunkBeyblade is a reasonable example of these results (which one wins a higher % of the time shifts between lower end and higher end hardware). I haven't tested it myself.
-
1
-
-
An and-gate and the toggle switches are a pretty straight forward transistor which will get you modern computers which are turning complete as long as you're willing to fudge on the issue of your read/write tape not actually being infinite (but limited by how much RAM/disk the system has or in this case how many logic blocks you dedicated to storage).
If you use factories you could have a horizontal line of blocks (1) or empty space (0) a read head of a distance sensor and a write head which either destroyed the block or printed a new one. Then you'd get a literal Turing Machine inside the game (though it's still be running on physical hardware with finite limits). And actually making the heads move with repeatable precision and would be hard.
-
You don't need to hit delete. If you start typing it will replace the existing text. That being said there is certainly a lot of room for UX improvements.
-
1
-
-
On 10/10/2018 at 7:17 AM, D.Mentia said:
The current system also adds complexity, effectively adding to the amount of time it takes to do anything,
Poor UX isn't a good source of extending game play. These systems are sufficiently complex. In fact they are Turing Complete, making them as complicated as the computers there running on. If so inclined one could make a drone which itself was an implementation of Nimbatus (it would be really hard and the result would be at best incredibly slow if it didn't just out right break, but theoretically possible).
My point is making it easier to work with the editor won't reduce the number of hours you could spend making interesting things, it will just make you able to make more interesting things per hour.
-
1
-
-
I never got that thing to work... but how would something like Salt Levels Rising handle an enemy core stuck to its side rear? Wouldn't it just spin in a circle with its core tracing a larger circle and the thing stuck to it tracing a smaller one?
Also D.Mentia seems to have come up with a solid counter to that style of pusher by having a spinning drone with a series of flexible parts sticking out (springs/hinges). Tends to both do a lot of damage and generally prevent the pusher from being able to look straight at the core.
-
1
-
-
It's pretty important in sumo.
-
Strongly agree that a more robust match making system would go a long way to making the PvP more fun for a wide audience. Though I would recommend resisting the urge to use signals other than win/lose to rank performance it will most likely reduce the accuracy of your evaluation. I.e. don't look at the number of blocks used, just look at the outcome of the matches it's played.
I expect there's an open source implementation of Glicko for unity which you could probably get working without too much effort. If not then Elo should work well enough. Assuming you don't want to license TrueSkill from Microsoft.
-
2
-
-
That's attempting to stick your core to any surface of the opponent which is not the front.
-
It's not very good but is a reasonable proof of concept. Not sure I have time to make it work consistently. Think you'd need to have the magnets quickly cascade in switching from repelling to attracting. That only took 45 blocks, so there's some room to make the core into a center seeker after it's attached (or if it doesn't attach). Also could have a bit of anti-carrier precautions, though ultimately this design will have a lot problems with carriers/shields.
-
2
-
-
Ooo, actually a magnetic wrap style which attaches to the opponent then intelligently spins to keep your core at a particular (not-straight on) angle actually might work well. Just watched a fight that gave me that idea.
-
1
-
-
Detecting side vs front/back is pretty hard (though you might be able to do it using your core's direction vs opponent's core). But even if you're consistently pushing them off course there is still a high risk they'll end up with your core in their sights at some point.
-
1
-
-
The "Several breeds of drone" guide mentions carriers as a counter to pushers with the justification that they can confuse the pusher's sensors. However pushers can use a pair of directional sensors attached to the ends of it's contact surface to detect whether the enemy core is in a triangle in front of them which can't be confused by detached units. It is still possible for a carrier to overwhelm the pusher but that's generally unlikely given the reduction in parts count of the non-core drones (and if there's more than one of them the possibility that they don't work in perfect coordination).
A ram of similar quality as the pusher will clearly beat it as it replaces logic and sensors with more engines and therefore wins the shoving match, but that's not very interesting and it would lose many other matches.
Is there a category of drones which if well made would consistently beat a well made pusher (other than pushers or rams)? I could imagine something which stays some distance from the edge and uses jump thrusters to dodge at a right angle from on coming targets, but I haven't made one. Do people think that would work? Is there something else?
-
1
-
Add a seperate Logic Circuit builder
in Feature Requests
Posted
@Lurkily the reason for isolating internal logic is to make it possible to modularize your logic. I.e. take some common task and group it together into a "function" then call that function with a set of inputs and read the results through a set of outputs. In particular this allows you to reuse the same function multiple times in the same over all design without having to actually place all the blocks multiple times (and without their signals getting crossed).
For example (see Bumper Car for exactly this logic) you might want to have a function which has the inputs of "wall in front", "wall behind", "enemy in front" and the outputs of "fire forward thrusters", "fire backwards thrusters", which fires thrusters to go away from the wall unless there's walls in both or neither direction in which case it goes towards the enemy. This logic is exactly the same for up/down as it is for right/left and ideally it should just be a matter of assigning the inputs and outputs not renaming all the internal logic.
Over all I strongly agree with this. Except don't limit it to only 4 layers of nesting. Put a limit based on total number of pieces of logic for things like sumo and just check for loops in the dependency graph (if there are any warn the user and don't execute the logic).