Archive: 9 posts

---

Please let me know if you have a better title for this after you read the explanation: This is quite revolutinary: If we can have dynamic tag names that can be set at time of the object being emmited, through the use of keywords, it would be more than awesome. These keywords would stand in for stings that would replace the keyword, at the first level of emmision. Any subsquent emission from the emmited object would result in the same keyword as the parent. This would allow us to emit objects with signaling systems without name collisions with other emitted objects in the level (tags, tag sensors, followers), to rephrase: this would allow us to have objects that have unique signaling properties that work within itself, without breaking the signaling of other elements in the level. How should it work: We can have different keywords for the tag names within any emitted objects. So far, I thought of two keywords: &&objectid : This is a unique number that is generated at time of emission. &&playerid : This is the player id that is inherited from player data. &&objectid is the more important, and second one may not be necessary. How it does its job: We have an object that we will emit, and we can populate it with tags, tag sensors, and followers. When giving name to the tags, we can use the &&objectid keyword e.g. waypoint_tag&&objectid . We can have followers in the emitted object or its emitted children that follows the tags within the emitted object. When the object is emmited, the &&objectid is replaced with the unique id of the object. This way, the tags / followers within the emitted object would NOT cause interference with other emitted objects, creating signalling systems that are unique to the emitted object and its children, allowing us to create signalling sub-systems that don't create problems for each other. This would be immensely useful, I hope MM likes this idea somehow!

2011-06-12 17:17:00 Author: hesido Posts: 166

---

Few issues: -Tag Sensor becomes ... not Tag Sensor, tag should be tag not player, they should add extra tweak that allows to select tag or player -It's too complicated in MM's level of complicity, same as above, insted of using labels they should make extra tweaks and implement it in to UI, why making underground out of it? -WIth labaing emit count id, what happens if i want to detroy emited object and i want the following objecyt to follow next object? -What if i emit pair of objects and there ids will get unsync? theres need to be some outomatisation in to that

2011-06-14 15:03:00 Author: Shadowriver Posts: 3991

---

Hi Shadowriver, thanks for bringing these issues. 1) Tag sensors will keep on being as tag sensors. I'm not really interested in &&playerid as much as &&objectid , but the controllinator that the player is in will pass on the player number to the tag name. Any emitter that is tied to the controllinator will inherit the player number, using the player data, the same and already in-place signaling that is maintained for scoring. For example, you put a tag with the name "playerseat&&playerid". The player's controllinator could emit a sidekick that follows the player, and the sidekick could have its own followers without being interfered by other players sidekicks. But since there would be 4 players at most, all these could be done by hand, by giving each of them unique colors and/or names. So yeah, I'm not really after &&playerid 2) I'm a script programmer, and I don't think this is complicated at all. It's just a basic string replacement for emmitted objects, a string that is unique to the *first* level of emmited objects. You will be even allowed to view the resulting tagnames, as this would be only way to debug the emmited systems. The replaced tagnames would only be present in the emitted child objects. 3) If something is possible using the current system, you could still have a logic using the current system. If what you want is not possible currently, and this suggestion still does not make it possible, you could come up with a different suggestion, but this is not in the scope of this suggestion. 4) Any subsequent objects that is emmited from the parent object will have the same object id. So the id will be inherited. Therefore, if you want to emit separate objects with the same id, you will emit it from an emitted object, which will have the same synced id, so this will not be a problem. This suggestion is about creating signalling sub-systems that do not break eachother, and it has implications for: *Emitted follower systems that do not break eachother. *Emitted signalling systems that do not break eachother. Among the lots of useful stuff this system would bring, here's an example use: This will allow us to do screenspace optimizations for lots of moving stickered objects. The stickered holograms on moving objects could be emitted at will, when they enter the screen area (Turning all the frames off does not free up the sticker limit) I actually use this optimization for static objects in the boulder dash level with the retro graphics, otherwise it is a white mess, but I can't use this optimization for moving objects. I have a solution for it but it makes each object much more complex than necessary, and since it uses signalling with the same namespace with other objects, it is not bulletproof.

2011-06-14 21:23:00 Author: hesido Posts: 166

---

