Konchog

Definitely use tags and logic splitters!

If you are still interested, I can test... iPhone 8, iPad 4

So maybe Bio is a gloop that starts growing roots through the structure of the objective - so putting tension on the joints until they smash, rather than just direct hits. Bearing in mind the different types of projectile / beam, it could be synergistic - so it's really a bit different from the other weapons.. Eg, you need to use a projectile for seeding, but beams for growing....

It should be possible to build an inherently turning drone too, based on the start radius..

Here is a different arena wall crawler, using 2 direction sensors and dynamic thrusters to maintain direction. It needs a lot of tuning, based on the mass and velocity of the drone, so it's pretty exotic! Dynamic Arc.drn

Still not sure if this is a bug, a feature, or just a weird thing to be concerned with... I mentioned elsewhere (discord) that there seems to be signal flooding / propagation issues on logic parts. Here is a drone that should highlight how the synch/flooding propagation causes unexpected effects, such as triggering delay gates. de-synchro demo.drn

The tail end of the 'solarisation' of a planet (Programmer Captain, Campaign mode)...

So, thanks to Micha, and more analysis, I worked out the delay gate! Yay! The following shows a set of timings with various inputs. The driver drone is also here! Delay Gate Examples.drn

Attached is a pretty close model of the existing delay gate using a tuned trigger impulse with an and gate. dg-woes.drn

I would really like to see network lines between each tag instance too... It would save me hours of debugging. I guess one could decompile the save file into it's xml, and then do something with that... but that's not a game anymore...

Well yeah. So, how would you build a 13 iteration loop? ;-D. I calculate about 5+n components for each power(n) of 2, so a 13 iterator would be... about 21 components?! just to loop exactly 13 times! May as well just chain them, which isn't wonderful!

Yeah - sort of... This is what I have now - Delay Gate has just the Time variable, which is on a loop. At the last tick of each loop, it checks the input. If there is a value there, it sends an output. Otherwise it does nothing. That means you can have lots of stuff being sent to delay gate, and you only need a single tick of nothing for the delay never to send anything, if it's synchronised. So, why is that useful? I have no idea!

Well, with the battery full output, the delay gate time is less than than the battery expiry time. If you change the battery delay gate to 10 seconds, then the turquoise LED never lights - it's just the same as the other stuff. I do not think you need to be concerned about infinity, either.. Well - so my expectation was that the "Delay Gate" is what is called a "digital delay line" (There are analog delay lines too - which is normally fixed to a specific offset). So, we know the the game uses ticks, (which are normally called 'samples' in digital electronics), and the maximum number of seconds the "Delay Gate" is set to is 10, so you only need 10 * the number of ticks / second for storage; not infinity. The normal programming structure for a digital delay line is some form of FIFO queue. Normally you only update the pointer to an array, which acts both as the value to output, and then the place to put the next input. An empty three tick DDL, with inputs (at each tick) of 10100 will output 000101 000=>100 // Tick 1: output 0, input 1. ^ // Ptr at 0 100=>100 // Tick 2: output 0, input 0. ^ // Ptr at 1 100=>101 // Tick 3: output 0, input 1. (the pointer loops back to zero) ^ // Ptr at 2 101=>001 // Tick 4: output 1, input 0. (the input 1 has been delayed 3 ticks!) ^ // Ptr at 0 001=>001 // Tick 5: output 0, input 0. (the input 0 has been delayed 3 ticks!) ^ // Ptr at 1 001=>000 // Tick 6: output 1, input 0. (the input 1 has been delayed 3 ticks!) ^ // Ptr at 2 Now, because the Devs at stray fawn did NOT implement the delay gate this way, I'm trying to work out just why they did it the way they did. So, it's clear from experimentation that the Delay Gate will only activate if the input happens to coincide with it's own timing loop. Therefore, by tying an Impulse Giver with a active/pause of 0.1/1.2 (1.3 seconds total), to a Delay Gate with a delay of 0.7 seconds, the delay gate may never fire, even though. It also turns out that my earlier solution fails, because the buffer just blanks out any input changes, which isn't so hot. So, I then thought to actually build a proper delay line using If Gates for the FIFO queue elements. (see attached). lossy.drn I added a space key sampler (once the buffer is filled, press the space key to see if there are any 0 being propagated), and it's clear that the logic gates are very lossy indeed, which really sucks and is completely unnecessary: It looks like the rise times or fall times are not correctly coded, so the zeros are washed out of the signal. Damn. So I may be wrong, but it seems there is no feasible way of writing a simple digital delay line that is not lossy. Oh - is this a deliberate thing to stop storing variables? I don't think so - because it's reasonably straightforward to construct addressed memory out of the existing logic gates. It's a pain - but it's made much easier with the on-off switches... So.. what is going on?!

