Jump to content

Photo

Zelda Classic 2.53.0 Beta Release 2 (Official)


  • This topic is locked This topic is locked
118 replies to this topic

#106 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 16 August 2017 - 08:32 AM

This may be due to the fact that the script uses the Collision function from stdfunctions, which has been known to be less than 100 percent accurate.

Yeah, I didn't suspect that it was your script causing the difference, in case you thought that's what I was implying. It was simply the only script I knew of that called that function.

On the difference on fade-in, did you have the flag "Run Script at Screen Init" checked? That should make it where that everything is changed the instant you enter the room no matter the method.

The flag was checked, yes. Before I duplicated the room into two separate examples for the demo quest, I only had a single room in which I was trying the tile warp variations. I went through each one without ever changing the FFC, so the difference is definitely inherent to the fade-in code.

That being said, do these behaviors occur both in the original script as compiled in 2.50.2 and the newer version of ZC or only one of them?

The thing's outright nonfunctional when compiled in 2.53.0 B2, which was the secondary purpose of my report beyond the compile corruptions and crashes, so 2.50.2 is my only reference.

But I doubt it's your script, since others have gone nonfunctional, but more on that later since I'm only beginning to explore those for real. I wanted to wrap up this one before moving on.

Also, glad to see that you're still getting so much mileage out of that script !

Yeah, you know, it's a significantly different way of going about screen design. It's not so much a thing I use to redesign previous screens from earlier quests, but rather, heading toward new designs with the possibilities in mind sometimes shapes those designs considerably, as well as the areas that might lead up to them.

The only more significant change that totally changed the way I design maps was when linked portals were added to the Doom/Heretic/Hexen engine (the Eternity port anyway), and suddenly my favorite single-floored game could now have multiple floors and other non-euclidean designs. That was a total overhaul in thought process.

There is clearly something wrong with that test file. I cannot find a problem created by that script, though, in my tests. I created a blank quest in 2.53.0, and compiled that script, using both the old and new versions of ZQuest (2.50.2, and 2.53.0) and both appropriate versions of std.zh.

Saving and opening in crossed versions, and recompiling, using that script, did not cause any corruption. Is it possible that your test quest file itself was corrupted at some point, and you simply suspected this script to be the culprit?

I don't believe that to be the case.

For what it's worth, I took this opportunity to do a lot of system maintenance - malware scan, rootkit scan, temp removal, chkdsk /r, defrag & optimize, etc. - everything's working fine.

What you say about crossed versions led me to try different quests with different scripts. I already corrupted my first quest a few times, but I wanted to try another. Unfortunately, people are always passwording their stuff, but I remembered one quest that didn't have a password:

FleckQuest - download this.
Moosh Pits - paste this.

Open fleckquest.qst in ZQ 2.53 B2, import mooshpits.z, compile, add global, save. 3 tries, 3 identical corruptions. Worked perfectly fine in 2.50.2.

At this point, I'm fairly certain it has to do with loading quest files made in 2.50.x versions of ZQ into 2.53 versions of ZQ. Either I can't have so many corrupt quests from so many different sources, or 2.50.x consistently wrote corruptions that only 2.53 is finally reacting to. So I'm leaning toward a 2.53 issue, but of course it's only a quasi-educated guess.

I wish there were more quests that weren't of my own making to test with, but... password password password!

Regardless, I think this is the path worth exploring for now.

I would like to see all of the scripts that you were compiling with this, at one time, to see if any of them are doing things that are simply wrong, bad, and could have memory leaks.

Those were for something totally different. The example I gave in the previous post is an isolated incident - nothing other than what I posted was involved, so that other pack is irrelevant to that example.

That said, yes I have that separate file for the other quest, which I am still testing, and will probably post findings and an example of in a day or three. I want to try constructing the same example from scratch in 2.50.2 and 2.53.0 B2, then cross-checking them. I already determined that the scripts compiled in 2.50.2 worked fine in that version and in 2.53, and that there were some malfunctions/nonfunctions when compiled in 2.53, but it was only a cursory glance that I will have to look at for real in the coming days.

