Disappearing sprites in DinkHD but not YOD
Not sure what causes this, but it was reported on SOB that one of the wall sprites was missing, but it is there in WDED+ (v2.5.13.0), So I tried deleting it and then replacing it, and it seemed to just shift the problem to another sprite on that screen. This is the screen in Story 3 in SOB for the Armourer dude.
I'm now getting a similar problem in my current DMOD, again with a wall sprite that is there in the editor, but when testing with DinkHD it is gone. Yet if I test it in YOD the sprites are all there as they should be. So my fix is to double place it, which then makes it appear in DinkHD.
Still not sure why it is happening, but thought I'd mention it in case anyone else comes across this weirdness.
I'm now getting a similar problem in my current DMOD, again with a wall sprite that is there in the editor, but when testing with DinkHD it is gone. Yet if I test it in YOD the sprites are all there as they should be. So my fix is to double place it, which then makes it appear in DinkHD.
Still not sure why it is happening, but thought I'd mention it in case anyone else comes across this weirdness.
I couldn't reproduce the bug on SOB but one possible issue is the "sp_y(&temphold4, 550);" line on s3-armr.
s3-armr's main gets run before s3-awife so if player visited some other screen where &temphold4 is used, it'll move some random sprite off-screen.
s3-armr's main gets run before s3-awife so if player visited some other screen where &temphold4 is used, it'll move some random sprite off-screen.
Would YOD not also display the same error if a script and a global variable is at fault?
I guess it would...
Do you have a save from where I could see the issue?
Do you have a save from where I could see the issue?
You're in luck! I still have my SOB saves where it manifests, here you go: https://files.catbox.moe/pvxryn.7z
I included all the DinkHD quicksave and autosave data too.
Note, that this was played using SOB V3.03, so probably best to use the same version?
So just quickload in DinkHD V2.05, and enter the swordsmith's house on that screen. The wall on the top right always disappears when I use that quickload. Weird thing is, if I exit the house and enter again, it no longer disappears ever again!...
You can also manually load slot 7, it is just at the beginning of land 3, the desert. So you can just walk into town and enter the blacksmith's house (north, middle), each time the first time you enter it the problem manifests the same as above.
Edit:
Oh yeah, while testing this out, I found another bug in V3.03 of SOB, although this bug seems to be fixed in V3.06. The only thing is, I'm not sure if this is purely a DinkC bug or a combined DinkC and engine bug?...
So the problem manifests like this: when starting up SOB V3.03, just as the DMOD starts, you can press space and see Dink's text in the top left. If you press ESC now, you can open the menu during the intro "splash-screen". If you select "Load a previous saved game" from the esc menu, you open the load menu normally. The game keeps booting up the start menu in the background, and if you wait until the start menu has appeared, you can no longer select any menu option from the load game menu gui. In fact, you pretty much get stuck there unable to do anything!
Actually, this behaves the same in YeOldeDink, so I guess maybe it's not an engine bug? Or maybe it's a bug that happens in both
Either way, I don't think the engine itself should let you be in a menu with no way out than alt+f4... At the very least i think it should let you hit ESC again and close the load game / esc menus.
I included all the DinkHD quicksave and autosave data too.
Note, that this was played using SOB V3.03, so probably best to use the same version?
So just quickload in DinkHD V2.05, and enter the swordsmith's house on that screen. The wall on the top right always disappears when I use that quickload. Weird thing is, if I exit the house and enter again, it no longer disappears ever again!...
You can also manually load slot 7, it is just at the beginning of land 3, the desert. So you can just walk into town and enter the blacksmith's house (north, middle), each time the first time you enter it the problem manifests the same as above.
Edit:
Oh yeah, while testing this out, I found another bug in V3.03 of SOB, although this bug seems to be fixed in V3.06. The only thing is, I'm not sure if this is purely a DinkC bug or a combined DinkC and engine bug?...
So the problem manifests like this: when starting up SOB V3.03, just as the DMOD starts, you can press space and see Dink's text in the top left. If you press ESC now, you can open the menu during the intro "splash-screen". If you select "Load a previous saved game" from the esc menu, you open the load menu normally. The game keeps booting up the start menu in the background, and if you wait until the start menu has appeared, you can no longer select any menu option from the load game menu gui. In fact, you pretty much get stuck there unable to do anything!
Actually, this behaves the same in YeOldeDink, so I guess maybe it's not an engine bug? Or maybe it's a bug that happens in both
Either way, I don't think the engine itself should let you be in a menu with no way out than alt+f4... At the very least i think it should let you hit ESC again and close the load game / esc menus.
I assume it's one of those edge cases, similar to dying in a menu then walking around, potentially with the same underlying oversight.
Okay, I tested Drone's saves and it I was right: the sp_y(&temphold4, 550); line is the cause. The issue manifests only on the first visit because s3-awife sets temphold4 it's expected value, but it is only run after s3-armr, so it won't be set on the first visit. Afterwards the bug will be re-triggered if you visit any screen that uses temphold4 (for example, screen 316) and return, though the missing wall piece is different.
The issue can be fixed by addingf a wait(0) to s3-armr before it first uses temp4hold, or by moving the wife to above the top edge of the screen (which will change the order the scripts are run)
Also, the issue is present if you load the same save on YeOldeDink
The issue can be fixed by addingf a wait(0) to s3-armr before it first uses temp4hold, or by moving the wife to above the top edge of the screen (which will change the order the scripts are run)
Also, the issue is present if you load the same save on YeOldeDink
Ah I haven't tested that old SOB error between DinkHD and YOD, lazy me...
The one with the difference between DinkHD and YOD was in Necromancer, now since that DMOD has barely begun no point in releasing it to be tested yet. It probably is just my sloppy scripting that is causing this... I did have some sp_nodraw() commands happening but thought I'd removed them all, and I have some sprites using globals to store their sprite number to control their image, so it seems very likely, just the thing of not occurring in YOD confused me.
Maybe YOD and DinkHD process scripts or sprite order differently???
Either way double placing the wall sprite is a fix of sorts in Necromancer for the time being.
At some point I should look those SOB errors again...
_____________________________________
Okay so I just took a look at SOB and drone's quicksave, but the wall was there for me in DinkHD. Mind you I'm using my latest version of SOB which is 3.09 which I should really upload as 3.08 is the one here... sigh... just going to put it down to the joys of DMODing and deal with this all later.
The one with the difference between DinkHD and YOD was in Necromancer, now since that DMOD has barely begun no point in releasing it to be tested yet. It probably is just my sloppy scripting that is causing this... I did have some sp_nodraw() commands happening but thought I'd removed them all, and I have some sprites using globals to store their sprite number to control their image, so it seems very likely, just the thing of not occurring in YOD confused me.
Maybe YOD and DinkHD process scripts or sprite order differently???
Either way double placing the wall sprite is a fix of sorts in Necromancer for the time being.
At some point I should look those SOB errors again...
_____________________________________
Okay so I just took a look at SOB and drone's quicksave, but the wall was there for me in DinkHD. Mind you I'm using my latest version of SOB which is 3.09 which I should really upload as 3.08 is the one here... sigh... just going to put it down to the joys of DMODing and deal with this all later.
Okay so I just took a look at SOB and drone's quicksave, but the wall was there for me in DinkHD. Mind you I'm using my latest version of SOB which is 3.09 which I should really upload as 3.08 is the one here...
FWIW, I tested it only with 3.03 since that was what Drone had used.
You can test sprite load order by inserting debug statements on the scripts and checking in which order they appear on the log, but, since you might accidentally change the sprite order, I'd urge to just add a wait on the controlling script if you need to change stuff on the main procedure, or just set each sprite's initial state on it's own script.
Edit: Or just have one script that uses create_sprite to make the other sprites, like s3-catg, on SOB. that way you get reliable sprite references, have everything set on one place and you don't have to worry about ordering issues when editing the map.
FWIW, I tested it only with 3.03 since that was what Drone had used.
You can test sprite load order by inserting debug statements on the scripts and checking in which order they appear on the log, but, since you might accidentally change the sprite order, I'd urge to just add a wait on the controlling script if you need to change stuff on the main procedure, or just set each sprite's initial state on it's own script.
Edit: Or just have one script that uses create_sprite to make the other sprites, like s3-catg, on SOB. that way you get reliable sprite references, have everything set on one place and you don't have to worry about ordering issues when editing the map.
Yeah, I had the saves in V3.03 and knew that the issue could be replicated there each time. I didn't check if it's still present in newer versions