My 2cents about construct2

It doesn't change during runtime, but you cannot count on what it will be until after the object has been created at runtime. Each time you run the game the UID will likely be different.

So the index doesn't change during runtme at all, no matter how many instances are added and removed around it? If so it's a different beast to what I understood.

I guess sometimes you want to rely on ids that are essentially hard coded, but equally there are times where you need to use dynamic references that are created at run time. This is unavoidable when you are spawning items such as bullets or enemies that aren't manually placed but generated by code.

So what were the perceived negatives of using UID besides the fact that they will likely be different for each execution of the game?

The index is based on how many instances exist, or how many are picked, so yes that number will change if you create or destroy instances.

Like if you destroy sprite(0), sprite(1), will then be able to be referenced as the old sprite(0).

If you need a something to constantly pick a specific instance, you should use an instance variable.

That's essentially the same method as using the uid by setting a sprites instance variable to its uid on creation, but when you think about it, that's an extra step that's not needed, as you can pick via instance variable just as easy as you can pick by uid.

Also I think one way to think about uid's is to treat them as if they were random numbers.

Hi, after reading all of your replies and especially the one coming from Ashley. I think that construct2 has the potential to become the BEST html5 engine, code or no code, it just need to open up to its full potential.

I don't want to rely on firebug because then I would get a trace of the inner workings of construct, not of my "code" if I have to delve deeply in the recess of construct2 code I'm better off learning to code in a "real" html5 framework. At this point I would really settle off for a console.log(allmyvars);.

All the discussion on UID kinda make my point more valid. It's imperative to be able to access an object clearly after it has instanced, I don't care if UID changes, that is normal, what is not normal is that currently is a hit/miss thing.

There should also be a more clear way of understanding the flow and precedence of construct, I have often to rely on instancing an insane amount of variable like object_position_X,object_position_X1,object_position_X2, etc because sometimes var are overridden during complex instruction in an unpredictable way. This could be achieved simply by having groups behave like real functions, like

start group (passing variables)

do what the group does

return something

deactivate the group automatically

Right now is kinda possible to do this, but it involves a check (is group active) and a consequent manual deactivation after the group does it's thing and when you have 10-20 groups it gets confusing and unpredictable.

Take a look at this: dl.dropbox.com/u/23551572/C2/destroyByUID.capx

(from this thread: scirra.com/forum/topic46461.html).

After working on this for several days (to expand my game) I found out that the whole isSelected bit is not completely reliable, I added tons of new event inside that bit and I started noticing a delay between the destroying of the first and second card, I presume because sometimes it misses the isSelected bit, goes back to the beginning and starts over, resulting in a bit of delay, this is a big issue because we have no instruments to check the precedence of instruction and the flow of construct.

Since I bought this product I've seen only updates that add even more "click and play" features (like jump through platform) and none that addresses the real issues, and I fear that if this is the road you are taking serious projects will never see the light of the day.

The index is based on how many instances exist, or how many are picked, so yes that number will change if you create or destroy instances.

Like if you destroy sprite(0), sprite(1), will then be able to be referenced as the old sprite(0).

Hmm, OK, so the index is as I originally thought, and thus very unreliable to use as a reference because it has the potential to change during runtime.

The UID however will never change during runtime so acts as the most reliable reference. I still don't understand what the perceived negative is?

I use randomly asigned IDs a lot in my other work so I'm sort of defending them here, also, database convention such as in SQL uses randomly (or more likely incrementally) assigned IDs for identification because they are persistant, and by definintion, unique. Feels to me like a UID is one of the most robost identifiers to use, and also made even more attractive by the fact that there is a function built into Construct to select items by this identifier. Of course you need to keep reference but that's part and parcel of making larger scale dynamic games and applications.

PS - Persistance in this case means runtime persistance.

0plus1 if you find bugs or issues in C2, the good thing to do is to file a bug report.

If some issue hasn't been detected, it can't be corrected.

Yeah the picking system could improve a little. Pick Nearest and Pick by UID served me well till now but they could be insuficient for other cases. But what i miss the most right now is Families, Sprite Editor and better support for fonts.

I do have to add UIDs were added specifically for remembering object instances in combination with the 'pick by UID' condition - I would say they are best suited for that, instance indexes won't really cut it since they change and UIDs never change.

I do have to add UIDs were added specifically for remembering object instances in combination with the 'pick by UID' condition - I would say they are best suited for that, instance indexes won't really cut it since they change and UIDs never change.

