SOLVED Loading sprites as real number from file results in wrong sprites being displayed

[SirCaliber]

The scribble is meant to be a cheer emote. Basically, I save the cheer emote as a real number in an INI file, then read that number and set the player's emote sprite as that number.
However when adding new sprites, textures get mixed up and so the number actually correlates to the scribble now.
Any way to combat this?

 

[TheouAegis]

Maybe somebody has a better idea, but as of GMs 2.3, that is the unfortunate behavior of assets. You could instead of saving the sprite index, save a different number and use that number to reference an array of all the Sprites in your project. It's a little more work, but then your code won't be as crippled by any changes to the asset tree. You could also instead of saving numbers, save the Sprite named as a stream and then he get the index of the asset when you load the file using asset_get_index().

 

[Mr Magnus]

Don't rely on Game Maker's internal asset id's as eternal constants that can be preserved between the game running. The compiler will change them whenever it seems fit.

The "proper" solution here is to write a custom mapping: some function that takes in a sprite_index and maps it to some code you yourself decide upon that will not change. Then a different function going the
other way. That way no matter how much the compiler shuffles around the asset index you'll always have the exact same behavior, because your mapping doesn't care about what the "actual" values behind sprite_index is.

 

[Roldy]

Any way to combat this?

Don't store numbers, store strings instead. Store the name of the asset, then use asset_get_index to discover the index again.

Alternatively if you really want to write out a number then you need to make a mapping of YOUR_CUSTOM_INDEX -> "AssertStringName". Then when you load YOUR_CUSTOM_INDEX you look up the asset name, call asset_get_index to get the actual index.

 

[Slow Fingers]

Yup, was going to say just that, but @Roldy sniped me.
Save and read strings, and convert them in asset index with asset_get_index() .
Don't rely on in-game indexes, you'll be ****** as soon as you add or remove stuff, and is just a BIG no-no.
Oh, and if anyone tells you to not use asset_get_index because "it's slow", tell them we live in an era where a run-of-the-mill computer does billions of calculations per second and let them sink that in for a while.

 

[SirCaliber]

Ok, thanks everyone! I'm gonna go with the writing string method and reading with asset_get_index()

I honestly never even knew about asset_get_index() but it seems really useful

Thanks again!

 

[chamaeleon]

Oh, and if anyone tells you to not use asset_get_index because "it's slow", tell them we live in an era where a run-of-the-mill computer does billions of calculations per second and let them sink that in for a while.

To take this a bit further, I'm going to hazard a guess that the time to perform the asset lookup is rather smaller than the time to create a resource of that type.

 

[TheouAegis]

Actually I advise against using asset_get_index() because you can't change the names of your assets between versions, otherwise you will cripple any save file. After all, that has been the biggest criticism about relying on asset IDs across all versions of GM, that it will gimp not just project code but also save data.

 

[Slow Fingers]

I honestly never even knew about asset_get_index() but it seems really useful

Man, I use that all the time, this is a gamechanger, when you know how to use it.
Example: Change sprite automatically ->

player_state = "idle_";        //Assume this goes attack, idle, hurt, dead...
player_facing = "left";        //Assume this change to up, down, left or right

//Combine all this wo fit your sprite naming convention
spr_string = "spr_player_" + player_state + player_facing;

//Use that string to load the correct sprite
sprite_index = asset_get_index(spr_string);

Most people will go

if(bla-bla-bla) && yadiyadiyada {
    image_index = some_sprite;
} else
if(blo-bli-blu) && some_other_thing {
    image_index = some__other_sprite;
}
/// And so on, so you can clearly see what looks better and what's easier to read and debug as a human.