Archive: 11 posts

---

I was wondering if there is a way to make sackboys, after they die, enter the same controlinator as they used before. Because I want to make the players be able to use their popits. But if someone presses the 'Try again' button, I have to make sure he automatically enters his controlinator again, bacause the whole game is played in controlinators. The problem is that I fear that when, for example, you're playing with two players and one of them pops, he might accidentally take control of one of the other controlinators instead of his. I thought maybe someone here could help me with this. Do any of you have any suggestions? Thanks

2011-08-31 19:12:00 Author: Unknown User

---

On the first/main controllinator, wire the Active signal (which is mapped to the PS button) to a NOT gate and send that signal to the Player Eject Input of the 2nd controllinator. Now repeat this - invert the active signal of the 2nd (using a NOT gate as described earlier) and wire it to the Eject of the third, then wire the third to eject the fourth. The fourth you can just leave as is. So now... only the 1st controllinator will be usable with one player. Once a player enters it, the second will become available, and so on. Works for any number of 1-4 players. Now... This technique (thanks comphermc!) will work to ensure that the same 1-3 controllinators are used, but if two players were to "Try-Again" at the same time, it is conceivably possible that they might swap controllinators. I'd have to test. But I think the odds of it happening are rare enough to not be of any real concern. Hope this helps!

2011-08-31 22:21:00 Author: v0rtex Posts: 1878

---

Why pop players in the first place? Why not keep track of tries/lives with ones own logic so each player can stay in his DCS? And if you do need that effect of a player dying while in a DCS, stick a sackbot dummy in a DCS, have him belong to a player, copy its looks and follow that player; then blow up this DCS when a player is supposed to 'die' and emit a new one.

2011-09-01 09:24:00 Author: Antikris Posts: 1340

---

That was very helpful! Thank you, v0rtex.

2011-09-01 15:47:00 Author: Unknown User

---

Why pop players in the first place? Why not keep track of tries/lives with ones own logic so each player can stay in his DCS? And if you do need that effect of a player dying while in a DCS, stick a sackbot dummy in a DCS, have him belong to a player, copy its looks and follow that player; then blow up this DCS when a player is supposed to 'die' and emit a new one. It's not so that I want people to kill themselves. I just want to allow them to use stickers. But if they can use their popit, someone can try to pop himself, which would cause problems. I just want to be prepared for everything. I don't know why anyone would want to 'Try-again', but I need to ensure that no problems occur if someone would. Thanks for the tip, anyway.

2011-09-01 15:59:00 Author: Unknown User

---

On the first/main controllinator, wire the Active signal (which is mapped to the PS button) to a NOT gate and send that signal to the Player Eject Input of the 2nd controllinator. Now repeat this - invert the active signal of the 2nd (using a NOT gate as described earlier) and wire it to the Eject of the third, then wire the third to eject the fourth. The fourth you can just leave as is. While this idea is nice, if you are going to include it as a fail-safe, you better make sure it actually works properly, and this approach won't do that without additional logic... Try to imagine what will happen to any other seated players if the player in seat 1 chooses to pop him/herself? EDIT: I'd instead use four separate Player Sensors (Require 1, 2, 3 and 4 Players) to determine which seats should be active. This way you won't have the potential eject-chain-reaction if a player chooses to pop.

2011-09-01 16:11:00 Author: Slaeden-Bob Posts: 605

---

While this idea is nice, if you are going to include it as a fail-safe, you better make sure it actually works properly, and this approach won't do that without additional logic... Try to imagine what will happen to any other seated players if the player in seat 1 chooses to pop him/herself? EDIT: I'd instead use four separate Player Sensors (Require 1, 2, 3 and 4 Players) to determine which seats should be active. This way you won't have the potential eject-chain-reaction if a player chooses to pop. Good point. I tried it out and indeed, it didn't work. So I hooked up the active signal of the second controlinator to the 'activate' input of a microship in the first controlinator, which contained the NOT-gate we spoke about earlier. That way, the NOT-gate on the first controlinator wasn't able to transfer its signal to eject the second player. I did the same for the 2nd and the 3rd, and the 3rd and the 4th controlinator. I tested it with 2 players and it worked good. They sometimes do swap controlinators when they pop at the same time, though. I don't really get the Player Sensor-bit. Pretend the first person out of three pops. Won't the Player Sensors detect the remaining two as the first two and therefore think the respawning sack is the third player?

2011-09-01 17:45:00 Author: Unknown User

---

I don't really get the Player Sensor-bit. Pretend the first person out of three pops. Won't the Player Sensors detect the remaining two as the first two and therefore think the respawning sack is the third player? Very true! I'm sorry, but I already have my mind adjusted to the "Detect Unspawned Players" of the Move-Pack I never thought of using Microchips inside the seats - Very clever!

2011-09-01 18:26:00 Author: Slaeden-Bob Posts: 605

---

While this idea is nice, if you are going to include it as a fail-safe, you better make sure it actually works properly, and this approach won't do that without additional logic... Try to imagine what will happen to any other seated players if the player in seat 1 chooses to pop him/herself? EDIT: I'd instead use four separate Player Sensors (Require 1, 2, 3 and 4 Players) to determine which seats should be active. This way you won't have the potential eject-chain-reaction if a player chooses to pop. Ah - good point. I hadn't thought of that. I use it with no regard for whether they try again. I may have to have a look at mine to be sure I'm not leaving myself in a similar situation. Good point. I tried it out and indeed, it didn't work. So I hooked up the active signal of the second controlinator to the 'activate' input of a microship in the first controlinator, which contained the NOT-gate we spoke about earlier. That way, the NOT-gate on the first controlinator wasn't able to transfer its signal to eject the second player. I did the same for the 2nd and the 3rd, and the 3rd and the 4th controlinator. I tested it with 2 players and it worked good. They sometimes do swap controlinators when they pop at the same time, though. Very clever.

2011-09-02 02:18:00 Author: v0rtex Posts: 1878

---

A very informative post. Thanks for presenting your dilemma marne13, and to v0rtex2002 and Slaeden-Bob for providing the responses that helped determine a workable solution. One of the reasons I love this site.

2011-09-02 03:39:00 Author: RickRock_777 Posts: 1567

---

I'm having this issue too, only I'm trying to have a player counter (comphermc's version) detect which seats should be available out of 4, Then transport the players to 4 brand new DCS's at 5000 radius (teleporter style) for a multiplayer minigame. I've got the nots set up based on the wireless positional sequencers on both sets of 4 seats (first & last group) In short, it works, but the players are out of order when they teleport (because the second player detector is already ready to accept 'x' number of seats for the teleportarion group before you get there)... I guess my question is can you add a 0.1 second delay to your not logic to allow for ordered ejection without the players shuffling to each adjacent seat all the way down to the 4th one? Need some expert analysis here, or someone to simplify what I'm trying to accomplish... Thanks! UPDATE: I think I'll just stick to not gate logic... it should work well enough. It's probably not necessary to remove each player from their seat one at a time (I just realized I'd have to count backwards from 4 to 1 anyways!)

2011-09-04 16:45: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.