How to detect filt when its life prop>0?
-
I am designing a processor that interprets brainf ** k bytecode, and while I was testing some ideas for the input circuitry, I found something interesting.
I need to send a SPRK through a dense part of the circuit, and cannot use INRW+CRAY(SPRK), because there are a lot of metal on the way, then so out of curiosity I tried INST+CRAY(SPRK), and what I got were all FILT who were in front of it getting life =4, as if there BRAY going through it. The strange thing is that the tmp property of CRAY is equal to 1.
I can still use some tricks to redirect the SPRK, but could save several particles if I could detect when a FILT acquires life >0. Does anyone know if this is possible?
-
The reason this happens is because of the new FILT graphics function, which uses the .life. So when a CRAY/ARAY beam goes through it, its .life gets set to 4 and then counts down to zero. For CRAY(SPRK) anything except for PSCN OR INWR doesn't do anything, but it still causes a beam to go through the FILT. If the mods had added the highly requested ERAY, then yes it would be possible, but no, they didn't, so it isn't.
-
Maybe you could use DRAY? As long as you can get a SPRK in front of the DRAY, it can be copied to any arbitrary location in front of it using tmp2 and tmp.
Tutorial save:1615589View Save 1615589
Also we should probably add an element to the sensors menu that detects life. And for ERAY, all the requests varied a lot, I just know boxmein's implementation was hard to use (at one point?). Since really, how do you tell it which properties to copy and which not, and code it to not use any extra data and other things :P.
Edit: found ERAY codeEdited 2 times by jacob1. Last: 4th Jan 2015 -
Wow that is very different then the way I was trying to make my version work (also I made mine in lua and its still a WIP). I just used setting the .tmp for the length, the .tmp2 to a number which determines which field it copies based on elem.FIELD_xxx, and .ctype for what to set that field to.
-
Your tutorial comes in handy, but now I have a new doubt.
Initially i had problems with the timing: the DRAY needs 1 frame to react, then it was copying the SPRK with .life=3, and the eletronics particles (I am supposing) expects .life=4 to work. Quickly I got the idea of energize the ARAY and the DRAY in the same time, after all both have 1 frame of delay. It's working, but only when the whole thing stays in the same line vertical or horizontal. If I put the ARAY perpendicular to DRAY (e.g. DRAY down and ARAY side INST), the INST is copied but no the SPRK. Unless I let the 1 frame delay, then the SPRK with .life=3 goes.
You could show me a way to make this work perpendicularly, or tell me why it does not work?Edited once by spoon. Last: 5th Jan 2015 -
Couldn't you just use DRAY to copy a BTRY to location where it would power a PSCN+CRAY to delete it? That's similar to how LightPC makes it's multi-input SPRK busses work, except it uses CRAY instead of DRAY. Also, the reason it doesn't work is likely a particle ID problem. These are much more common nowadays, what is likely happenning becuase DRAY is being simulated to copy over the INST before the INST is being SPRKed by whatever you have SPRKing it.
Edited once by mecha-man. Last: 5th Jan 2015 -
@mecha-man, this idea is very powerful! But I do not know exactly how to apply it. In my case, I'm checking the status of a SWCH within a reversible binary counter using a BRAY beam, and triggering a bidirectional bus on the outside.
Well, after a few hours of trying I found a workaround to DRAY, using PSCN to synchronize the DRAY and INST(SPRK) in front of it. For now it works, but is not fully deterministic, thanks to our particle ID problem. I cannot delete a INST and put another, because breaks it.
Edited once by spoon. Last: 5th Jan 2015
