Archive: 15 posts

---

(I was debating between putting this in tutorials or in this part, if the mods think it needs to be moved, then I am fine with that.) I was building an add-on for pivottt's Health Meter Toolkit quite a while back, but it was doing some of the math too fast, which broke the system. I eventually just extended the wire through more chips, and it worked just fine. After telling pivottt that the extra chips caused enough lag to delay some math, he tried to say I was wrong, and continued to try to take the wire out of the extra chips, which broke the chip again. I was able to fix the chip once more, and all I did was create a 1-frame delay. He kept saying it shouldn't do that, and that the chips do not create lag. That was a few months ago, but today while building a level, I had the opportunity to actually watch the chip cause a delay of about 1-frame. After seeing that lag first hand, I continued to keep trying to take a picture of it, and I got it. 39281 You can see here that the wire outside of the chip is on, but not the one inside. This proves my whole microchip lag theory, which seemed unlikely, but it is now proven.

2012-03-23 18:49:00 Author: fly_4_a_jedi Posts: 151

---

I haven't been keeping up with the tech lately, but I've seen microchip lag a lot, at least in relation to the bottom input. It might even be intentional. Also, there was a workaround. IIRC you had to run the input wired to the bottom into the side of the chip as well. Maybe there's a workaround for your situation as well.

2012-03-24 15:33:00 Author: Rogar Posts: 2284

---

It is not broken, and I am not asking for help. Also nothing is in the bottom. All I am doing is showing that it is there indeed a lag, which caused a math problem to be delayed, I just didn't have proof until now. This may be the cause of something else I discovered relating to microchips quite a while ago. I found out when building a level for LBPC 2 that if you have too many microchips inside of one thing it will lag a lot. I went from having only one player in a level at a time with lag, to 4 players without lag. The fix was just putting all logic on the main part of the controlinator, instead of sorting it all into microchips. You receive lag while moving logic, but not while playing. Other players have called this chipception.

2012-03-24 15:50:00 Author: fly_4_a_jedi Posts: 151

---

I can see it's not the bottom but a side input. What I mean is if you can isolate the exact cause of the lag, you might be able to find a workaround that still lets you use chips within chips (they are rather convenient, after all).

2012-03-24 16:03:00 Author: Rogar Posts: 2284

---

It is not breaking anything, it causes about a one frame delay on a heal, which is constant anyways so it can have that delay since if all heals are one frame off, then all heals are the same distance apart. The only thing that is possibly causing the lag is the chip, when a wire is turned on outside, then it should be inside as well. This post is not asking for help (it was this or tutorials, but not help) I was just posting it as something for creators to watch out for. It may be caused by a wire going through too many chips, but in the end I started to color code the main chip on all levels anyways, so it may not happen when I am done.

2012-03-24 16:14:00 Author: fly_4_a_jedi Posts: 151

---

When I placed 1000 microchips in series there was no signal delay. How do you explain this? What you have there is either a rendering issue or something else causing problems. If you want to prove otherwise you need to provide steps to reliably replicate the problem or place the offending logic in a copyable level so it can be scrutinised.

2012-03-24 17:40:00 Author: Ayneh Posts: 2454

---

When I placed 1000 microchips in series there was no signal delay. How do you explain this? !!!?? As a Serious Chip Addiction Syndrome??!!! j/k : P

2012-03-24 17:51:00 Author: zupaton Posts: 167

---

Both times this occurred it was a counter set to pulse that was sending the signal if that helps. I can not be on lbp right now, but if it was just a rendering issue, then it would not happen every time I would think. I took the pic while the game was unpaused, and just kept snapping until it got the pic, but it lagged every time, not just once. I can not think of why it does it I would say a bug, but it has happened twice now, and the projects were unrelated.. EDIT: I know it is not the thing the pulse is being inputed to, because it happens before that is turned on. I think the pulse leaves a chip, then enters one or two others.

2012-03-24 17:56:00 Author: fly_4_a_jedi Posts: 151

---

Sorry for DP, but I want to make sure the others see this. After working with the chips, I have rebuilt them all, and after copying the setup I had, the problem was still inside. I then tried to rebuild the setup (this was copying the same logic, and just put it in blank microchips) and it is gone... Thanks for replying, but I do not know how to rebuild this problem, instead redoing it fixed it.

2012-03-25 01:07:00 Author: fly_4_a_jedi Posts: 151

---

Oh well, at least we know it's fixable. Maybe it has something to do with the order in which you place components.

2012-03-25 12:46:00 Author: Rogar Posts: 2284

---

I literally just selected all of the stuff in the chip, and L3 copied it. The chip position did not matter, it just needed to be replaced possibly.

2012-03-25 17:09:00 Author: fly_4_a_jedi Posts: 151

---

Microchips definitely can introduce latency, but they don't always. From my (limited) experimentation, signals generally won't lag if they simply enter or exit a chip, but they will if they exit and then re-enter the same chip. I've actually made use of this to build a deceleration sensor, looping a signal through a pair of chips a few times to introduce a few frames of latency, then comparing the current signal with the delayed signal. If you copied a chip and the lag problem went away, that's probably because when you copy or move a chip the game collapses unneeded inputs and outputs. For example, wire the output of a chip back to its own input, then select the chip and move it, and you'll see the output and input disappear to be replaced with an internal (on-chip) wire.

2012-03-28 09:50:00 Author: Dr C Posts: 122

---

After copying the logic onto a new chip, I put it back in the same loop, just too see if it was that loop, which means I reconnected every input/output to the original places, and it was still gone. I don't know why but this does happen quite often for me

2012-03-29 03:26:00 Author: fly_4_a_jedi Posts: 151

---

I've run into the problem before. I had logic that theoretically should've cut the signal before it got to a certain point, but the cut off was lagged a bit, so the signal was getting through and giving me funky results. I had Aya look at it for me and he explained.... something... I didn't really get it as it was from the perspective of somebody who understands actual programming. Anyway, I solved it by adding a 1 frame delay to the signal's throughput (can't remember exactly how I did it--this was well over a year ago) so the cutoff would have a chance to kill it before it got through. Interestingly, there were four of these circuits (they were identical) on the chip and only two of them suffered from the problem (I added the delay into all four, though, just to be sure). Not sure if that helps, but it is a semi-well-known issue among some of the hardcore logic people.

2012-03-31 23:56:00 Author: Sehven Posts: 2188

---

I had Aya look at it for me and he explained.... something... Howdy, stranger. I'll leave this quote from the beta forums here... To answer the question "where is latency deliberately inserted?", the answer is "nowhere". Any latency you see is due to the order in which the components' states are re-evaluated on each simulation frame. Each wire can only change state once per simulation frame, so if the components aren't updated in the 'logical' order, then your circuit may take several simulation frames to reach a stable state. The update order is based on the connections between components, so if component A's output is an input for component B, then component A's state will always be re-evaluated before component B's. Where a circuit has feedback, there may be no re-evaluation order which is 'logical' for every possible state transition, so some transitions may show latency. However, there exists what is arguably a bug with the system, which is that some components' inputs on the bottom of the component (such as microchip activate, and selector cycle) don't actually count as dependent connections when the update order is being determined, which is why there is apparent latency in both my selector-based ripple counter, and Foofles' microchip activation cascade circuit, but there is a workaround. Where you're feeding components via one of these problematic inputs, simply create an additional connection between the two components via one of the inputs on the left-hand side of the component, and the re-evaluation order is adjusted to remove the latency. Since then, it's been generally accepted that you always lose one frame on a positional sequencer's input - no workarounds for that so far.

2012-04-01 17:46:00 Author: Aya042 Posts: 2870

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.