Yeah, but picking by uid is useless with out using a variable, and you can skip the uid part, then just use a variable.

Plus you can set the variable in the editor.

Seriously you would be better off setting a variable to the sprite index, rather than its uid.

Yes I know you can't do that. <img src="smileys/smiley17.gif" border="0" align="middle" />

"Lack of debug. It' s impossible to keep track of what is happening in a complex project. I don't need nothing fancy, even something basic with all the var dump would be helpful."

How hard is to make yer own debugger? Seriously. And if you make it yerself, you can customize it to yer own liking and specs., no?

C2 is still beta, but it is no doubt, the best 2D game making engine out there, even if it's only for web games. I am one of those who wishes more exporters were available, specifically EXE. But I'd have to be pretty dense not to realize C2's capabilities, and thus, an EXE exporter would make C2, quite honestly, THE game making tool. Still, as it stands right now, I haven't seen anything better and time efficient.

Ashley: So UIDs never change, but they do change depending on when the object was added to the project, and once created they will never change. Instance index change as objects are created. Correct? My question, UIDs are equivalent to doing something like: Upon creation of an instance, set some instance variable to 1 (or 0) + # of instances of that object already exist before it. Index, would be constantly changing the variable, not only upon creation, but also as objects are added. Yes?

newt - I don't understand, you're supposed to use a variable with a UID. What's wrong with that?

Instance indices are useless because they change all the time. If you delete the object with index 0 every single other instance changes its index. So if you stored an index in a variable it's now wrong. Why would you ever want to use that?

Imo there's no need for a debugger at all as in code debugger, since there's no code involved that you have direct control of. But there's a need of a runtime inspector like there was in Classic. And about UID there's nothing wrong with them at all. People just don't seem to know how to use it

newt - I don't understand, you're supposed to use a variable with a UID. What's wrong with that?

Instance indices are useless because they change all the time. If you delete the object with index 0 every single other instance changes its index. So if you stored an index in a variable it's now wrong. Why would you ever want to use that?

Well that's my point, you wouldn't, but its easier to pick.

As it is you have to make an additional action to use uid, but that's only if the object is already picked, and the only realistic way is on creation.

Anyway I'm just saying uid's are pointless, as we have the index, or variables.

And yes picking using the index really doesn't work for everything, unless you were to make it possible to change the index like you would a z index.

.... I think.

> I do have to add UIDs were added specifically for remembering object instances in combination with the 'pick by UID' condition - I would say they are best suited for that, instance indexes won't really cut it since they change and UIDs never change.

Yeah, but picking by uid is useless with out using a variable, and you can skip the uid part, then just use a variable.

Plus you can set the variable in the editor.

Seriously you would be better off setting a variable to the sprite index, rather than its uid.

Yes I know you can't do that. <img src="smileys/smiley17.gif" border="0" align="middle" />

I'm with Ashley on this one, and in my own words: much safer and more robust. Why set a variable to remember an index that you potentially have to keep updating in case any changes are made, when you can set it once and have it as a unique identifier for the entire duration of the runtime. If you've ever been stung by it you want to avoid relying on index ordering for references if you can, in most cases.

Also the UID is automatically assigned, so it would makes sense to use it rather than replicating the same thing by creating your own ID numbering system. You have to think of UIDs as what they literally are, reliably unique ways to reference items.

I guess the reason I am hammering on is that your original statement was emphatic about avoiding the use of UID and I feared it might be teaching what I consider to be bad habits to the others on the forum. I know since I am personally new to Construct I thought there must have been some reasons behind the scenes that I wasn't aware of but it seems not to be the case. So I'd emplore the opposite, please use UIDs.

Good debate though, willing to be shown any merits or limitations of either option to determinine if they are worthwhile influencing the way you'd approach certain situations. For me the bottom line is usually robustness and reliability.

... and better support for fonts.

kiyoshi: There are now a spritefont and a webfont plugins in the plugins forum.

All C2 users around, be sure to check the list of custom behaviors/plugins once in a while, more and more third party developpers are releasing new awesome tools every day.

> ... and better support for fonts.

kiyoshi: There are now a srpitefont and a webfont plugins in the plugins forum.

All C2 users around, be sure to check the list of custom behaviors/plugins once in a while, more and more third party developpers are releasing new awesome tools every day.

Thanks man. I completely forgot about this. I will check this, since I have been fidgeting over sprite fonts for a while.