Jump to content
Stray Fawn Community


  • Posts

  • Joined

  • Last visited


15 Good

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. What? Everything currently is a boolean; and/or gates as-is would be perfect and easy to implement, I was just saying they would be optional with a number-based logic system because math gates would be able to do equivalent things. Many existing games use number-based systems for their logic, such as GMod and Scrap Mechanic's 'The Modpack' - it would just let us do more, like make bots that hover perfectly stable above a planet, rather than bouncing back and forth across some arbitrary altimeter setting
  2. This might be too big of an ask, but, the current logic system feels very limited and takes a lot of parts to get anything done. I propose a logic overhaul to use numbers instead of booleans. Thrusters would take in a number, indicating the power they fire at; sensors would output a number indicating the distance to whatever they detect (or 0). Logic blocks like AND/OR could either be removed in favor of using math for the same result, or could treat all <=0 as false and >0 as true. Batteries/gas/etc could output their current fuel amount, inputs to shields and heaters could set the radius or strength (so setting either to 0 would disable it). Hinges could be wired to take an input speed, pistons a speed or range, springs a strength value, etc. Basically everything that we currently hard-set through the editor now, let us instead set it with logic Then things like speed sensors/altimeters could output an actual number, directional sensors could output an angle, and (required) new math logic blocks would be able to manipulate those into usable values to make really good automations. The things you could do if the sensors gave you an actual number value to the target are nuts
  3. I don't think it'd be any more messy than what happens if you try to make two diagonal thrusters adjacent to eachother But you're not wrong, if we were able to center the grid on a different part. It would mostly solve alignment problems and not be messy if we could just rotate the grid around the core, though
  4. I also saw that "Definitely not a peen" or whatever bot, and the sad part is that it's actually not bad, cuz it beat me...
  5. I agree that being able to send numbers over the logic networks instead of current binary style would be nice, if possible, and would let us do a LOT more than we can do now. But I also feel like it'd be a bit of a whole system overhaul, so even if it can't be done, the current implementation seems perfectly good to me
  6. I like how it's basically a subroutine with an input and an output - currently being able to input/output between logic networks is impossible, I was hoping for something more general to handle that, but this also has the advantage of not having to apply physics to logic. I think that's important and good, because they're small, relatively fragile pieces and it seems a little odd to have them bouncing around and bumping into your drone's actual structure. What's the idea with the size of this block? It would almost have to be able to resize to work properly, otherwise you'd pretty much always end up with too much or too little in the PCB compared to the logic it contains Also, as for Sumo being a 'minigame' - I know more content is coming, but Sumo is the only part of the game that seems replayable and it should probably have a lot of focus on it
  7. Sort of, the problem is doing something to a drone's thrusters, which are behind a logic separator, based on the input from a global key, which isn't - there's no current way for my separated logic to ever do anything based on a global key input, or output a global keypress based on separated logic So even if I were to attach a logic connector, any inputs I receive from it can't be sent through the separator to affect the drone. The alternative would be to have whole separate thrusters attached to the logic connector, to do something based on global input, but then there's no way to tell the separated thrusters to stop trying to do things
  8. I saw the key/tag transceiver, but it's a slightly different implementation of the same concept - this idea is a little less complex because it doesn't require two parts to work, but this idea also doesn't allow you to communicate between two non-core networks like the transceiver would. So, vote on whichever one you think would work best
  9. Mostly I'm just reminded of an old mod for GMod called WireMod; it involved wiring up simple gates in the source engine to do whatever you want, usually attaching them to thrusters and sensors for flight. Then, they eventually released Expression chips, which allowed you to get rid of all the gates and just write code - and over time, these chips evolved to be able to alter the laws of time and space, up to and including spawning props and applying forces to them without an origin. As you might expect, the player population dropped massively because doing anything in it was trivialized - a build that used to take hours of complex thought and wiring instead took 2 minutes of coding, and very quickly everything that could be done, had been done. The point I'm getting at is, a game like this is successful at least partially because of the complexity in using basic logic. If the basic logic could be replaced by code, or by one chip that does all the logic, it would remove pretty much all of the challenge in automation. If we wanted to code, we'd open an IDE and do it - a game should provide enough of an abstraction from code that it's a separate challenge entirely
  10. Wires might look very messy and could make it really hard to make a drone look nice, but I totally feel you on wanting something visual. I know the current system can be really hard to tell what goes where, but that also means you don't know what a drone does by looking at it - which means a new player has to experiment and learn how to use the logic system, instead of copying some picture of how wires should be connected, and a player can't copy someone else's design just by taking a screenshot of it in sumo. The current system also adds complexity, effectively adding to the amount of time it takes to do anything, adding to the amount of gameplay a user can get from the game. This kind of artifical complexity is really important in these games, because without it the logic can quickly become trivial and a 100 hour game becomes a 20 hour game
  11. Also +1 for replacement, however it's implemented, and also agree that the second bit should be its own suggestion. That's basically an overhaul of the logic system, it currently can only send 0 or 1, so allowing it to send actual numbers and compare them doesn't seem all that likely. I mean I'd love it, I just imagine they already considered the idea and intentionally went with a boolean-only logic system
  12. Some sort of way to tell controls at a glance would be awesome, though I'm a bit of a fan of this suggestion Either way would be nice though. One thing worth mentioning, if you aren't already using TAG in the top left, give it a shot - it lets you use variable names for inputs and outputs, making logic MUCH less complicated
  13. I definitely thought the TAG and Input were ANDed for a while, ORing them seems counter intuitive and allows for extra inputs and outputs for a given chip. If they were ANDed, sending a 1 to "SomeTag" "W" would only trigger something specifically listening for that combination of keys, instead of triggering both W and "SomeTag" Making them AND by default would make logic much more complicated by removing the option for extra inputs/outputs, but I'm all for that
  14. I have concerns that oversimplifying the logic would hurt gameplay, but if you're building something so large that it's becoming unstable from the amount of logic, then yeah that becomes a bit of a problem. I think it'd be a great idea as long as it's not allowed in sumo, and if it was locked behind some research it'd still encourage new players to play with and learn the logic gates before giving them a part that replaces them all
  15. I think it's a bit complicated and uses center of mass currently, so if it's left of the center of mass it's considered a right turn thruster, etc. I agree that simple directions like you're describing would be better, since even forward thrusters are pretty much never placed in line with the COM EDIT: Just to clarify, I have no idea how it actually works and COM is just a guess from what I've seen
  • Create New...