Zelda Classic 2.53.0 ( Beta 10 )

[ZoriaRPG]

Here is Zelda Classic 2.53.0 Beta 10 for Windows (http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_10--fixdrawint--fixgamecombo.zip)

Updated 2nd October, 2017 at 16:22GMT with --fixdrawint --fixgamecombo

Here is ZC 2.53, Beta 10, which fixes the following, over the last major beta build:

Doors on dungeon maps when using diagonal movement, nor operate more smoothly.

This includes some slight adjustments to ensure that if the left and right doors have a solid obstacle in front of them, that Link cannot open them around the obstacle.




Fixes the issues with Link in water, flying through land tiles when he is hit by his own weapons.


Adds additional filetyles to the Import Script dialogue (.zh, .zs, .zlib, .zscript), in addition to the extant .z extension.

This will make it easier to use the import dialogue for header files, and other filetypes.
Note: We purposely avoided showing files with an extension of .txt, as to avoid making the use of .txt for a ZScript filetype some kind of absurd, and lazy standard.




The use of .zs, .zlib, and .zscript, are to aid in the filetype conflict for .z, which is used for ZLIB Archive files on *nix systems.


Fixes an issue where scrolling warps with different DMap IDs for source->dest, do not show a map that Link does not have; and that ZC does not show an incorrect map, on the passive subscreen.


Fixes compatibility issues with wizzrobe and other floating/flying enemies spawning on solid combos (when they should not), or flying through walls.


It also adds a warning dialogue when you open the ZConsole via the menus:

http://timelord.insomnia247.nl/zc/zc_dev/DebugConsoleWarn.png



See the Changelog below for more information. As before, the Build ID for this release is '31', to distinguish between 2.50.3RC1 (Build ID '30') and earlier ZC releases.

This thread replaces the previous Beta thread for 2.53.0 (http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_8.zip).

We would appreciate bug reports on any of the following:

Playing quests made in 1.92, 2.10, 2.50.x and reporting any compatibility bugs.
Verification that scripts made in 2.50.0, 2.50.1, 2.50.2, and 2.50.3RC1 still work.
Testing that scripts compiled in 2.53.0 work properly in 2.53.0.
Tests that scripted quests compiled and saved in 2.53.0 work proper;y on 2.50.2 (and/or 2.50.3RC1).
Bug reports on any changes, or new features.
Bug reports on joystick configuration.

Please note: The std.zh files in this package may not represent what will be included in the final release. It is likely that the std.zh changes will be pushed forward to 2.54 or later, and not included; but they will be available as a separate download. The latest versions of all common ZScript headers will be included in the final release.

This release is built on the Allegro library, version 4.4.3, with some special fixes applies, and it includes new Allegro library files.

