Subscreen crashes ZC in weird instances

I'll provide an example quest containing the problematic subscreen, since I have not been able to replicated it, and I'm unsure what even causes it: Download for the quest file

The specific steps taken to cause the crash:
1. Have an arrow item in your inventory but not any other equip-able items.
2. Press start to open the active subscreen.

I found this bug in 2.52 (?) (v2.50 Build 29 is listed in about), one of the more recent stable releases. I sent the quest file to Avataro for a second opinion and it crashes for him to in 2.53 beta 8.

Something is obvious wrong with the subscreen, but neither he nor I could seem to replicate it. Usually when something is a problem with the subscreen it just stops working though, rather than straight up causing ZC to crash.

It's crashing trying to write the name. subscr.cpp, line 3636:

Code:

---

                    if(Bitem->dummy_bool[0]==true)  //if we also have a bow

---

Bitem is null. A simple Bitem && seems to be sufficient.

Quote:

---

Originally Posted by Saffith

It's crashing trying to write the name. subscr.cpp, line 3636:

Code:

---

                    if(Bitem->dummy_bool[0]==true)  //if we also have a bow

---

Bitem is null. A simple Bitem && seems to be sufficient.

---

I put that in a pull request for 2.50.x for the present. Thank you @Saffith for the quick fix, and thank you @Lunaria for the report and the example files.

https://github.com/ArmageddonGames/Z...assic/pull/129

Needs to be applied to master too, but a lot of this is different, there. I will be doing a re-merge of my local and fork assets in a few days to synchronise.

I'm not sure what you mean by a "re-merge of local and fork assets" but the command to pull changes from the remote repository is simply

git pull

In any case I've applied Saffith's fix to both 2.50.x and master (the fix is identical).

Quote:

---

Originally Posted by DarkDragon

I'm not sure what you mean by a "re-merge of local and fork assets" but the command to pull changes from the remote repository is simply

git pull

In any case I've applied Saffith's fix to both 2.50.x and master (the fix is identical).

---

I know. :)
I had local files that were WIP that were not oin the repo, filesthat were only local, and files in the rep
o that were different and needed git-merge.

I fixed all of it, stashed the uncommitted files, backed up my local files, did a merge from ANG/master to my remote, and fixed all of the locals.

This happened because we were both doing different things with files such as zdefs, and I helted all of my commits until you finished, but the merging process was a pain. I still have changes that I need to reapply and push, but my priority is to commit the 2.53 changes to master, before I do anything else.

That is why I asked if someone would handle the commits to master while I bugfixed 2.53. I will be committing the latest stuff soon, to master, but I wanted to perfect the fixes in 2.53 first, as it is easier to deduce if bugs are stemming from specific factors in that (the most stable) branch.

Your changes to water need redaction. They introduced bugs that are worse than what was reported in the logs from Lut.

What water bugs? Where is the report thread?

I saw something on Pure about Link getting knocked into water by damage, and haven't looked into it yet, but this should be independent from any of the changes to Link walking between land and water across screens...

We tried to put a single thread at purezc for bug reports for the peeps that only go there, but it somehow began replicating itself and spreading past the quarantine zone. Kind of like Zombies. In fact it's exactly like Zombies. :P

I've fixed the one issue I found on Pure (Link pops out of water when hit by his own fire/boms due to some buggy logic in the collision code). I couldn't find any posts about problems with the fix to land/water transitions across mapscreens, but I'll take a look if you point them out to me.

Quote:

---

Originally Posted by DarkDragon

I've fixed the one issue I found on Pure (Link pops out of water when hit by his own fire/boms due to some buggy logic in the collision code). I couldn't find any posts about problems with the fix to land/water transitions across mapscreens, but I'll take a look if you point them out to me.

---

Good, good: I fixed the NES doors (diagonal movement) and pushed it to 2.50.x. I'll start integrating the changes to master, after I sleep.

I asked in the pull if I should make this a QR. Probably not, but the sensitivity could be in quest data in the future, or in FFScript::DoorTimer.

I've posted some comments on the pull request on GitHub.

A quest rule is not out of the question (if you add one, please make sure it's set up consistently across 2.50.x and master, including its position in the bit field!!) but I don't think it's absolutely required here, unless you can think of a reason the gameplay of an old quest might be affected.