[Suggestion] Show I/UIDs for selected objects

After shuffling NPCs around the screen, all of them are using the same animation, but everyone have an UID, right?

If you know how you placed them, you can manipulate each one using their UID, making specific paths, etc, right?

It's only a brainstorm. For example a RPG game, how do you deal with UIDs?

I was thinking to make general NPCs on a Village (Vendors inside the buildings), sometimes repeated NPCs, using the index created by placing them on the screen, but if you be a time far from the project, and missed who has the UID 3.. you will lose a bit of time to discover it back.

So, I would like ask if is hard to implement on the bottom bar of Construct 2, a text showing the UID of the selected object? And if it works like I'm thinking.

Thanks!

A better solution would to use an instance variable to store the id of your objects. The uid is only only constant at runtime. In the editor if you change the z ordering the uid can be different at runtime.

rojohound, thanks buddy, here on the forum have some posts about it to research about =)

And, I think it will be possible to be reached later, when Ashley (if he really make it) implement the real time (or partial real time) feature on the canvas editor xD

That's because using JSON, like he said, C2 will need to generate the IIDs and UIDs before store the onion skins.

More about: scirra.com/forum/a-dream-coming-true_topic54953.html

Interesting, didn't know z order affected it.

Yeah as R0J0hound suggested instance variables are the way to go.

The only other thing you can rely on is the iid, and the order of creation, but just like uid, that can change when you destroy an instance.

I agree you should add a private variable to keep your entities in control.

But if you really want to know your object's UID why not add a text object and: "Cursor is over object ---> "Set text to: Object.UID" (you get the idea :P)

There were times I needed this, the UID shown in the editor would have sped up some of my game's development time..

I agree you should add a private variable to keep your entities in control.

But if you really want to know your object's UID why not add a text object and: "Cursor is over object ---> "Set text to: Object.UID" (you get the idea :P)

This is how I did it <img src="smileys/smiley1.gif" border="0" align="middle" />

I was in need of it, and figured out how to obtain with your suggestions folks!

Thanks a lot all the help.

The final result is that little smoke on the little spaceship at the end.. ^^

https://dl.dropbox.com/u/47035927/00%20-%20EQUILIBRIUM/index.html

IIDs and UIDs in the editor don't change depending on the Z order, but they do change if you delete and insert instances. Because of this you should not rely on knowing UIDs or IIDs in advance at all - the instance with UID 3, for example, could change to a different object if you add or delete some things in the layout view. This could easily break your game or make it work differently "randomly" (it will seem random to many users because they won't realise certain things they did changed the UIDs and IIDs). For this reason I don't think UIDs or IIDs should ever be displayed in the editor, in order to discourage this bad practice.

IIDs and UIDs in the editor don't change depending on the Z order, but they do change if you delete and insert instances. Because of this you should not rely on knowing UIDs or IIDs in advance at all - the instance with UID 3, for example, could change to a different object if you add or delete some things in the layout view. This could easily break your game or make it work differently "randomly" (it will seem random to many users because they won't realise certain things they did changed the UIDs and IIDs). For this reason I don't think UIDs or IIDs should ever be displayed in the editor, in order to discourage this bad practice.

Ashley,

Using IGM and Stencyl, we can handle the specific object on the canvas after placing it, because the software will return to you a name for that object, so, if you have 10 Ogres using the same "gadget" (a gadget is where they put the behavior and animations, just like an object for C2), but you can handle each gadget on the canvas just calling his name.

Something like this:

You placed 10 Gadget "Ogre" on the layer 2.

The software will return to you a specific name, ogre_01, ogre_02, etc.

Editing the source code, you wanna do different AI for each one, because one of them will pick an axe on the ground, the other will pick a spear, etc.

It's just how these softwares works for me.

Now, think how a beginner will feel bad if he need to make an advanced code to search the UID/IID and after all this, he will destroy that gadget and will lose all his code (or will make random weird things on the screen after lacking the right UID).

The best to make here, in my lowly opinion, C2 should use a unique automatic indexing system to help beginner don't get lost, and speed up their learning curve.

I'm really worried about the UIDs, because my main game use modular characters, with dozens of sprites (pants, weapons, etc) and they have the possibility to pick things on the screen, like a sword on the ground (just like little fighter) and after learning about the issues around IID, I should never destroy an enemy, or anything on the screen, because it can break the game.

So, now, the workaround used was recycling the enemies in different places of the stage (one good thing) but it will be a bad practice when talking about memory usage, etc.

Don't get mad with me, I'm just an curious about game, I do it for hobby, and I hope the better for C2, true it.

the main thing to remember and Ive mentioned this elsewhere. You CANNOT trust those numbers outside of runtime. It doesnt matter if its displayed in the editor or not its not somethin you should depend on goin from edit time to run time.

The IID is basically the index of a specific instance in relation to all the other instances of the same object. Im pretty sure it goes in the order they were created. I dunno if it keeps numbering higher when more are created or if it fills in gaps (instead of making a new IID 10 it would be somethin like 6 if the current ones were 1,2,3,4,5,7,8...)

IID should NEVER be used to point to a specific instance. It should only be used possibly with loops and the like. Its basically a running count. Only in very very specific circumstances would it work out as intended for anything else.

UID (as far as I know) will always be specific to that instance in the entire game. Thus its unique. Once that instance is created you can use the UID to point directly to that instance as long as it exists. Thats not to say that ANOTHER instance wont get that UID IF the first ones been removed.

Its a trustable value to use as long as your aware of how your using it before hand. The main use is to relate one object to other objects during runtime (what your tryin to do with your example here) And it works perfectly fine as long as you take into account the times that instance (and thus its UID) might be unavailable.

When you create an object the next action can set a variable to the UID of that created object. That variable can then be used to pick that specific instance of the object. If and when that instance is removed you need to set that variable to somethin else (like another UID of a newly created instance) or a value you consider "null" and use that value to determine if you CAN use the value to interact with the intended object.

Basically IID is only useful for counting/looping for the most part. UID is the value to use but only if you set it on creation during runtime and take into account it possibly changing

I only use UID and IID when dealing with things I don't create more of or delete, which are my game's buttons.

It's pretty useful as with it, in my level selection, I managed to reduce about 25 events into one with using their UID to send them to their levels.

After researching and trying to see over the fence, I figured out a solution about the indexing objects issue.

scirra.com/forum/forum_posts.asp

It's really awesome, and Ashley was trying to say it all the time, but when you don't have the knowledge behind the scene, it's difficult to figure out.

Maybe later I do a Tutorial explaining about it and other things to help everyone else.