Bug in dmod or freedink
Scourger (The)
October 27th 2012, 11:24 AM
shevek
When playing the Scourger, I managed to do the fence-puzzle to get to the knight. I also died somewhere later. I reloaded from just before the puzzle, but I could not play it again, because the speaker voice was not working. In debugging mode, I could see that freedink does claim that it will work, but nothing appears on screen.
Could people please try to reproduce this, both with freedink and with other flavours? I've put the save file on my server. From the save bot, just walk right, down, right, then talk to the pole.
Thanks!
Could people please try to reproduce this, both with freedink and with other flavours? I've put the save file on my server. From the save bot, just walk right, down, right, then talk to the pole.
Thanks!
Not having played The Scourger before (at least not that far), that was a pretty surreal experience. 
I assume Dink was supposed to talk to someone instead of just himself. After a while the game asked if I wanted to try again.
This was on v1.08, so it seems like a dmod bug.
I assume Dink was supposed to talk to someone instead of just himself. After a while the game asked if I wanted to try again.This was on v1.08, so it seems like a dmod bug.
October 27th 2012, 12:23 PM
shevek
that was a pretty surreal experience.
That's not because of the dmod. Before reloading, everything was fine, and a voice was talking back.
Also, I don't see a problem in the script, and with debugging output, freedink claims that sprites are talking, too. So for now, I'm going for a bug in the engine (in a part which is not freedink-specific).
Of course, given the state of the engine, a dmod that doesn't work around one of its bugs should be considered buggy itself.
That's not because of the dmod. Before reloading, everything was fine, and a voice was talking back.
Also, I don't see a problem in the script, and with debugging output, freedink claims that sprites are talking, too. So for now, I'm going for a bug in the engine (in a part which is not freedink-specific).
Of course, given the state of the engine, a dmod that doesn't work around one of its bugs should be considered buggy itself.
Yes, I'm getting the same bug with Dink v1.08... Might dig some deeper into this to see what's causing this, I've never before heard of this bug.
The only thing I did notice is that the variables in the savegame looks quite a bit different in the savegame editor compared to one saved under windows. I can't be a hundred percent sure, but I'm afraid this might have something to do with either linux formatting or freedink formatting of savegames.
The only thing I did notice is that the variables in the savegame looks quite a bit different in the savegame editor compared to one saved under windows. I can't be a hundred percent sure, but I'm afraid this might have something to do with either linux formatting or freedink formatting of savegames.
I played around a little, and adding a preload_seq(444) in the beginning of the script fixes the problem, so it appears to be a problem with the sprite not being loaded into memory. (Remember the infamous disappearing NPC bug? 
)
Likewise, if you at any time encounter one of them cagey boxes on your playing session, the bug won't happen again until you quit to system and start the game again. (At least on 108)
)Likewise, if you at any time encounter one of them cagey boxes on your playing session, the bug won't happen again until you quit to system and start the game again. (At least on 108)
October 28th 2012, 07:12 AM
shevek
adding a preload_seq(444) in the beginning of the script fixes the problem
Ok, that explains what happens: the sprite sequence isn't loaded until the screen is updated. And for some reason the sprite can't talk until its sequence is in memory (makes sense if you don't think about it...)
It also explains why it didn't happen before: I suppose sprite 444 was already loaded somewhere earlier in the game.
preload_seq is intended to be a performance tweak. I find it unacceptable to require it to make things work. Luckily there is another solution: add wait(1) after the call to create_sprite does the job as well. I suppose this makes sure update_frame is called, which loads the sequence.
Well, it works in freedink at least.
Ok, that explains what happens: the sprite sequence isn't loaded until the screen is updated. And for some reason the sprite can't talk until its sequence is in memory (makes sense if you don't think about it...)
It also explains why it didn't happen before: I suppose sprite 444 was already loaded somewhere earlier in the game.
preload_seq is intended to be a performance tweak. I find it unacceptable to require it to make things work. Luckily there is another solution: add wait(1) after the call to create_sprite does the job as well. I suppose this makes sure update_frame is called, which loads the sequence.
Well, it works in freedink at least.