This script in fact, does something rather terrible, by declaring a user array of ComboD[176]-- never make a user declaration using an identifier that is already reserved by ZScript internally, it is just a bad idea--  but that s not the cause of any of these issues.

...well... OK, but... Works For Me™.

I don't suppose you have a recommended alternative?

Perhaps these differences are required for NES compatibility (with lake secrets, etc?)

In any case this probably needs a quest rule if changed.

I'm afraid I can only guess in regards to NES compatibility, but I don't believe lake secrets would require a difference like that since all whistle secrets reset by default during/after exiting the screen and you need a script to keep any of them permanent, so re-entering the screen would always use the reset (original) version anyway, which should make it irrelevant to those. And even if not, it would still mean certain screens may have potentially different renderings based on how they're approached.

 

To be clear, the example quest I made doesn't actually use the Whistle -> Dry Lake screen data option, or any screen data options for Whistle at all. It's strictly a combo cycling/animation trick. I added my (sloppy test) gradient shades to CSet 2, and made a 10-frame animation using mass tile recolor to cycle the lake from filled to empty. I noted the animation speed from the original effect to mimic it seamlessly, but it's not the original effect.

 

I suppose a quest rule is as good as any - I for one would use it, and be grateful for it - but if I understand correctly, you're running quite low on those for this version, and I'm not sure how you'd clearly word a rule like that in a way that people understand what different behavior it's changing. I can't think of any screens that would be dependent on using the original Item Cellar/Passageway fade-in compared to the Scrolling Warp fade-in, and again, you'd already have a conflicting rendering method if there was something dependent on it and they were approached with a Scrolling Warp instead.

 

Anyway, I get that it's a small issue, and sorry if I'm sounding pushy. It just ended up being personally relevant to me, and I was hoping it could simply be quick tweak, that's all.



#107 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 18 August 2017 - 04:23 PM

I've completed the test demonstrations for the "much larger script compilation for a previous 2.50.2 quest update" that I mentioned in the previous post.

I first built the test demo from scratch in 2.50.2, and imported and compiled the scripts, to a complete success. As expected, opening the 2.50.2 quest in 2.53.0 B2, and reimporting and recompiling the scripts, generated a consistent corruption on 3 of 3 tries. I then built the test demo from scratch again in 2.53.0, and imported and compiled the scripts, to a partial success. On one hand, I feel safe saying that quests built from scratch in 2.53.0 shouldn't come across any corruption issues, as I've compiled and recompiled multiple script files in multiple quests to no ill effect. On the other hand, the functionality of the scripts compiled in 2.53.0 is... rocky, to say the least.

To start, the files:

TTL Script Test Demo (2.50.2 Build) - a series of test rooms demonstrating scripts from the script pack in action.
TTL Script Test Demo (2.53.0 Build) - the same as above, rebuilt from scratch in 2.53.0.
TTLv12scripts-ghost.z - script pack for the project including ghost.zh import w/ global start/update.
Ghost.zh - as configured for this particular project.

Next, the breakdown of the scripts as they (generally) progress through the test demos, and their 2.53.0 functionality report:

Heart Piece Message (Item) [database] - Malfunction

This script keeps track of how many Heart Pieces you pick up, and displays a series of 4 strings for each of the 4 pieces, using D0-D3 for the string numbers. In 2.53.0, the script displays the message for Heart Piece #2 when you pick up Heart Piece #1, the Heart Container Complete message when you pick up Heart Piece #3, and the next string in the list when you pick up Heart Container #4. In other words, the strings are offset by +1.

Anti-Knockback Stone (Global) [forum post] - Success

This script gives you an inventory item that prevents Link knockback. Uses the Stone of Agony graphic.

Map & Compass Bundle (Item) [discord discussion] - Success

This script gives you a combined map and compass when you pick up this single item.

Item Pick Up Message (Item) [database] - Nonfunctional

This script displays a string when an item is picked up, using D0 for the string number. In 2.53.0, nothing displays, not even a wrong or blank string that freezes action (as the quest rule states).

Enemy Spawner (FFC) [forum post] - Nonfunctional

