Zelda Classic 2.53.0 ( Beta 10 )

[ZoriaRPG]

Why does it even exist? It adds 800KB of save data to any quest that includes it, it's not used or mentioned anywhere, and the name suggests it's garbage you forgot to delete.

Oh, you know, it was something that I forgot to delete. i thought it was the only array, but it was not, and I removed it in favour of the [4096] sized array, that I also renamed in the process. My fault. I put that in there at some past point when I was deciding on the array size. I'm not overly concerned with 840KB of RAM usage, though, given that the ZC footprint is hundreds of MBs. Despite this, a size of 4096 (16KB) is probably fine.

Eh, I guess. But that only happens if the inputs were invalid in the first place. I don't really like the idea of legitimizing script errors.

Oh, it's for cases such as when Sqrt() returns an error, or other stuff, such as invalid DMap or Map Ids, so that for loops that do things that are illegal can have a continue instruction to cover these cases. It isn't important, and I may rip it out if there are true concerns over it. It is not used by the header itself, yet, but I have considered having functions break or return on error, and this may become more relevant in the future, so I wanted to ]reserve it for future expansion.

Huh, indeed it is. It should be possible to escape it ( '\'' ), but that doesn't seem to work.

Precisely, and I do not see a reasonable way to fix this, short of adding a special case for three ' tokens. The TAB issue still stands, and the list provides a quick reference for what chars do each thing. ::

Before I move on, here is the latest sub-beta, so that you can review the changes to std.zh:
http://timelord.insomnia247.nl/zc/zc...ixwaterjig.zip

This ZIP includes all prior fixes, and all fixes in this post.

Please let me know if you see anything new. I fully revised the NPCA* constants, and one NPC Editor field puzzles me, notably, the Gleeok use of its misc4.

The editor has a default value of 48 in this field, and it is seemingly only used by esGleeok::esGleeok(), but in a way that is never utilised in the function body:

Here, the gleeok case references misc4:

Spoiler: show

case eeGLEEOK:
    {
        id &= 0xFFF;
        
        for(int i=0; i<zc_max(1,zc_min(254,guysbuf[id&0xFFF].misc1)); i++)
        {
            if(!guys.add(new esGleeok((fix)x,(fix)y,id+0x1000,c, e)))
            {
                al_trace("Gleeok head %d could not be created!\n",i+1);
                
                for(int j=0; j<i+1; j++)
                {
                    guys.del(guys.Count()-1);
                }
                
                return false;
            }
            
            c-=guysbuf[id].misc4;
            ret++;
        }
    }
    break;

...but here, the input Clk (note the casing of Clk) is never used:

Spoiler: show

esGleeok::esGleeok(fix X,fix Y,int Id,int Clk, sprite * prnt) : enemy(X,Y,Id,Clk), parent(prnt)
{
    xoffset=0;
    yoffset=(fix)((dmisc5*4+2));
//  dummy_bool[0]=false;
    timer=0;
    /*  fixing */
    hp=1000;
    step=1;
    item_set=0;
    //x=120; y=70;
    x = xoffset+parent->x;
    y = yoffset+parent->y;
    hxofs=4;
    hxsz=8;
    yofs=playing_field_offset;
    clk2=clk;                                                 // how long to wait before moving first time
    clk=0;
    mainguy=count_enemy=false;
    dir=rand();
    clk3=((dir&2)>>1)+2;                                      // left or right
    dir&=1;                                                   // up or down
    dmisc5=vbound(dmisc5,1,255);
    
    for(int i=0; i<dmisc5; i++)
    {
        nxoffset[i] = 0;
        nyoffset[i] = 0;
        nx[i] = ((((i*(int)x) + (dmisc5-i)*((int)parent->x))) /dmisc5);
        ny[i] = ((((i*(int)y) + (dmisc5-i)*((int)parent->y))) /dmisc5);
    }
    
    necktile=0;
    //TODO compatibility? -DD
    /*
    for(int i=0; i<4; i++)
    {
      nx[i]=124;
      ny[i]=i*6+48;
    }*/
    bgsfx=-1;
    //no need for deadsfx
}

