Archive: 39 posts

---

Hello there, In this Tutorial I show you how to make a basic checkpoint system for sackbots. The First thing you need to do is making a checkpoint. Start with the following(this could be anywhere, where you want your checkpoint) http://i9.lbp.me/img/ft/4799d5a90c4871c8ae337f6af41dfdaafbe5de71.jpg -Tag sensor: Is for detection of sackbot, so it can activate the checkpoint. Sackbot needs to have a tag with the same name/colour as this tag sensor. -OR gate: For organisation of the wires. -Microchip(inside the microchip) Now open up that microchip and: http://i2.lbp.me/img/ft/032a11230ebc37d0fe65892279d6ef7096b22cc6.jpg Tag sensor: needs to have a different colour/name then the previous tag sensor. This tag sensor need to have max detection range, so it can see if sackbot is still alive or is dead. Set this tag sensor to inverted this way it turn the emitter on, whenever the sackbot dies.(sackbot should also have a tag with the same colour as this one inside it) Emitter: frequecy to 0, lifetime and max emitted to infinite. and max emitted at once to 1. the emitter emits sackbot(including the two previous described tags, so you need to capture this sackbot) Making the checkpoint notice-able. http://id.lbp.me/img/ft/b8ded05578411f6ec50846be3aaf52ecb47ad92c.jpg Of course you want to see when the checkpoint is activated, i chose for a simple led light. Hook the OR gate's output up to this led light(or something like that) and hook it up to the microchip inside the microchip. Creating multiple checkpoints. Just copy what you just made and put it somewhere else, and voila you have another checkpoint. ]Making the checkpoints work: http://if.lbp.me/img/ft/4efe38026f757e264f4f76bb5bc3ce68b0c7ba3a.jpg Inorder to make the checkpoints work, you will need a main microchip somewhere in your level. For each checkpoint you will need 2 OR gates and 1 counter. The first OR gate is for organisation or your wires(left in picture) The second OR gate is for reseting the other checkpoints The counter acts like a permanent switch to keep the checkpoint activated. The counter needs to be set so that it count only 1. The picture above shows a system of 7 checkpoints. (counting from top to bottom) From each checkpoint connect the (in this example) red tag sensor to the First OR gate(on the left in the picture) checpoint 1 should connect to the OR gate, checkpoint 2 to the OR gate beneath that one, etc etc. Connect the output from these OR gates to the input of the counter, of course each checkpoints as his own counter. Connect the output of the counter to the OR gate input, of the checkpoints microchip(see picture 1, 2 or 3). Now with this set up all checkpoint can be activated at the same time, this would cause trouble, so we need a reset system. This is the use of the Middle OR gate(in the picture), this OR gate needs to have as many input as there are checkpoints, so in this case 7. (and again, each checkpoint has his own OR gate) If checkpoint 1 is activate, it needs to reset all other checkpoints. So connect the output of the OR gate(on the left) from checkpoint 1 to the "reset" OR gate(middle in the picture) of checkpoint 2 3 4 5 6 and 7. And repeat this for every other checkpoint. If done correctly, you should have a working sackbot checkpoint system. Advanced tip: You can also connect for example a button to the OR gate of a Checkpoint(the OR in which the tag sensor connects) in this way you can remotely activate a checkpoint. I also made a little level, in which i show this: http://lbp.me/v/xj6t8w Edit: [lbpmelevelurl] doesnt seem to work, so here is the link click (http://lbp.me/v/xj6t8w)

2011-02-07 17:40:00 Author: Dexist Posts: 570

---

Easier way, doesn't require global chip http://s001.radikal.ru/i195/1102/89/583062b6e537.png Circles at the left side of a picture are tag sensors Forgot to draw: sensor 2 activates a tag for sensor 3

2011-02-07 18:07:00 Author: darkphoenix Posts: 97

---

But with that you can have multiple checkpoints activated at once, isnt it? and that would be a problem

2011-02-07 18:13:00 Author: Dexist Posts: 570

---

Edited a post, there was a fail

2011-02-07 18:17:00 Author: darkphoenix Posts: 97

---

How, would you activate that tag 3? maybe if you activate that tag with another checkpoint/sensor? is that what you mean?, then you will need basicly the same as i did in the main microchip. Want to explain it a bit more ?