OMG - what a fool I can be. Thanks, [ab]+[BA]+

The delay gate seems to be acting differently than I imagined. Maybe it changed in the last update? So, in the enclosed drone (see picture), the three circuits all have an impulse pause of 3 seconds, and the gate has a delay of 1 second. From the top down, the impulses last for 0.9s, 1.0s, and 1.1s respectively. Before you run the drone, ask yourself which LEDs are going to be lit, and at what time offset from zero are they going to be lit, and for how long? I would have thought, bearing in mind it's a delay gate - that we would see all 3 LEDs lit, all at the 4th second, with the each LED being lit for 0.9s, 1.0s, and 1.1s respectively. Seems reasonable, for a delay gate. But that is not what happens. In fact, only the bottommost LED is lit, and it is lit for 0.1 second. So - it appears that an 'off' value sent to the delay gate while it is processing the delay just clears the gate's internal delay buffer. filter component.drn It seems that any change to the input cancels the buffer, which means it's some sort of short frequency filter. Maybe that is your intent - but I think that calling it a delay gate is a bit weird.. There's a real thing called the "gate delay" (or propagation delay) - which is the length of time which starts when the input to a logic gate becomes stable and valid to change, and ends at the time that the output of that logic gate is stable and valid to change. The only way I can see to get the the behaviour I expected efficiently is by adding a driver - a buffer gate, which has the timing set to be equal to the delay gate. (see the following drone for the blinkenlights). While this works, it does mean that the forward timing (of the delay gate) must be repeated in the buffer gate, which doesn't seem to be correct. I am quite willing to be told that I am ignorant and out of my depth here! delay driven with buffer gate.drn

My one doesn't yet completely consume the planet but it does a good job! Nanites.drn

Hahaha -- well, never mind ;-D. Most people will either not know it, or take it with the great amount of irony that it suggests ;-D. I like the idea of Stettium and Rogium!

Well, my nanites do quite well at mining - they pretty much eat the planet in the process. I was hoping to use a little more intelligence though!!

Tritium is a great resource, but it's a bit weird to be mining it. With a melting point of -248℃ and a boiling point of -254℃ it is hard to imagine a less mineable material. I know it's just science - but if we have unobtanium for the other resource, why not use hardtofindium, droneium, phlebotinum, eludium, or if you want one that really exists, dysprosium?!

Being able to construct a loop is really important in automation. I'm aware that it's possible to use switches to implement - (see the following link) https://steamcommunity.com/sharedfiles/filedetails/?id=2068273406 but it gets a bit tricky if one isn't used to programming, or if one wants to use arbitrary numbers!

I think I may have mentioned it on Steam - but mods - even just drone part mods - would be awesome.

In fact, there is a horrible workaround using the current camera system - by using windowing and then changing the window size so that it is extremely wide, one can increase the angle of camera rotation enough to see the entire planet. Which sort of defeats the whole intent of limiting camera view.

Unless I am missing something, it seems impossible to cross the logic separator - which is great, but for instance if I want a subsystem to respond to a request, there is no way to do it without exposing the entire subsystem. A simple interface (eg 'show value') would solve that. In fact, it could be added into the logic separator (pass key xx over as yy)

There is a really weird 'feature' about the way in which you guys are doing the camera: When slowing down time in test mode the camera controls also slow down... Possibly a bug?

Ideally, having the ability to (1) set a throttle value (2) an activator to increase throttle (3) an activator to decrease throttle