The Dink Network

sp_custom

February 26th 2008, 12:49 PM
dinkdead.gif
Does sp_custom stay if you change screen, like editor_seq/frame? And is it saved in save game files?
February 26th 2008, 03:16 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
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.
February 26th 2008, 03:38 PM
custom_magicman.gif
magicman
Peasant They/Them Netherlands duck
Mmmm, pizza. 
sp_custom doesn't work with sprite 1. Alas, no free globals
February 26th 2008, 05:06 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
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().
February 26th 2008, 05:19 PM
dinkdead.gif
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.
February 26th 2008, 05:27 PM
custom_magicman.gif
magicman
Peasant They/Them Netherlands duck
Mmmm, pizza. 
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.
February 26th 2008, 05:30 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
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(&current_sprite, -1);
&crap *= 1000;
int &crap2 = sp_y(&current_sprite, -1);
&crap += &crap2;
editor_frame(&current_sprite, &crap);

//main procedure
//extracting the x,y
int &crap = editor_frame(&current_sprite, -1);
int &crap2 = &crap;
&crap /= 1000;
sp_x(&current_sprite, &crap);
&crap *= 1000;
&crap2 -= &crap;
sp_y(&current_sprite, &crap2);

//end of scripting

This way you can use editor_seq() for the sequence of the death.
February 26th 2008, 05:37 PM
custom_magicman.gif
magicman
Peasant They/Them Netherlands duck
Mmmm, pizza. 
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(&current_sprite, -1);
&crap *= 1000;
int &crap2 = sp_y(&current_sprite, -1);
&crap += &crap2;
int &me = sp_editor_num(&current_sprite);
editor_frame(&me, &crap);

//main procedure
//extracting the x,y
int &me = sp_editor_num(&current_sprite);
int &crap = editor_frame(&me, -1);
int &crap2 = &crap;
&crap /= 1000;
sp_x(&current_sprite, &crap);
&crap *= 1000;
&crap2 -= &crap;
sp_y(&current_sprite, &crap2);

//end of scripting
February 26th 2008, 05:45 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
Dang I completely forgot about the editor number. Woops
February 26th 2008, 06:08 PM
dinkdead.gif
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.
February 28th 2008, 07:16 AM
dinkdead.gif
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(&current_sprite, -1);
&crap /= 2;
&crap *= 1000;
int &crap2 = sp_y(&current_sprite, -1);
&crap += &crap2;
&crap /= 2;
int &me = sp_editor_num(&current_sprite);
editor_seq(&me, &crap);

//main procedure
//extracting the x,y
int &me = sp_editor_num(&current_sprite);
int &crap = editor_seq(&me, -1);
&crap *= 2;
int &crap2 = &crap;
&crap /= 1000;
&crap *= 2;
sp_seq(&current_sprite, &crap);
&crap /= 2;
&crap *= 1000;
&crap2 -= &crap;
sp_y(&current_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?
February 28th 2008, 06:33 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
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.
February 28th 2008, 06:52 PM
dinkdead.gif

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
February 28th 2008, 07:58 PM
custom_magicman.gif
magicman
Peasant They/Them Netherlands duck
Mmmm, pizza. 
But you can easily put both a coordinate and a direction in editor_seq. The cap is not *that* low.
February 28th 2008, 08:55 PM
fairy.gif
Someone
Peasant He/Him Australia
 
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);

February 28th 2008, 11:00 PM
dinkdead.gif
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?
February 29th 2008, 01:59 AM
wizardb.gif
Phoenix
Peasant He/Him Norway
Back from the ashes 
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.
March 1st 2008, 09:20 PM
dinkdead.gif
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(&current_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(&current_sprite, &temp);
&temp2 = math_mod(&temp2, 801);
&temp = &temp2;
&temp / 2;
sp_y(&current_sprite, &temp);
&temp = math_mod(&temp2, 2);
if (&temp)
sp_seq(&current_sprite, 141);
else
sp_seq(&current_sprite, 143);
sp_brain(&current_sprite, 5);
kill_this_task();
}
//rest of script
}

spawned script:
void main (void)
{
//global &sprite = &current_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
March 2nd 2008, 08:20 AM
fairy.gif
Someone
Peasant He/Him Australia
 
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
March 2nd 2008, 05:47 PM
dinkdead.gif
"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