Am I missing something, or is this field truly unused, and set to 48 for no good reason? I defined it in std.zh as NPCA_GLEEOK_CLK or something like that, with a line comment or two.

Mostly in the constants. Both, in some cases. I think this is everything:
130-187: There's an extra blank inserted. CHAR_QUOTE_LOW should be 130, and CHAR_0_SUPER should be 186. Everything in between is likewise off by one.

Fixed the offsets.

62: Generally said to be "greater than" rather than "more than," particularly in HTML, where it's encoded as >

Fixed.

160, 169, 196, 203, 207, 214, 228, 235, 239, 246, 252, 255: The mark is generally said to be a diaeresis rather than an umlaut. Doesn't matter much; they do look identical. But if they're going to stay as they are, "umlaut" is misspelled.

I fixed the missing 'u', however, umlaut and diaeresis have different linguistic applications. In German, these are almost exclusively umlauts, because they modify the sound of the vowel. Would you prefer both instances per character? That's what I did, for now, as it was trivial.

140, 156, 172: Angle quotes or guillemets, not mathematical symbols. » should be 187, but it's missing.
134: Ellipsis
135, 136: Dagger (the cross is U+271D)
141, 157, 198, 230: Ligature, not diphthong; also, 157 has OW instead of OE
174: Soft hyphen
181: Acute
209, 241: Enye
184, 247: Should have "MATH" variants to fit with predominantly American style

Fixed.

Mostly, probably, but they're based on Windows-1252 encoding. 7F-A0 are different in Unicode and ISO-8859-1, so those are less likely to work correctly, especially on Mac or Linux.

That is potentially true. The ANSI values are not platform-static. It would be far simpler if everything used Extended ASCII, which was a single standard. I can amend this with Linux definitions, and add a prefix of WIN_* to the uppr-128. I had a second set at one time, of pure ASCII chars, that I removed. Mapping this a second time won'na be fun, but I will do it if the need exists. I suppose someone should check if text files processed by ZQuest on Linux and OSX produce different values for these, and if they do, then I will of course rectify that.

Other things...

std.cfg:
typo: STD_EMULATE_EMGINE_COLLISION (it's unused, anyway)

I'll fix the typo, certainly. I wanted to get this, and a few other things into this version, but I ripped them out temporarily, because of user confusion. I may re0implemnt them, and disable them (new stuff) by default, as that seems a better option. I was not entirely certain that I had the collision emulation down pat, either. I think that I disabled STD_CENTERXY_USES_HITBOXES code, too, in the process; or that I removed the new functions that use it. I am trying not to add too much until std.zh v2.0, for 2.54 and above, and I end up with leftovers hanging about.

std_constants.zh:
Irrelevant constants: NPCSF_*, BITDX_*, WARPFX_*, WARP_*, ITM_REQUIRE_*, maybe CB_*

NPCSF_* : How is this irrelevant? Oh, because 2.50.x doesn't have npcdata? I see. Holdover artefact from developing 2.60. I'm not sure if I want to rip that out, as you can still read these in 2.50.x; right?

CB_* is less relevant now than it will be in December. I put that in there because I added arrays for Input, and I want to reserve the constants, but I do need to re-check the values.

The rest, I culled, and I will reinstall them in 2.54.

Comments around NPCM_SPAWNFLICKER are wrong. 0x10 does indeed represent the flickering spawn animation, and the other NPCM_ constants are correct already.

Ah, I see the confusion here. I should have removed the comments entirely. If you note, I have a line comment 'fixed' after that one, signalling that I fixed the rest, but I never deleted my other comment. I'm clearly senile.

Probably more. Lots of stuff to go through.

Aye. It's not fun, and I appreciate the assistance in cleaning this up. I also corrected the second instance of Acute I, which should have been Acute O.