The second one is basically saying that when you push the button in the aforementioned circuit you don't see the bottom flip-flop turning on at all: Starmade treats that as instantaneous, it only updates the image once the circuit has reached a stable state
...of course, delay blocks doesn't count as they trigger another stabilization step 0.5s later (and it's exactly why sometimes there's no way around delays if you want something small).
However, instant pulses can't be used to time things: their duration is either 0s ("in game time") or something uncontrollable depending of your computer and Starmade's load ("real time").
weird, I can't find the circuit in the thread, I'm pretty sure I got it from you.
it has:
1 button, connected to a not gate, flip flop and activator.
1 activator, connected to the flipflop
1 not gate, connected to an or gate and the flip flop
1 or gate connected to the flip flop
then copy the circuit and paste it and connect the not to the button in the next circuit
repeat this a few times and then you can loop back the circuit using a not gate and then back into the button of the first circuit.
there, a clock without any delay signals!
fun fact, it has more resistance against lag than a delay block (don't ask me why)
What you just described is a not-button clock with superfluous elements.
Unless theres a additional connection or element in there that actually does something with the rest of the circuit other than flip a flip flop?
Possible to get a picture or BP?
It's been a while since I've done anything of actual value on this thread, and I've been meaning to do this for about two moths, but now seems like an OK time.
This is moderately simple stuff (harder than getting doors to work, but not something any logic enthusiast will really care to read about (this is probably why I haven't really worked on it much)) (I also didn't discover any of this, this has been around since, like, computers. And no, I don't mean the thing you're on, I mean stuff like bombe)
There's a very useful thing in logic called adders, and there's also half-adders. Half adders are a lot simpler to explain, so here's some documentation.
This is a half adder when both of it's inputs are off. To build it, all you have to do is connect both inputs to an or and an and, connect the or to an and, the and to a not, and the not to the and the or came from. The or's I have on this are superfluous, but they make keeping track of the outputs easier.
And here we see the other three states the two inputs can be in. It might seem like a simple thing that's going on, but what's happening is actually quite useful. The half-adder is counting, it's input table arranges like this;
0 0 = 0 0
0 1 = 0 1
1 0 = 0 1
1 1 = 1 0
Regardless of which input is on, the half adder will always only output to its first output if one is on, and will only output to its second output if both are on.
To make this more useful though, you really need to step it up to keep track of three inputs, a full adder.
The first bit in the bottom left of this is the same as before, and so is the bit in the top right. The first two inputs go to the first half adder, just like normal, but then they do something weird, the output for only one input being on goes to another half adder, coupled with a third input. The way the first half adder interacts with the outputs and with the other half adder is the real key to this. If one of the two grouped inputs turns on, it will go through the first half adder, and then go to the second half adder to check if the non-grouped input is on, then it will go to its proper output. If the non-grouped input is off, it will go to the first output, if it is on, it will go to the second output. However, if both of the grouped outputs are already on, they do not need to go through the second half adder, and automatically go to the second output. The table for this looks like this;
0 0 0 = 0 0
0 0 1 = 0 1
0 1 0 = 0 1
1 0 0 = 0 1
0 1 1 = 1 0
1 1 0 = 1 0
1 0 1 = 1 0
1 1 1 = 1 1
If you get good at this, and understand it well, eventually you can make more complex adders to count larger inputs.
I'll add a picture and a bit of documentation on this later. My old counter sort of does this, but it does a lot of bullshit before it so it's a bad example.
So, logic drives have been fixed in dev build. If/when the update makes it to the live version I'll make a post about the development (at least in my faction) of the exploitative drives, and the concepts behind them.
First one was changed, might be fixed might not be, I haven't tried breaking it hard enough :P
Instant charges are fixed.
No module computers no longer charge.
Of course, this is all still in dev, so things might change. It's why I'm not posting my stuff now, I'm afraid of the extremely slim chance that this update just has a horrible bug in it and can not be fixed, meaning that the exploit will have to be left in. I'm pretty confident in schema though.
hmm well I'm guessing the devs can't figure out how to allow logic charging without the possibility of near instant charging. XD I suppose they could limit the charge rate for the inputs to something like say at best 10x what the normal charge rate is but other than that it is either take it away outright or find a happy compromise.
Instant charge appears to be fixed, there's still a few avenues I'm exploring myself though.
Zero module charging is gone, actually caught in code now.
Other than that we need to charge them with time discreet signals now, so no more abusing signal multipliers here.
There is a specific frequency to charge drives at, but logic charging cannot equal manual charging in terms of speed currently because it can never hit the 'reload' mark consistently unlike a 'is mouse button down?' check.
You can get close though, or not depending on lag.
So a High enough frequency clock should hit the reload/charge point most of the time? Doesn't sound like it breaks any of my AI ships too badly, just need to figure out how many more or less logic blocks to put on the things before making new ones.
So, looks like the update sticked, might add pictures in a bit but here's the general gist of what happened.
First Planr posted a thread about how logic could charge and fire JD's.
Next I made the Zurich, and put a simple clock going into 45 jumpdrives in it. This was slow af. It took twenty minutes to charge.
After that however, Azereiah asked what would happen if we put overclocked logic on it. I tried that out and it charged faster. Then I remembered a weird thing with overclocked logic, a while ago I was making something to fire a lot of missile/cannon computers really quickly, but I was having issues with clocks synchronizing. Clock synchronization would completely take away from the time between missiles (they'd go back to acting like it was a simple clock, going at half second intervals) but would still fire as many missiles per second as it should, by firing multiple missiles at once. I noticed that when this happened with my JD, it took no longer to charge than when the clock was fully functional.
And with that, the main concept of all of my jumpdrives had been solved; sending multiple simultaneous signals to singular drives to get the to charge faster. It started by having a clock go into what I called an amplifier, a series of not-gates linked in a chain all linked up to a single flipflop, and ended up with a drive where you could press a single button to have it completely charge and jump.
So, looks like the update sticked, might add pictures in a bit but here's the general gist of what happened.
First Planr posted a thread about how logic could charge and fire JD's.
Next I made the Zurich, and put a simple clock going into 45 jumpdrives in it. This was slow af. It took twenty minutes to charge.
After that however, Azereiah asked what would happen if we put overclocked logic on it. I tried that out and it charged faster. Then I remembered a weird thing with overclocked logic, a while ago I was making something to fire a lot of missile/cannon computers really quickly, but I was having issues with clocks synchronizing. Clock synchronization would completely take away from the time between missiles (they'd go back to acting like it was a simple clock, going at half second intervals) but would still fire as many missiles per second as it should, by firing multiple missiles at once. I noticed that when this happened with my JD, it took no longer to charge than when the clock was fully functional.
And with that, the main concept of all of my jumpdrives had been solved; sending multiple simultaneous signals to singular drives to get the to charge faster. It started by having a clock go into what I called an amplifier, a series of not-gates linked in a chain all linked up to a single flipflop, and ended up with a drive where you could press a single button to have it completely charge and jump.
And could be made very compact, I think mine was at 54 blocks by feeding amplifier signals into the end of the chain as well as down it, and this would work for any sized ship as well.
Today, Fellow Starmadian showed me a logical game of Tic Tac Toe on SMD's pubchat and I decided to play logic golf with it I reduced the number of logic blocks on it by a bit under half. Check out his version; https://starmadedock.net/content/logical-tic-tac-toe.4147/
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
