sp_custom
Should this work?
I initialized "&spc" as a global variable in main.c.
Then I had this script attached to the first screen:
void main (void)
{
&spc = create_sprite(200, 200, 9, 169, 1);
sp_custom("dump", &spc, 722);
int &pooper = sp_custom("dump", &spc, -1);
say_stop("&pooper", 1);
}
And this one attached to the second screen:
void main(void)
{
int &cheese = sp_custom("dump", &spc, -1);
say_stop("&cheese", 1);
}
After walking onto the first screen, then the second, the custom key doesn't seem to be carrying over (On the second screen, Dink says "-1"), even though I have &spc set as a global... I've created sprites as globals before so they could communicate between scripts, so I know that works, but does this not work between screens? So... did I
a)Just make a stupid mistake or
b)How else could I accomplish something similar?... (I need these values to survive between screens, I'm trying to use them as global variables... ha.) I really doubt 248 globals will suffice for my current project, so I really need to find a way to make this work, or I'll have to remove all of the really cool stuff
.
Thanks in advance!
I initialized "&spc" as a global variable in main.c.
Then I had this script attached to the first screen:
void main (void)
{
&spc = create_sprite(200, 200, 9, 169, 1);
sp_custom("dump", &spc, 722);
int &pooper = sp_custom("dump", &spc, -1);
say_stop("&pooper", 1);
}
And this one attached to the second screen:
void main(void)
{
int &cheese = sp_custom("dump", &spc, -1);
say_stop("&cheese", 1);
}
After walking onto the first screen, then the second, the custom key doesn't seem to be carrying over (On the second screen, Dink says "-1"), even though I have &spc set as a global... I've created sprites as globals before so they could communicate between scripts, so I know that works, but does this not work between screens? So... did I
a)Just make a stupid mistake or
b)How else could I accomplish something similar?... (I need these values to survive between screens, I'm trying to use them as global variables... ha.) I really doubt 248 globals will suffice for my current project, so I really need to find a way to make this work, or I'll have to remove all of the really cool stuff
. Thanks in advance!
The problem is that sp_custom attaches the number to a sprite, not to the variable. The variable only retains the sprite's number on the screen(if you know some programing, you can consider it a pointer). When the screen changes, &spc will remember the sprite's number, but it will call that sprite from the current screen.
You can do some tricks, still to store several numbers in one variable. You can check paul pliska's riddle script to see how he can store an entire word in one number. This works of course, if your numbers are lower than a certain number. For example, if all your numbers are lower than 10, you can keep 9 numbers in one var. If they are lower than 100, you can only keep 4.
If this isn't good enough, I'll think of something else.
You can do some tricks, still to store several numbers in one variable. You can check paul pliska's riddle script to see how he can store an entire word in one number. This works of course, if your numbers are lower than a certain number. For example, if all your numbers are lower than 10, you can keep 9 numbers in one var. If they are lower than 100, you can only keep 4.
If this isn't good enough, I'll think of something else.
Ah I see... the problem is, I'm having to store a multitude of multiple-digit numbers in global variables... I can use supervars to store some of them, but most are multi-digit (up to 4).
Further complicating the situation, the project requires a great number of these variables to be active at the same time, so even if I could store them in supervars, they would all have to be unpacked at the same time, still exceeding the variable cap with local vars...
I was trying to find a way to combat this problem by using sp_custom keys. So there's no way to make a sprite global so I could just create a sprite and pack it full of keys to use as pseudo-globals? Maybe a way you could transfer the same sprite to a different screen without making it sprite 1? If not, are there any other possibilities for getting around the variable cap?
Hm... I just got another idea... if there isn't another way around it, I might be able to store a limited number in each supervar and then when the screen is loaded, unpack them into sp_custom keys, so I wouldn't go over the cap with locals... speaking of which, there aren't any limitations to these keys, are there? DinkC Ref v4.0 says that you can store an unlimited number per sprite, but is there, say, a certain ammount of memory allocated for keys that can't be exceeded or anything like that?
Also, can you do something like this: say_stop("sp_custom("Blah", ¤t_sprite, -1)", 1); , or do you have to create a variable to store the key value in, then plug that into say_stop? I tried this and it didn't work, but I'm just checking to make sure I didn't screw it up or something. In this project I have to have a lot of text objects on the screen and I don't want to have to create an extra var for every one of them.
Further complicating the situation, the project requires a great number of these variables to be active at the same time, so even if I could store them in supervars, they would all have to be unpacked at the same time, still exceeding the variable cap with local vars...
I was trying to find a way to combat this problem by using sp_custom keys. So there's no way to make a sprite global so I could just create a sprite and pack it full of keys to use as pseudo-globals? Maybe a way you could transfer the same sprite to a different screen without making it sprite 1? If not, are there any other possibilities for getting around the variable cap?
Hm... I just got another idea... if there isn't another way around it, I might be able to store a limited number in each supervar and then when the screen is loaded, unpack them into sp_custom keys, so I wouldn't go over the cap with locals... speaking of which, there aren't any limitations to these keys, are there? DinkC Ref v4.0 says that you can store an unlimited number per sprite, but is there, say, a certain ammount of memory allocated for keys that can't be exceeded or anything like that?
Also, can you do something like this: say_stop("sp_custom("Blah", ¤t_sprite, -1)", 1); , or do you have to create a variable to store the key value in, then plug that into say_stop? I tried this and it didn't work, but I'm just checking to make sure I didn't screw it up or something. In this project I have to have a lot of text objects on the screen and I don't want to have to create an extra var for every one of them.
Uberpizza.. wow.. it's been a while. (I missed that you posted a tiny bit last month.) Where've ya been?
Yeah, it has. Well, once my freshman year started I got really busy and didn't have that much time for Dink. That, coupled with the fact that my computer had to be formatted and I lost all my Dink projects... So essentially I just became burned out and frustrated.
At the begining of this summer, though, I had some time to kill, so I redownloaded Dink and played a few dmods. I worked on my Dink project for a couple weeks, and basically redid all the work that I had lost and got a bit further. I'm really intent on completing this project and the dmod (also in the works) that will implement it.
So... I guess expect some more updates and info as I progress more on the project
I think it's pretty ambitious considering my authoring skills... LoL. So far the whole thing has been a "2 steps forward 1 step back" kind of thing. It's good and healthy though because I'm learning a lot of things the hard way.
BTW (slightly off-topic) Are there any negative side effects to using more than a single digit for a value of &vision? In the ref it says it recommends single digits but any ammount is possible...?
At the begining of this summer, though, I had some time to kill, so I redownloaded Dink and played a few dmods. I worked on my Dink project for a couple weeks, and basically redid all the work that I had lost and got a bit further. I'm really intent on completing this project and the dmod (also in the works) that will implement it.
So... I guess expect some more updates and info as I progress more on the project
I think it's pretty ambitious considering my authoring skills... LoL. So far the whole thing has been a "2 steps forward 1 step back" kind of thing. It's good and healthy though because I'm learning a lot of things the hard way. BTW (slightly off-topic) Are there any negative side effects to using more than a single digit for a value of &vision? In the ref it says it recommends single digits but any ammount is possible...?
sp_custom does support unlimited attributes. It uses dynamic memory allocation to get the job done. Granted, if you try to store a billion of the buggers, I'm not sure how well that would work.
As for how to store lots of values... I've had an idea for quite a while. I haven't used it a lot, but it works. Be sure to read the warnings at the end.
In Dink (all versions), the only easily accessible persistant data is global variables and editor sprite information. There's plenty of other information (item scripts, various variables, etc.), but it really isn't very useful or accessible.
So... you have 248 globals (integers), 76032 (99 sprite * 768 screens) editor frames (bytes, range 0-255), and 76032 editor sequences (shorts, range 0-65535). Hey... there's a lot of editor frames and sequences, aren't there?
We can *easily* access all of them. I suggest taking advantage of the custom procedures in Dink 1.08. Try this script:
//function.c
void super_editor_seq( void )
{
//Arguments: &arg1 = map (1-768), &arg2 = sprite (1-99), &arg3 = value (-1 to return)
//NOTE: value must be in range 0-65535 due to memory limitations.
int &old_map = &player_map;
&player_map = &arg1;
int &value = editor_seq(&arg2, &arg3);
&player_map = &old_map;
return(&value);
}
Then insert this in main.c:
//main.c
make_global_function("function", "super_editor_seq");
And then, in theory, you could use it like this:
//somescript.c
void main(void)
{
// set the value of the '768-1' editor variable to 45
super_editor_seq(768, 1, 45);
}
//anotherscript.c
void main(void)
{
// get the value of the '768-1' editor variable
super_editor_seq(768, 1, -1);
int &my_value = &return;
say("&my_value", 1);
//We could also just do say("&return", 1); but then we couldn't access the value after that
}
Bam. You now have 'easy' access to 76,032 more values. You just have to remember the map-sprite key (probably a good idea to write it down somewhere). And if you want even more values, you could create a super_editor_frame function too.
Now... for the bad news. You can't use all 76,032 values. The editor_seq and editor_frame data is used in conjunction with editor_type so barrels can stay broken and the like. It is highly recommended that you only use screen numbers for empty screens.
If you plan on using every screen on the map, then your options are a bit more limited. Most screens don't use all 99 sprites, so you should be able to access sprite 99 data for all 768 maps without too much trouble.
Even if you use all 99 sprites on each screen, you could try to keep track of which sprites could have editor_types of 2, 3, 4, and 5. That includes boxes, chests, burnable trees, etc. Also watch out for sprites with scripts that use Paul's Script Trick (which also abuse editor_seq and editor_frame).
And if decide to make all 99 sprites for each screen a breakable barrel... well, then I think your D-Mod has some serious gameplay issues.
As for how to store lots of values... I've had an idea for quite a while. I haven't used it a lot, but it works. Be sure to read the warnings at the end.
In Dink (all versions), the only easily accessible persistant data is global variables and editor sprite information. There's plenty of other information (item scripts, various variables, etc.), but it really isn't very useful or accessible.
So... you have 248 globals (integers), 76032 (99 sprite * 768 screens) editor frames (bytes, range 0-255), and 76032 editor sequences (shorts, range 0-65535). Hey... there's a lot of editor frames and sequences, aren't there?
We can *easily* access all of them. I suggest taking advantage of the custom procedures in Dink 1.08. Try this script:
//function.c
void super_editor_seq( void )
{
//Arguments: &arg1 = map (1-768), &arg2 = sprite (1-99), &arg3 = value (-1 to return)
//NOTE: value must be in range 0-65535 due to memory limitations.
int &old_map = &player_map;
&player_map = &arg1;
int &value = editor_seq(&arg2, &arg3);
&player_map = &old_map;
return(&value);
}
Then insert this in main.c:
//main.c
make_global_function("function", "super_editor_seq");
And then, in theory, you could use it like this:
//somescript.c
void main(void)
{
// set the value of the '768-1' editor variable to 45
super_editor_seq(768, 1, 45);
}
//anotherscript.c
void main(void)
{
// get the value of the '768-1' editor variable
super_editor_seq(768, 1, -1);
int &my_value = &return;
say("&my_value", 1);
//We could also just do say("&return", 1); but then we couldn't access the value after that
}
Bam. You now have 'easy' access to 76,032 more values. You just have to remember the map-sprite key (probably a good idea to write it down somewhere). And if you want even more values, you could create a super_editor_frame function too.
Now... for the bad news. You can't use all 76,032 values. The editor_seq and editor_frame data is used in conjunction with editor_type so barrels can stay broken and the like. It is highly recommended that you only use screen numbers for empty screens.
If you plan on using every screen on the map, then your options are a bit more limited. Most screens don't use all 99 sprites, so you should be able to access sprite 99 data for all 768 maps without too much trouble.
Even if you use all 99 sprites on each screen, you could try to keep track of which sprites could have editor_types of 2, 3, 4, and 5. That includes boxes, chests, burnable trees, etc. Also watch out for sprites with scripts that use Paul's Script Trick (which also abuse editor_seq and editor_frame).
And if decide to make all 99 sprites for each screen a breakable barrel... well, then I think your D-Mod has some serious gameplay issues.
You mean editor_seq() even works with sprites that don't exist on the map?
Neat 99 more globals per screen is good!
Neat
99 more globals per screen is good!Wow... that's very impressive. 
Just one question though... in the super_editor_seq(); procedure, you have to switch the player's location to the map screen in question... wouldn't doing that nuke what's going on on the current screen, so you couldn't load these values up in the middle of the action taking place on the original screen?
For my project I was worried about hitting the variable cap by having too large of a number of locals running, because all the values had to be used at the same time. So the solution would have been to use a modular script system, calling up each "module" as I needed it and loading up it's values so as not to engage all of them at the same time. (We're talking most likely 2-3 hundred at a time.) So, I'm not sure that I would have enough sprite sequences to work with on
So worst case scenario, if I'm not able to use this system, how much abuse do you think custom keys could handle? (i.e. about 1-200 values)
Also, you mentioned using editor_frame... does that mean 99*50 possible values per screen?! (i.e. 50 frames per sequence?) or am I just being a n00b?
Just one question though... in the super_editor_seq(); procedure, you have to switch the player's location to the map screen in question... wouldn't doing that nuke what's going on on the current screen, so you couldn't load these values up in the middle of the action taking place on the original screen? For my project I was worried about hitting the variable cap by having too large of a number of locals running, because all the values had to be used at the same time. So the solution would have been to use a modular script system, calling up each "module" as I needed it and loading up it's values so as not to engage all of them at the same time. (We're talking most likely 2-3 hundred at a time.) So, I'm not sure that I would have enough sprite sequences to work with on
So worst case scenario, if I'm not able to use this system, how much abuse do you think custom keys could handle? (i.e. about 1-200 values)
Also, you mentioned using editor_frame... does that mean 99*50 possible values per screen?! (i.e. 50 frames per sequence?) or am I just being a n00b?
Changing &player_map won't actually send Dink to the new screen unless you call load_screen() and draw_screen(), as is typically done in warp scripts. So using this trick should't mess anything up on the current screen.
Every screen has 99 sprites (in this case editor-placed-sprites, create_sprite can make more). Every sprite has an editor_seq and editor_frame. So basically every screen holds 198 variables. Warning, though. There are value limits on editor_seq and editor_frame. editor_seq can only hold values from 0 to 65535, and editor_frame has an even lower limit.
Well, redink1, your ideea is great. What happends if we change the map using the load_map command in v1.08?
All of the editor information still exists... but it can cause problems. Remember how barrels stay broken? Depending on what's on the next map, a tree, NPC, or a fish could appear as a broken barrel. That's why I created the clear_editor_data command in 1.08. It would clear all of the values, fixing any barrel issues, but erasing all of the data stored in the method I described.
Friends Beyond 3: Legend of Tenjin had the barrel problem a little bit, but I don't think Wesley used that many barrels and boxes, so it wasn't a huge issue.
Friends Beyond 3: Legend of Tenjin had the barrel problem a little bit, but I don't think Wesley used that many barrels and boxes, so it wasn't a huge issue.
But that's only an issue if you utilize the sp_seq's on a map screen that you use in your dmod, right? (i.e. on a screen that is part of the actual game's action that Dink can walk on)
