sp_custom
Does sp_custom stay if you change screen, like editor_seq/frame? And is it saved in save game files?
To my knowledge, sp_custom works as sp_strength and all those. But if you attach it to sprite 1 it may carry over screen. I'm not sure about how Dink is transferred to screen so the only real way to know is to test it. I doubt it would save though.
sp_custom doesn't work with sprite 1. Alas, no free globals
I seem to remember using sp_gold() when I was working with my switchable character project. It retained it's value over switching screens. So even if sp_custom won't work with Dink you could use sp_gold().
I forgot about sp_gold() but I think that won't do either.
I wanted to keep dead bodies showing like Redink1 did in Initiation but also have some way of saving the sprite's sequence, he uses editor_seq/frame to store the x/y positions so there's not much left.
Unless... what about editor_type? Could I use that? I'll do some testing soon if I can.
I wanted to keep dead bodies showing like Redink1 did in Initiation but also have some way of saving the sprite's sequence, he uses editor_seq/frame to store the x/y positions so there's not much left.
Unless... what about editor_type? Could I use that? I'll do some testing soon if I can.
Don't use editor_type, that'll screw things up. editor_seq and editor_frame are really the way to go. You can set the sequence and frame manually using sp_pframe and sp_pseq in the main procedure.
Couldn't you set the sequence/frame where you set the x/y? I think messing with the editor type would mess things up. If you really need to save the direction they died in then you can make the editor_frame() act as a supervar.
//example
int &crap = sp_x(¤t_sprite, -1);
&crap *= 1000;
int &crap2 = sp_y(¤t_sprite, -1);
&crap += &crap2;
editor_frame(¤t_sprite, &crap);
//main procedure
//extracting the x,y
int &crap = editor_frame(¤t_sprite, -1);
int &crap2 = &crap;
&crap /= 1000;
sp_x(¤t_sprite, &crap);
&crap *= 1000;
&crap2 -= &crap;
sp_y(¤t_sprite, &crap2);
//end of scripting
This way you can use editor_seq() for the sequence of the death.
//example
int &crap = sp_x(¤t_sprite, -1);
&crap *= 1000;
int &crap2 = sp_y(¤t_sprite, -1);
&crap += &crap2;
editor_frame(¤t_sprite, &crap);
//main procedure
//extracting the x,y
int &crap = editor_frame(¤t_sprite, -1);
int &crap2 = &crap;
&crap /= 1000;
sp_x(¤t_sprite, &crap);
&crap *= 1000;
&crap2 -= &crap;
sp_y(¤t_sprite, &crap2);
//end of scripting
This way you can use editor_seq() for the sequence of the death.
There is an upper bound to editor_frame and editor_seq values, and this is lower than the upper bound of "normal" variables.
Also, your code doesn't work. editor_frame and editor_seq (and editor_type too) need an "editor sprite number", not an "active sprite number". Fixed:
//example
int &crap = sp_x(¤t_sprite, -1);
&crap *= 1000;
int &crap2 = sp_y(¤t_sprite, -1);
&crap += &crap2;
int &me = sp_editor_num(¤t_sprite);
editor_frame(&me, &crap);
//main procedure
//extracting the x,y
int &me = sp_editor_num(¤t_sprite);
int &crap = editor_frame(&me, -1);
int &crap2 = &crap;
&crap /= 1000;
sp_x(¤t_sprite, &crap);
&crap *= 1000;
&crap2 -= &crap;
sp_y(¤t_sprite, &crap2);
//end of scripting
Also, your code doesn't work. editor_frame and editor_seq (and editor_type too) need an "editor sprite number", not an "active sprite number". Fixed:
//example
int &crap = sp_x(¤t_sprite, -1);
&crap *= 1000;
int &crap2 = sp_y(¤t_sprite, -1);
&crap += &crap2;
int &me = sp_editor_num(¤t_sprite);
editor_frame(&me, &crap);
//main procedure
//extracting the x,y
int &me = sp_editor_num(¤t_sprite);
int &crap = editor_frame(&me, -1);
int &crap2 = &crap;
&crap /= 1000;
sp_x(¤t_sprite, &crap);
&crap *= 1000;
&crap2 -= &crap;
sp_y(¤t_sprite, &crap2);
//end of scripting
Dang I completely forgot about the editor number. Woops
Nice, thanks!
I thought of supervars, downloaded the supervar source thing and spent a while staring gormlessly at it.
This looks a lot easier to understand, so I'll stare at this for a bit (maths is not my strong point!).
I'd need to use editor_seq because the limit of editor_frame is only 255 but that doesn't make a difference.
Edit: Got it, with the help of a good ol' pen and paper
The limit of editor_seq is smallish as well, at 65535 so I may need to shrink it again before putting it in editor_whatever.
I thought of supervars, downloaded the supervar source thing and spent a while staring gormlessly at it.
This looks a lot easier to understand, so I'll stare at this for a bit (maths is not my strong point!).
I'd need to use editor_seq because the limit of editor_frame is only 255 but that doesn't make a difference.
Edit: Got it, with the help of a good ol' pen and paper
The limit of editor_seq is smallish as well, at 65535 so I may need to shrink it again before putting it in editor_whatever.
65535 is a bit small to be working with and get accurate results after extracting it.
What I've got so far:
//example - storing seq (not bigger than 143) and y position.
int &crap = sp_pseq(¤t_sprite, -1);
&crap /= 2;
&crap *= 1000;
int &crap2 = sp_y(¤t_sprite, -1);
&crap += &crap2;
&crap /= 2;
int &me = sp_editor_num(¤t_sprite);
editor_seq(&me, &crap);
//main procedure
//extracting the x,y
int &me = sp_editor_num(¤t_sprite);
int &crap = editor_seq(&me, -1);
&crap *= 2;
int &crap2 = &crap;
&crap /= 1000;
&crap *= 2;
sp_seq(¤t_sprite, &crap);
&crap /= 2;
&crap *= 1000;
&crap2 -= &crap;
sp_y(¤t_sprite, &crap2);
//end of scripting
Which gives a result 1 larger than the numbers I started with, which is ok for x/y but not for the sequence! If I do x and y instead of the seq and y then it's anywhere up to 600 and 400 which means more shrinking to fit into 65535 and less accurate when extracted. Help?
What I've got so far:
//example - storing seq (not bigger than 143) and y position.
int &crap = sp_pseq(¤t_sprite, -1);
&crap /= 2;
&crap *= 1000;
int &crap2 = sp_y(¤t_sprite, -1);
&crap += &crap2;
&crap /= 2;
int &me = sp_editor_num(¤t_sprite);
editor_seq(&me, &crap);
//main procedure
//extracting the x,y
int &me = sp_editor_num(¤t_sprite);
int &crap = editor_seq(&me, -1);
&crap *= 2;
int &crap2 = &crap;
&crap /= 1000;
&crap *= 2;
sp_seq(¤t_sprite, &crap);
&crap /= 2;
&crap *= 1000;
&crap2 -= &crap;
sp_y(¤t_sprite, &crap2);
//end of scripting
Which gives a result 1 larger than the numbers I started with, which is ok for x/y but not for the sequence! If I do x and y instead of the seq and y then it's anywhere up to 600 and 400 which means more shrinking to fit into 65535 and less accurate when extracted. Help?
Hmm.. It looks like you'll just have to stick with using editor_seq for the x coordinate and editor_frame for the y coordinate. I didn't know that those numbers were capped off so low. It appears as if there is no other way.
In doing it this way you will end up with all your dead sprites facing the same direction. It wouldn't be much, but having them face a random direction might make things look a little less ugly.
In doing it this way you will end up with all your dead sprites facing the same direction. It wouldn't be much, but having them face a random direction might make things look a little less ugly.
Oh well.
Trouble with having it random is when you go in and out of the screen they'll keep switching directions.
Oh hang on... I only need to remember 2 different sequences. I could save just 1 or 0 to know which one. Duh
But you can easily put both a coordinate and a direction in editor_seq. The cap is not *that* low.
seq range 65536
frame range 256
max states = 65536 x 256 = 16,777,216
x range = 600
y range = 400
seq range = 2
store with multiple bases:
&var = seq + y * 2 + x * 801
max value = only 481,401!
store:
&edseq = math_mod(&var,65535);
&edframe = &var / 65535;
extract:
&var = &edseq + &edframe * 65535;
&x = &var / 801;
&var = math_mod(&var,801);
&y = &var / 2;
&seq = math_mod(&var,2);
frame range 256
max states = 65536 x 256 = 16,777,216
x range = 600
y range = 400
seq range = 2
store with multiple bases:
&var = seq + y * 2 + x * 801
max value = only 481,401!
store:
&edseq = math_mod(&var,65535);
&edframe = &var / 65535;
extract:
&var = &edseq + &edframe * 65535;
&x = &var / 801;
&var = math_mod(&var,801);
&y = &var / 2;
&seq = math_mod(&var,2);
Wonderful!
I've scripted it and I'll test tomorrow. Now almost 4am so off to bed
Why 801 btw? What's special about that number?
I've scripted it and I'll test tomorrow. Now almost 4am so off to bed
Why 801 btw? What's special about that number?
It's because he used y * 2 to store y, which means that 400*2 = 800, so he starts storing x at 800 + 1 to avoid "interference" between the values. If that made any sense, lol.
No luck. So what've I got wrong, the maths or the scripting? Or both?
After they're killed, when I enter the screen they're all at roughly x,y 90,325 and all sequence 143.
Here's what I've done:
void main (void)
{
//extracting
int &ed_num = sp_editor_num(¤t_sprite);
int &temp = editor_seq(&ed_num, -1);
int &temp2 = editor_frame(&ed_num, -1);
if (&temp)
{
&temp2 * 65535;
&temp += &temp2;
&temp2 = &temp;
&temp / 801;
sp_x(¤t_sprite, &temp);
&temp2 = math_mod(&temp2, 801);
&temp = &temp2;
&temp / 2;
sp_y(¤t_sprite, &temp);
&temp = math_mod(&temp2, 2);
if (&temp)
sp_seq(¤t_sprite, 141);
else
sp_seq(¤t_sprite, 143);
sp_brain(¤t_sprite, 5);
kill_this_task();
}
//rest of script
}
spawned script:
void main (void)
{
//global &sprite = ¤t_sprite
//sprite dies with hurt()
//storing:
int &ed_num = sp_editor_num(&sprite);
int &temp = sp_pseq(&sprite, -1);
if (&temp == 141)
{
&temp = 1;
}
if (&temp == 143)
{
&temp = 0;
}
int &temp2 = sp_y(&sprite, -1);
&temp2 * 2;
&temp += &temp2;
&temp2 = sp_x(&sprite, -1);
&temp2 * 801;
&temp += &temp2;
&temp2 = math_mod(&temp, 65535);
editor_seq(&ed_num, &temp2);
&temp / 65535;
editor_frame(&ed_num, &temp);
kill_this_task();
}
I would store it in the die procedure but that doesn't seem to run when the sprite's killed with hurt().
Oh and thanks Phoenix, it did
After they're killed, when I enter the screen they're all at roughly x,y 90,325 and all sequence 143.
Here's what I've done:
void main (void)
{
//extracting
int &ed_num = sp_editor_num(¤t_sprite);
int &temp = editor_seq(&ed_num, -1);
int &temp2 = editor_frame(&ed_num, -1);
if (&temp)
{
&temp2 * 65535;
&temp += &temp2;
&temp2 = &temp;
&temp / 801;
sp_x(¤t_sprite, &temp);
&temp2 = math_mod(&temp2, 801);
&temp = &temp2;
&temp / 2;
sp_y(¤t_sprite, &temp);
&temp = math_mod(&temp2, 2);
if (&temp)
sp_seq(¤t_sprite, 141);
else
sp_seq(¤t_sprite, 143);
sp_brain(¤t_sprite, 5);
kill_this_task();
}
//rest of script
}
spawned script:
void main (void)
{
//global &sprite = ¤t_sprite
//sprite dies with hurt()
//storing:
int &ed_num = sp_editor_num(&sprite);
int &temp = sp_pseq(&sprite, -1);
if (&temp == 141)
{
&temp = 1;
}
if (&temp == 143)
{
&temp = 0;
}
int &temp2 = sp_y(&sprite, -1);
&temp2 * 2;
&temp += &temp2;
&temp2 = sp_x(&sprite, -1);
&temp2 * 801;
&temp += &temp2;
&temp2 = math_mod(&temp, 65535);
editor_seq(&ed_num, &temp2);
&temp / 65535;
editor_frame(&ed_num, &temp);
kill_this_task();
}
I would store it in the die procedure but that doesn't seem to run when the sprite's killed with hurt().
Oh and thanks Phoenix, it did
Debugging is no fun
You can try the easy way, in a way that Endy was the first to use somewhere, since there's plenty of room in the variables to waste states extravagantly.
store:
if (y > 200)
{
x += 1000;
y -= 200;
}
if (seq == 1)
x += 10000;
store x in ed_seq, y in ed_frame
//////
extract:
if (x > 10000)
{
x -= 10000;
seq = 1;
} else seq = 0;
if (x > 1000)
{
x -= 1000;
y += 200;
}
---
This strategy is a lot more restrictive and boring, but it'll work here and is easier to set up
You can try the easy way, in a way that Endy was the first to use somewhere, since there's plenty of room in the variables to waste states extravagantly.
store:
if (y > 200)
{
x += 1000;
y -= 200;
}
if (seq == 1)
x += 10000;
store x in ed_seq, y in ed_frame
//////
extract:
if (x > 10000)
{
x -= 10000;
seq = 1;
} else seq = 0;
if (x > 1000)
{
x -= 1000;
y += 200;
}
---
This strategy is a lot more restrictive and boring, but it'll work here and is easier to set up
"Debugging is no fun"
Ok, after a load of debugging... Half the problem was me killing off the sprite and then trying to store things in it. That's fixed, and rather than try and fix the rest of it I think I'll use the easy way, which works! Thank you
Ok, after a load of debugging... Half the problem was me killing off the sprite and then trying to store things in it. That's fixed, and rather than try and fix the rest of it I think I'll use the easy way, which works! Thank you