The Dink Network

I'm trying to script torches that go out one minute after they've been set on fire. And they have to remember when they are set on fire, so, for example: You light them on t=0, then you wait 15 seconds and go to another screen, then t=15. You wait 15 seconds there and go back, t=30. You wait 30 more seconds and it stops burning. I'm using this script for time-management:

void main( void )
{
loop:
wait(1000);
&duntimer += 1;
if (&player_map < 353)
{
&duntimer = 0;
kill_this_task();
}
goto loop;
}

In which &duntimer is a global. The if line is there because it should stop counting when in a specific area. I don't think the variable-value limit is relevant here, because you have to be really sick when you spend that much time while the script is active. It basically adds 1 to the &duntimer for every second since it is spawned, which happened in a base script.

When you've launched a fireball at it, the dam-fire checks if the sp_gold() value is 10, and if so, it runs the burn(void) proc, which looks like this:

void burn( void )
{
int &junk = sp_editor_num(&current_sprite);
editor_seq(&junk, &duntimer);
int &crap = &duntimer;
sp_gold(&current_sprite, 0);
sp_pseq(&current_sprite, 916);
sp_brain(&current_sprite, 6);
sp_seq(&current_sprite, 916);
sp_frame(&current_sprite, 1);
goto timecheck;
}

It uses Pauls Script trick with editor seqs/frames to let the sprite remember when it was put on fire, it changes the graphic to a burning torch and goes to the timecheck label:

timecheck:
&crap = editor_seq(&junk, -1);
wait(100);
&brap = &duntimer;
&brap -= &crap;
say("Global time: &duntimer. Local time: &crap. Difference time: &duntimer - &crap = &brap.",&current_sprite);
if (&brap < 60)
{
goto timecheck;
}
unburn();

This is also a constant loop, unless &brap reaches 60. Then the script runs the unburn(void) proc:

void unburn( void )
{
int &junk = sp_editor_num(&current_sprite);
sp_gold(&current_sprite, 10);
sp_brain(&current_sprite, 0);
sp_pseq(&current_sprite, 850);
sp_pframe(&current_sprite, 23);
editor_seq(&junk, 0);
&crap = 0;
}

Maybe goto's work better than this proc() using, but my problem occurs even before this stage. As you can see I've added some dev-text in the timecheck proc. But now the weird thing is, the torch says: "Global time: 17. Local time: 2. Difference time: 17 - 2 = -32". That in itself is pretty weird, but when I've got more torches on one screen, the "Local time" doesn't matter. All "Difference times" are the same (they count, too, just like the Global time).

Anyone knows what's happening here? If it doesn't even work when staying on the screen, how am I supposed to make it work if you change screens?

Oh, as a sidenote, does get_sprite_with_this_brain() work with "new" brains, like brain 23 or something?

As for your side note, yes, new brains are permitted by this command, my bizzare wall building procedure uses this.

As for the rest... I have no idea... there ought to be a simpler way to do things, but I can't think of it. My experience with custom procedures has been that they do screwy things.

But I'm curious, where is this timecheck label, and what is &junk in that context?

&junk is defined in the main, as well as in any other procedures called by proc(); in the following way:

int &junk = sp_editor_num(&current_sprite);

I've put the timecheck: label in a separate procedure:

void check( void )
{
timecheck:
//etc...
}

This procedure is never called by check();

I need the brain thing, so I can check if there are any not-burning torches on the screen, this way I can add a "darkness" to the dungeon and make it disappear when all torches are lit (Zelda-style).

Since I still haven't been able to figure it out by myself, I've included the whole torch.c, so you have more to work with. The problem might be something trivial like forgotten semicolons or brackets, or a misspelled name, but EasyDinkC doesn't find any bracket/semicolon errors, and the only uncolored things are the say-strings and the sp_gold();

void main( void )
{
int &brap;
int &junk = sp_editor_num(&current_sprite);
sp_hard(&current_sprite, 0);
draw_hard_sprite(&current_sprite);
int &crap = editor_seq(&junk, -1);
sp_gold(&current_sprite, 10);
if (&crap == 0)
{
unburn();
return;
}
if (&duntimer < &crap)
{
unburn();
return;
}
&brap = &duntimer;
&brap -= &crap;
say("&duntimer - &crap = &brap",1);
if (&brap <= 60)
{
sp_gold(&current_sprite, 0);
sp_pseq(&current_sprite, 916);
sp_brain(&current_sprite, 6);
sp_seq(&current_sprite, 916);
sp_frame(&current_sprite, 1);
goto timecheck;
}
goto timecheck;
}

