Inverse Spread Value: Problem

[TheFieryPlumber]

I’m beating my head against the table here!

I want a sequence where I want the same kind of objects to spawn in certain spots at random. Everytime the timer hits X, the object is created in the designated spot told by an RNG. The problem is, these objects use Spread Value to separate themselves from each other: ID values. However, a major drawback I’m realizing from “Spread Values” is that newer objects will always take the lowest number while older objects will have their IDs replaced with older ones. It’s normally fine if the objects are created upon start-up: however, once an object is created due to an event, the other objects go haywire because their relationship with one another has been compromised by the change in ID.

I wonder if you can make the “Spread Values” work backwards: make the newest object take the latest ID number while the older ones keep theirs. Or at the very least, does someone have a way to circumvent this problem? It’s giving me a massive headache!

[defisym]

Run a for-each loop, then set ID by object num - for-each loop index

[Volnaiskra]

What about fixed values? Every created object already gets automatically assigned a unique fixed value, and you can use these as IDs instead. The fixed values are numbers like 38293848 and 9458273, so if you want neat consecutive IDs like 1, 2, 3... then they won't be suitable. But if you just need a unique number that can be used to keep track of separate instances when needed, then they're perfect, especially since they already exist without any extra effort from you. They're basically like serial numbers: they're not pretty, but they're permanent and they're unique (within reason...they'll theoretically start to repeat if you create gazillions of objects).

[YesNoYes]

Assuming your object IDs increment linearly from 0, you could try...

+ on event
- spread value (( NObjects("your Object") - NObjects("your Object")) - ID("your Object")) in ID("your Object")

You'll need to retrieve the number of currently created objects before executing the above action. So it would have to be in a different event to the one which creates the objects, but that will reverse the spread of the values in all the object IDs.

[TheFieryPlumber]

What about fixed values?

Considering how my mother and child objects relies on organized ID values, changing it to rely on fixed values instead is way too much to handle: it might even require a complete rewrite.

As for the other solutions @defisym and @YesNoYes suggested, I might try it out tonight AFTER testing one method I thought up after I left programming for the day.

There was this one method I was trying that tells it to do this (Note: This was after spreading the values of Home_Object):

Spawn_Object is overlapping Home_Object
ID of Spawn_Object <> ID of Home_Object
Set ID of Spawn_Object to ID of Home_Object

I thought something this simple would work: however, every time a new Spawn_Object is created, all other Spawn_Objects will take the ID of the Home_Object that recently created one of these. There is definitely a solution for this, but I would have to investigate my code to understand why my Mother and Child worked so well before and attempt to replicate it in this situation.

[Volnaiskra]

Spawn_Object is overlapping Home_Object
ID of Spawn_Object <> ID of Home_Object
Set ID of Spawn_Object to ID of Home_Object

The middle line seems redundant to me. This would have the identical result:

Spawn_Object is overlapping Home_Object
Set ID of Spawn_Object to ID of Home_Object

Considering how my mother and child objects relies on organized ID values, changing it to rely on fixed values instead is way too much to handle: it might even require a complete rewrite.

Yes, it all depends on how your code is organised. I use fixed values for all my mother/child relationships. If you have the mother scoped at the time that the child is created, then it's as easy as this:





Then you can always find any pair easily - you never even need to know what the ID number actually is:





This is probably the easiest way to create mother/child relationships. But if your system works in a way that the mother isn't scoped at the time that the child is created, then that's a little more complicated.

[TheFieryPlumber]

The middle line seems redundant to me.

The middle line is meant for the game to never repeat the action once it’s done. The Spawn_Object will not take the ID of the Home_Object if they’re already equal.

As for Fixed Value, it seems like a great idea and I would love to use it once I make a fresh game again; but not this time. Too many objects rely on the initial ID method that changing it would be a greater hassle than using the simpler solutions posters here are suggesting.

I unfortunately, have to hold off programming until tomorrow, but I’ll get down and dirty with these suggestions once I finish my afternoon errands!

[Volnaiskra]

The middle line is meant for the game to never repeat the action once it’s done. The Spawn_Object will not take the ID of the HomeObject if they’re already equal.

Sure, but for what purpose? If the Home Object is #66 and the Spawn Object is already #66, then whether or not the action runs makes no difference: the Spawn object will end up as #66 either way. But removing the middle line would make the code simpler, and would give you a small performance boost, because the condition that tests for ID is more expensive than the action that sets ID. So setting the ID of all Spawn Objects indiscriminately would be cheaper than forcing Fusion to check the ID of each one first. It's not a big deal, of course, and unless you were testing an enormous amount of objects, the performance gain would probably be negligible. Just thought I'd mention it.

[TheFieryPlumber]

Wow, not answering that question deleted my initial response! How swell!

I assumed not using an “off” switch so to speak, “If ID of X <> ID of Y” for example, will make the program attempt to perform that action indefinitely similar to how the *Always* condition does its thing; and applying the condition will make the program ignore the command when it deemed unnecessary thus saving performance. Well if that’s not the case, then that’s some news to me! I will still do it out of habit, but these actions aren’t often the ones that makes my performance dip on occasion. Nope, it’s often the necessary Always commands, that includes the “test ID” command that has to run a ForEach loop all the time.

[Volnaiskra]

I'm not much of a fan of those questions either :/

I assumed not using an “off” switch so to speak, “If ID of X <> ID of Y” for example, will make the program attempt to perform that action indefinitely similar to how the *Always* condition does its thing; and applying the condition will make the program ignore the command when it deemed unnecessary...

All of that is still true. But applying the condition comes with its own workload. If you have 100 Spawn Objects, and 10 of them are overlapping the Home Object, then your method will:

a. Run an overlap check for 100 objects
b. Perform an ID check for 10 objects
c. Set the ID for 1 object


Whereas my method will:


a. Run an overlap check for 100 objects
b. Set the ID for 10 objects.


To put it very simplistically, your method makes Fusion do 111 items of work, while my method makes it do 110. So your method doesn't actually cut down the workload. Both methods require a similar amount of items of work, but the 2nd method should be a little more performant, as it omits 10 slightly expensive conditions, and exchanges them for 9 slightly cheaper actions.

To put it another very simplistic way: imagine you had 10 paper documents in front of you, with different dates written somewhere in them. What would be faster: searching through all 10 documents to find the one from 21/2/2023, then marking it with an "X"? Or just marking each document with an "X" without looking through it? For me, intuitively the latter would be faster. And - at least judging by a few simple tests I've done in the past - it seems that Fusion tends to be a bit faster in the latter scenario too.

Of course, it all depends on the type of actions and conditions. Some conditions (eg. checking a global value) are very cheap, while some (eg. checking overlaps) are very expensive. Some actions (eg. setting an alterable value) are very cheap, while some actions (eg. creating an object) are very expensive. "Always" is actually the cheapest condition of all, though of course this doesn't count for much if the actions underneath it are expensive, as in your ForEach example.