2011-02-07 18:30:00 Author: Dexist Posts: 570

---

When I wrote this, i didn't have enough time, now I have. Ingame pic: http://i1.lbp.me/img/ft/9a19813b77bc8e95a55855dbe6af533e00049d43.jpg Tag sensors are in the same order, first with 5000 max range, inverted, second with small max range, third with small minimum range(I used 1.0) and 5000 max range, I connected 2nd sensor to a 1-counter with self-reset. Your main microchip does the same thing as the selector.

2011-02-08 04:34:00 Author: darkphoenix Posts: 97

---

third with small minimum range(I used 1.0) and 5000 max range You actually don't need that min range as tag sensors can't activate from tags in same microchip.

2011-02-08 06:02:00 Author: waD_Delma Posts: 282

---

EDIT: disregard my comment. Posted too fast and missed the entire point of this topic. My apologies. This Help topic (https://lbpcentral.lbp-hub.com/index.php?t=47058-How-to-Make-a-Race&p=758735) has some interesting discussion going on about checkpoint logic as well. Here is a schematic for a 3-lap race with 3 checkpoints and a finish line that I posted myself; my comments are in the reply over there (https://lbpcentral.lbp-hub.com/index.php?t=47058-How-to-Make-a-Race&p=757255&viewfull=1#post757255). http://i.imgur.com/lhSna.gif

2011-02-08 09:41:00 Author: Antikris Posts: 1340

---

darkphoenix's system is the optimal solution for a Sackbot respawn module. Though as waD_Delma said, tags on the same chips aren't detected by sensors, so there's no need to worry about that. Thanks for the thread.

2011-02-08 11:58:00 Author: Linque Posts: 607

---

You know, there is an even easier way to do all of this. I'm at school, so I don't have pictures, but... Put the sackbot emitter on the piece of holo that you have the player on. If you don't have the player on holo, you probably should, set to follow the sackbot around, at say 80%. Place down a tag somewhere for your checkpoint. For the sake of brevity, we shall make this a green tag and label it "Checkpoint." Put a follower on your piece of holo set to follow the Checkpoint tag, 100%. Place another tag on your sackbot; for example a blue one, called "Sackbot 1." (1 for each player) On your holo, make a tag sensor, inverted, set to match Sackbot 1. Wire this tag sensor to the follower looking for the Checkpoint tag. Place another tag sensor on the holo that has a fairly small radius, which matches up with the Checkpoint tag. Wire this to the emitter for your sackbot. Make sure your emitter has the max emitted at once set to 1 and will not destroy last emitted. Now, when the sackbot dies, the Checkpoint follower will activate. Thus, your holo, with the player attached, will move to the checkpoint. When it gets there, it will turn on the emitter for your sackbot. Viola. --- For a more complete system, you can turn the green Checkpoint tags on and off to make them work as checkpoints. Selectors are awesome for making sure only one lights up at a time. Additional logic will be necessary for cooperative multiplayer. This is left as an exercise to the reader.

2011-02-08 12:23:00 Author: comphermc Posts: 5338

---

Now, when the sackbot dies, the Checkpoint follower will activate. Thus, your holo, with the player attached, will move to the checkpoint. When it gets there, it will turn on the emitter for your sackbot. Viola. Why didn't I think that. Thats way better way as it saves thermo and usually you have the player on holo too. Selectors are awesome for making sure only one lights up at a time. Its better to use tags to deactivate checkpoints as it saves lot of unnecessary wiring.

2011-02-08 13:02:00 Author: waD_Delma Posts: 282

---

Its better to use tags to deactivate checkpoints as it saves lot of unnecessary wiring. Six in one, half dozen in the other. Using a selector would require less thermo, although the difference is negligible.

2011-02-08 13:44:00 Author: comphermc Posts: 5338

---

You know, there is an even easier way to do all of this. I'm at school, so I don't have pictures, but... Put the sackbot emitter on the piece of holo that you have the player on. If you don't have the player on holo, you probably should, set to follow the sackbot around, at say 80%. Place down a tag somewhere for your checkpoint. For the sake of brevity, we shall make this a green tag and label it "Checkpoint." Put a follower on your piece of holo set to follow the Checkpoint tag, 100%. Place another tag on your sackbot; for example a blue one, called "Sackbot 1." (1 for each player) On your holo, make a tag sensor, inverted, set to match Sackbot 1. Wire this tag sensor to the follower looking for the Checkpoint tag. Place another tag sensor on the holo that has a fairly small radius, which matches up with the Checkpoint tag. Wire this to the emitter for your sackbot. Make sure your emitter has the max emitted at once set to 1 and will not destroy last emitted. Now, when the sackbot dies, the Checkpoint follower will activate. Thus, your holo, with the player attached, will move to the checkpoint. When it gets there, it will turn on the emitter for your sackbot. Viola. --- For a more complete system, you can turn the green Checkpoint tags on and off to make them work as checkpoints. Selectors are awesome for making sure only one lights up at a time. Additional logic will be necessary for cooperative multiplayer. This is left as an exercise to the reader. This is what comph does when he's supposed to be teaching. Teach your class, not lbpc!

2011-02-08 14:18:00 Author: Bremnen Posts: 1800

---

For a more complete system, you can turn the green Checkpoint tags on and off to make them work as checkpoints. Selectors are awesome for making sure only one lights up at a time. Additional logic will be necessary for cooperative multiplayer. This is left as an exercise to the reader. Would the following logic make for a self-contained (and thus easily clone-able) checkpoint? Of course, ON and OFF states on the CP are easily combined with your spawning holo. http://i.imgur.com/nmm4X.gif

2011-02-08 14:33:00 Author: Antikris Posts: 1340

---

You know, there is an even easier way to do all of this. I'm at school, so I don't have pictures, but... Put the sackbot emitter on the piece of holo that you have the player on. If you don't have the player on holo, you probably should, set to follow the sackbot around, at say 80%. Place down a tag somewhere for your checkpoint. For the sake of brevity, we shall make this a green tag and label it "Checkpoint." Put a follower on your piece of holo set to follow the Checkpoint tag, 100%. Place another tag on your sackbot; for example a blue one, called "Sackbot 1." (1 for each player) On your holo, make a tag sensor, inverted, set to match Sackbot 1. Wire this tag sensor to the follower looking for the Checkpoint tag. Place another tag sensor on the holo that has a fairly small radius, which matches up with the Checkpoint tag. Wire this to the emitter for your sackbot. Make sure your emitter has the max emitted at once set to 1 and will not destroy last emitted. Now, when the sackbot dies, the Checkpoint follower will activate. Thus, your holo, with the player attached, will move to the checkpoint. When it gets there, it will turn on the emitter for your sackbot. Viola. --- For a more complete system, you can turn the green Checkpoint tags on and off to make them work as checkpoints. Selectors are awesome for making sure only one lights up at a time. Additional logic will be necessary for cooperative multiplayer. This is left as an exercise to the reader. That works nicely thanks Comph. I had designed a similar system on the beta, but it wasn't as efficient as your method. I had to make one minor alteration to the design though. The hologram moves at speed toward the checkpoint, so it emits the respawning sackbot at a velocity and kind of throws him sideways. It was easily remedied by putting a second's delay on the emitting time.

2011-02-08 16:05:00 Author: Ungreth Posts: 2130

---

This thread here... makes all the rest of LBPC bearable! Some nice thinking on all fronts; especially comph.

2011-02-08 17:07:00 Author: Gravel Posts: 1308

---

The hologram moves at speed toward the checkpoint, so it emits the respawning sackbot at a velocity and kind of throws him sideways. In the emitter there is option "ignore parent velocity" that prevents this.

2011-02-08 17:10:00 Author: waD_Delma Posts: 282

---

In the emitter there is option "ignore parent velocity" that prevents this. Doh, of course! Thanks for reminding me about that option.

2011-02-08 19:26:00 Author: Ungreth Posts: 2130

---

All these new, easier, and probably better ways to make it. Make my work look like i spend to much time on it XD.(although i was happy when it fully worked, since it was my first logic thingy ) But anyway, thanks for all the replies and such .

2011-02-08 21:20:00 Author: Dexist Posts: 570

---

I didn't want to hijack this thread any more, but I will say that there is a very simple way to do modular (all-in-one) checkpoints, which I discuss in full, along with a more thorough explanation of the follower system, over at LittleBigPlanetarium (http://www.littlebigplanetarium.com/index.php?/topic/226-sackbot-checkpoints/). This was the modular checkpoint logic: http://img189.imageshack.us/img189/2225/lbpcheckpoint.png Cheers.

2011-02-09 00:55:00 Author: comphermc Posts: 5338

---

I didn't want to hijack this thread any more, but I will say that there is a very simple way to do modular (all-in-one) checkpoints, which I discuss in full, along with a more thorough explanation of the follower system, over at LittleBigPlanetarium (http://www.littlebigplanetarium.com/index.php?/topic/226-sackbot-checkpoints/). This was the modular checkpoint logic: Glad to see my diagram was correct.

2011-02-09 01:41:00 Author: Antikris Posts: 1340

---

Glad to see my diagram was correct. Yeah, I tried to make sense of that (but was distracted) and wasn't sure if I was describing the same system. Edit: On second glance, I think the confusion arises from the fact that you called the tag a sensor. I had no idea what that sensor was meant to be, nor how it connected to the connector! Then, the bottom tag sensor is the thing to provide the off state signal, but it was shown as receiving it. My head didn't like that diagram. Heh. Also, you don't need to set the minimum radius on the resetting tag sensor. Tag sensors don't read tags on the same circuitboard.

2011-02-09 02:48:00 Author: comphermc Posts: 5338

---

Edit: On second glance, I think the confusion arises from the fact that you called the tag a sensor. I had no idea what that sensor was meant to be, nor how it connected to the connector! Then, the bottom tag sensor is the thing to provide the off state signal, but it was shown as receiving it. My head didn't like that diagram. Heh. Also, you don't need to set the minimum radius on the resetting tag sensor. Tag sensors don't read tags on the same circuitboard. I just noticed my mistake. Yes, that should have been named a Tag.

2011-02-09 07:16:00 Author: Antikris Posts: 1340

---

Having spent last evening putting Comph's design into practice, I have a few observations/suggestions. First off, following the design word for word, there seemed to be a significant delay before the replacement sackbot appeared at a checkpoint. The emitter would be activated immediately, as I could tell from seeing the input cable illuminated at the right time, but it was anywhere from 2 -5 seconds before the emitter would actually emit. It seemed as though it wouldn't recognise previous sackbots as "destroyed" until a few seconds after their death. Also, setting the emitter to "one shot" instead of "on/off" meant that it didn't emit anything at all. So I figured if the game doesn't register a sackbots death until a few seconds later, then maybe the "destroy oldest" option needs to be set to "yes". It worked perfectly. Instant respawn when combined with a one-shot setting. For a fast camera pan to the respawning site, I also recommend setting the speed of all followers to the max of 100 and set the emitter to "ignore parent velocity". If you give the follower that tracks the sackbot and the sensor that detects it both a maximum radius of 5000, this will safely allow you to set the max speed without the risk of your hologram mounted controllinator zooming right past the newly spawned sackbot and leaving you stranded.

2011-02-09 09:49:00 Author: Ungreth Posts: 2130

---

Actually, Ung, the emitter not detecting the object as destroyed is a glitch, and most of the time it wont work until you tweak the settings to destroy oldest as you already said. I think it's caused by changing the setting after the sackbot is already destroyed, not sure. I think emit once might be borked in this situation.

2011-02-09 09:59:00 Author: Bremnen Posts: 1800

---

The delay only seems to exist when using a destroyer, but I think it might only be specific destroyers. If you plunk the sackbot in water, the respawn is instant. If he drops into fire, it's again instant. But if you use the Splat setting on the destroyer, I know for a fact that it takes a good 3 seconds. I have a theory in that it won't spawn until all of the destroyer effects have disappeared. Thus, Splat would be the worst offender, since the effect is a very long process. I haven't had a chance to test that thoroughly.

2011-02-09 11:40:00 Author: comphermc Posts: 5338

---

But if you use the Splat setting on the destroyer, I know for a fact that it takes a good 3 seconds. How about, instead of using the emitter to decide when to respawn the Sackbot (based on "Destroy Oldest" being set to "Off"), you use the absence of the Sackbot's tag? It's possible the game engine deems the tag to be destroyed before the Sackbot is. Haven't tested this theory tho'.

2011-02-09 12:59:00 Author: Aya042 Posts: 2870

---

How about, instead of using the emitter to decide when to respawn the Sackbot (based on "Destroy Oldest" being set to "Off"), you use the absence of the Sackbot's tag? It's possible the game engine deems the tag to be destroyed before the Sackbot is. Haven't tested this theory tho'. Then the emitter still needs to wait before it can spawn another sackbot, because the "splat"procedure is still going on. Even if the tag already is gone, and thus switches the emitter on, there is still a "dieing" sackbot.

2011-02-09 13:13:00 Author: Dexist Posts: 570

---

Then the emitter still needs to wait before it can spawn another sackbot, because the "splat"procedure is still going on. Even if the tag already is gone, and thus switches the emitter on, there is still a "dieing" sackbot. Sorry. I thought it was clear that I meant you should turn "Destroy Oldest" on, thus allowing it to spawn before the previous one is fully destroyed.

2011-02-09 13:26:00 Author: Aya042 Posts: 2870

---

Honestly, the only necessary adjustment to comph's design is to turn "destroy oldest" on with a one-shot input to the emitter. Simple as that. It works perfectly, emitting the new sackbot instantly.

2011-02-09 19:07:00 Author: Ungreth Posts: 2130

---

Honestly, the only necessary adjustment to comph's design is to turn "destroy oldest" on with a one-shot input to the emitter. Simple as that. It works perfectly, emitting the new sackbot instantly. But wouldn't that also respawn a new Sackbot any time you happen to pass a checkpoint? You need some way to detect the active one has died, surely?

2011-02-09 21:06:00 Author: Aya042 Posts: 2870

---

But wouldn't that also respawn a new Sackbot any time you happen to pass a checkpoint? You need some way to detect the active one has died, surely? Actually, after playtesting again, you're right. The sackbot flickers as it passes a checkpoint and can't jump in front of it, presumably because it's switching bodies at that point. Back to the drawing board. I also observed something today which may be related to the anomaly of the emitter delay. On shooting a sackbot with a plasma ball it evaporated, but for a moment while the destruction effects (splat) were still visible, a second plasma ball in the volley of shots hit the splatter effect and just hung there in the air as though it had hit a wall. So it would seem the theory posted earlier may hold true, that the emiiter doesn't fire immediately because although the trigger tag is destroyed, the creature technically remains present for a second or two.

2011-02-10 18:13:00 Author: Ungreth Posts: 2130

---

I thought I'd throw my two cents in here and direct you to my Sackbot Checkpoint Tutorial (http://lbp.me/v/xgk2qy) level. How it works is I put a chip onto an actual Checkpoint with a Player Sensor and a Tag Sensor (each with a trigger radius of 9.0, ~the size of the checkpoint), wired to an OR gate (the Tag for this Sensor should be on the Sackbot). The OR gate trips a state on a selector, and the same state's output activates a tag on the Checkpoint and activates the Checkpoint itself. You wire all of your level's checkpoints into the selector the same way, which will track which one has been activated most recently and turn on its tag. You then make a piece of hologram with your Sackbot emitter and a Follower on it. The Follower looks for the Checkpoint tag and travels toward it with maximum speed. The Emitter is set to only emit 1 Sackbot at a time, and NOT to destroy the oldest emitted. This means you don't need a Tag Sensor to determine whether your Sackbot is still alive, as the emitter will be keeping track for you. It also allows a player to activate a Checkpoint for a Sackbot, and vice versa. Furthermore, even if you don't have any Sackboys in the playing field, it looks more natural to the player using an actual Checkpoint. It's purpose is clear and they know when they've activated it. EDIT: I forgot to mention, I really dislike the method of having a hologram with the player on it buzzing around the level. I placed a movie camera on a piece of hologram and had that track the Sackbot instead, keeping the player in one spot for the duration of their control. I feel that this gives me more freedom in designing levels, since I can then design a system that allows you to take or relinquish control of a Sackbot at will, opening a door for new game mechanics.

2011-02-10 20:53:00 Author: Unknown User

---

EDIT: I forgot to mention, I really dislike the method of having a hologram with the player on it buzzing around the level. I placed a movie camera on a piece of hologram and had that track the Sackbot instead, keeping the player in one spot for the duration of their control. I feel that this gives me more freedom in designing levels, since I can then design a system that allows you to take or relinquish control of a Sackbot at will, opening a door for new game mechanics. Good luck making that work with 2+ players.

2011-02-11 03:44:00 Author: comphermc Posts: 5338

---

Good luck making that work with 2+ players. I'd actually bet that it'll work perfectly fine, Mr. I'm Going To Prejudge Your Idea With My Rolleyes Emote. The level I'm designing currently is intended for single player, but it's not like I haven't put any thought into how the system could work with more than one person. If you meant specifically the part about relinquishing control of the Sackbot, then yes, you would need everyone to relinquish control since you can't have a camera on the bots and the control room at the same time. but hear me out here. I haven't put it together and playtested it yet, but I have a system in my head for designating a group leader among Sackbots. This player would be given priority in decision making and the camera would be modified to always follow the player with the highest priority. If a player dies, priority passes to the next living player until it is recalculated when everyone is dead. The Checkpoint system would be amended to make sure that either all players are dead or that at least one is onscreen before respawning any of the Sackbots, and the Sackbots would have an added chip to determine when they are offscreen, triggering a kill timer just like Sackboy's. This function can also be disabled when the player is not in control of the Sackbot so that it doesn't die when the camera returns to the control room. I'm kinda more interested in putting together a different project at the moment, but I guarantee I can give you a working model of this by the end of the month.

2011-02-11 08:07:00 Author: Unknown User

---

Funny, funny. Last night I spoke to deviantgeek about this, and 5 minutes later he had produced a perfect respawning sytem that urinates all over the designs being debated here. It's totally modular, simple to understand and very quick to install. He's posted it in the Object Showcase if anyone's interested.

2011-02-11 15:05:00 Author: Ungreth Posts: 2130

---

It sounds almost identical to a system I had running in the beta. I had a set of microchips that turn on and off tags at each checkpoint location and a follower hologram that moves to that location? It came out as 2 tag sensors, a tag and a hologram per checkpoint chip, and an emitter, a follower and a tag sensor on the following hologram. You just place down checkpoint chips at each location, they turn each other on and off in a mutually exclusive way, via wireless comms and the emitter hologram just follows the new tag that is activated, emitting a new bot on destruction of the previous. Adding a new checkpoint is as simple as placing a microchip.

2011-02-11 16:20:00 Author: rtm223 Posts: 6497

---

It sounds almost identical to a system I had running in the beta. I had a set of microchips that turn on and off tags at each checkpoint location and a follower hologram that moves to that location? It came out as 2 tag sensors, a tag and a hologram per checkpoint chip, and an emitter, a follower and a tag sensor on the following hologram. You just place down checkpoint chips at each location, they turn each other on and off in a mutually exclusive way, via wireless comms and the emitter hologram just follows the new tag that is activated, emitting a new bot on destruction of the previous. Adding a new checkpoint is as simple as placing a microchip. Yeah, that's pretty much how it works. It's a nice simple design, very user friendly, with no obvious flaws as far as initial playtesting shows.

2011-02-11 16:24:00 Author: Ungreth Posts: 2130

---

It shouldn't have any flaws at all, unless 2 checkpoints can be triggered at exactly the same time - both would set, but not reset. For most cases this would be no issue (because the chances of it happening are stupendously slim to none (depending on your set up) and actually, by having a single emitter you'll always have a mutually exclusive spawn point (which would be the same effect as the losing / further away checkpoint being triggered a fraction of a second earlier and is thus acceptable behaviour). Id suggest that any effects / visual cues you have to indicate which spawn point is active are based upon the presense of the follower, not the internal state of the counter in the device. Note, behaviour is slightly altered in terms of conflict if you have select-based set-resets than counter-based. The counter is closer to typical LBP checkpoints, in that you can activate a new one even when someone is standing in front of the currently active one - selectors would prevent this.

2011-02-11 16:43:00 Author: rtm223 Posts: 6497

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.