Reply to Re: Dink Smallwood HD for :Windows update
If you don't have an account, just leave the password field blank.
The sp_custom command isn't really used for more variable slots though. It's used to have more sprite properties, custom properties. Like how often has Dink talked to this sprite, how often has it been hit, what is its order in a puzzle, ... But it can not be retrieved without being able to refer to the sprite holding the value (which usually requires a variable xD) and it can only be used on the same screen the sprite is on. Now, if we could use sp_custom() with the Dink sprite itself, THAT would open up a lot of options for variable usage. Oh yeah, I wish we could do that the more I think of it 
But that would mean this sp_custom is saved in the save file, which it isn't at this point unfortunately. This would also partially solve the following issue.
However, I wasn't even talking about the global variable limit in my previous post (though that is a concern). I was talking about the max amount of variables being available at any given time (around 250?). I have a rather complicated battle system in my d-mod in development that requires about 15-20 variables in play per enemy sprite to track a variety of things such as poisonous, life steal, critical hits, elemental weakness, ... This already limits me to how many enemies I can have on screen (a compromise I was willing to make). Now add to that variables used by spells that might be flying around, custom UI variables, variables used by the equiped weapon script and the full amount of globals which are always in use and you can see how that limit is easily reached (which breaks something every time it's exceeded). We have a pretty decent amount of global variables we can use, but that's only because we abuse the living hell out of the editor sequence and frame to store extra things inside a sprite on a screen. Like sometimes I would just place a barrel only to store 2 variables that are saved in the savefile. Tracking the status of a conversation with a sprite has traditionally been using this trick as well.
I also track things such as which secrets have been found to check them off a map. But that means that, since we don't have arrays, I need a global variable PER secret. I have worked around this by using variables to store huge numbers, abusing the integer. Like a variable holding the value 5785454274 and then isolating seperate digits for extraction. A usable workaround, but very inconvinient to track which digit stands for what without writing all of that down somewhere. However, if we choose globals for this, we use up a lot of our global variables, these are counting heavily toward our maximum amount of live variables being used by the game at any given moment. And the problem persists.
Don't get me wrong though, d-mods have worked and will continue to work and shine without improving this, but this problem specifically is hard to find a solution for in scripting. It almost always ends with me saying "oh well I'll have to scrap that idea" and that's a shame
And I guess I do understand your fear of changing functionality instead of adding to it or improving on it. I realize it can be dangerous. Perhaps there is a workaround for this? Like a sp_interrupt(&curent_sprite, 1) to enable/disable it?
Anyway, I'm off filling my graphics slots with transparent sprites
But that would mean this sp_custom is saved in the save file, which it isn't at this point unfortunately. This would also partially solve the following issue. However, I wasn't even talking about the global variable limit in my previous post (though that is a concern). I was talking about the max amount of variables being available at any given time (around 250?). I have a rather complicated battle system in my d-mod in development that requires about 15-20 variables in play per enemy sprite to track a variety of things such as poisonous, life steal, critical hits, elemental weakness, ... This already limits me to how many enemies I can have on screen (a compromise I was willing to make). Now add to that variables used by spells that might be flying around, custom UI variables, variables used by the equiped weapon script and the full amount of globals which are always in use and you can see how that limit is easily reached (which breaks something every time it's exceeded). We have a pretty decent amount of global variables we can use, but that's only because we abuse the living hell out of the editor sequence and frame to store extra things inside a sprite on a screen. Like sometimes I would just place a barrel only to store 2 variables that are saved in the savefile. Tracking the status of a conversation with a sprite has traditionally been using this trick as well.
I also track things such as which secrets have been found to check them off a map. But that means that, since we don't have arrays, I need a global variable PER secret. I have worked around this by using variables to store huge numbers, abusing the integer. Like a variable holding the value 5785454274 and then isolating seperate digits for extraction. A usable workaround, but very inconvinient to track which digit stands for what without writing all of that down somewhere. However, if we choose globals for this, we use up a lot of our global variables, these are counting heavily toward our maximum amount of live variables being used by the game at any given moment. And the problem persists.
Don't get me wrong though, d-mods have worked and will continue to work and shine without improving this, but this problem specifically is hard to find a solution for in scripting. It almost always ends with me saying "oh well I'll have to scrap that idea" and that's a shame
And I guess I do understand your fear of changing functionality instead of adding to it or improving on it. I realize it can be dangerous. Perhaps there is a workaround for this? Like a sp_interrupt(&curent_sprite, 1) to enable/disable it?
Anyway, I'm off filling my graphics slots with transparent sprites
