Archive: 10 posts

---

This is probably a no-brainer, but I can't for the life of me figure out what to do here. I have a cut-scene showing a stationary obstacle, then it goes back to play mode, then you pull a switch, which in turn triggers another cut-scene showing the obstacle that is now moving because of the switch. My problem is that if I die by this obstacle, I will respawn at a checkpoint and as soon as I run across the player sensor again, it retriggers the cut-scenes, and I have to run through both the scenes before i can play through the obstacle again. This just repeats itself if I keep dying. Please help! I'm sure it's really one of those "duh" situations, and maybe it's the hours spent making this level that is just making my mind go blank.

2011-09-06 00:05:00 Author: InfiniteTwilight Posts: 159

---

Have you tried using a "destroyer" after the cutscene is done?

2011-09-06 01:31:00 Author: zzmorg82 Posts: 948

---

Yes, and for some reason it's not working. Maybe I'm placing it wrong?

2011-09-06 01:45:00 Author: InfiniteTwilight Posts: 159

---

If you want some logic to happen once and never be retriggered by subsequent passerby there are a few quick and reliable pieces that you can add to your microchip. The most basic is a two-input OR gate whose output loops around into its second input. If you connect your player sensor to the first input, it will trigger the OR gate when the player passes and the OR gate will then feed into itself and remain active forever. So if your OR gate's output connects to a non-looping sequencer, for example, it will start it playing once and then never again because the signal never stops and restarts. Just remember that if you trigger this setup in create mode you will have to rewind or manually reset the OR gate: otherwise it will never run your cutscene again! A similar solution is to have your player sensor trigger a port on a selector. Leave the first port of the selector empty as your default state and have the second port trigger your cutscene. Like the self-sustaining OR gate, this will only trigger the scene once because it doesn't turn off and on again. The player sensor will keep trying to reactivate the output that's already active to no effect.

2011-09-06 01:58:00 Author: Uncuddly Posts: 237

---

Thanks, Uncuddly. I'll try this later. You were helpful on another question I had, so I'm sure this will also turn out quite helpful

2011-09-06 02:07:00 Author: InfiniteTwilight Posts: 159

---

Similarly you could use a player sensor to trigger a counter (count up to 1) to trigger the cutscene. (player sensor ---> counter ---> cutscene) That's how I do it.

2011-09-06 02:08:00 Author: Unknown User

---

Maybe I'm placing it wrong? Place the Seqeuncer on a microchip and plce the destroyer on the same microchip, DO NOT PLACE THE DESTROYER ON THE SEQUENCER. And when the cutscene is about to end, place a battery on the very last stripe of the sequencer, hook it up to the destroyer and there you go. It may help if you place all this on a thin peice of invisible hologram.

2011-09-06 02:13:00 Author: zzmorg82 Posts: 948

---

DO NOT PLACE THE DESTROYER ON THE SEQUENCER. Hey that's right! I used to try that and it wouldn't work, which made no sense. Had to pop the destroyer on the object itself, outside the sequencer, but wired from inside the sequencer. The game plays by some weird rules sometimes.

2011-09-06 02:36:00 Author: Unknown User

---

You already have some great answers, but I just want to throw this out there for reference. In this case I would probably pick the counter like Arbiekko said. They're all fairly similar, but the counter is the easiest to spot as triggered during debugging and one of the simplest to reset. The selector would be almost identical functionally, but is less obvious when zoomed out. In a different scenario, the OR gate solution is the best. They both do essentially the same thing. The biggest difference would be that the counter introduces one frame of latency into the circuit. In the current situation that would be irrelevant because no one will ever even notice it. In a time critical circuit where things need to happen instantly, the OR gate solution has 0 latency and would be the best fit, even though it is less intuitive from a debugging standpoint. EDIT- This is just my opinion. Your mileage may vary.

2011-09-06 03:04:00 Author: tdarb Posts: 689

---

Everyone had really good advice, so I just chose one to try out and zzmorg82 is who's I went with. It was easy to set up and perfect! Also, it's true that you definitely want to use a piece of hologram material to place your chip on, because at first I had my microchip on the back thin layer and everything disappeared lol thanks guys for all the help!

2011-09-06 03:22:00 Author: InfiniteTwilight Posts: 159

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.