HMW wrote:
That's an interesting approach. Perhaps I'll look into that some time, it may be useful for other things. (Say, running bspzip automatically to embed custom content...)
Heh, nice idea. It would be nice if VBSP had a Pakrat style auto scan, or Pakrat took command line options. I suppose you could just ram it all in a batch file and add a new build step in hammer though 
HMW wrote:
On the subject of logic gates: I fixed them so they can be connected in a loop. Now you can make memory circuits and stuff. Like this.
That's awesome! It looks a bit like those educational circuit boards you get in highschool physics, but does away with any ambiguity. Might have to borrow those instances =) (I do so hate indicator lights...)
HMW wrote:
Man Love.
Indeed.
HMW wrote:
There is still one problem with the XOR gate that I don't know how to solve yet. It sometimes starts out activated even though it shouldn't, and then it keeps operating in reverse.
From what I gather you seem to have the final truth table value routed through a system like:
//Logic branch: Output_Normal
OnTrue, Return True
OnFalse, Return False
//Logic branch: Output_Inverted
OnTrue, Return False
OnFalse, Return True
Then based on your $start_enabled, kill either Output_Normal or Output_Inverted.
If I remember right, killing an object can take upto the next frame to actually process. (So at the start for example, both output states may be competing, and an XOR linked to any kind of toggle might have a 50/50 chance of being inverted based on which was active at the time. ) I tried to think through a bunch of solutions:
-Use a logic branch listener instead: Fairly automatic, your truth table is only 3 lines for 2 inputs and they update even when an object is killed saving you a little IO.
-Have an AND gate at the end. One input is your truth table value, the other is an OnMapSpawn, SetValue, 1 with a delay of 0.5
-Just give the user a NOT\NAND gate.
But in all of those cases the one problem seems to be anything that uses a toggle, or which will only trigger one time based on a value of 1.
(I.e. an exit door that stays open, or a panel that's supposed to stay up).
All I can suggest is instead of the current system, just make sure every gate is defaulted to their no input state, and doesn't use any form of toggle. For the end of any chain where the output should be inverted but only triggered once, make a small gate that is like a timed AND, so that it won't fire the wrong output untill your gate chain has had a chance to filter through the appropriate values.
Then again, I could easily have misunderstood the whole thing and just wrote a bunch of nonsense 