Oh i get it ^^ label string replacemnt, theu it's still quite complicated fro MM standard, there policy is to make things simple as much as possible. I was suggesting to implement player specific tweaks not only for follower but also score giver and sensor for versus and for that tweak should do the job If you need chained waypoint system via tags you can try switching colors each waypoint and switch folower via selector each waypont, this is what people do with tower defences.

2011-06-15 00:51:00 Author: Shadowriver Posts: 3991

---

Good ideaz! But.. what if two objects are emitted in the same frame?

2011-06-15 02:16:00 Author: Unknown User

---

This is very good idea but it is pretty complex and there is still problems in it. What prevents the destruction of the parent object/emitter? If I got it right that would destroy the system. And what about transferring data other way? How it would handle multiple emitted objects? I think it would be better just have way to connect wire to emitted object by adding more inputs to emitter and having outputs inside the emitted object.

2011-06-15 13:31:00 Author: waD_Delma Posts: 282

---

@waD_Delma : The destruction of the master/parent object should not destroy the system. Any children that is emitted from a child object of the master/parent will inherit the replaced value. Every emitted object with the keywords will look for the objectid value, which is stored in its parent objects emitters. I can make a video or diagram of it if I'm not explaining this correctly. Any non-emitted object (that we put in there using the goodies bag, for example) will have the keywords non-replaced and visible. Let's call non-emitted objects 1st level objects. Let's call any emitted object 2nd level objects. Let's call the children of the 2nd level objects 3rd level objects, and so on. 1st level objects would have an emitter or emitters on it, that would emit objects with unique objectid's replacing the keywords. All 2nd level objects would have unique id's. All 3rd level objects would inherit values from their parent. LBP actually keeps track of the levels of objects, from what I've seen. For the optimization trials I did, I made self emitting objects that emitted simpler versions of themselves with simpler logic and no stickers, and destroyed themselves, and when there's the need, the simpler version would emit the complex one and destroy itself, creating a circular reference! Even tho the parent destroyed itself, this would go on for 10 times, so the 10th emitted object was not allowed to emit anything any longer, although there was no parent anymore to add to complexity. I was quite surprised LBP could allow circular references in emitted objects, I still don't know how they store that information But of course the circular reference doesn't cut it, because when after the 10 times this happens, the 10th object kills itself. About the wire proposal, that's a good solution to control stuff inside the emitted object and without interference too, but it could be more complex than to implement string replacement for tags with keywords. There'd have to be a good interface for it to be understandable. It is not impossible of course. But this still wouldn't let us create non-interfering followers, for example, which the tag keyword solution can provide. So wires would solve problems, but only some of it, but a signalling system would handle both what wires would do, and also add support for discrete follower systems.

2011-06-15 14:32:00 Author: hesido Posts: 166

---

All 3rd level objects would inherit values from their parent. That where the problem lies. If I destroy the master object, will the 2nd level objects turn to master objects? If not, how the 2nd level object know that they aren't transferring/receiving data? it could be more complex than to implement string replacement for tags with keywords. IMHO I think that it would be easier system to grasp as it is graphical. But this still wouldn't let us create non-interfering followers, for example, which the tag keyword solution can provide. I didn't think that but there could be option to use the emitter itself as tag.

2011-06-15 15:15:00 Author: waD_Delma Posts: 282

---

@waD_Delma: "Follow parent emitter" would be nice indeed. Actually that alone could solve my particular optimization problems. But the tag keywords can bring so many opportunities to the table that it is hard to pass that scheme up. If parent objects are destroyed, 2nd level objects will keep on being 2nd level objects. They will keep their tag names, and their signalling systems would go on functioning like before, and they could continue emitting 3rd level objects (which LBP already keeps track of). It's not likes wires are being used. The concept doesn't work like cascades. So a 2nd level object can signal a 5th level object (which has the same tag keyword replacement) even when all the 3rd and 4th objects are destroyed. A 6th level object can signal a 3rs level object even when all other objects are destroyed. The first level objects cannot specifically communicate with any 2nd and lower level objects, as it doesn't have the keyword. It can message all of them tho, through normal tags without keywords. The first level objects just emit the 2nd level objects, which creates those isolated subsytems (isolated in the sense that they can still use generic tags to talk to the rest of the game world)

2011-06-15 15:52:00 Author: hesido Posts: 166

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.