Archive: 20 posts

---

I'm having trouble with the timers... While for general use it's fine, for movers and rotators theres a very annoying bug that means the timer ends one frame short. It is definatly a problem with the timer, as the movers and rotators are 100% accurate when powered by a single pulse, but when I try to use a timer, they always end up 1 frame short. Given the maximum speeds this can mean a mover is upto 3 blocks out of position or a rotator can be as much as 50 degrees short. For small or quick movements this isnt an issue, as I can use a single pulse, but for movements longer than 1/30th of a second, or Smooth animations (pulse looks extremely jerky) i'm reliant on the timer, and they are just not accurate enough. Anyone found a workround/fix for this problem?

2011-02-13 23:12:00 Author: Unknown User

---

have you tried using a sequencer instead? Timers are mostly for adding delays and making events happen for a set duration. Sequencers are, well they are for sequencing things, and tend to do better when you need to synchronize timing as they offer much more control.

2011-02-13 23:23:00 Author: tdarb Posts: 689

---

I was having trouble with timers myself. I needed two bots to perform the same actions at exactly opposite times. Each had a timer set to 4 seconds to switch to the next behavior chip. They were both exactly the same and set to the exact right time to be opposite. But somehow everytime one bot would slowly and slowly catch up with the other bot and eventually they were doing the same thing instead of being opposite. I ended up just using 1 timer for both which is what I should have done to begin with. But I still don't understand how two identical timers can end up not takin the same amount of time.

2011-02-13 23:32:00 Author: Kitkasumass Posts: 494

---

have you tried using a sequencer instead? Timers are mostly for adding delays and making events happen for a set duration. Sequencers are, well they are for sequencing things, and tend to do better when you need to synchronize timing as they offer much more control. "Making events happen for a set duration" is EXACTLY what i am trying to do... and the timer is not accurate enough to do that... ive run test after test and its definatly missing the last frame of the timer. example.. using a 1 second count down timer, attached to a 360 speed rotator, leaves the rotator EXACTLY 12 degrees short. 360 / 30 (frames per second) = 12. you can tell its 12 degrees because you have to run the timer 30 times to get it to stop back at its original position.

2011-02-13 23:35:00 Author: Unknown User

---

I've no doubt that the timer is behaving oddly. The way I understood it, you are trying to synchronize movements. Anything that requires precision is better suited for a sequencer. What i meant by things happening for a set duration is maybe a fire burning for three seconds, or water falling briefly, or a cool down timer.

2011-02-13 23:51:00 Author: tdarb Posts: 689

---

While a sequencer does work, it adds further complications to the situation. if i set a the sequencer to a 1 second, and have a battery across the entire sequencer, the rotator never stops., the only solution is to have a gap both before and after the battery on the sequencer, this adds an unwanted pause to the smooth rotation i am trying to achieve.

2011-02-14 00:08:00 Author: Unknown User

---

