2.53 Fixes -> Master : Need a Period of Suspended Pushes

The next two days are a major holiday for me, so I will wait until it ends before I delve into this, but I want to get all of the minor fixes that we put into 2.53, into master.

In order to do this, i would like to see a suspension period of a few days for any other changes, so that I do not need to worry about the builds breaking, as the changes are scattered about. Most of them are to link.cpp, ffscroipt, guys.cpp, qst.cpp, zquest.cpp, and similar. I also intend to get the fonts in, and to get master up to the spec for 2.54 and above.

I am also either going to need someone who can stand by and apply the pulls, or to flipping have merge access, so that i can do this quickly, and efficiently. There is quite a lot of small stuff to go over and patch, and I do not want it to drag on any longer than needed. I do not want master to get any more out of sync with 2.53 fixes and features.

Can we all agree on this one?

Sounds fine to me. Besides minor things I'm not working on master right now. I can help you with that if you let me know the day.

Just give a timeframe for @DarkDragon and @Grayswandir so they know exactly when.

Sure thing, I'll hold off on pushing for a while.

Sure. I'm traveling this week and won't be able to touch the code anyway.

By the way you should look into git cherry-pick. In some (but not all) cases it can apply patches from one branch painlessly to another one.

I gave you write access so you don't have to deal with all this patch nonsense.

Quote:

---

Originally Posted by Gleeok

I gave you write access so you don't have to deal with all this patch nonsense.

---

Thank you kindly. That will help immensely, as I will be able to make and merge the patches without waiting on someone else, repeatedly. I may be able to get them done in a day or two, instead of a week now. :D

Quote:

---

Originally Posted by DarkDragon

Sure. I'm traveling this week and won't be able to touch the code anyway.

By the way you should look into git cherry-pick. In some (but not all) cases it can apply patches from one branch painlessly to another one.

---

Everything is done, and merged in master now.

Please note that it is not the cause of issue 144..

I sort of suspect your itemdata, npcdata, and weapon abstraction there, as it is an issue loading some components of the save data, that appear to not exist. It only affects Release builds, so tracking it down is not going to be fun, and you may want to look at some binaries from me to find any issues that are MSVC--8 related.

Ok, I'll take a look.

Is there a specific quest that's crashing? Or the default/empty quest? I just tried and couldn't reproduce the crash.

Quote:

---

Originally Posted by DarkDragon

Is there a specific quest that's crashing? Or the default/empty quest? I just tried and couldn't reproduce the crash.

---

Trying to use a timed save from 2.50.x, produces a header error:

Code:

---


Decrypting...okay.
Opening...okay.
Invalid header string:  '-(N=7A+        
L>N*~ANLon' (was expecting 'AG Zelda Classic Quest File
 ' or 'AG ZC Enhanced Quest File
  ')
Reading Header...error.

---

After that, I tried to make a quest using ZQuest (master) in debug mode, and use a timed save from that. It also produced the same header error.


Thus, I was only able to try the default quest.

Here is my binary output from when I last built the master repo:

http://timelord.insomnia247.nl/zc/zc...5SEPT_2017.zip

Please tell me if that crashes for you, as it certainly does, for me. This was built using CMake->MSVC9 with the following flags:
Unity: No
PCH: No

For MSVC, incremental linking is off.

I still need to test if using the allegro debug libs to compile release cures this, to rule out an issue with alleg44.dll, or the other lib files; there is something odd going on with the libs in general too, as we have a slew of new bugs that occur only after Beta 2, and Beta 3+ are built using your last build of the allegro libs.

Anyway, as this only affects master, I find it very unlike;y that the libs are a culprit, but I may as well verify that.

So hold on a second: the crash only occurs when loading timed saves (not when loading a standard .qst file?)

If so I think it's the Allegro encryption password handling change rearing its ugly head again. I'll investigate.

Quote:

---

Originally Posted by DarkDragon

So hold on a second: the crash only occurs when loading timed saves (not when loading a standard .qst file?)

If so I think it's the Allegro encryption password handling change rearing its ugly head again. I'll investigate.

---

No, no.

The default quest in ZQuest crashes., when you load it (clean copy).

ZQuest cannot read time save file headers in addition to the crash, and that does in fact sound like a packfile_password("") issue. Did i forget to correct the allegro-fix patch that ntfwc applied to master?

Ok. So if it's crashing after loading doors, the problem must occur while loading dmaps (the next section after doors in the default quest). Unfortunately when I compile the code I do not get a crash in either debug or release, so I will have to put in some al_traces to narrow down where the error is happening for you.