Zelda Classic 2.53.0 ( Beta 10 )

OK, here is the list of some of the older quests that work and don't work in 2.53:

3rdEX - fails. Need an earlier version
New 1.02 - fails. Need an earlier version
New 1.84 - 1.02 version loads after a conversion. Same bug as 2003 though, the item doesn't show up in MD 1 making the game unplayable.
Demo 1.84 - loads, item doesn't show up in Level-A, making the White Sword unobtainable.
Unofficial 3rd Quest - Works, no issues. Let's Play: https://www.youtube.com/playlist?list=PLZg6iQHFIdmjWHlEZcWbGdjckeVQxsJRz
Revenge - Works, no issues. https://www.youtube.com/playlist?list=PLZg6iQHFIdmjThQkYZf4BT-zsM0HWI3vT
Revenge 2: Works, has issues. Already reported. No Let's Play
New Quest 2003 - loads, but fails in Mini-Dungeon 1 as an item does not properly show up, too much 1.02 structure still left as far as I know.
James Quest (original)- Works, no issues. Let's Play: https://www.youtube.com/playlist?list=PLZg6iQHFIdmg66OcBNBmbm8F17wf6Brmw

1.84 support seems to be pretty broken. I think anything made in 1.84 definitely needs to be retooled or exported out and rebuilt in 2.53 as of this point. 3rdEX doesn't even read one bit in any version since it's from one of the beta versions of ZQuest! I think New Quest got converted somewhere between 1.02 and 1.84, which is why I was able to read-only it in 1.84 and convert it.

If there's anything more you want to have me look at from 1.92 and below let me know.

-James

I (still) have a lot of issues with the additions to std.zh...