This script allows you to spawn an enemy at the position of the FFC, using D0 for the enemy ID number. It works regardless of the "Dungeon Boss (No Return)" screen state being set. The demo spawns 2 Fire Gels and 2 Keese. In 2.53.0, nothing spawns.

Fire Trail Duration Reduction (FFC) [database] - Nonfunctional

This script shortens the duration that Fire Zol/Gel trails remain on screen through an FFC, using D0 for the duration in frames (where 60 frames = 1 second). The demo sets a maximum of 3 fire trails behind Fire Zols. Use the Fire Gels spawned in the previous room for reference. In 2.53.0, no reduction is applied.

Permanent Block Secrets (FFC) [database] - Success

This script requires an FFC using a combo with an inherent flag of 16 to keep block (and other) secrets permanently triggered.

Enemy Music (FFC) [database] - Nonfunctional

This script plays a specific MIDI selection while an enemy/boss is on screen, then reverts to the default music when the enemy/boss is killed, using D0 for the MIDI number. In 2.53.0, no music plays at all.

Wizzrobe Summon Limit (Ghost Global / FFC) [forum post] - Malfunction

This script uses ghost.zh to create an invisible "enemy" that determines what enemies - and how many - a Wizzrobe Summoner can summon to a single screen, by having it summon only the ghosted enemy. For reference, the ghost.zh invisible combo is 1272, the "enemy" FFC slot is 5, and the empty tile blocks are the top left of tile page 39. The demo sets a maximum of 10 summoned enemies, those being Gels, Keese, and Goriyas. In 2.53.0, the Wizzrobe Summoners only summon an invisible enemy that dies the instant it's summoned.

For reference, this malfunction happened once before when I accidentally called the wrong FFC slot in the ghosted enemy's Data 2 configuration (Misc Attr. 12). However, I've triple checked these settings to be sure they're the same (though I suppose a quadruple check from fresh eyes wouldn't hurt), and so, due to the large amount of FFCs failing in this script compilation, I currently attribute this to yet another FFC failure.

Moosh Pits (Global) [database] - Success

This script provides 3 primary pit varieties - falling into a pit and restarting at the room entry point, falling into lava and restarting at the room entry point, and falling into a pit and down to a lower floor using Side Warp A for the destination. The demo dedicates 1 room to each of these 3 varieties, and each one works fine. A relieving result, given how complicated it is.

No-Move-On-Fall (Global) [discord discussion] - Success

Because Moosh Pits don't hold Link in place while falling down to the lower floor, and thus you can move to other screens while still falling, this was added to the global to prevent that (courtesy of Avataro).

Linked Secrets (FFC) [database] - Nonfunctional

Detailed in previous test demos.

Stop Compass Blink On Enemy Defeat (FFC) [forum post] - Success

As the title says. In the demo, it happens after killing the Aquamentus in the green left-side segment.

Stop Compass Blink On Item Pickup (Item) [forum post] - Success

As the title says, again. In the demo, it happens when you pick up the Bait at the end.

So there you have it. At this point, it seems globals always work, items are questionable, and FFCs mostly fail.

Just to be sure, I tried compiling the Fire Trail Duration Reduction script in its own self-contained 2.53.0 demo, but it remained nonfunctional as it did in the larger demo. Between that and the previous Linked Secrets demos, I don't believe isolating any of the failed scripts will produce a different result than they do in this larger demo.

As always, check the 2.50.2 build in either ZC version to see how everything should work, and the 2.53.0 build to see how it doesn't.


  • Avataro likes this

#108 ZoriaRPG

ZoriaRPG

    ZC Contributor & Wiki Editor

  • Members
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 19 August 2017 - 02:52 AM

It sounds like the first of the InitD args is being popped early, and eaten. Something similar happened earlier on in the process of the compiler fix that corrected variables in scope, so this is obviously a remnant that was not fixed; but that seems odd, as I was able to compile and use scripts using the eight data args with no problem.

 

Does this data eating only occur when the scripts are recompiled, and not cleanly (newly) compiled in 2.53? That is bizarre, if true.



