Consistent method to change game object's ID in the editor

[ghost]

AGS 3.2.2 introduced means to drag game items around in their lists, but because of how game compilation and engine worked this was never made truly consistent with these item's IDs and actual position in a game array at runtime. At runtime all game entities still have an order in which they were appended to the project.

Changing object's ID is not something that is commonly required, but still may be beneficial if a game developer wants to gather a group of objects together in a sequence and use some kind of formula to select one; for example, randomly pick from a range.

Also it's just inconvenient and baffling that the order of objects inside project tree does not necessarily correspond to the order they will be at runtime.

EDIT: Also related: an older forum discussion: https://www.adventuregamestudio.co.uk/forums/index.php?topic=54640.0

My suggestion is: 1) if object is dragged in the list its ID is changed correspondingly; 2) ID property should be made editable (where available), but restricted to range [0 - item count).

[AlanDrake]

I think the game developer should instead put all those objects inside an array and use that for grouping them together. We could add a script command that returns an array from an inventory folder, that would be the cleanest way to achieve what you suggested. Reasoning on arbitrary numbers is usually prone to fault.

[ghost]

I think the game developer should instead put all those objects inside an array and use that for grouping them together.

There was a discussion years ago and this is what I suggested too, but the person insisted that objects may be already arranged inside a project the way he wants (and visually so), so why repeating the step.

The idea above is to make these existing IDs and their position inside game array to correspond to the visual order in the project tree. Because currently moving them around achieves nothing in practical sense.

We could add a script command that returns an array from an inventory folder, that would be the cleanest way to achieve what you suggested.

This is what I also suggested iirc, but the folders are not part of the runtime game data right now, game object list is flattened before being put into compiled game. Normally ofcourse that's a valid idea. I remember I actually suggested to have a separate "lists" concept in the editor where items may even repeat.

On the other hand, the "whole list" may be thought as a folder too, and it already has a corresponding array.

PS. just in case: the point is to make existing numeric ID follow the visual organization. So that if you drag one item to the first place in editor it will stay on the first place in game array.

PPS. the necesessary changes are purely in UI, not in data format, nor compilation logic. Basically: if item is moved inside a list, then switch ID.

[ghost]

I found the old discussion, but afaik it's not even the first of this kind: https://www.adventuregamestudio.co.uk/forums/index.php?topic=54640.0

[ghost]

UPD: Actually... the more I read the old threads on this issue, the more I wonder whether such change will benefit or make things worse. Because of the folders. If there are two folders, adding to the first folder will make items take precedence over the items in the second, and therefore the items in second folders will always have their indexes shifted down.

This is a big conflict between organizing items for convenience and organizing them for sorting that cannot be solved without having separate in-folder index and access to sorted folder array at runtime.

The "big item list" in such case will be only reliable so long as you do not use folders - otherwise you won't be able to easily control its order.

UPD: Additionally, there's a thing that I forgot about: if user was referencing game objects with a number then this change may break the scripts on game import, because user may have already have objects dragged around in the list. The only workaround in such case that I see is to completely reset the ordering in the list to the order of IDs.

[ghost]

UPD: A dumb (partial) solution could be to just let the user change global ID property of an object by hand (just like you can change sprite's), unrelated to object organization in the tree and folders.

Advantages: 1) Does not add any new mechanics nor change any data formats. 2) User keeps total control of object numeric IDs. 3) May be simply ignored if you don't use it.

Disadvantages: 1) Still reliant on manual work (just like with sprites or old-style music/sound filenames). 2) Still visually inconsistent with object arrangement in folders.

[morganwillcock]

Similarly to sprite loading, I feel this is more a general issue of how resources are packed and loaded. Perhaps the data file should also contain metadata to assist in returning data in some order, maybe it should just be standard data archive like a zip file that can contain a full file hierarchy, but I think it should be down to the scripting environment to get a reference to the internal content.

• in some cases using a path is going to be more useful than using a number
• listing files in default sort order will generate a numbered index, if I want one
• if I want something fancy so I can iterate over resources in a specific order, I'll supply my own index or my own sorting function

[rofl0r]

in some cases using a path is going to be more useful than using a number

in which case a string identifier would work just as well

[ghost]

Similarly to sprite loading, I feel this is more a general issue of how resources are packed and loaded.

I guess this may be split into finding long-term and immediate solution too.

[morganwillcock]

Just in general, with the exception of allowing the content to be obfuscated, is there an advantage to using custom storage instead of a known archive format?

(asking for a friend who doesn't know any better)

[rofl0r]

the immediate advantage is that 1) it already works well and is well-tested, and 2) the data can be loaded in-memory (even mmap()d directly from disk) without needing temporary storage for extraction. rewriting the system would provide little to no gain, while adding a whole lot of new complications.

[ghost]

Just in general, with the exception of allowing the content to be obfuscated, is there an advantage to using custom storage instead of a known archive format?

Sorry, but how is this related to this particular issue? Maybe you were going to post in different thread?

[morganwillcock]

I'm suggesting that the index shouldn't be defined in the game data (either project data or built data files) and should be generated by the game scripts. But to do this the storage needs to support some data worth querying. The original relative file path for the source file might be enough, with a default ordering of alphabetical (so for people who don't want to script a re-order you could just name your source files in order).

[ghost]

I'm suggesting that the index shouldn't be defined in the game data

If objects are saved into runtime game data, then they are already in some order, should not that be their default index? If yes, then you do not need to save source filenames for runtime data only for this purpose, it's enough to know them at the compilation time.

[morganwillcock]

If objects are saved into runtime game data, then they are already in some order, should not that be their default index?

It depends where the initial order is coming from. If this ends up being the order that items were imported or created, this isn't necessarily the order you logical want them in within the game, and isn't necessarily the most efficient order to read them back from disk. I think we would agree on this part, since this issue is about re-ordering objects to receive a different index. I only suggest that there could be additional data available that someone could use to build their own index, and that this be possible at runtime. This also helps with removal of the spritecache at design time.

[sonneveld]

This is just for the editor correct? So it wouldn't assist in issues when objects are in different orders when trying to use a save game of a different version of the game?

Should we expand the scope such that all objects have a unique id (random, like a uuid) which is order agnostic and saved in the game data? If a developer requires specific range of incrementing integer indexes (I've seen them used for simulating animations), then maybe that should be an explicit setting on the objects, all other objects to be added in a psuedo-random order to discourage assumed order in scripts?

Maybe order could be only guaranteed in view loops, requiring scripting functions to query loops and their available views?

[ghost]

Should we expand the scope such that all objects have a unique id (random, like a uuid) which is order agnostic and saved in the game data?

Uid-based object reference is also one of the prerequisites for portable saves imho.

But this is going far... I was hoping to find a simple short term solution to let people reorder particular objects in their game, because there were complaints about this in the past. Naturally this will become obsolete when/if you change the way objects are stored or identified. Anyway, maybe I've already found one (https://github.com/adventuregamestudio/ags/issues/853#issuecomment-505833914)

[ghost]

I implemented the formal ability to do this, so this is covered for now: #858