Archive: 6 posts

---

I have checked the FAQ, the solution doesn't seem to be there. Alright, so right now I'm working on the beginning of my level, which I'd like to start out with a sort of intro cutscene. I've got four Sackbots in this intro, dressed as players 1 through 4. The only problem is, I can't seem to find out how to make Sackbots disappear when their respective players aren't playing. For instance, if there are three people playing my level (players 1, 2, and 3), I don't want the Sackbot dressed as player 4 to appear in the intro. I thought Sackbots that were dressed as non-existent players would automatically be invisible, but they seem to dress as player 1 instead. I thought about using a player sensor, but the problem is that it detects the number of players rather than the players themselves. It can detect that there are three players exactly, but I want it to detect that there's a player 1, a player 2, and a player 3. Now, this is where my questions come in. I might have this all wrong, in which case I'll pretty much know where to go from there. Is it possible to play a game with, say, Players 1, 2, and 4? Say, if Player 3 leaves at some point throughout the level or if it's a guest/host who disconnects their controller? Or would Player 4 automatically be bumped up to Player 3? If there's no way to have a player [insert number here] without a player [insert lower number here], my problem's pretty much solved. If not, I need to know how to detect that there are players 1, 2, and 4 rather than just detecting that there are 3 players. I know I'm being a bit confusing about this, so here's a quick example of the kind of thing I'm trying to avoid: There are three players visiting my level. Player 1, Jack. Player 2, Sally. Player 4, Bob. There is no player 3. My level detects that there are three players, so it sets up 3 Sackbots for the intro dressed as players 1, 2, and 3. Because of this, there are two Jack Sackbots and no Bob Sackbots. I need to find a way to avoid this. Now, knowing my luck, you can't, in fact, have a higher-numbered player without all the lower-numbered players, and I'm just sitting here rambling about something stupid. I really don't have any way of easily finding out for myself, though (I lack extra controllers and friends at the moment). I've seen this done on story mode (maybe it only works on movies?), so I know there's some way to do this, I just need to find out how.

2011-09-14 04:29:00 Author: Unknown User

---

What if you emit the Sackbots, and then only emit a Sackbot if the seat it is referring to using is occupied by a player? And you can sort the players by applying the DCS colour hierarchy (https://lbpcentral.lbp-hub.com/index.php?t=45968-How-do-I-select-the-control-seat-of-a-specific-player).

2011-09-14 08:43:00 Author: Slaeden-Bob Posts: 605

---

You can set a bot's costume to owner, so you won't have to set it to a player number specifically. The receiving DCS, taking a player signal, on the bot's chip will then determine who it will look like. The problem now shifts to the unique color frequency of transmitting and receiving DCS's. If you do not go the hard route of emitting a single, universal bot for each player, you can do this: place four blocks of invisible holo with (auto) mountable transmitting DCS where players enter the level. These DCS's each have a unique frequency associated with a unique receiving DCS on what can otherwise be a universal bot. All four bots stand waiting outside of the view and once their receiving DCS becomes active (Active output on the receiving DCS layout), the bot comes running into view - or jumps down, or, if you are logically inclined, comes flying in using a follower; it then switches to a mode in which you have full control over the bot. The universal bot emission route is a bit more tricky. You create a bot template in which all four unique DCS frequencies are incorporated, but with every emission of a bot instance a corresponding DCS must be chosen. You can do this by having a unique tag present on the follower block for each player: "player1Active", "player2Active", etcetera. This unique tag for each follower block gets activated by the transmitting DCS once it is occupied by a player. Player detection logic (multiple player sensors to a selector) will activate a corresponding sequence of bot emissions; when 2 players detected, it emits 2 bots in sequence (not at once!), when 3 players, 3 bots, etcetera. Now, the logic on the bot should have tag sensors corresponding with the tags on the follower blocks, "player1Active", "player2Active", etcetera; they are all hooked to a selector which will activate a separate chip for each channel, each chip containing a corresponding receiving DCS plus a tag "playerXbot" (the X standing for the player number associated with it). On each follower block detection of the playerXbot tag should deactivate the tag playerXActive so that on the next bot submission that bot does not get paired with a following block that already has a bot associated with it. This will not instantly work of course, because the second the playerXActive tag of for instance player 4 gets deactivated, the bot will detect player3Active and pair with player 3. What needs to be done is that each emitted bot needs to pair only once and never again. To do this, place the playerXActive tag sensors on the bot template onto a dedicated microchip. Now add another channel to the selector next to it. Wire that channel's output to the activation port of the sensor array microchip and set the default selection of the selector to #5. Now, the sensor array will be active until one of its sensors activates a different channel on the selector (and thus pairs the bot with a player) and the sensor array will instantly be deactivated, not allowing another pairing of that bot but still remembering which player it was paired with. If you read this far, I should probably pen this all up in a tutorial or something.

2011-09-14 11:53:00 Author: Antikris Posts: 1340

---

Oh man, what a handful! Okay, well, there are enough solutions here so that I'll be able to manage at least one of them (hopefully). I've just got a few questions before I tackle this. First, replying to Slaeden's post, are these Controllinator colors supposed to be exact? Because if I remember correctly, you can choose between a large handful of colors on some kind of color wheel, and there might be more than one colors that could be considered blue or red. Unless they go by tag colors instead of the color wheel. I'm not at home right now, but I'll check which color system the controllinator uses next chance I get. Second, and this may sound a bit silly, but what is DCS? Is that, like, a strange nickname for the Controllinator? Because I can't seem to find the answer anywhere. And lastly, somewhat unrelated, is it possible to somehow detect players' colors (the colors you choose when customizing your character)? Like, say, if someone with light blue and yellow as their colors jumped into my level, I could have a flag that would be light blue and yellow? I'm not really depending on player colors or anything, it just seems like something I could use to add to the fun if it were possible. Thanks for all the help!

2011-09-15 03:27:00 Author: Unknown User

---

1. Yes the colours are the same as the tag colours 2. DCS is short for Direct Control Seat, an earlier name of the controlinator from beta 3. Sort of, not 'detect' per se but most logic pieces retain or pass through player input colour so if set up properly, then yes, you could have a flag be a player's colour. You could even emulate score bubbles, if you had a player sensor on a bit of holo and wired the output to the holo and set it to player colour it'll light up the colour of the person who approaches it. Same with more complicated logic, 4 players in DCSs could press a button that runs through an OR gate to a light set to player colour, and it should light up as the colour of who pressed it... Haven't tried that so maybe not a good example. But only the players 'main' colour not the secondary one. The main colour is the colour of the popit.

2011-09-15 07:29:00 Author: Mr_Fusion Posts: 1799

---

And to add to this, most materials and objects that allow to change the color of its light source (holo, neon, light bulbs...) provide an icon of a sackboy next to the color wheel. Selecting this icon will mean that the color of the object will be that of the popit color of the player whose signal the material is picking up. This 'picking' up can come from a wire going into it or from 'being owned' because of a DCS attached to it. Where a player signal comes from is a bit of a complicated topic that I am not yet fully versed in myself, but I know that any output from a DCS contains a player signal (the Active output is always save to use). Emitted objects do, too, if they were emitted from an owned object or a wire carrying a player signal (i.e. DCS output) went to the emitter. If that emitted object would be holo or neon set to player color, you can see it adopts player color. In turn, this emitted object can then transfer this player data again to an impact sensor that registers collision with such owned object. Hook the impact sensor to a score giver and you will notice that the player who emitted the object gets rewarded for the impact; the basis of a player versus player shooting game...

2011-09-15 10:04:00 Author: Antikris Posts: 1340

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.