Archive: 14 posts

---

Heya, Stellakris again. (In some lovely Hatsune Miku costume, courtesy of CZ127 (http://lbp.me/v/xy89k4)) http://i3.lbp.me/img/ft/3537d6ae77b26c427a729f032d9b0714ba398b57.jpg Today I want to talk about some more advanced Controlinator logic. The kind that lets you control sackbots in various ways. Or more specifically: Determine the order in which controlinators get taken Override some sackbot behavior, but not all of it Switch between different controlinators without changing seat Switch between controlinator and movinator, manually or automatically Switch between remotely controlled sackbots in multiplayer mode Quite a list, so let's get started! Determine the order in which controlinators get taken Say you have four controlinator (Direct Control Seat, or DCS)seats lined up for your audience, but you want to make sure that seat #1 gets occupied first, #2 second and so on. It's not so hard, but you will have to know what that input at the bottom of a DCS is for: when activated it disables the DCS (and ejects anyone occupying it and prevents anyone from entering while active). This is kind of unintuitive since most stuff is activated when powered. (In this tutorial I use both chip activation of controlinators and direct deactivation. Pay attention. ) http://ic.lbp.me/img/ft/c9c9ea454fcfaf69b5bd4968a95df04f60015069.jpg Here you see four blocks with a seat on it. Each DCS chip hasits own tag, activated by the Active output of that DCS. This means the tag is active when the seat gets occupied. Every next block has a tag sensor detecting the activation of the seat to the left of it. The sensors are inverted so they will send a signal when no active tag is present. With this setup all but the leftmost seat are deactivated; when the first seat gets taken, the second opens up, then the third, and so on. This is the wireless version; you can leave out the tags/sensors and do it all with wires, but this is good practice. Especially for objects that are able to move freely through your level. Which is what we'll do with these blocks. Override some sackbot behavior, but not all of it http://ic.lbp.me/img/ft/e8c5b11b58e4dc1b56e6c465be93101d6a773a7d.jpg So here we have the basics of a remotely controlled sackbot: an (invisible) holo/stickerpanel block with a mountable DCS on it, which has a follower activated that chases the tagged bot. The DCS is a transmitting one, in this example transmitting on the red frequency. I liberally used some stickers to show what is sending and what is receiving and in what colors. The sackbot has a receiving DCS on its chip in order to pick up the signal of the control seat. This DCS is set to override sackbot behavior so the bot will behave exactly like your sackboy. The bot also contains a unique tag that allows the seat to follow it. For good measure, this tag only gets activated when the bot is taken control over. Okay, so the bot does everything sackboy does. But what if we don't want it to jump? What if we want to create our own jump logic but leave the rest of the controls intact? http://i2.lbp.me/img/ft/ae2bfae30f6dcc95a6bcfe8b8f06e725443f7f38.jpg Set the receiving DCS to not override sackbot behavior and place a normal (not receiving nor transmitting) DCS next to it; wire all the controls that you want to remain default behavior from the receiving DCS to the normal one's inputs. Except for the jump button; you can wire that to your own logic. (Thanks Evret and BagheadInc for clearing this up for me) Switch between different controlinators without changing seat http://if.lbp.me/img/ft/f0f595ac5eed12d004bbf0262f0db8202251a21c.jpg Normally, you'd like to do something like in the picture above: on the sackbot you place separate (receiving) controlinators of which one gets activated depending on the circumstances. This works fine for most scenarios in which you switch a sackbot's (or any other object's) behavior and controls; for instance, your bot picks up a powerup and suddenly has new abilities. However, if you'd like to switch between controlled objects/sackbots altogether, then this approach can get complicated in a multiplayer scenario. But let's take a look at it from a single-player PoV first. The following is a simple solution for 1 player to switch between controlled sackbots. http://ia.lbp.me/img/ft/18aa2130965abd51688efef309780c6c1646cda9.jpg On the transmitting DCS, a player can switch between unique tags. A tag gets picked up by a bot and this signals it to activate the chip containing its receiving DCS. Pretty simple, eh? Now add multiplayer... http://id.lbp.me/img/ft/d8d39d808f6e704d2835d47c465c70f86cc335af.jpg It starts to get pretty hairy already. And this is only two players... A player would still be able to select a tag even though the bot that is already controlled won't hand over the control to you. You'd have tell the transmitting DCS that and.. meh.. Wouldn't it be easier if each bot could just have a receiving DCS and players could switch between transmitting controlinators instead? Yes. But that doesn't work. You can try and stick a transmitting DCS on the chip of a controlinator seat, but it won't transmit any movement. Bugger! But if you stick it on a bot, then it does! Introducing the conduit sackbot. http://i0.lbp.me/img/ft/d108b2ceb1bdb2db1f63e4dc3db8fff26ef37d33.jpg It is a little buddy bot stuck in a prison, receiving your control over a dedicated frequency. Another transmitting DCS can then control the target object. On the conduit bot you can then manipulate which transmitting DCS is being used. I'll make this clear in the next chapters. http://if.lbp.me/img/ft/55f2f5d097b05a61193b160b0182bdeef5297084.jpg Switch between controlinator and movinator, manually or automatically Say, you want to create a level that uses the PS Move controller but not let player who don't have it out in the cold. Then it's nice to be able to switch between controlinator and movinator and bind different actions to both; for instance, the movinator gives the player control over a cursor to pick up stuff, while the controlinator deploys a cursor-like substitute that the player can control via the right stick on a normal controller. The problem lies in the fact that a player must sit in a (transmitting) movinator seat but a bot has to receive a control signal on an ordinary receiving DCS in order to use the controls of that DCS in its logic. You cannot set a transmitting movinator to for instance yellow signal and have a receiving controlinator get the signal on the yellow bandwave; those two don't mix. However, the conduit sackbot fixes this. http://ib.lbp.me/img/ft/8cb77bd218ad3457f5086b2d72f2f8d269956432.jpg So we have a movinator seat that receives all the movement a normal DCS would, transferred to a conduit bot, which then transfers that to either a set of normal controlinators or a set of movinators. In the screenshot the player can toggle manually between the two. Wouldn't it be nice if there is an automatic detection for it instead of manual control? http://i4.lbp.me/img/ft/0e4d453bcfdcd71e05669603f711773655d3860e.jpg Instead of the toggle switch there is now a small sequencer (set to positional) with a battery on it, spanning the length of its canvas; this sequencer will output a signal when the analog input that it receives is greater than 0. Its input comes from the receiving movinator's movement output; when a PS Move controller is activated (and held in hand by the player) it is never kept fully still; so this output always generates a small signal. This signal does not exist when the PS Move controller is turned off. Switch between remotely controlled sackbots in multiplayer mode This tutorial was inspired by this help forum thread (https://lbpcentral.lbp-hub.com/index.php?t=67055-Fantastic-Four-Sackbots-HELP) and it illustrates nicely what you can use sackbot switching for. Here is what you will be able to do: if one player spawns, he can switch control between four different sackbots; if two or three players spawn, everyone can switch control to the currently uncontrolled sackbot; if four players spawn, each player controls a sackbot and cannot switch to another. http://ia.lbp.me/img/ft/55aa8bb5b585ec4ddfe71986f1a9acad811c2b1d.jpg Using the knowledge of two chapters back we can now set up four transmitting DCS seats (each a unique color), four conduit bots (each with a corresponding receiving DCS) and four target bots. Each of the conduit bots will have the same logic as the yellow one displayed here, just another receiving DCS. A flip of a button by a player will make him switch control to another of the bots. However, chances are that the bot he switches to is already under control by someone else. We'd have to check for that and if necessary automatically switch to the next available bot. For that, we set up some tags that get activated depending on which bot the conduit bot has taken control over. http://i6.lbp.me/img/ft/4f63f824b5b36e1c743d48cfa81e292f41ce7b2a.jpg Then, on each conduit bot, we detect whether such tag is active already, corresponding with the bot we try to take control over, and if so, force the selector to the next port. Active tags that are on the same (stack of) chip(s) as the sensor measuring it will be ignored; that means that if a player controls a red bot, his own red tag sensor will not deactivate the control. http://i6.lbp.me/img/ft/b66ca2bda237c780f0859dc1600c04aca11db089.jpg For all the tags: http://i6.lbp.me/img/ft/0164254eb7248243a5921335f09f96e5452919a7.jpg If you do duplicate this on all the conduit bots and make sure you set the selector's default value right (#1 for conduit bot 1, #2 for conduit bot 2, etcetera) then this should work just right. Right? Well, almost... When a player switches to a bot that is already taken, with this setup he will still briefly activate the chip - and therefore the tag - that will cause the other player to instantly switch to the next bot. In effect it causes a player to take over control of a bot and force the other player to drop control. We want instead for the player to not be able to gain that control. http://i5.lbp.me/img/ft/1150dbf92d0516a592e6552e9982090930809e66.jpg We can go the complex route here, but here is a simple solution: instead of activating the the tag on a chip instantly, we postpone it by 0.1s; use a battery to a timer (set to Count Up) and hook that to the tag. Now, when a player tries to take control over a bot, if he is not allowed to, the activation of the chip will be too short for its tag to activate. Everything now works as intended. And last but not least, if you want your holo/stickerpanel follower block to chase the right sackbot, you can repeat the logic above on the controlinator seat but activate followers instead of chips: http://ia.lbp.me/img/ft/2da430e58626b257f2a0ad16676332d594f5155e.jpg Goodluck! And remember to spread the love. Kawaii!! http://ia.lbp.me/img/ft/5aa3d8ae60099450c6c5d7b1b39a66affd707eb4.jpg

2012-01-22 14:17:00 Author: Antikris Posts: 1340

---

Wonderful tutorials Kris! clearly explained, and great illustrations too. You're a real trooper for sharing this info with all of us

2012-01-22 14:28:00 Author: rialrees Posts: 1015

---

Great stuff man. I'm bookmarking this page in case I need this knowledge later You should try making tutorial videos!

2012-01-22 14:30:00 Author: SnipySev Posts: 2452

---

Excellent explanations paired with clear images. Really well done!

2012-01-22 21:16:00 Author: Mr_Fusion Posts: 1799

---

Nothing I didn't know, but it's great to see a clear place which explains it all with pictures. However, I would add one thing : instead of leaving your intermediate sackbots in prisons, you should place them on controlinators set not wireless, invisible. This way, they won't die when underwater or by any other sad way, and they don't do any sounds.

2012-01-23 02:34:00 Author: Unknown User

---

Nothing I didn't know, but it's great to see a clear place which explains it all with pictures. However, I would add one thing : instead of leaving your intermediate sackbots in prisons, you should place them on controlinators set not wireless, invisible. This way, they won't die when underwater or by any other sad way, and they don't do any sounds. That is a good idea. For the sake of organisation you can even stick them on an extra controlinator attached to the player's follower block. Worst comes to worst and you need those four dedicated color frequencies for something else, you can even lay wires between your own DCS seat and the bot next to you without creating a jungle of lines.

2012-01-23 06:43:00 Author: Antikris Posts: 1340

---

Hi. What's the easiest way to have 4 players taking it in turns to control the same object? They way I plan (at least, in my head) to do it, is to have a controlinator per player, with the buttons (L stick, R stick etc) activating tags, which in turn activate the appropriate (mover etc) action on the object. I'll put those tag on a microchip on each controlinator, and have a tag sensor (which recognises whose turn it is) attached to the on/off input of the microchip. This seems to be the simplest way, unless you know of any more trickery?

2012-01-23 14:08:00 Author: Ali_Star Posts: 4085

---

This seems to be the simplest way, unless you know of any more trickery? Well, using conduit bots to switch between transmitting controlinators is a way, but whether it is the simplest for your problem, I don't think so. I mean, all you'd have to do is cycle through receiving selectors on the controllable object (place each of them on a chip that you activate with a selector). Conduit bots would decentralize and duplicate that switching mechanic without any real benefit.

2012-01-23 18:15:00 Author: Antikris Posts: 1340

---

Another great tutorial, awesome job! Using a sackbot to transmit the controls is brilliant. Useful for everything using multiple channels, not just those using sackbots. EDIT: Missed the end of the explanation, ignore what I wrote before.

2012-01-26 19:02:00 Author: SSTAGG1 Posts: 1136

---

Antrikis I followed the directions to a "T" but somethings still wrong. I can only get two characters to move per controlinator, and sometims, who will be able to move becomes stuck on one character only despite which bot the holo is following

2012-04-09 21:47:00 Author: TREMIC1 Posts: 263

---

Another nice tut, clear and easy to understand What I was actually searching for (with no luck) was how to get a cursor working with a sackbot or on-demand. It seems that once the movinator is on a chip of any kind, a cursor wont appear (at least, thats what Ive found so far, altho Ive only just got the move so maybe there is a solution). Using tags+emit/destroy with some holo and nearest player controls movinator works, but it seems like a sloppy work-around. So if anyone has any nugget of info on this, Id love to hear it

2012-04-13 10:21:00 Author: Masseyf Posts: 226

---

...for instance, the movinator gives the player control over a cursor to pick up stuff, while the controlinator deploys a cursor-like substitute that the player can control via the right stick on a normal controller. ...except your example won't actually let you do that. The red transmitting controlinator will only retransmit signals which also exist on the movinator, which excludes the right analog stick. From an earlier post... It's a bit of a shame that neither the Movinator nor the Controlinator will let you trap both the Move outputs, and the right analog stick outputs, should the player be using a DualShock+Move combo rather than a Nav+Move combo. More so, because it means you can't use just a Movinator for a hybrid control system where you want the right analog stick to control the cursor, thus leaving the left analog stick free for something else in either configuration, which would be ideal for a level where you want the left stick to control your Sackperson as usual, but also have, say, a crosshair you could control either with the Move, or the right stick, depending on which you have. I spent ages playing with this in the beta with Shadowriver, and the best workaround we could come up with was to first suck each player into a Movinator, use that to detect if they have a Move or not (by examining the Move outputs), then suck them either into a nearby Controlinator or Movinator, depending on which they have. It worked fine, but it still felt more than a little hacky. The only additional optimization I can think of would be not bother sucking them into another Movinator if they have the Move, but just use the existing one used for Move detection. ...this sequencer will output a signal when the analog input that it receives is greater than 0. Its input comes from the receiving movinator's movement output; when a PS Move controller is activated (and held in hand by the player) it is never kept fully still; so this output always generates a small signal. It's not 100% clear, but in the image it looks like you've taken the output from the Twist Left/Right output, which you can't guarantee is greater than 0% all the time. See this post (https://lbpcentral.lbp-hub.com/index.php?t=63273-Move-Does-the-Activate-input-on-the-Move-Cursor-even-work&p=927582&viewfull=1#post927582) for a more bulletproof (and lower thermo/latency) method. It seems that once the movinator is on a chip of any kind, a cursor wont appear... Confirmed. Still, for the movinator to have any effect on a sackbot, it must be being receiving from a transmitting movinator which the player is occupying, so can't you just put the cursor on the transmitting movinator?

2012-04-13 21:14:00 Author: Aya042 Posts: 2870

---

Confirmed. Still, for the movinator to have any effect on a sackbot, it must be being receiving from a transmitting movinator which the player is occupying, so can't you just put the cursor on the transmitting movinator? Well actually I was thinking if I got the answer to one, I'd have it for both (which I've a feeling now that's not gonna happen!). What I was trying to do is simply have either a cursor for select areas, or perhaps on-demand, without having to enter a movinator. If you put one loose and put it to nearest player, it's always on and not a good solution regardless since it won't work well in multiplayer. So you want it on only when players are in certain places, and in such a way each person gets their own as needed. You can't turn them on or off (that I know of), so first thought - put it on a chip, chip on/off via player sensor, done. But that doesn't work ^.^ The emit/destroy with holo does work, quite well. Just feels like there is (or should be) a better way...

2012-04-13 22:17:00 Author: Masseyf Posts: 226

---

What I was trying to do is simply have either a cursor for select areas, or perhaps on-demand, without having to enter a movinator. The easiest way to ensure each player gets their own cursor would be to have all the players control costume-copying sackbots for the entire level. If that's not possible (e.g. if some sections use water or grappling hooks), then you might be able to do a cheat when entering one of these "select areas" when the players are 'turned into' sackbots behind a foreground object, and turned back afterwards. You can't turn them on or off (that I know of)... You can only turn one off by enabling another one, so have two cursor objects, one with the logic, and one with an invisible cursor (set size to 0), and switch between them with a selector.

2012-04-13 23:59:00 Author: Aya042 Posts: 2870

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.