Shouldn't be full. I have about 70 people, and I deleted a bunch a couple of days ago. Sure it's not that your list is full?
I've tried a couple things but the latency is still present I tried adding you but I think your list is full.
I don't know if you had any luck solving that, but I just made a post which might help clarify, here: http://www.lbpcentral.com/forums/sho...521#post705521
Well, in the experiment I did, I used a circuit node to connect the input and outpt internally, but I don't know if it's necessary. Also applies to the first one in the chain, so whatever triggers the enable port on the first chip (if different to the other chips) also needs to be fed into a regular input, otherwise you'll lose a frame between the initial trigger and the first chip becoming enabled. I think this counts as a bug. Tough bit is articulating it into something easily understandable on the bug report form.
Thanks Interesting to know. So I pretty much should just have a dummy line going through the whole chain?
Finally figured out latency problem. I was planning to write a more detail explanation later, but to summarize: any inputs at the bottom of a component (e.g. microchip enable, selector cycle) don't count as inputs when the component update order is determined. The latency you see is due to the components updating in the opposite order to which you'd like, so to force it the other way, each microchip must have an output which acts as a regular input to the next one in the chain.
So far, I haven't found any latency with microchips specificially. I'd be more inclined to say it's the chain of impact sensors, but I'm still not 100% on how you have it configured.
I think the microchip lag increases with each level of microchip... that's why the view appears to be drawn from close to far. Using the layer glitch I think I can get away with not needing recursion whatsoever, and it'd look pretty good to boot. But I don't know. I think I'm gonna stick to "dungeon crawler" variants in retail
Well, there's no apparent feedback in there, so it's tough to say. I tried adding you, but you seem to be too popular, but feel free to send a request my way.
The logic is extremely simple, I used to have cascading ANDs and NOTs in a single microchip but I narrowed it down to more or less this as on my blog: http://3.bp.blogspot.com/_Gdu0BF9bwl...0/RAYLOGIC.jpg In the dungeon crawler there are some more sensors, but it's still essentially a chain of those, canceling out further microchips if one hits a wall. I should go back and see if the single chip cascading method had that visible delay or not. I thought it was clever at the time and then this just seemed so beautifully simple, but there's that delay.
