Archive: 12 posts

---

Well, I'm trying to make a character select screen for one of my levels and I'm having problems.. Here's my setup: http://i270.photobucket.com/albums/jj105/Giygas12/APhoto.jpg http://i270.photobucket.com/albums/jj105/Giygas12/APhoto_2.jpg http://i270.photobucket.com/albums/jj105/Giygas12/APhoto_1.jpg And while I have it where, when the player presses X/Cross on the selection he's chosen, it confirms it, but he can still select another choice.(and move around the cursor.) I have deconfirmation set up to the O/Circle, but.. How can I fix this issue, where the player can only select one choice, unless he deconfirms it?

2011-06-17 01:43:00 Author: Unknown User

---

http://i270.photobucket.com/albums/jj105/Giygas12/APhoto.jpg Single-port XOR gates as buffers o_o; Couldn't you just stick that stage of logic in a microchip and activate it with O and deactivate it with X using a two-port selector? It's pretty barbaric but it's the first thing that comes to mind. You basically just want to block the player inputting any new commands after their first one unless they press O.

2011-06-17 03:14:00 Author: Ayneh Posts: 2454

---

I was experimenting with the available logic--; Yes, I basically I don't want the player making multiple choices, if they've already made a choice. (In a sense, if the player has chosen a character, they can't move the cursor around or anything, unless they cancel their decision with O) I tried following SilverScorp91's tutorial, but since the AND gates were screwing up(SilverScorp91's tutorial was for the beta), by activating three cursors, instead of one, I decided to use XOR gates, instead, but now I'm stuck with this problem. But, I know this won't be it. Because I'm planning on making this level 2-Player.

2011-06-17 03:53:00 Author: Unknown User

---

Single-port XOR gates as buffers o_o; Couldn't you just stick that stage of logic in a microchip and activate it with O and deactivate it with X using a two-port selector? It's pretty barbaric but it's the first thing that comes to mind. You basically just want to block the player inputting any new commands after their first one unless they press O. I think Ayneh had the buttons backwards, but that's a good approach. I would take it a step further. You could run the directional buttons (that can control which character you are trying to select) to two AND gates before getting to the direction splitter that divides up/down and left/right. The other input of the AND gates will be a one shot counter that's reset by the X button and activated by the O button (by default, the counter will be set to max value of 1 and current value of 1). This way the player won't be able to move the cursor once a selection is made, but if they press circle, it will move again.

2011-06-17 04:09:00 Author: shane_danger Posts: 283

---

I think Ayneh had the buttons backwards No, X needs to deactivate the microchip to block further player input (the necessary frame or more of latency aside). O enables the microchip which allows the inner components to receive input if the player decides to change their mind. This isn't obvious?

2011-06-17 04:44:00 Author: Ayneh Posts: 2454

---

Howcome you are not using 3 selectors with 3 gates each? One selector for each row. You then wire each selector's #3 gate to an inverted OR gate and hook that up to an AND gate. Split your controller signal and wire the horizontal + bit into the same AND. Its output goes into a directional combiner (+) in front of the cycle input of each selector. You do the same for gate #1 of all selectors combined with the horizontal - signal, into the - input of the combiner. That accounts for horizontal movement. Vertical movement is pretty simple too: you use a 4th selector, 3 gates, that represents the rows; similar to the horizontal confinement logic above, you now apply that to the vertical signal. Each output of this selector activates a separate microchip that hosts the selector that represents each row (the ones from the first paragraph). If you stick self-resetting 1-shot counters in between the splitted controller signals, then the player have to let go of the buttons to move step by step (and he will be able to actually select the middle options). Hitting X will simply toggle a toggle switch; have this switch led to two AND gates and stick the vertical and horizontal controller signals before split into there as well, so that when the toggle switch is off no controller signal gets through to the rest of the logic. The currently selected grid block will however still be lit up. If you want to switch to ON by cross and to off using circle, use a 1-shot counter instead of a toggle switch; X sets it, O resets it. Duplicate this logic for each player, think hard about how you display a selection (I'd use a player colored cursor box) and there you go. EDIT: you can even opt for making the cursor holo material and set its OFF state to player color but less bright. Hook the toggle switch (or 1-shot counter) to the cursor. Now player can see the difference between a movable cursor and one that is stuck after a selection has been made.

2011-06-17 12:18:00 Author: Antikris Posts: 1340

---

I was originally following SilverScorp91's tutorial, except I decided on using the XOR, since the AND gates were screwing things up. Now I've run into another road block, but let me get on my PS3 later, take a picture and then post it on here.

2011-06-17 18:15:00 Author: Unknown User

---

No, X needs to deactivate the microchip to block further player input (the necessary frame or more of latency aside). O enables the microchip which allows the inner components to receive input if the player decides to change their mind. This isn't obvious? I think I just misunderstood your post because of how you worded it... assuming that the player would push X before they would need or be able to push O... no need to get upset. In fact, right after I said that, I described something very similar as a means to disable the controls.. I was originally following SilverScorp91's tutorial, except I decided on using the XOR, since the AND gates were screwing things up. Now I've run into another road block, but let me get on my PS3 later, take a picture and then post it on here. Hey Saohc, why not invite one of us to help out? It's easier and faster than deciphering pictures.

2011-06-17 18:16:00 Author: shane_danger Posts: 283

---

Okay, then. I'll add you guys on PSN. Or you can just send a friend request.

2011-06-17 18:35:00 Author: Unknown User

---

Alright, now while shane_danger helped me out with that issue and got it mostly set up for 2 players... I have a few problems and such. First off, I want to add something, that triggers when both players select their desired character. In terms, a "Yes/No" sorta of object. If the first player selects "Yes", the controlinators are destroyed and they're teleported to the checkpoint, where their character is. "No" is self-explantory, as it doesn't change anything and it doesn't destroy the controlinators and the players can choose a different choice. Second of all, this is a bit cosmetic, but.. i want the players to go to their respective checkpoints, but end up in the sackbots already, but I want the checkpoint to be hidden somehow. How can I do so? Finally, the sackbots(or characters) are going to have three lives, in a sense, but how can I make it, when the Sackbot is destroyed, the player reappears at the checkpoint, but with a new sackbot? I'm planning on adding tanks, but I want to limit things, to where you can only summon one tank at a time and you can only summon the tank three times. Now another issue is, that with the way, the sackbots are set up, if they get killed by paintinator shots, both the sackbot and controlinator(which is on a hologram with Destroyers on it) are destroyed. But if for example, the sackbot is crushed by, in this case, a moving tank.. The sackbot dies, but yet the controlinator isn't destroyed(which makes some sense). How can I fix this issue? I would like to prevent the players from choosing the same character, but me and shane_danger can fix this right up. and I obviously know, that split screen isn't going to be possible.

2011-06-19 23:42:00 Author: Unknown User

---

Sorry I couldn't get over to help you today. Some friends and I were in the middle of a project. There's a lot here, I will answer what I can. Alright, now while shane_danger helped me out with that issue and got it mostly set up for 2 players... I have a few problems and such. First off, I want to add something, that triggers when both players select their desired character. In terms, a "Yes/No" sorta of object. If the first player selects "Yes", the controlinators are destroyed and they're teleported to the checkpoint, where their character is. "No" is self-explantory, as it doesn't change anything and it doesn't destroy the controlinators and the players can choose a different choice. The way you currently have your menu set up (which I urge you to redesign with something similar to what Antikris put forth) you'll need to wire each of the 8 one shot counters on your character select boards to OR gates, then both of those OR gates to an AND gate, which will allow the action to continue. Now, the problem with that is that your system will no longer work with just one player. You'll need a conditional player sensor (for when there is 1 and ONLY 1 player) to bypass this AND gate so that you can get into the level. Second of all, this is a bit cosmetic, but.. i want the players to go to their respective checkpoints, but end up in the sackbots already, but I want the checkpoint to be hidden somehow. How can I do so? Hiding a checkpoint isn't too hard. You can decorate a checkpoint just like anything else. That's a simple way to go about it, but you can also shrink it and hide it in other ways. Search through the tutorials on the forum. As for the players spawning in checkpoints, the easiest way is to not kill the player. Leave them in a holo that follows their sackbot. You can control where sackbots spawn, but players is another story. Finally, the sackbots(or characters) are going to have three lives, in a sense, but how can I make it, when the Sackbot is destroyed, the player reappears at the checkpoint, but with a new sackbot? Again, I'd recommend spawning only the sackbot and not the players. You can put the emitter right on the checkpoint. Put tags on your sackbots and label them what you wish. Then put an inverted tag sensor with the same label and a player sensor on checkpoint. wire those to an AND gate, the AND gate to the emitter. This way, if the player is in range with a sackbot, the emitter will not emit anything. But if the player spawns from the checkpoint, he will be put in a sackbot. I'm planning on adding tanks, but I want to limit things, to where you can only summon one tank at a time and you can only summon the tank three times. You can set the amount of "ammo" that an emitter has. If you set it to three, once it fires three times, it will not activate again. You can also set it to "max emitted" as 1 and uncheck "destroy oldest when max reached." Now another issue is, that with the way, the sackbots are set up, if they get killed by paintinator shots, both the sackbot and controlinator(which is on a hologram with Destroyers on it) are destroyed. But if for example, the sackbot is crushed by, in this case, a moving tank.. The sackbot dies, but yet the controlinator isn't destroyed(which makes some sense). How can I fix this issue? If you are still not emitting just the sackbot but a sackbot with the player, then your holo follower needs to have an inverted tag sensor (set to the sackbots tag label and color) wired to a destroyer. If you destroy the holo that the player's controlinator is on, you'll kill the player.

2011-06-20 04:48:00 Author: shane_danger Posts: 283

---

Alright. I'll get to fixing things up tonight.

2011-06-22 00:08: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.