Archive: 13 posts

---

Hi, I have some very precise logic that triggers on a per-frame basis. It works fine in Create mode, but when I go into Play, it doesn't trigger! I can't easily go into detail about the logic specifics, but in a nutshell it involves receiving a key signal and returning one within the same frame. The level is a 2D puzzle game where the player controls a box that moves 1 big grid space per frame, and the part that breaks is when it passes over a wedge deflector which changes its direction of movement. Works like a charm in Create; it instantly changes direction with no movement latency. In Play, the player's box just passes straight through the deflector. I'm dreading that this is some inconsistency in the time it takes for sensors to pick up/output their information. Does anyone have any experience with this? Or, can anyone suggest things that would cause a difference in behaviour between Create and Play? I may have overlooked something.

2012-08-14 00:27:00 Author: merkaba48 Posts: 79

---

There is probably a bit of lag involved, especially when trying to time things that exact. I've had to purposely buffer events in the past to make sure they happen in the correct order, even though it meant slowing down the gameplay a tad.

2012-08-14 01:11:00 Author: Brannayen Posts: 438

---

Why don't you show us your logic? There could be an alternate method to doing your logic which would avoid the problem altogether.

2012-08-14 03:44:00 Author: BIGGamerer Posts: 182

---

It's best to avoid very exact events in any level, since any amount of lag will ruin the effect. The problem appears to be that frames that are missed due to lag are skipped / rapidly occur, messing up any per-frame logic since it relies on each frame running in unison. Try using countdown timers at 0.1s instead of self resetting /1 counters (or whatever it is you are using for single frame activations). Could you explain why it 'needs' to work on a per-frame basis? Could you delay each grid movement, or make it slower? If it's a matter of preventing movement beyond a certain point, why not disable movement in that direction using some simple bounding box logic (inverted impact sensor (tag) AND movement signal to mover, contact deactivates AND) You could also try using an antigrav at 100% damp (pulse using countdown timer 0.1s), then continue on its way.

2012-08-14 04:00:00 Author: SSTAGG1 Posts: 1136

---

if you are not using the distance based analog value of the sensor it's best to set the sensor to signal strength as this can often fix sensor latency issues

2012-08-14 08:59:00 Author: evret Posts: 612

---

if you are not using the distance based analog value of the sensor it's best to set the sensor to signal strength as this can often fix sensor latency issues Thanks, that's the kind of solution I was hoping to explore. I'll give it a go when I get home. If that doesn't work, I'll try posting up my logic after simplifying it.

2012-08-14 13:30:00 Author: merkaba48 Posts: 79

---

It's best to avoid very exact events in any level, since any amount of lag will ruin the effect. The problem appears to be that frames that are missed due to lag are skipped / rapidly occur, messing up any per-frame logic since it relies on each frame running in unison. I may be wrong, but in my experience LBP never skips frames (at least in single player), but rather just slows down. I've never observed in multiplayer, but my level is single-player only so I'm not concerned about that. However, I've only ever developed by myself and tested by myself, and don't play multiplayer much at all in LBP...so I may be quite wrong here :-)

2012-08-14 13:41:00 Author: merkaba48 Posts: 79

---

That really only applies to multiplayer. Say you have an emitter, sound effect, and counter all tied to a single 1-frame pulse. With more than one player and lag, some or all of the components will fail, but the signal will still appear to be sent (eg: sound will activate, emitter and counter will not).

2012-08-14 14:57:00 Author: SSTAGG1 Posts: 1136

---

That really only applies to multiplayer. Say you have an emitter, sound effect, and counter all tied to a single 1-frame pulse. With more than one player and lag, some or all of the components will fail, but the signal will still appear to be sent (eg: sound will activate, emitter and counter will not). Is there a way to guarantee that a map is only played in single player? I don't want the level to break because people try connecting with friends and have it start introducing lag.

2012-08-14 15:34:00 Author: merkaba48 Posts: 79

---

MAKE A HUUUUGE SIGN IN THE DESCRIPTION IN CAPITAL LETTERS. It usually works

2012-08-14 18:13:00 Author: Unknown User

---

You can also include logic to end the level if more than one player is in it.

2012-08-14 20:39:00 Author: BIGGamerer Posts: 182

---

You can also include logic to end the level if more than one player is in it. I was about to start a thread asking the best way to exclude extra players from gameplay in single player levels, but you've saved me the bother now. Good idea...don't even allow the level to begin unless they leave...I like it.

2012-08-14 22:58:00 Author: Ungreth Posts: 2130

---

Hi, thanks to all for the replies! The signal strength was a good tip, though didn't fix my problem. Did you know setting a sensor to signal strength means it activates closer to the edge of its radius than when set to distance strength? Weird. Anyhoo, my problem boiled down to some baffling decision of mine to turn a deflecting key (the trigger that actually results in a direction change) off if the box was in the same space as the wedge. Quite how this EVER worked, I have no idea, but it did in Create. Perhaps I had done it to work around some other bug...I've been working on/off this level for 18 months now, so anything is possible. So the weird thing is that it worked in Create but not in Play. In create, the key would trigger something in the box BEFORE it was switched off in that frame, whereas in play, it would be swiched off BEFORE triggering the box sensor. At this point I'm thinking it's something very low level in the code of the game that just gets ordered slightly different depending on the game mode it's in. Anyway, it works now, so my investigation is over. I'm just hoping there wasn't a good reason why I made that key turn on/off.

2012-08-14 23:23:00 Author: merkaba48 Posts: 79

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.