#109 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 21 August 2017 - 12:10 PM

Whatever the error relating to the non-functionality of certain compiled scripts may have been, it's been resolved as of 2.53.0 Beta 4.

 

I rebuilt the above script compilation test demo from scratch for a third time using 2.53 B4, and every functionality error I listed in the previous post has been resolved.

 

For reference, the file:

 

TTL Script Test Demo (2.53.B4 Build)

 

With that out of the way, I can finally confirm what I initially wanted to confirm when I started all this: scripts compiled in 2.50.2 work successfully in 2.50.2 and 2.53 B4, and scripts compiled in 2.53 B4 work successfully in 2.53 B4 and 2.50.2.

 

Of course, that still leaves cross-version corruption. While 2.50.2 was able to successfully open a 2.53 B4 quest file and re-import/recompile scripts, 2.53 B4 still faces routine file corruption issues when re-importing/recompiling scripts into a 2.50.2 quest file. I've tried tinkering with different settings and processes, but it's only me throwing punches in the dark, and always to the same result. Beyond continually retrying with newer betas, I don't believe I can be of much more help in regard to this particular issue.

 

At this point, I would suggest you guys strongly push for script authors to compile and test their material using the latest beta. As much as I've tried compiling and testing these scripts, and as much variety as I've tried to include, I'm still not a coder by any stretch. I can't look at raw files and determine how they should work, and even with a decent description, I still can't know what the author's intentions were and if the description is truly in line with them. Now that 2.53 B4 appears to be compiling fresh files without a problem, your next big public release (whether B4 or later) should include a call for script authors to build fresh test demos and report in with their results. Maybe even make a separate ATTN: topic in the Scripting Discussion forum in addition to the standard release thread in this forum. With the possibilities being as great as they are, it's going to take more than a casual user to thoroughly test compiler functionality, not to mention compare it with previous functionality for discrepancies.

 

ALSO: the Beta 4 update introduced a new fatal crash in ZQuest.

 

Grab a quest, any quest, even a new quest, then go to Quest -> Rules -> Backward Compatibility...

 

...yeah, this new ZQ doesn't seem anywhere near as interested in preserving the past as it does in expanding the future :P

 

Furthermore: I tested all 4 entries in the Metroidvania Contest using 2.53 B4, and they all performed successfully.

 

They also performed consistently with the streams from players using 2.50.2, which may be more to the point for this topic.



#110 Nicholas Steel

Nicholas Steel

    Hero of Time

  • Members
  • Gender:Male
  • Location:Australia

Posted 22 August 2017 - 03:28 AM

Where is 2.53 beta 4 (and newer) available from?


Edited by Nicholas Steel, 22 August 2017 - 03:29 AM.


#111 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 22 August 2017 - 03:39 AM

They're not "officially" released, but click the "ZC Dev & Latest Betas" link in ZoriaRPG's sig, and they're right at the top of the index, the latest being "2.53_Win_Beta_4.zip" (40 MB). It's a working folder, not a "proper" distribution package, hence a lot of other miscellaneous material in the folder, but it has the latest builds of the programs.



#112 Nicholas Steel

Nicholas Steel

    Hero of Time

  • Members
  • Gender:Male
  • Location:Australia

Posted 22 August 2017 - 04:11 AM

Oh, in that case you should also specify the date and time that you downloaded your copy from there.



#113 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 22 August 2017 - 04:32 AM

I was sent the link in private over Discord, so I wasn't sure I should post it to this topic. I didn't realize it was part of the public ZC Dev folder until earlier today.

 

But to answer the question, I downloaded it 2 days ago, about the date that the index lists it as (in my part of the world anyway).



#114 ZoriaRPG

ZoriaRPG

    ZC Contributor & Wiki Editor

  • Members
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 22 August 2017 - 07:50 AM

Beta 4 is an internal build. I sent it to Lüt, as he effectively volunteered to aid in extensive testing, and it was important to learn if the build fixed the issues that he was having. (Clearly, only in part.)

For reference, beta builds are sequential. if I were to upload a new one, it would be 'Beta 5', not a replacement for 'Beta 4'. (Beta versioning is also, always in whole numbers.) This is why none of you saw Beta 3.

