Archive: 20 posts

---

I think that a switch that could be attached to an object that triggered "On Destruction" would be handy. I notice the problem when using emitters, I want an object to stay "live" for eterntiy, but if it gets destroyed somehow like pinched somewhere, I would like to emitt another one. Is there a way to do that now? Ted

2010-06-07 13:58:00 Author: Muskwa_1 Posts: 213

---

Yes, there is. Make an emitter set to emit a little piece of dark matter with a key on it. Max emitted = 1, lifetime = infinity, timing = .1 seconds. Put a grab switch on the object that is set to be destroyed. Preferably on something not grabbable. Then wire the grab switch to the emitter. When the object is destroyed, it kills the grab switch and the emitter is free to emit its key. Tada.

2010-06-07 21:21:00 Author: comphermc Posts: 5338

---

Yes, there is. Make an emitter set to emit a little piece of dark matter with a key on it. Max emitted = 1, lifetime = infinity, timing = .1 seconds. Put a grab switch on the object that is set to be destroyed. Preferably on something not grabbable. Then wire the grab switch to the emitter. When the object is destroyed, it kills the grab switch and the emitter is free to emit its key. Tada. Hahaaa, Comph! You've got an answer for everything! ;D

2010-06-07 21:29:00 Author: piggabling Posts: 2979

---

Generally, that's an overly complex method and only really needed if you need the object to travel far. An inverted magnetic switch detecting a magnetic key on the object will normally suffice. of course both methods get a little bit more complex if you have an emitted object made up of multiple objects and you need to detect if any of them are crushed, at wich point a winch-based OR, where the removal of an input makes the connector start to move, would be pretty effective. If you are good with your emitter blocking then you wouldn't actually need any magnetics for the OR gate

2010-06-07 21:58:00 Author: rtm223 Posts: 6497

---

I thought the rtm223 way. Though compher's way isn't THAT complex (why the 'key' there? Isn't the grab switch enough?). But, all extra fluff to easen up our life is welcome, isn't it? They made the Bounce Padz! if there's a-plenty of them objects, I'd use the grab switches with it: set it to directional inverted, take the OR gate (the version where pistons retract to activate) and connect. Voila. Of course, attach the OR sensor to a demitter.

2010-06-08 06:22:00 Author: Unknown User

---

Wow, responses from the "big guns"...I am impressed... Thanks guys... So you area saying that if I have an emitter in the scene stationary and the switch on the moveable object that will be emitted, that the next moveable object emitted will still be connected to the stationary emitter in the scene? If that is the case then it is simplified. I will try that tonight... Ted

2010-06-08 14:07:00 Author: Muskwa_1 Posts: 213

---

I think I misunderstood your issue, in which case, go with rtm's suggestion. I assume you are making efforts to make your level fail-safe?

2010-06-13 12:12:00 Author: comphermc Posts: 5338

---

Are you kidding me? I didn't know there was already a way to do this! Jeez, so many times where this could have come in handy.. Thanks for clearing things up guys. (:

2010-06-14 05:13:00 Author: Mastadom Posts: 195

---

"On Destroction" switch actually good idea anyway both by crash or explosion and sound element already has it in LBP1, it might be useful

2010-06-14 13:46:00 Author: Shadowriver Posts: 3991

---

Except it won't work, without a massive change to the logic system in LBP. If the object that your on-destruction switch is on is destroyed. The switch is destroyed so the wire coming off of it would also be destroyed, leaving the destination object uncontrolled by any kind of switch. This effect is exactly what happens if you use comphermc's method above, making the concept a little bit redundant. It works with sounds because the sounds are destroyed along with the object to, so it's all self contained, but for it to work as a general purpose switch you would need to have the destination destroyed along with the object, making it very limited.

2010-06-14 14:03:00 Author: rtm223 Posts: 6497

---

You don't think deeply in to issue this switch can be still alive same as LED does, but then on crash it might not work. It's possible to workaround it to make in more usable, maybe not via switch but something else, and you don't need to massivly change logic.

2010-06-14 14:37:00 Author: Shadowriver Posts: 3991

---

It could be a combination switch and emitter possibly with color codes to allow more than one set in a session. When the switch is destroyed the emitter can emit another object with a switch attached. Ted

2010-06-14 15:16:00 Author: Muskwa_1 Posts: 213

---

But what happens if we got more objects emitted at ones?

2010-06-14 16:39:00 Author: Shadowriver Posts: 3991

---

Well it can be configured to a specified number allowed active at one time. If there is one allowed and the existing one gets destryed it will emit another one. If it was set to 3 mximum and one got destroyed it would emit one more. Ted

2010-06-14 21:14:00 Author: Muskwa_1 Posts: 213

---

I think that you solution is too complex even for LBP2 and it should be part of something bigger beyond what we see in LBP2 i say what you saying is spark of bigger more complex event system... but i don't think LBP will go this way looking on what we have now. Actiually i notice that "On destraction" is some what possible on LBP1, but it's not possible with destruction of whole emitted object

2010-06-16 00:56:00 Author: Shadowriver Posts: 3991

---

I read somewhere that LBP2 emitters will let you select some object on the screen so that may do what I am thinking. Ted

2010-06-18 14:59:00 Author: Muskwa_1 Posts: 213

---

Well it can be configured to a specified number allowed active at one time. If there is one allowed and the existing one gets destryed it will emit another one. If it was set to 3 mximum and one got destroyed it would emit one more. There is a feature to do this in LBP2, although it's not really a "on destroy switch" - it's more limited than that. It's still a fantastic feature though I read somewhere that LBP2 emitters will let you select some object on the screen so that may do what I am thinking. That's a different feature that allows you to effectively modify the object inside all of your emitters without recapturing and tweaking the emitters themselves - just modify the object in the level and the emitters auto-update

2010-06-18 15:10:00 Author: rtm223 Posts: 6497

---

True, that was in the article as well. But I am sure there was something said about selecting objects on the screen with switches on them that will stay connected when the next one is emitted. Cool feature though with emitters within emitters etc. and all updating with changes with changes to their emitted objects. Ted

2010-06-18 15:18:00 Author: Muskwa_1 Posts: 213

---

Which article was that? I didn't see this in game and no one mentioned it at MM. In honesty it doesn't sound like it could actually work with the emitted object linking back to the main level (possibly the other way around, but it doesn't make any sense for the emitted object to be the source of the signal, because you can have multiple emitted objects and only one source).

2010-06-18 15:24:00 Author: rtm223 Posts: 6497

---

I was searching for a "Material" list the other day and came across it on a site I hadn't seen before. It had a link in the article to a viceo had the developers, including Johnee, doing a little talk at the begining. I have been looking around this morning and cant seem to find it. I am sure it wasn't on LittleBigWorkshop.com or LittleBigLand. Ted

2010-06-18 17:19:00 Author: Muskwa_1 Posts: 213

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.