• std_*_2.54.zh shouldn't be included
• std_constants_shortcuts.zh shouldn't exist if it's going to be empty
• std_vars.zh has [font=monospace]int GlobalBugger[214747][/font]
• Out of date comments ("//!...and will be fixed in 2.50.3."😉
• Incorrect comments ("//dir+DIR_IGNORESHIELD: Prevents blocking by enemy shields."😉
• NPCA*_ constants appear to be appropriate only for walking enemies
• Constants meant for features that don't exist here (WARPFX_*)
• Constants with no clear purpose (ERR_RETURN)
• Constants that are simply wrong (DEG_DIR_* and RAD_DIR* are flipped vertically)
• Similarly, all of the new direction to angle functions are wrong
• Typos (SFW_SENDDIRECT should be SFW_SENSDIRECT)
• Aside from dubious usefulness, the CHAR_ constants in particular have several issues:
  [list]
• ASCII values 1-31 are never meaningful in ZC, so why include them?
• The characters represented by values 127 and up vary depending on the font, so the constants are misleading
• Incorrect, or at least non-standard, terms
• Lots of typos and spelling errors

I can get a more thorough list together, but I don't know what exactly the plan is here.

[MENTION=42228]ZoriaRPG[/MENTION] since you are currently most involved with the ZScript changes in 2.50.x, could you please address Saffith's reported issues?

DarkDragon wrote:[MENTION=42228]ZoriaRPG[/MENTION] since you are currently most involved with the ZScript changes in 2.50.x, could you please address Saffith's reported issues?

I just saw this message from him:

I am again unable to access AGN
Same issue as before:
Your connection to this server has been blocked in this server's firewall.

IIRC wasn't this a temporary issue that fixed itself last time? I'm not sure, but here it is.

[edit] Just sticking this here since I'm not sure if it got fixed yet or not (I'm using a 2.50.2-ish ZQ build for this quest right now).

Side Warp-> set up to 'A'; then goto Screen data-> timed warp ticks = 90; then check the random warp box and ZQuest crashes.

I am temporarily hopping through a different VPN, but aye, that problem is back (AGN firewall). I will check in periodically for a response, but until the firewall issue is fixed, I will only likely to check in once daily, as I had to interrupt my entire network simply to log in. "War Lord and "Chris Miller , help. As I understand, this is caused by the host scanning post content, and reading code tagged text (or inline code), as a potential hijacking attempt; then RSS blacklisting the IP of the user.

Not a grand idea for a system that uses a substantial quantity of inline code in posts, so the host needs to address this properly

Here is the reply that I tried to post, immediately before the host blacklisted me.

Saffith wrote:I (still) have a lot of issues with the additions to std.zh...

• std_*_2.54.zh shouldn't be included
• std_constants_shortcuts.zh shouldn't exist if it's going to be empty
  

Removed, and removed. The 2.54 file was in there in error, and std_constants_shortcuts is dead anyway.

[list]

std_vars.zh has [font=monospace]int GlobalBugger[214747][/font]

Is your objection the identifier, or that there is a standard array, or the array size?

• Out of date comments ("//!...and will be fixed in 2.50.3."😉

I'll do a comment cleanup towards the end of things. I have not edited the file to look for these, since before the initial 2.53.0 betas.

• Incorrect comments ("//dir+DIR_IGNORESHIELD: Prevents blocking by enemy shields."😉

Removed the constant.

• NPCA*_ constants appear to be appropriate only for walking enemies

I added the full set, and reworded the identifiers. I'll need to make a decision or two on organising them.

• Constants meant for features that don't exist here (WARPFX_*)

Trimmed

• Constants with no clear purpose (ERR_RETURN)

 if (!( function() == ERR_RETURN ) ) 

...for -1 returns.

• Constants that are simply wrong (DEG_DIR_* and RAD_DIR* are flipped vertically)
• Similarly, all of the new direction to angle functions are wrong

Do you know the correct values, or which way I flipped them, off hand? Do I have them inverted, rotated? I do not recall immediately, so I'll check.

Fixed. Thank you both. [MENTION=38582]Saffith[/MENTION] and [MENTION=42714]Gleeok[/MENTION].

[*]Typos (SFW_SENDDIRECT should be SFW_SENSDIRECT)

Fixed that one. This is why it is helpful to have additional eyes reading it.

• Aside from dubious usefulness, the CHAR_ constants in particular have several issues:
  [list]
• ASCII values 1-31 are never meaningful in ZC, so why include them?
• The characters represented by values 127 and up vary depending on the font, so the constants are misleading
• Incorrect, or at least non-standard, terms
• Lots of typos and spelling errors

The lower characters are meaningful in some scripted string applications. I have used things such as CHAR_BELL (when parsing a string, finding this char plays a sound effect), and CHAR_EOT. Likewise, I use CHAR_TAB frequently, as you cannot type ' tab ' as a singlechar reliably (e.g., forums eat it), and CHAR_QUOTE is flat-out impossile, as the parser does not comprehend ''' as SINGLECHAR. The old ASCII chars for transmission are occasionally useful in more complex string systems, where you are creating intra-script communication using strings. As am example, I can set up a system that an object is ready to receive data using the transmission codes. I can also wrap control text using them, and actual text meant for display, with STX and ETX.

Granted, this is of limited usefulness, to the average user, but the constants take up no space, and skipping them does not seem to have a benefit.

I have found that extended ASCII chars can be used, for allegro.log printing, and I believe that if a font is set up to support the extended chars, that they might display. None of our fonts use them, at present, but as I add support for extended chars, they will all use the same values (standard high ANSI).

You can do traces with the extended chars. They are also usable in tile fonts, using Tango. I'm also planning to add fonts, including the base allegro font, and fonts with upper-ASCII support, so that non-English users can utilise these. I do not know if I will address the old fonts in this manner, but I may revisit them later.

Please specify on 'incorrect or nonstandard terms', and are the typos in the comments, or in the constants?

The changes will be in Beta 9.

Did you send the error you're getting to War Lord? He keeps telling the host to turn off their filter but for some reason it never seems to fully take.

Is your objection the identifier, or that there is a standard array, or the array size?

...for -1 returns.

and CHAR_QUOTE is flat-out impossile, as the parser does not comprehend ''' as SINGLECHAR.

Please specify on 'incorrect or nonstandard terms', and are the typos in the comments, or in the constants?

I have found that extended ASCII chars can be used, for allegro.log printing

Other things...

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

std_constants.zh:
Irrelevant constants: NPCSF_*, BITDX_*, WARPFX_*, WARP_*, ITM_REQUIRE_*, maybe CB_*
Comments around NPCM_SPAWNFLICKER are wrong. 0x10 does indeed represent the flickering spawn animation, and the other NPCM_ constants are correct already.

Probably more. Lots of stuff to go through.

Saffith wrote: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. ::shrug::

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_dev/2.53_Win_Beta_8--fixdoors--fixwaterjig.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 [FONT=Courier New]esGleeok::esGleeok()[/FONT], but in a way that is never utilised in the function body:

Here, the gleeok case references misc4:

[spoiler]

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 [FONT=Courier New]Clk [/FONT](note the casing of [FONT=Courier New]Clk[/FONT]) is never used:

[spoiler]

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 = 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
}

I'll fix the typo, certainly. I wanted to get this, and a few other things into this version, but I [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.

Thanks guys for working together on sorting this stuff out. I haven't been keeping up at all with the changes to these files.

ZoriaRPG, please don't forget to send patches for master as well as 2.50.x (also for the door fix you submitted a few days ago). Otherwise the next version of ZC will have delightful regression bugs...

DarkDragon wrote:Thanks guys for working together on sorting this stuff out. I haven't been keeping up at all with the changes to these files.

ZoriaRPG, please don't forget to send patches for master as well as 2.50.x (also for the door fix you submitted a few days ago). Otherwise the next version of ZC will have delightful regression bugs...

I haven't forgotten. I just have not had the time. This was a bad week, with servers down, and to put the cherry on top, I had to have minor surgery. I will forward-port the revisions.

Please, please, fix the AGN connection issue though. I can send you a PM with the IP address that needs to be unblocked, if needed. You have not been on Skype lately, and have not seen (or at least, responded to), my messages, there.

Needing to rest equipment across the board, is very time consuming. I would otherwise be checking AGN 10+ times per day.

It's unfortunately not something I can fix. My advice remains to send War Lord the full text of the error message you are getting, so that he can raise the issue with his host.

Please let me know if you see anything new.

Am I missing something, or is this field truly unused, and set to 48 for no good reason?

Would you prefer both instances per character? That's what I did, for now, as it was trivial.

It would be far simpler if everything used Extended ASCII, which was a single standard.

Saffith wrote:One thing - some of the constants for blank characters have mismatched names and values. CHAR_BLANK142, CHAR_BLANK144, CHAR_BLANK145, and CHAR_BLANK158 should each be named one less.

Fixed. I forgot to change the identifiers, when I offset their values.

It is used. It's passed to the base class constructor to initialize clk, which in turn is used to initialize clk2. What it ultimately controls is how long it takes for each head past the first to start moving. Why that's something you'd want to change, I have no idea.

Hmm... If I was going to choose a gleeok value to expose, it would be the shot timer (for 'breath' weapons, this would be useful), not the head movement timer. How utterly random. I'll make a note of it in the next update. I'm not even sure how to name that constant.

[FONT=Courier New]NPCA_GLEEOK_HEAD_CLOCK[/FONT] ? I hate identifiers that can;t explain enough about what they represent, and require a paragraph of comments to clarify what they do. :/

That works, sure.

The thing is, it's not. "Extended ASCII" refers to any standard that fills in 128-255, but ANSI never extended ASCII beyond 7 bits. A lot of confusion seems to stem from the fact that Windows called its encodings "ANSI code pages." That was because they were supersets of ASCII, but a lot of people took it to mean that the encodings themselves were ANSI standards.

I was referencing IBM's Code Page 437, which is usually regarded (once upon a time) as 'upper-ASCII' (not upper-ANSI, although these days, both are seemingly tossed about interchangeably), and I was bleating that it would have been nice if one of these was standardised. There were other things around at the time on every platform, such as Apple's MouseText, and most home PCs had upper chars that were graphical in nature. The MSX and the C64 both immediately spring to mind, in this regard.

I should prefix the present set with CP1252_* though, instead of CHAR_*, as that would [help to] prevent platform-based confusion.

Here is a re-up of the ZIP, with the amended files:

http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_8--fixdoors--fixwaterjig.zip

I would also like an opinion on something...

Which do you prefer of these two functions:

//Functions to converty angular behaviour to directional, based on the angle.
//Call when setting bool Angular for an object, as Angular = DoAngular(ptr)
//This ensures that the lack of decimal precision in conversion to Allegro radians
//does not prevent setting certain angles; causing 'drift'.
bool Angular(npc n, int deg){
	if ( deg % 45 != 0 ) { n->Angle = deg; return true; }
	else {
		//u,d,l,r,lu,ru,ld,rd
		int dgs[8]={ 270, 90, 180, 0, 225, 315, 135, 45 };
		for ( int q = 0; q < 8; q++ ) {
			if ( deg == gds[q] ){
				n->Dir = q;
				return false;
			}
		}
	}
}

...OR...

//Variation on Angular() that has a void type. Use when declaring a pointer, to st the angle and direction.
void SetAngular(npc n, int deg){
	if ( deg % 45 != 0 ) { n->Angle = deg; n->Angular = true; }
	else {
		//u,d,l,r,lu,ru,ld,rd
		int dgs[8]={ 270, 90, 180, 0, 225, 315, 135, 45 };
		for ( int q = 0; q < 8; q++ ) {
			if ( deg == gds[q] ){
				n->Dir = q;
				n->Angular = false;
			}
		}
	}
}

These are part of the std.zh 2/0 spec, and I'm not sure which users would prefer.

I prefer the boolean return to bool Angular, as you can do this (in 2.60):

if ( n->Angular = Angular(n, degrees) ) { //Note, this is not quality, it is *assign*; assign in a statement is now legal
   ///Adjust attached npc segments for angular movement;
}
else { adjust attach npc segments for directional movement; }

This to me, is better than separately setting, then checking it.

I have both in there at present. If you want to see the WIP files, thy are here: std.zh v2.0--alpha, for ZC 2.60

P.S. [MENTION=38500]War Lord[/MENTION], or whoever is responsible: I can again access the forum without workarounds. Thank you.

ZoriaRPG wrote:Which do you prefer of these two functions:.

Neither. :P

Besides being in desperate need of optimizing, I don't see the clear purpose of the functions..? But I'm also tired and on my way to bed, so there's that. :spin:

Gleeok wrote:Neither. :P

Besides being in desperate need of optimizing, I don't see the clear purpose of the functions..? But I'm also tired and on my way to bed, so there's that. :spin:

// This ensures that the lack of decimal precision in conversion to Allegro radians
// does not prevent setting certain angles; causing 'drift'.

I hear my share of complaints about this.

Setting a moving object to an increment of 45 degrees, other than 0, sets it to a radian value that is only an approximate for that angle. e.g., Setting an angular object to move straight up and down. It may be off by a small amount, and potentially drift; compared to setting Angular false and DIR_UP/DIR_DOWN. That is what these functions automate. It's the only viable way to fix the lack of decimal precision, as it allows a moving object to shift from using Angular to Directional movement, only when its angle (which may be a changing value, and should be passed in degrees), is one of the 8-way directions.

Obviously, this is useful only to cases where that precision is needed, or beneficial, but it gives an easier way to handle it than making if/else statements in a script.

I could turn the for loop into a switch block, but I do not think that would be any more optimised at an ASM level, although it would use fewer registers. I'll probably do that, or make it an if chain. I also need to add cases for 360 and amounts over 359 in general, and less than 0 (embedded wrapping).

x, y movement components of eweapons and npcs in ZC needs to fixed from within I think, rather than script hacks that mask errors for special cases. Of course I'm assuming there is an actual underlying bug here. As you know I have a few npc bugs on the top of my todo for 2.5x. If you can get a simple use case I'd be happy to look into it while I'm digging around in the debugger.

I think those functions are better suited in std_extra.zh; I'm open to a second opinion though.

Put it in stdextra.zh

I bumped the OP to Beta 9, and I updated all of the links, and the changelog, and other information, there. All of the fixes discussed in this topic should be in the package now.

[MENTION=38634]Chris Miller[/MENTION] : Could you adjust the topic title, please? I think that this is a forum bug, but editing the title for the OP no longer changes the title displayed anywhere on the forum, unless a Mod+ does it. I simply need the '7' to become a '9'.

21st Sept, 2017 @ 03:30GMT

Bugfix: 2.53_Win_Beta_9--fixdrinkguys.zip

I updated the link in the top post of the thread. Anyone still testing the original Beta 9 release can toss it in the scrap heap, unless you want a few giggles...

Few suggestions.
Include all the documentation for ghost.zh and tango.zh.
Also, add ffcscript.zh

Tamamo wrote:Few suggestions.
Include all the documentation for ghost.zh and tango.zh.
Also, add ffcscript.zh

What am I missing? The documentation should all be in ./Docs/
ghostZHChangelog.txt
tangoZHChangelog.txt
tangoUsage.txt
tangoFAQ.txt
glost.txt
stdWeaponsReadMe.txt

...and ffscript.zh is in the package. ???

It includes:

ffscript.zh
ghost.zh
ghost_legacy.zh
laser.zh
Music.zh
particles.zh
stdCombos.zh (possibly dubious, given that most of what this does will end up in std.zh anyway
stdExtra.zh
stdWeapons.zh
styles.zh (used by Tango)
tango.zh
tangoQuickStart.zh
ZVersion.zh

If you can think of something else that should be in there, please let me know.

i didn't realize you moved them to the docs folder
never mind.

Tamamo wrote:i didn't realize you moved them to the docs folder
never mind.

Not a problem. I'm just trying to reduce clutter in the main path. I may move the headers to /include or something, in the end, but not just yet.

I updated the API specification documentation to v1.2, as I had forgotten to define the controller mapping changes in the previous revision. The update is linked int he top post, but you may also grab it here:

Zelda Classic and ZQuest 2.53 API Specification, v1.2 (PDF).

Also, [MENTION=56506]Tamamo[/MENTION], [MENTION=38582]Saffith[/MENTION], and others: Are there any other headers that you would like to see included by default?

I need to update ghost.zh and tango.zh for Beta 10 or RC1, whichever comes first.

[font=Georgia]Another update addendum to Beta 9:

2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap.zip

This should hopefully fix the issue with dungeon maps displaying improperly through scrolling warps, without creating any new bugs. [/font]

• [font=Georgia]I would appreciate if some of you could help test this, by checking any quests that use scrolling warps and seeing if there are any new issues.[/font]

You forgot autoGhostReadme.txt. It's the one that details how to set up ghost.zh. Also, what if Saffith updates any of his headers? You'll have to keep the included files up to date. (ghost.zh for example was just updated sep. 11)

Also Gleeok, drunk enemies? 0_o

[MENTION=42228]ZoriaRPG[/MENTION]
ffcscript,ghost, and tango are all used like butter now a days. Do to ease of use.

[font=georgia]Yet another update addendum to Beta 9:

2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap--extrasanitycombosm.zip

This refactors some sanity checks, and adds error messages for: [/font]

• [font=courier new]Game->GetComboSolid[/font]
• [font=courier new]Game->GetComboCSet[/font]
• [font=courier new]Game->GetComboData[/font]
• [font=courier new]Game->GetComboFlag[/font]
• [font=courier new]Game->GetComboInherentFlag[/font]
• [font=courier new]Game->GetComboType[/font]
• [font=courier new]Game->SetComboCSet[/font]
• [font=courier new]Game->SetComboData[/font]
• [font=courier new]Game->SetComboFlag[/font]
• [font=courier new]Game->SetComboInherentFlag[/font]
• [font=courier new]Game->SetComboType[/font]

• [font=georgia, serif]I would appreciate if some of you could help test this, by testing any scripts that use these instructions, and reporting if anything has broken. [/font]

[font=georgia]Right. This will (I hope), be the last addendum to Beta 9. [/font]

[font=georgia]I fixed the Import ZScript file lister dialogue to list .zh, .zs, .zlib, and other common extensions, rather than only listing.z files, when using the Import button to choose a file.[/font]


[font=georgia]2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap--extrasanitycombosm--importscriptsimprovement.zip

Updated again at 16:34GMT: This was a minor fix to std_functions.zh to remove a duplicate constant. [/font]