Home    LittleBigPlanet 2 - 3 - Vita - Karting    LittleBigPlanet 2    [LBP2] Ideas and Projects
#1

Giving unique id's and signaling channels to emitted objects

Archive: 43 posts

I have devised a method to give unique signaling channels to emitted objects. Not being able to use emitted object specific messaging or followers has been a pet peeve of mine for quite a while. (https://lbpcentral.lbp-hub.com/index.php?t=58086-Dynamically-generated-tag-names-using-keywords)

I have a working proof of concept with 10 channels (10 objects emitted together or at random times being assigned to different channels, without intereference), but the technique could easily be scaled and modified.

The first applications that come to my mind are
*emitted objects using discrete tag / follower systems (which is displayed in the proof of concept)
*emitted objects signaling their emitted sibling without interference
*signaling a specific emitted object without interference
*multi-channel verified counting on emitted objects

The system can be used for all sorts of games where each unit may require discrete signaling, unique tag / follower systems (an object emitting a destination of its own)

I'll bump the thread with a video later on, it might help understand its uses, hopefully.
Anyone interested in this? It is too hard to make a tutorial out of it, but the system is easy to operate.		2011-07-12 22:25:00

Author:
hesido
Posts: 166

I assume either each emitted object has a large bank of tags present on them, or, that you're aligning a tag sensor bolted to the object with a narrow radius to point at different transmitting tags which represent different channels?

I'm more interested how the signals/tags are being assigned. At a guess I'd say each time something is emitted a selector is cycled to the next channel/tag. What if the emitted components were destroyed in a different order to what they were emitted in? Would that mess up which signalling channels were assigned to each object or is the assigning process handled dynamically to avoid this problem?		2011-07-12 23:02:00

Author:
Ayneh
Posts: 2454

Hi Ayneh,

That's the beauty of it. I use a central detector that looks for open channels, and brodcasts this when requested. Each emitted object request the open channel from this central system. Whenever an emitter in the middle is destroyed, the channel is open. I use analogue signals from a counter, coupled with sequencers to hold the tags / sensors / followers.

I'd like to show you the sytem if you like. Anybody interested can add me to the PSN with a note like LBPcentral. I'll be on for the next hour.		2011-07-12 23:17:00

Author:
hesido
Posts: 166

This is what you messaged me about, right? I tried to join, but it failed multiple times, so I gave up. Try joining me next time I'm on. If it doesn't work, I'll give you the key to my current version, just to see what I'm using. It's basically a modified 'nearest player controlled' DCS, but with channels similar to what you explain.2011-07-12 23:56:00

Author:
SSTAGG1
Posts: 1136

This is all such a coincedence. I was about to write a tutorial on this subject the coming days. My methods are a bit less grand, though. I do not use a central channel detector, but instead a selector that cycles through half a dozen tags to assign.

I use it when emitting squadrons of enemies; an invisible bonus follower goes after the squadron and emits bonuses when the entire group is destroyed, regardless of order. In another instance, I am emitting 10 drones that all follow the drone in front, creating a snake-like motion.		2011-07-13 00:11:00

Author:
Antikris
Posts: 1340

@sstag1: Yeah, exactly. I thought you weren't interested at all. My bad.

@Antikris: I don't want to make a tutorial out of mine. Just disseminate this to advanced logic people so the idea can be built upon. Maybe you can make your tutorial with a pirate theme? :=)

I use the central channel detector to speed up the next channel assignment, kind of like a buffer. My first iteration was like yours, the channel seeking was done in the emitted object. It would create a lot of latency if I was to scale this to, say 30 elements, the 30th element would take quite a long time to get to the 30th channel. (there's still added latency if all such objects are emitted all at once, they wait for their turns to get the empty channel, but things are quite fast if you emit stuff at different times.
I thought I had it easy, keeping the channel assigner in a central position, making the emitted objects simpler, but I had to solve lots of messaging problems because of it. But I'm sure this concept can be built upon and modified to perfection by you people, if there's not a better solution already (maybe your method is already better, can't say)

In my system, when the object is assigned an id, it also starts signaling it, its emitted "ilk" learns that id, and tune themselves up. A bit hard on the thermo, but the learning is instantaneous. The learner chip then destroys itself to go easier on the thermo, after it has passes that information to analog memory cells where needed.		2011-07-13 00:33:00

Author:
hesido
Posts: 166

@Antikris: I don't want to make a tutorial out of mine. Just disseminate this to advanced logic people so the idea can be built upon. Maybe you can make your tutorial with a pirate theme? :=)

Sounds good. I'll see what I can come up with. It has to be a practical example that gives the reader enough insight to adapt it to his own ideas.


In my system, when the object is assigned an id, it also starts signaling it, its emitted "ilk" learns that id, and tune themselves up. A bit hard on the thermo, but the learning is instantaneous. The learner chip then destroys itself to go easier on the thermo, after it has passes that information to analog memory cells where needed.

I really want to see this!

You know, weeks ago, when I knew less, these concepts were like abracadabra to me. Next I am making stuff that is the most advanced I have ever made and just another week later I look back on it and already shrug "This stuff is now outdated and easy". Funny.		2011-07-13 07:29:00

Author:
Antikris
Posts: 1340

Sounds interesting. I have something like this for passing information from emitted sackbots to a central monitor system. I wanted it to be "infinitely" scalable, and it didn't have to be fast, so I used one tag and had the sackbots claim a timeslot as their channel. Each timeslot needs 2 frames, and there's always a free slot at the end, so if you have 14 sackbots you'll have one transmission cycle per second. IIRC.

How scalable is your solution? What do you use as channels?		2011-07-13 12:30:00

Author:
Rogar
Posts: 2284

How scalable is your solution? What do you use as channels?

Mine is not designed to be scalable, just a practical solution to a walled problem. I use a counter hooked to an analog signaling tag. Increase the counter whenever a squadron is made (5 units are then produced), the analog signal goes up. Every unit in a squadron that gets created has a brief neutral moment in which it picks up the analog signal through a tag sensor, wire it to a pos sequencer (these are slow in their response!) loaded with batteries. I stream each battery output through a node on a microchip into selector gates, port #2 and up; port #1 keeps the chip active, so once the selector is set to a different port, the receiving signal is cut and the memory is set. Port #2 and up are hooked to unique tags, "squadron1", "squadron2", etcetera.

This setup leaves room for scaling, though. Just up the counter, add more batteries on the sequencer, inputs on the selector and more tags. Not that I need any. There won't be more than 5 squadrons on screen at all time and I have no reason to unique-ID every individual unit on the screen.

I think I will set up my tutorial this way: use it to emit 4 unique-ID sackbots (+follower) for a max. 4-player level, with an offscreen sackbot template captured by the emitter. You know there will be only 4, so there is no need for a super flexible system. It will keep down the complexity of the tutorial.		2011-07-13 15:31:00

Author:
Antikris
Posts: 1340

Hi guys,

I'm showing the systems capability in a video:


http://www.youtube.com/watch?v=bwm9BcpbF04

My system is scalable to a great extent. It's just a matter of adding more tags to the sequencers, and just adjusting the source counter number. You can have one set of tags, one set of sensors, one set of followers and use them everywhere you would normally use a tag, sensor, or follower.

I'll be on PSN for the next hour, but sometimes might be away from my ps3.		2011-07-13 18:29:00

Author:
hesido
Posts: 166

Bah, if I could join you, I would. That looks like an incredibly useful tool, especially for when I add AI patrol units to my game.2011-07-13 19:16:00

Author:
SSTAGG1
Posts: 1136

It sounds awfully overengineered to have a central management module for achieving the assignment of channel. Each object should be able to comfortably query the channels that are available at the moment that they are spawned and pick for themselves the lowest indexed free channel, and store that value in a selector the frame after spawning. Unless I've missed something, it seems a lot neater and simpler to do things this way


Edit, grabbed this image off my moon. It's actually a stripped out version of what I was using to create:

emit 4 unique-ID sackbots (+follower) for a max. 4-player level, with an offscreen sackbot template captured by the emitter.

The following is a completely modular object and follower set up. upon spawning, the object takes ownership of the highest indexed free channel (by simply looking at what channels are already taken). The channel is freed once the object is destroyed. Other freeing methods could be implemented -as soon as the tag is no longer active, the channel is free, so just adding an extra input to the selector could be used to release the channel that is currently owned and subsequently you could grab a new channel, if you wanted.

http://www.lbpcentral.com/forums/attachment.php?attachmentid=35562&d=1310593888

Note: the tag sensors are inverted... They should all actually be active in this image (indicating that all channels are free), but I took it in pause mode.

You have issues with more than one object trying to take ownership of free channels at the same time, which can happen if they are spawned simultaneously, or if you emit n+2 or more objects for n channels and then a channel becomes free. this can normally be handled in level design though, or if you feel like going for the belt and braces approach, you could implement some collision detection with a backoff algorithm which shouldn't be too hard.		2011-07-13 22:13:00

Author:
rtm223
Posts: 6497

It sounds awfully overengineered to have a central management module for achieving the assignment of channel. Each object should be able to comfortably query the channels that are available at the moment that they are spawned and pick for themselves the lowest indexed free channel...

...assuming you're comfortable with a potential channel collision should two objects be emitted on the same frame.

However, I'm still not clear on the practical applications for any of this.		2011-07-13 23:02:00

Author:
Aya042
Posts: 2870

...assuming you're comfortable with a potential channel collision should two objects be emitted on the same frame.

Pretty sure you'd get the same issue if 2 objects queried a master system at the same time. Either way you have to accommodate for collision, in one way or another. As I was emitting all objects from the same emitter, collisions can be easily avoided



However, I'm still not clear on the practical applications for any of this.

I wanted to emit 4 sackbots with a health bar that follows them and I didn't want to make 4 duplicate sackbots with just slightly different colour tags and then maintain 3 extra sets of logic, so it was easier to emit 4 instances of an object that would configure itself at runtime.		2011-07-13 23:05:00

Author:
rtm223
Posts: 6497

http://www.lbpcentral.com/forums/attachment.php?attachmentid=35562&d=1310593888
Looks similar to what I have. Initially I thought hesido's design escaped the limitation of requiring premade channels, which would be amazing . Seems like the same thing though .

Hesido, could you post a pic of how you set up the channel selection. I still haven't seen it, and am curious how you went about doing it.

EDIT: Also, is it better on the thermo to make these self-configuring creations, or just emit a separate creation for each configuration? I'm thinking its better using these channels, but just making sure.		2011-07-13 23:16:00

Author:
SSTAGG1
Posts: 1136

Pretty sure you'd get the same issue if 2 objects queried a master system at the same time.

Hmm. You're probably right. I assumed the 'master system' was somehow analagous to some sort of semaphore system for thread synchronization. I s'pose I should've checked out the example first.



I wanted to emit 4 sackbots with a health bar that follows them and I didn't want to make 4 duplicate sackbots with just slightly different colour tags and then maintain 3 extra sets of logic, so it was easier to emit 4 instances of an object that would configure itself at runtime.

Can't you just bolt the health bar to the sackbot?

I guess it's a little more elegant than the case-n'-paste (http://catb.org/jargon/html/C/case-and-paste.html)-type solution, although I'm surprised a thermo-obsessive such as yourself would dare suggest such a thing.

I actually did that with the Spacewar ships, so I might have to check this out once I get back home to my PS3.		2011-07-13 23:30:00

Author:
Aya042
Posts: 2870

However, I'm still not clear on the practical applications for any of this.

My sackbots have emotions, and I wanted to determine which emotion was prevalent, so I had each bot claim a timeslot and a monitor to tally each cycle and signal the start of a new one. I'm open to simpler solutions, I couldn't think of any myself.


Initially I thought hesido's design escaped the limitation of requiring premade channels, which would be amazing

Yeah, that's why I used time slots as channels. The system can dynamically add more time slots at the end, extending the total transmission cycle. If speed is not a requirement, of course. And you're right, I am amazing. 		2011-07-13 23:49:00

Author:
Rogar
Posts: 2284

Hmm. You're probably right. I assumed the 'master system' was somehow analagous to some sort of semaphore system for thread synchronization. I s'pose I should've checked out the example first.

Those kind of muttexing systems get kinda fiddly in their implementation when you have to make them run with true concurrency, specifically because it's possible for two threads to take a the semaphore at the same time and you generally don't know until after the event. That's all transparent in the application layer, but it is going on somewhere (it has been a while though, I forget the details of such systems)

In lbp, for the kind of application we're discussing here, whether you use a centralised co-ordination system or not, you can't avoid having race hazards so additional logic will be required to account for those scenarios unless you can design. The system to not generate them (which is generally kinda easy). Gut feeling makes me think that cutting out the centralisation will actually make fixing the race hazard easier and simpler (maybe not better - the centralised system would enable you to avoid ever generating a collision, by not assigning valid channels to objects that request simultaneously (just return an error signal to both), whereas the distributed solution would generally require you to have a true collision to detect before you back off, but that shouldn't cause you too much of a problem.

but just don't generate collisions, that's the best way



@rogar: how do you coordinate dynamic timeslicing in your system?		2011-07-14 07:18:00

Author:
rtm223
Posts: 6497

rtm has arrived!

The setup is beautiful for its simplicity. But I think I can't apply this to my squadrons: 5 dedicated squad tags, 5 inverted sensors set to detect 5 of each tag. It works great, but as soon as I kill a squad member at the same time another group is emitted, one member of the other group will adopt the wrong tag.		2011-07-14 07:22:00

Author:
Antikris
Posts: 1340

Probably the entire squad would pick the wrong channel actually. But if each squad is using the same channel, can't you emit the whole squad together and just have the squad "leader" select the squad's channel.2011-07-14 07:56:00

Author:
rtm223
Posts: 6497

Nice discussion, let your knowledge spill! RTM's solution is very elegant indeed, and should be sufficient for a heck lot of applications. I'm going to post my logic here in a few minutes if I can figure out that lbp.me picture. Maybe we throw it in the bin, or we may refine it.2011-07-14 09:23:00

Author:
hesido
Posts: 166

Probably the entire squad would pick the wrong channel actually. But if each squad is using the same channel, can't you emit the whole squad together and just have the squad "leader" select the squad's channel.

And then have the rest of the squad pick up from the leader? That's getting way more complex than I need it to be. Right now, I have a miniature version of a central system that knows when a squadron is being created and signals the fresh, neutral units which tag to use.


Maybe we throw it in the bin, or we may refine it.

Well, the more we learn from one another, the better any tutorial we write will be, right?		2011-07-14 10:26:00

Author:
Antikris
Posts: 1340

but just don't generate collisions, that's the best way

@rogar: how do you coordinate dynamic timeslicing in your system?

It's been gathering dust on my moon for a while, so I don't remember every implementation detail. But basically it's like I explained before: there's a start-of-cycle signal from the central monitor, then a number of time slots in which sackbots await their slot to send a signal, then an empty slot where newly emitted sackbots can jump in.

I made time slots two frames long, the first frame a new sackbot listens if someone's sending, and if not, he claims it by transmitting during the second frame. If you wanted to half cycle time at the cost of slower start of transmission you could instead wait a cycle to start transmitting.

The central system has a counter for how long the cycle should last, and whenever someone claims the empty slot at the end it increases the counter to allow for another empty slot. New sackbots wait for the start-of-cycle signal to start counting and wait for a free slot* , then store the current value of the counter to compare against during the next cycle.

And regarding collisions, I agree. I considered letting sackbots listen for others and in case they hear someone, randomly stay put or find a new slot. But I didn't implement it, because I'm fine with emitting sackbots only once per cycle.


* Which coincidentally could be in the middle of the cycle if another sackbot died and left the slot empty. I've thought about cleaning up empty slots by letting bots move in front if a slot clears, but I don't think I actually bothered.		2011-07-14 10:30:00

Author:
Rogar
Posts: 2284

http://ic.lbp.me/img/ft/05c7e461b6cd5f98956ec2fcfe3468b899118b72.jpg
Above is the central open channel detector. The sequencer holds the id sensors, and it is tied to a counter. If an id tag is detected, it makes sure it adds 1 to the counter. If every tag is full, this keeps on scanning for empty slots. When two requests are detected, I try to block the signaling. It doesn't always prevent it, tho, so I also had to employ a deferrer in the acquiring step.
This is the inside of the sequencer that looks for id's:
http://if.lbp.me/img/ft/25fb526922cf4314829243708f6c7d0ecdb19441.jpg
Below is the id acquire chip (green) and id chip (red). After you're done getting the id, the id acquire chip could be disabled or destroyed (when on a separate object).
http://i2.lbp.me/img/ft/c421bb332eb849640338907896e66339b4cbb522.jpg
The id acquire chip signals that it wants an id, based on the non-presence of other such signals, but it takes at least a frame before it can detect other signals and block itself, that's why it is tied to a 0.1 second timer. This is how collisions are avoided.
In down-left corner of the redchip is a counter, and it is kept open until the id can be acquired. After than it signals that it acquired the id, it enables the sequencer (so the sequencer is inactive until the id is decided). On the top right corner is the d-latch that holds the id information. This information is passed to the positional sequencer, when the id chip receives the final id. It is also connected to a tag that is used to signal the id value, so the emitted children can acquire this id.

This object can teach its emitted children its own id. Preferrably, it should emit that object right on the same spot: Here's the learning chip:
http://i7.lbp.me/img/ft/377fb42edff1b1d03cd3e9cd1d96ba9252ad886f.jpg
That sequencer is just an over-0 analogue tester, when it detects the inherited id, the object is no longer necessary and kills itself. Or it could just turn itself off. This info is passed to d-latches which are tied to sequencers that hold either of these so the objects can function in discrete signaling channels:
http://ic.lbp.me/img/ft/f0c7a5760c44055b76b185471585172b63ba76dc.jpg

The advantage of this system is that you can get rid of the learning chip or the id acquire chip completely, once you acquire the id. I wanted this to be scalable. The selector solution was the first to come up to my head, but I didn't go down that route because I didn't think it was as scalable. The system is complex for just 4-5 objects, when you want to deal with more objects such as 20-30, it should prove a bit tidier, and overall less thermo intensive as at least compared to a selector solution as we don't need to keep the id acquire part for the parent object, and passing this information to any such further emitted objects from a parent object is very simple and non-thermo intensive (I meant, just passing this information along is not thermo intensive, of course the 2nd level emitted objects would come with their own tag sequencers, which will be thermo intensive)

Edit: Rogar's implementation sounds very nice, I wish to re-read it several times and understand it However, can that be used for follower systems? Since I couldn't completely understand it, I can't say.		2011-07-14 10:31:00

Author:
hesido
Posts: 166

what rtm said is pretty much how i've done it in both my Missile Command level http://lbp.me/v/w2-01f (missiles will only move toward the beacon that was placed at the same time)
and for the enemies in my new 3rd person shooter Dem Bones http://lbp.me/v/1g9hte (they need to match a "copy" in another room for positioning purposes)		2011-07-14 10:36:00

Author:
evret
Posts: 612

[IMG]The advantage of this system is that you can get rid of the learning chip or the id acquire chip completely, once you acquire the id.

You can get rid of the ID acquire part of the selector solution as well. Once you've acquired an ID, my solution just switches off the ID acquire chip forever, so you can destroy it if you want. The thermo intensiveness, even for a large number of channels is pretty much equivalent in either system. I'll give you that the selector method is tidier, but all the additional delays etc. just make it more messy and the blocking of signalling with deferrers etc. sounds pretty hacky (partial solutions patched up with partial solutions).

If you wanted a tidy and robust solution, then you could store the ID as an analogue value and use sequencers, yet still lose the centralised assignment module. A backoff algorithm will allow you to easilly avoid collisions and will only add in delays when you need them, rather than always deferring the acquire. That would probably be the best approach.		2011-07-14 11:05:00

Author:
rtm223
Posts: 6497

here is a pic of the logic i used in my dem bones level to get my emitted enemies to select the same tag/sensor set as the emitted "copy" i use to get the ememies to move correctly on the rotating level, it's pretty much the same setup on both.
I'm only emitting one at a time with a max of 10 active at once, but it's easily extendable
http://i2.lbp.me/img/ft/3922332f3e468e98f362038db6aa940fd50f9407.jpg

the counter at the bottom is set to one and inverted		2011-07-14 13:27:00

Author:
evret
Posts: 612

@evret: Thanks for sharing! What do the red chips hold?

@rtm: Thanks for the insight. Sorry, I now see you can easily remove the id acquire chip in your version also. That said, in my requirement, I needed to have the ability to re-acquire an id when necessary, so I needed to keep it, and the potential to avoid holding so many sensors at every object, this seemed to be the better way to go, however, a de-centralized version may also be feasible for other applications.

About delays: There aren't many delays. The only 0.1 second delay that *always* happens is at the time of first acquisition. Other than that, the central system immediately goes to the next active channel, ready to be transmitted immediately when required, and there's the signaling delay.

When multiple objects are emitted at the same time, you'll have back-off delays no matter what system you use. And when you use a back-off system post-acquisition, you'll never be sure if you have acquired the wrong id during the time it takes to understand there's a collision, to begin with. In the post-acquisition back off method, there'll be a period of time when you are not exactly sure if the id you acquired is the correct id or not. So it would not be wise to not do anything until you make sure you backed-off, and try a re-acquisition, and even after that, you'll not be sure if that is a unique id, and this will go on. When you have 10 such objects emitted at the same time, like my video shows (cloned objects during pause should simulate it), this re-acquisiton will go on for a while as they always collide (according to my own tests), only with that single problem: you'll not be sure during that time. However, if you do a pre-back off like I do, the id you acquire would be more dependable. It boils down to whether you'll be emitting stuff from a single source, where you do not need to back off anyway, so you can omit that delay entirely, or whether you may wind up in a situation where there may be multiple acquisition of the same id, then you need to have delay whether you do it before the acquisition or after, until you can start depending on the id of the object.

edit: To sum up (for people who hate wall of text): If there's potential to be emitted at the same time, a post back off system, unlike my pre-back off system, is worse off. You'll have to wait somewhere. And if you make sure there won't be concurrent emissions, you can remove the acquisition delay in my system, making it not so slower than the selector system without back off, as the open channel is pre-cached after each acquisition.		2011-07-14 15:35:00

Author:
hesido
Posts: 166

@evret: I know it is just a slight improvement, but if you create one extra port on the middle selector, the default port if you like, and wire that to both chips activation inputs, you save a bit of logic there. Rtm did it in his screenie a few replies up.2011-07-14 18:52:00

Author:
Antikris
Posts: 1340

@evret: Thanks for sharing! What do the red chips hold?

on that chip the red chips just hold a few sensors connected to tags to detect distance and send that as an analog signal, the receiving chip is a lot messier and is more complex which is why i took a pic of this one instead

@evret: I know it is just a slight improvement, but if you create one extra port on the middle selector, the default port if you like, and wire that to both chips activation inputs, you save a bit of logic there. Rtm did it in his screenie a few replies up.
yeah, the level is already published so i'm not gonna worry about changing it now, though it is a lot better than the one i made for missile command, coz in that i made a custom priority chip because i was unaware of the selectors priority function lol		2011-07-15 05:10:00

Author:
evret
Posts: 612

@rtm: Thanks for the insight. Sorry, I now see you can easily remove the id acquire chip in your version also. That said, in my requirement, I needed to have the ability to re-acquire an id when necessary, so I needed to keep it, and the potential to avoid holding so many sensors at every object, this seemed to be the better way to go, however, a de-centralized version may also be feasible for other applications. Out of curiousity, what were the max number of simultaneous open channels and the max number of active units (I'm assuming the latter is greater than the former here, right?). I can see for instances where you have a very large number of open channels and an even larger number of units that a central system would make sense. But that is the only scenario I can see where it is optimal - for (probably) every other scenario it's gonna be less effective.

WRT to the pre-back off, the assumption that you should always back off first is only true if you have a very high probability of collisions on first attempt. Not 100% sure on the system you are using but for large numbers of units, yes, your probabilities of collision go up pretty rapidly and IIRC your mean time to converge to a stable solution for the entire system rises exponentially - actual time for convergence is non-deterministic and you have to wait for your system to be in a stable state before it actually can do stuff. Conversely, if you simply spawn objects on subsequent frames you won't have them all appear at once, true, but you will have a full system up and running quicker, with minimal and deterministic time delay that has a linear relationship against the number of channels. At best, the delay can be n/30 seconds, where n is the number of channels i.e even for 30 units it's possible to assign an id for all of them in under 1.0s using the system I describe.


If, for some reason you have to have all units appear at once, then your probability of collisions is always going to be 1, if you don't pre back off. But then if you have to have all units spawn at once, then you are using a stupid system to assign IDs. Instead, assign ID by spawn position and know that it's going to be safe. Again, there are some situations where you can't actually ensure this, but it's going to be pretty rare again. As initial mass spawn is far more likely to be the point at which you get collisions, as opposed to subsequent re-acquires (Again depends exactly on your requirements), then you can simply remove the possibility of collisions at that point and introduce a far simpler collision detection system for the re-acquires later (if you even need them, which is probably also rare).


Basically, it's better to just design a system when probability of collisions can be known to be always zero, which, unless you have to have objects dynamically releasing and re-requesting channels and you have to have more objects than you have channels, is actually really simple. Otherwise you are over engineering a solution by creating a problem into something that is more complex than it needs to be 		2011-07-16 21:28:00

Author:
rtm223
Posts: 6497

Hi Rtm,

Can you please eloborate the "assign id by spawn position" part? It may solve quite a lot of problems for me.

I agree my take on the problem is not the most efficient for every scenario, but I think it is quite neat, and imho it is not overengineered for cases where collisions are inevitable. I'd like to see a post-back off tag-selector-tag system that understands the solution being stable that is simpler than mine, and I'll be convinced. It is a very basic open channel scanner that lays in the center, with objects asking for open channels using a very simple id acquire chip that you can keep on the object, and it doesn't have many components.

In my case, I'm planning to use it for grid based games where objects emit their own destination for smooth / perfect grid movement, and for moving objects that destroy their sticker panels when out of screen, but remits them when in screen space for sticker optimization (The assigning center would move with the camera). For the latter case, a sturdy messaging system where sticker panels receive signals for moving could also be used, but for smooth movement, a tag-follower system may still be necessary, thereby making unique tag-follower systems a necessity. I think this whole unique id notion would be very useful for unit based games where you have multiple cloned objects (whatever system you use). I wish to do benchmarks for cases where there may be high load of objects for the tag-selector-tag system.

Also, there might be "exotic" uses of having an analogue value as an id, e.g. it could be used for messaging through a single tag-sensor if you could live with having to message one object at a time (dunno if there'd be any practical uses for it, but hay!)

Anyway, I think this thread has been quite useful for me, I hope it is to others as well. I'd have liked the feedback even more if I were blessed with this feedback when I was screaming for a unique id system suggestion in the suggestions thread, tho 		2011-07-18 21:12:00

Author:
hesido
Posts: 166

In my case, I'm planning to use it for grid based games where objects emit their own destination for smooth / perfect grid movement, and for moving objects that destroy their sticker panels when out of screen, but remits them when in screen space for sticker optimization

I may be asking a stupid question, but I suppose making the hologram invisible doesn't help aleviate the thermo (in play mode if not in create mode)? That would really simplify this problem.


Anyway, I think this thread has been quite useful for me, I hope it is to others as well. I'd have liked the feedback even more if I were blessed with this feedback when I was screaming for a unique id system suggestion in the suggestions thread, tho

If you mean the Suggestions forum, that's for posting suggestions for Mm to implement. I for one don't pay a lot of attention to it, I'll just make do with what's available. The Help section's where you ask questions.

But yeah, interesting thread.		2011-07-18 22:46:00

Author:
Rogar
Posts: 2284

Can you please eloborate the "assign id by spawn position" part? It may solve quite a lot of problems for me. Say you spawn 10 items at the same time, i.e. for initial spawn, then you can generally know where they are likely to spawn. If you know where your objects are going to spawn then you can also spawn a tag next to them that would assign their initial ID.

In that way, you could emit the same reference object 10 times, from 10 different emitters, but also just emit it a piece of hologram that had tags underneath each of the objects that told them their initial ID. You could comfortably use that method for initial spawn and then a dynamic method for subsequent spawns, which could alleviate a number of potential issues and probably handle most cases where collisions are inevitable (group spawning being the most likely cause).

Similarly, if you wanted to do reacquisition of signals, you could do a funky system where the unit emits a piece of hologram next to itself object that contains all the logic for detecting the currently free channels and communicates that back to the unit, as an analogue value. This would be almost equivalent to your centralised system, but the central system would not actually exist in the world for most of the time and would typically be able to kill itself after a couple (2? 3?) frames. It would cause massive spikes in thermo if you had to spawn many objects simultaneously though.


Distributed collision detection is very easy to test for btw - just check if someone is using the same ID as you. you would only have an invalid ID for one frame, which shouldn't be enough to cause issues and I still think you can remove collisions for almost all scenarios 		2011-07-18 23:02:00

Author:
rtm223
Posts: 6497

I may be asking a stupid question, but I suppose making the hologram invisible doesn't help aleviate the thermo (in play mode if not in create mode)? That would really simplify this problem.


Stickered invisible holograms do not free the sticker limit, but only destroyed stickered objects free resources, that's why I / we need to destroy them when out of screen. For static objects, this is easy as pie. For moving objects, the stickered part needs to follow the logic part. When you have many objects, you need them to not interfere.

@rtm: Thanks. Pre-determining the id may be useful in some scenarios. As for the distributed collision detection but in another form, I'm already doing it (checking if any other signal request exists).

As for my usage case, you could check out my boulderdash level youtube video (you could search for "hesido" channel, youtube is currently blocked on this computer, sorry) or you can try out the level (my sig) and press L3 for 3 seconds at title screen to go to the editor mode and zoom out using R2, go up for while to see the level, and see the sticker optimization. Static pieces are emitted / destroyed which helps the sticker limit, but diamond holos are just turned off. So I didn't even care to turn off the boulders That would give an idea of how this is going to be used, there could be at least 15-20 moving objects operating at the same time, and re-assigning would be based on camera position (central system attached to the camera). If the levels were just horizontal it would be easier to optimize, but by way of chain reaction, off screen elements may need to move, so I can't omit the complex logic objects completely, but this is an open area to be explored.

Btw, objects that emit complex objects also seem to affect the thermo quite a bit even when the object has not been emitted yet, but I didn't test it thoroughly, so storing the complex logic object in an emitter may not be feasible, no?		2011-07-19 09:03:00

Author:
hesido
Posts: 166

...you can also spawn a tag next to them that would assign their initial ID.

Presumably just having a fixed named tag next to the emitter would also work. After all, isn't the point of the exercise to minimize the number of varations of your emitted objects?

If you're prepared to emit a different tag next to each unit, you may as well just vary each unit.		2011-07-19 13:17:00

Author:
Aya042
Posts: 2870

If you're prepared to emit a different tag next to each unit, you may as well just vary each unit.

It may still beat having to rename every tag and follower inside, but I agree that it kind of drifts away from the core objective.		2011-07-21 08:16:00

Author:
hesido
Posts: 166

Just a thought: you could do positional initialisation without different tags by using the distance to some external tag as the seed. For example, use the distance to the external tag as input on a positional sequencer, and activate a tag from the position on the sequencer. Units that are close will still have channel collisions, but there will be a lot fewer, so you'll be able to resolve them faster.2011-07-21 09:30:00

Author:
Rogar
Posts: 2284

Just a thought: you could do positional initialisation without different tags by using the distance to some external tag as the seed. For example, use the distance to the external tag as input on a positional sequencer, and activate a tag from the position on the sequencer. Units that are close will still have channel collisions, but there will be a lot fewer, so you'll be able to resolve them faster.

you could also use distance to an external to tag to give the emitted objects an order in which they are to select an i.d.
for example it could detect and transmit it's distance then compare it against the highest external signal (from another object wanting an i.d)
if it's the highest it would select an i.d. and stop transmitting it's distance so the next closest becomes closest and can select the next available i.d.

it should only take a frame or 2 for each so it should be fine for most applications where no 2 will be emitted at the exact same place at the same time		2011-07-21 11:50:00

Author:
evret
Posts: 612

If you're prepared to emit a different tag next to each unit, you may as well just vary each unit.

Not sure there is any logic there Aya, allowing changes to logic to be carried out on a single reference object and have the whole system update regardless of number of units is still the main benefit.

Emitting the tags next to each unit is basically a one-shot job, if you do it right. Having multiple reference units means lots of duplication of work and excessively high thermo (to store each extra unit in memory permanently).		2011-07-25 16:11:00

Author:
rtm223
Posts: 6497

...allowing changes to logic to be carried out on a single reference object and have the whole system update regardless of number of units is still the main benefit.

Meh. Point is: why bother emitting a tag which could just be placed in a static configuration next to an emitter?



...and excessively high thermo (to store each extra unit in memory permanently).

If you (non-dynamically) emit an emitter, which then emits your unit, it uses zero thermo until emitted. Regardless of whether your units are varied or not, you ultimately end up paying the same amount of thermo for the same number of active units.

Thus, you would necessarily incur less of a thermo hit if you simply varied the units, rather than using external tags, although it's so marginal it's not really worth it.		2011-07-25 16:36:00

Author:
Aya042
Posts: 2870

You could place the tags in static configuration next to the emitter. That would work fine. But what you said was that it was comparable to modifying every single unit individually, every single time you wanted to make a change. Which is a silly thing to say 2011-07-25 16:45:00

Author:
rtm223
Posts: 6497

...what you said was that it was comparable to modifying every single unit individually, every single time you wanted to make a change. Which is a silly thing to say

Well. I was working on the following assumptions...

That you're not using dynamic emission.
That there's a single tag on the exterior of each unit which you can tweak to do the varying.


With your "emitting a tag" suggestion, I was assuming you meant to put a tag on a piece of hologram, and emit that. So in order to vary it you'd have to...

Find holotag from My Objects.
Place holotag.
Tweak tag.
Recapture holotag.
Retweak emitter to emit new holotag.

...and if you s/holotag/unit/g in that list, it feels like the same amount of work to me.		2011-07-25 17:05:00

Author:
Aya042
Posts: 2870


LBPCentral Archive Statistics
Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Datenschutz
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.