void unburn( void )
{
int &junk = sp_editor_num(&current_sprite);
sp_gold(&current_sprite, 10);
sp_brain(&current_sprite, 0);
sp_pseq(&current_sprite, 850);
sp_pframe(&current_sprite, 23);
editor_seq(&junk, 0);
&crap = 0;
}

void burn( void )
{
int &junk = sp_editor_num(&current_sprite);
editor_seq(&junk, &duntimer);
int &crap = &duntimer;
int &brap;
sp_gold(&current_sprite, 0);
sp_pseq(&current_sprite, 916);
sp_brain(&current_sprite, 6);
sp_seq(&current_sprite, 916);
sp_frame(&current_sprite, 1);
goto timecheck;
}

void check( void )
{
timecheck:
&crap = editor_seq(&junk, -1);
wait(100);
&brap = &duntimer;
&brap -= &crap;
say("Global time: &duntimer. Local time: &crap. Difference time: &duntimer - &crap = &brap.",&current_sprite);
if (&brap < 60)
{
goto timecheck;
}
unburn();
}

I don't like how you've declared &crap twice (once in burn, once in main), but it shouldn't cause problems in any case... I'm baffled.

Edit: It's also good manners to end a procedure with a return, but if thats causing your problems, you can fry my balls in oil.

Try using a variable other than &junk. Rename it to &hunk or something. Why? IIRC, &junk is a global.

It isn't a global; it's Seth's favorite local.

Alas, it won't work. I've changed every instance of &junk into &hunk. Even in &dddaa but it didn't do anything. I added return; before each proc closing bracket, and it didn't work. I replaced "unburn();" with "goto unburrnn;", and added a "unburrnn:" after the opening bracket. I got rid of some double int's, but nothing worked

shouldn't you put some wait(100); infront of the goto commands. Also putting some more wait commands at other points in the script would help too.

Well...dang Seth, then.

There are some very serious problems with supposedly "local" variables getting mixed up. This gave me hell working on Triangle Mover. It's a little late for decyphering scripts or remembering exactly what the bugs were (after midnight here) but I think there's always some way around it. Wne locals don't work right, you can use global variables for math (as long no waits need to happen during the calculation) and attributes like sp_gold and sp_strength for storing things.

The other trouble spot I see is that scripts calling their own functions can't (reliably?) access their own locals. You may be able to use goto instead. (Yes you can goto between functions, even outside them if you want.)

I've placed several wait(100); 's in the script, but it didn't seem to work.

Just after trying igloo15's suggestion, I've replaced every instance of &crap with &droopy. Basically the script should work the same way as before, but now 17-2=15

Anyway, thanks all for suggestions. I really appreciate it

EDIT: Now shoot me, if you must, but there's still var-exchange between two torches

Two torches on the same screen:

The first says: 20-5 = 15, the other one says: 20-15 = 15

Well, what's the most torchs you'll have in a room? The easy solution would be to just make than many different scripts each with their own variable name. Though I admit that's not too graceful.

Yeah... multiple instances of the same script in the same screen will communicate variables between each other. It is horrible.

Though you never see that problem with enemy scripts, such as the dragon. Dragons use more variables than the other enemies, but things still go well when you place more of them on one screen.

Sounds like I really have to create different scripts for every torch on a screen

The problem is still there in enemy scripts... try something like:

int &rand = random(3,1);
say("&rand", &current_sprite);

in an enemy script, and I think they'll all say the same number.

Well, I tried it. But even the exchange seems to be random. On the first screen I checked: All pillbugs (three in total) said "3", second screen (two bugs): "1","2"

Strange...

Hmm... I remember messing with this about a year-and-a-half ago, and I think you're right. Say isn't affected by the variable intermingling.

But... try setting the speed of the pillbugs to the random number. I'm pretty sure they'll all walk the same speed, even though they'll say different numbers. I vaguely remember something like this.

The main time this bug shows up (as best I remember) is when you assign the value of one local to antoher variable. Such as:
&local1 = &local2;
or
&global += &local;

@redink1:

You are correct. I have your test dmod (at least I think so) that you used to prove that they will move the same speed. It was called "Versatile Pillbug". Ring any bells?