Please understand that Beta 4 is not a public build, because it has its own issues, primarily with some Allegro changes that we're trying to implement, and Allegro not cooperating with my compiler. (PNG images are the core of that new problem.)

It would be a bad policy to post a public beta with known critical issues.

Still, these are not hidden in any way. There is a link in my signature in every post, to where you can find dev builds, and related files, for 2.53.0, and (Alphas for) 2.54+/2.60. : :shrug::

Edited by ZoriaRPG, 22 August 2017 - 07:56 AM.


#115 Nicholas Steel

Nicholas Steel

    Hero of Time

  • Members
  • Gender:Male
  • Location:Australia

Posted 22 August 2017 - 07:54 AM

I have signatures hidden. Good to know each release has its own version number to avoid confusion.


Edited by Nicholas Steel, 22 August 2017 - 07:55 AM.


#116 ZoriaRPG

ZoriaRPG

    ZC Contributor & Wiki Editor

  • Members
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 22 August 2017 - 09:21 AM

I have signatures hidden. Good to know each release has its own version number to avoid confusion.


Ah well, that is silly. Look what you've been missing: Some of us have, you know, useful links there. :P

The only time I would replace a beta, is if within minutes of uploading it, I realise that it is missing a file, or that it has padding that it can live without. The actual binaries would never change.
It is always safer, or at least more prudent, to upload a new beta. In some cases, I will flag these as Beta-n-context, such as Beta-2-Early.

This is during a preparation process, so that Beta-2-Early, is followed either by Beta-Late, or proper Beta-2 (which is the final build of a beta). See: http://semver.org/

I did that a few times for [2.future] builds. Beta 52 is still is in the prerelease phase, as Beta-52Later or something, as I decided to hold off on it until there is some idea of what the stock ZC 2.54 will look like in its final form.

Spoiler

Edited by ZoriaRPG, 22 August 2017 - 09:23 AM.

  • Anthus likes this

#117 ZoriaRPG

ZoriaRPG

    ZC Contributor & Wiki Editor

  • Members
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 23 August 2017 - 09:01 AM

Fixed the bug on Quest Rules: Compatibility.

#118 DarkDragon

DarkDragon

    Junior

  • ZC Developers
  • Gender:Unspecified

Posted 24 August 2017 - 09:53 PM

The script corruption issue should be fixed (see https://github.com/A...sic/issues/122)



#119 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 27 August 2017 - 04:49 PM

OK, so to summarize some recent Discord discussion and wrap up this topic:

Beta 5 did indeed fix the Backward Compatibility QR crash.

As for Beta 6...

I opened both the 2.50.2 and 2.53 B4 versions of my Script Test Demo, recompiled them in B6 multiple times using both buffer content and imported .z(h) files, and played them in 2.50.2 and B6.

Then I repeated the process with the actual quest that used those scripts.

Finally, I dug up some of the most script-heavy quests I could find, that I was also familiar with, and knew how they should function, from having played them before. Of the ones that could actually be recompiled from their buffer contents, I did so multiple times, then played them (nearly completely) in B6 and 2.50.2...

And...

Looks like the compiler issue is indeed finally solved :D

I couldn't detect any functional differences between the original and the recompiled versions, nor did either version demonstrate any stray glitches or other errors.

Still, I'm not remotely any kind of coder, so again, it's best to encourage the actual script authors to check their scripts precisely.

Regarding previous report content: the Solid Secret Water-Sink, Passage Subscreen Update, and Sword Spin Loss all appear to be fixed as far as I can push them (though the sword swing sound effect still plays upon entering the cave). The Bombchu (Mis)behavior, Hammer Pound/Fade-In Differences, and Shop Text Disappears don't appear to have been addressed (though correct me if I'm missing a new quest rule or something). Finally, the issues relating to Infinite Wallet Not Infinite all appear to be fixed - however, it introduced a new issue with the standard wallets/rupee count.

But, since B7 is now public and this thread is wrapping up, I'll carry any remaining issues over to that topic.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users