Zelda Classic and ZQuest v.2.53.0 API Specification (PDF, Rev. 1.2) (http://timelord.insomnia247.nl/zc/zc_dev/Zelda_Classic_and_ZQuest_2.53_API_Specification.pd f)


ZLaunch Repository on GitHub (https://github.com/ZoriaRPG/ZCLaunch)

Zelda Classic Changelog for v.2.53.0 Beta 10
-=SPOILER=-

ZLaunch Changes v2.6.1

ROMview Changelog Version 2.6.1

Added Win32 platform guards to ZCL video driver selection, and bumped version to 2.6.1. ( ZoriaRPG, 29th August, 2017 )

Added the ability to set the allegro video mode on Windows (fullscreen, and windowed drivers).
Added 'Drivers' tab. ( ZoriaRPG, 28th August, 2017 )
Added ROMView launching button to main panel. ( ZoriaRPG, 27th August, 2017 )



Thank you for testing, and for your feedback!

[Nightmare]

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

[Saffith]

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 int GlobalBugger[214747]
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:
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.

[DarkDragon]

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

[Gleeok]

ZoriaRPG 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.

[ZoriaRPG]

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.


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 int GlobalBugger[214747]



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. Saffith and Gleeok.



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.

[DarkDragon]

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.

[Saffith]

Is your objection the identifier, or that there is a standard array, or the array size?
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.


...for -1 returns.
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.


and CHAR_QUOTE is flat-out impossile, as the parser does not comprehend ''' as SINGLECHAR.
Huh, indeed it is. It should be possible to escape it ( '\'' ), but that doesn't seem to work.


Please specify on 'incorrect or nonstandard terms', and are the typos in the comments, or in the constants?
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.
62: Generally said to be "greater than" rather than "more than," particularly in HTML, where it's encoded as >
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.
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


I have found that extended ASCII chars can be used, for allegro.log printing
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.


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.

[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. ::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 esGleeok::esGleeok(), but in a way that is never utilised in the function body:

Here, the gleeok case references misc4:

-=SPOILER=-

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

-=SPOILER=-

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.

[DarkDragon]

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...

[ZoriaRPG]

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.

[DarkDragon]

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.

[Saffith]

Please let me know if you see anything new.
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.


Am I missing something, or is this field truly unused, and set to 48 for no good reason?
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.


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


It would be far simpler if everything used Extended ASCII, which was a single standard.
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.

[ZoriaRPG]

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.

NPCA_GLEEOK_HEAD_CLOCK ? 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 (https://en.wikipedia.org/wiki/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 (http://timelord.insomnia247.nl/zc/zc_dev/__std_zh_v2.0.zip)


P.S. War Lord, or whoever is responsible: I can again access the forum without workarounds. Thank you.

[Gleeok]

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:

[ZoriaRPG]

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).

[Gleeok]

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.

[Avataro]

Put it in stdextra.zh

[ZoriaRPG]

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.


Chris Miller : 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'.

[ZoriaRPG]

21st Sept, 2017 @ 03:30GMT

Bugfix: 2.53_Win_Beta_9--fixdrinkguys.zip (http://timelord.insomnia247.nl/zc/zc_dev/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...

[Tamamo]

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

[ZoriaRPG]

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.

[Tamamo]

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

[ZoriaRPG]

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.

[ZoriaRPG]

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) (http://timelord.insomnia247.nl/zc/zc_dev/Zelda_Classic_and_ZQuest_2.53_API_Specification.pd f).

Also, Tamamo, Saffith, 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.

[ZoriaRPG]

Another update addendum to Beta 9:

2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap.zip (http://timelord.insomnia247.nl/zc/zc_dev/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.


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.

I am not thrilled with how I had to do this patch, but it will need to be this way until 2.60 territory, or whenever I rewrite warping. (I have tried to refactor warping three times !! to date.)

I updated the top post to match this build.

[Avataro]

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

[Tamamo]

ZoriaRPG
ffcscript,ghost, and tango are all used like butter now a days. Do to ease of use.

[ZoriaRPG]

Yet another update addendum to Beta 9:

2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap--extrasanitycombosm.zip (http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap--extrasanitycombosm.zip)

This refactors some sanity checks, and adds error messages for:


Game->GetComboSolid
Game->GetComboCSet
Game->GetComboData
Game->GetComboFlag
Game->GetComboInherentFlag
Game->GetComboType
Game->SetComboCSet
Game->SetComboData
Game->SetComboFlag
Game->SetComboInherentFlag
Game->SetComboType



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.

Invalid inputs for the map, screen, or combo position will now report the specific error to allegro.log, and the function will exit. Getters will return -1 to the user on error, as well as tracing an error message to the log.

[ZoriaRPG]

Right. This will (I hope), be the last addendum to Beta 9.

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.


2.53_Win_Beta_9--fixdrunkguys--fixscrollingmap--extrasanitycombosm--importscriptsimprovement.zip (http://timelord.insomnia247.nl/zc/zc_dev/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.

[BFeely]

Didn't I hear somewhere that Allegro 4.4 uses DirectX8?
However, I installed DXGL (version 0.5.12) on this build and apparently it in fact ZC uses DirectX7 for the graphics, as it took the ddraw.dll, apparent when I set it to stretch mode.

[ZoriaRPG]

Didn't I hear somewhere that Allegro 4.4 uses DirectX8?
However, I installed DXGL (version 0.5.12) on this build and apparently it in fact ZC uses DirectX7 for the graphics, as it took the ddraw.dll, apparent when I set it to stretch mode.

DirectDraw is indeed used, and it is in DX8.

Why are you using DXGL?

[BFeely]

DirectDraw is indeed used, and it is in DX8.

Why are you using DXGL?

I was using it for testing purposes. I guess Allegro 4.4 does use other DirectX APIs in version 8 though (DirectDraw was discontinued after version 7)?

By the way, by turning on Aspect corrected stretch and setting aspect to 14:9 (or crop to aspect on 4:3 screens) it fixes the game to a perfect 4:3 aspect.

[ZoriaRPG]

I was using it for testing purposes. I guess Allegro 4.4 does use other DirectX APIs in version 8 though (DirectDraw was discontinued after version 7)?

By the way, by turning on Aspect corrected stretch and setting aspect to 14:9 (or crop to aspect on 4:3 screens) it fixes the game to a perfect 4:3 aspect.



DirectDraw was included in the DirectX SDK, Feb 2010. It was discontinued in the DirectX SDK, June 2010. Both of these were > DirectX 7. Whether ddraw changed at all during the time between 7 and 8, is another matter. (It would seem unlikely, at best, that Microsoft changed anything about it.)

If you want to make a little tutorial for the userbase on DXGL, I would not object. It is not our preferred (internal) solution to all of these issues--although I am not opposed to it--but it is certainly something that would benefit a great number of users.


--------------

And now, for something you'll really like... - Rocket J. Squirrel

Beta 10, Updated (http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_10--fixdrawint--fixgamecombo.zip) 2nd October, 2017 at 16:22GMT with --fixdrawint --fixgamecombo to include a reversion of the entire set of Game->Get/SetCombo* functions. This should un-break quests that rely on them.

The patch also fixes the output of DrawInteger() with zero decimal places; and both the array size, and the permitted values of Game->LKeys[] and Game->LITems[]. The new array sizes are [512] and the assigned values have a valid range of 0 to 255.

[Saffith]

Proposed additions to std.zh:


bool HasKey(int level)
bool HasKey()
* Returns true if Link has any keys, either global or level-specific.
* If level is not specified, the current level is used.

int NumKeys(int level)
int NumKeys()
* Returns the total number of keys, both level-specific and global, Link has
* in the given level.
* If level is not specified, the current level is used.

bool ConsumeKey(int level)
bool ConsumeKey()
* Removes a key if Link has any, preferring level-specific keys. Returns true
* if a key was consumed, false if Link didn't have any keys.
* If level is not specified, the current level is used.


bool HasKey(int level)
{
return Game->LKeys[level]>0 || Game->Counter[CR_KEYS]>0;
}

bool HasKey()
{
return HasKey(Game->GetCurLevel());
}

int NumKeys(int level)
{
return Game->LKeys[level]+Game->Counter[CR_KEYS];
}

int NumKeys()
{
return NumKeys(Game->GetCurLevel());
}

bool ConsumeKey(int level)
{
if(Game->LKeys[level]>0)
{
Game->LKeys[level]--;
return true;
}
else if(Game->Counter[CR_KEYS]>0)
{
Game->Counter[CR_KEYS]--;
return true;
}
else
return false;
}

bool ConsumeKey()
{
return ConsumeKey(Game->GetCurLevel());
}

[ZoriaRPG]

That all looks good. My only question:

Why ConsumeKey() and not UseKey()?

( Did I have no levelkey functions in std.zh v2.0? I'll need to check. )

Anyway, I'll add these to Beta 12.

[Saffith]

Why ConsumeKey() and not UseKey()?
Just seemed a bit more logical to me; I tend to think "using" a key means doing something in addition to consuming one. Doesn't matter much, though.

[ZoriaRPG]

Just seemed a bit more logical to me; I tend to think "using" a key means doing something in addition to consuming one. Doesn't matter much, though.

I suppose it's fine. I don;t think most usersd would latch onto ConsimeKey as an identifier, simply because it is nonstandard language for hos the typical user would use the function. I remembered where I saw UseKey(): I thought it was from my work on std.zh, or on my lockblock scripts, but it was from link.cpp. :p

I put the functions in std.zh as-is for now. I had previously added NumLevelKeys(), but that's unimportant, as that is in the 2.0 version of the header.

I need to update this thread to beta 11, and the update will be in beta 12.

One thing that I would like to do, before the release of 2.53, is to go through and optimise the std.zh functions. In particular, in any case where we can use ++n instead of n++, I want to change the syntax; purely for performance reasons. (++n is 33% faster.)

If you have any ointerest in assisting with std.zh stuff, that would be fantastic. I'm going to clean up std.zh v2 in a few weeks, and we can all start debating that.