...theres a very annoying bug that means the timer ends one frame short. Not always - see this post (https://lbpcentral.lbp-hub.com/index.php?t=47951-Guide-to-Speed-Rotation-and-length-units-in-LBP2-UPDATED-SOME-NEW-INFO&p=765993&viewfull=1#post765993) for more info. As for a workaround, you might be able to get away with chaining timers of smaller durations to get the correct number of frames, otherwise you'll probably need something like a pulse-generator and a counter to count out exactly the right number of frames.

2011-02-14 09:12:00 Author: Aya042 Posts: 2870

---

I'm thinking you should give the sequencer another chance. It's much more versatile: you can set each bar to only .1s but you can still divide the bar into thirds by using small batteries, so you could just add .033s (a single clock cycle) by extending the battery that much more. As for your problem with it never stopping, don't run the battery across its entire length. Leave a tiny bit of space at the end of the sequencer and stick another battery on that space and feed it into the sequencer's reset input.

2011-02-14 15:40:00 Author: Sehven Posts: 2188

---

You mentioned you tried pulses. But isn't a pulse defined as both an on and an off, which would be causing the jerky movements? If so, try sending a constant ON for the exact number of clock ticks you need (I use selectors to do it and you can even send patterns down the wire). I use these all the time, because I don't always need the time to be in increments of 3 ticks. This is what Aya042 is alluding to. BTW, I don't use sequencers because they have one tick of latency.

2011-02-14 15:55:00 Author: Shanghaidilly Posts: 153

---

I used a pulse to check that the trouble was with the timer and not the rotator., and its because of the jerky nature of using pulses that I would like to use a timer. but I cannot use a 1 second timer (or seemingly any multiple of a whole second) to run my mover when the timer is losing the last frame. I've published an example of the bug ( http://lbp.me/v/xtmmfk ) and as you can see if you run the level, if the timer is on the following times, it loses a frame : 0.5, 0.7, 1.0, 1.4, 1.5, 1.9, 2.0, 2.3, 2.5, 2.8, and 3.0 (got bored after setting 30 different timers) Currently the only workround is to choose a setting for the timer that works... but it would be nice if I didnt need to as this means I have to recalculate all my motions to account for a shorter or longer run time so instead of basing my movements on simple blocks and 360 degree rotations, i'm left doing a huge amount of math to get it to work properly. Again... using a sequencer doesn't work for the reasons I've already outlined previously, yes you can set it to run for a precise length of time, but the pause required both before and after in order for the rotator to stop leads to jerky pauses in the motion.

2011-02-14 17:40:00 Author: Unknown User

---

Ive published an example of the bug... I don't think it's a bug (see this post (https://lbpcentral.lbp-hub.com/index.php?t=47951-Guide-to-Speed-Rotation-and-length-units-in-LBP2-UPDATED-SOME-NEW-INFO&p=765993&viewfull=1#post765993)) but a workaround for reset latency to ensure self-resetting timers remain in sync.

2011-02-14 17:57:00 Author: Aya042 Posts: 2870

---

i used a pulse to check that the trouble was with the timer and not the rotator., and its because of the jerky nature of using pulses that i would like to use a timer. but i cannot use a 1 second timer (or seemingly any multiple of a whole second) to run my mover as the timer is losing the last frame. Ive published an example of the bug ( http://lbp.me/v/xtmmfk ) and as you can see when you run the level, if the timer is on the following times, it loses a frame : 0.5, 0.7, 1.0, 1.4, 1.5, 1.9, 2.0, 2.3, 2.5, 2.8, and 3.0 (got bored after setting 30 different timers) currently the only possible workround is to choose a setting for the timer that works... but it would be nice if i didnt need to. You're still confusing pulses with a constant ON for a number of clock ticks. Pulses have OFF's in them, which is why you get jerky behavior. But what if I told you you could create your own timer that works just like the built in ones except it works off the number of clock ticks? Selectors have a couple very neat attributes. First, they have no latency selecting the port you hook your input into. Second, if you hook the output of your port into the input of another port on the selector, this selection incurs one frame of latency. So let's say you set up a selector with 6 ports. Your input goes into the second port, the output of that port goes into the third. The output of the third goes into the fourth, etc. until you reach the sixth port. The output from that port goes into the first port. Take the output of the first and send it to a permanent switch (a counter set to one will work) and then hook that to a light bulb. If you apply a single tick of ON to your input, you'll see the bulb turn on in exactly 5 clock ticks (.165 sec.). From the time you send the pulse - Port 2 takes no time to be selected Port 3 takes one tick to be selected Port 4 takes two ticks to be selected Port 5 takes three ticks to be selected Port 6 takes four ticks to be selected Port 1 takes five ticks to be selected (the counter takes no time, so it's on within the same clock tick). Selectors have another neat attribute. If you loop the ports together as I described, and then leave the input ON for longer than it takes to reach the top port, then it will repeat itself. WHY is this important? Now you can use two counters, an AND gate, a NOT gate, and a two port selector to create your own timer that works off of clock ticks without the rounding problem you found in the built in timers. Take a two port selector and hook your input into a NOT gate and a counter set to one. Hook the NOT gate to the reset port of this same counter. Hook the output of this counter to the second port of the selector and the reset of a second counter. Hook the selector's second port's output into the input of the first port on the same selector. Also, hook the output of the second port into the second counter. Hook the output of the first port into an AND gate as well as the output of the second counter. Hook the output of the AND gate to whatever you're trying to turn on. Whatever you set the second counter's number to will be the number of clock ticks from the time you send your input until it stays on.

2011-02-14 18:29:00 Author: Shanghaidilly Posts: 153

---

Google would like to argue with you Aya... if you type "define: bug" you get the answer "a fault or defect in a computer program, system, or machine" and a timer losing 1 frame 11 out of 30 times seems like a bug to me.

2011-02-14 18:30:00 Author: Unknown User

---

if you type "define: bug" you get the answer "a fault or defect in a computer program, system, or machine" and a timer losing 1 frame 11 out of 30 times seems like a bug to me. But who's to say it's a "fault" or "defect"? If MM's design specification was written such that a one-second timer should only be active for 29 frames, then it's to-spec, and therefore not a bug. It's irritating perhaps, but is it more or less irritating than having your self-resetting timer go out of sync by 1 second every 30?

2011-02-14 18:41:00 Author: Aya042 Posts: 2870

---

I am not confusing pulses with anything... I define a pulse as a single frame of activation, as obtained by either a self resetting counter, a self resetting count down timer, or a Not Astable. it was used to generate a precise single frame of motion and was used to identify that the movers were not the cause of the problems I was, and still am having... the problem is with the timer, which on specific timer settings (rather annoyingly on every half or whole second) loses a single frame of activation at the end of its cycle. which in turn leads to ANY mover or rotator being controlled by that timer to fail to position itself correctly.

2011-02-14 18:49:00 Author: Unknown User

---

I am not confusing pulses with anything... I define a pulse as a single frame of activation, as obtained by either a self resetting counter, a self resetting count down timer, or a Not Astable. it was used to generate a precise single frame of motion and was used to identify that the movers were not the cause of the problems I was, and still am having... the problem is with the timer, which on specific timer settings (rather annoyingly on every half or whole second) loses a single frame of activation at the end of its cycle. which in turn leads to ANY mover or rotator being controlled by that timer to fail to position itself correctly. And I understand that. What I was referring to was when you said you tried to use pulses and it resulted in jerky behavior. My point (and the solution I provided) is that you can send the precise number of frames without using a timer AND get smooth response. Sorry for the confusion.

2011-02-14 18:53:00 Author: Shanghaidilly Posts: 153

---

But who's to say it's a "fault" or "defect"? If MM's design specification was written such that a one-second timer should only be active for 29 frames, then it's to-spec, and therefore not a bug. It's irritating perhaps, but is it more or less irritating than having your self-resetting timer go out of sync by 1 second every 30? if it is MMs specification for the timer to only use 29 frames, then the BUG! is even worse, as the timer OVERRUNS by 1 frame 19 times out of 30... The point of the post is, there is a BUG! whereby a timer is 1/30th of a second OUT for various times run. this makes it difficult to use them efficiently for controling movers and rotators... having to build elaborate and complex timers yourself in order for the game to work properly is counter productive. having to calculate motions and rotations to account for not being able to use a set timer is counter productive. you SHOULD be able to just say "I want to turn that block by 90 degrees... and i want it to take 2 seconds..." if the timer worked properly this would be extremely simple. you set the timer to 2 seconds, you set the rotator to 45, and your done. with the BUG! in the game the closest time that works correctly is 2.1 seconds... meaning you need to set your rotator to 42.857 degrees. which is impossible to do, meaning your rotation and any subsequent motion of that block is out by nearly a whole degree. with the BUG! in the game, you not only have to limit your motions to limited timescales, but you are further hampered by the limitations of the movers themselves.

2011-02-14 19:19:00 Author: Unknown User

---

if it is MMs specification for the timer to only use 29 frames, then the BUG! is even worse, as the timer OVERRUNS by 1 frame 19 times out of 30... Call it what you will (feature, quirk, misfeature, bug, elephant), but I wouldn't expect a 'fix' to be forthcoming. Now the behaviour has been defined, any attempt to change it will cause failures in levels which rely on its behaviour, and MM are unlikely to (deliberately) change anything which will break the functionality of published levels. So no matter how many times you use the word "BUG!" you're just gonna have to deal with it.

2011-02-14 19:47:00 Author: Aya042 Posts: 2870

---

Call it what you will (feature, quirk, misfeature, bug, elephant), but I wouldn't expect a 'fix' to be forthcoming. Now the behaviour has been defined, any attempt to change it will cause failures in levels which rely on its behaviour, and MM are unlikely to (deliberately) change anything which will break the functionality of published levels. So no matter how many times you use the word "BUG!" you're just gonna have to deal with it. Agreed. And Morelyn, if you really didn't want help, you should have posted this here (https://lbpcentral.lbp-hub.com/index.php?t=44678-Lbp2-bugs-list)

2011-02-14 19:51:00 Author: Shanghaidilly Posts: 153

---

Take a two port selector and hook your input into a NOT gate and a counter set to one. Hook the NOT gate to the reset port of this same counter. Hook the output of this counter to the second port of the selector and the reset of a second counter. Hook the selector's second port's output into the input of the first port on the same selector. Also, hook the output of the second port into the second counter. Hook the output of the first port into an AND gate as well as the output of the second counter. Hook the output of the AND gate to whatever you're trying to turn on. Whatever you set the second counter's number to will be the number of clock ticks from the time you send your input until it stays on. tried to build this as described and it doesn't work. with a static input, the input holds the selector on the second output, instead of cycling as your 6 port example does. 30554 and Aya... repeatedly posting links to your own posts, that in no way help or provide any insight into the problem does not constitute help. Would you throw a "How to Swim DVD" to a drowning man?

2011-02-15 02:29:00 Author: Unknown User

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.