Zelda Classic 2.11 Beta 16

[ShadowTiger]

It's not a full version.

It's a Beta.

It's meant to be tested to get these bugs out so when the full version comes around, it's going to be bug free.

If nobody wants to use it because it's full of bugs, don't expect all the bugs you could have found to be ironed out because you were too afraid of a real quest being bugged up. Don't build a quest for serious use of its new features. Build a test quest to test those new features, rather than showing them off in a real quest environment.

So instead of complaining about how all the betas are buggy, the more bugs we actually find, the more likely it is that future versions, "Full" or not, will not be as buggy.

Considering that the Devs actually stated that these are the last new features to be implemented, we may as well start to expect a full version sooner than later, and test our butts off to ensure that it's not another 2.10.


We need to work on a test quest; something quick and dirty that actually goes right through every possible feature and tests all facets of it. Replaying old quests is a great way to get it done, assuming it doesn't crash.

That said, it'd be nice if the devs themselves could play test these versions for five or ten minutes before release. Some of these bugs are just extremely obvious. (Though I'll admit jman not finding that scrolling bug in the enemy editor is just plain luck.)

[The_Amaster]

I already have a test quest I use. You start with every item, and it has screens with every feature and boss in the game.(Except scripting, I cant script yet) It took a while to compile, but it's great for debuging. Only problem is sometimes I still can't tell if the bug is a bug, or a mistak due to my incompetance.

Oh, anyone have an idea why b16 is corrupt for me?

[Solair Wright]

It's not a full version.

It's a Beta.

It's meant to be tested to get these bugs out so when the full version comes around, it's going to be bug free.

If nobody wants to use it because it's full of bugs, don't expect all the bugs you could have found to be ironed out because you were too afraid of a real quest being bugged up. Don't build a quest for serious use of its new features. Build a test quest to test those new features, rather than showing them off in a real quest environment.

So instead of complaining about how all the betas are buggy, the more bugs we actually find, the more likely it is that future versions, "Full" or not, will not be as buggy.

Considering that the Devs actually stated that these are the last new features to be implemented, we may as well start to expect a full version sooner than later, and test our butts off to ensure that it's not another 2.10.


We need to work on a test quest; something quick and dirty that actually goes right through every possible feature and tests all facets of it. Replaying old quests is a great way to get it done, assuming it doesn't crash.

That said, it'd be nice if the devs themselves could play test these versions for five or ten minutes before release. Some of these bugs are just extremely obvious. (Though I'll admit jman not finding that scrolling bug in the enemy editor is just plain luck.)

Well, I know it's a very hard task to work on betas, and there will be betas buggier than others. It's okay, no one can help it at times, and that's why we have a beta testing forum to pinpoint bugs the developers missed.

[The_Amaster]

I think some bugs are really hard to predict, possibly because they don't directly relate to the feature, and are mistakes in the code based off of other stuff. (A great example is the raft bug. I don't recall any feature in the last beta that would have required deliberate editing of the code)(But than again, I'm not a dev)
Oh, BTW, anyone figure out why my b16 is corrupt yet (Yes, I'm going to keep saying this)

[_L_]

[*]Fixed the script commands that return map, screen, or dmap numbers so they return integers intead of floats. Work done on the LINKCHARGING command.

Actually, I intended it to be called LINKCHARGED, and would return true only if Link was currently performing a spin attack, quake hammer or something. This is so that the spin attack and quake hammer are "visible" to scripts.

DN seems to have changed it to LINKCHARGING and made it a getter/setter for Link's "charging" variable. Giving scripters control of this variable is, in my opinion, neither good nor useful, as I coded it under the assumption that it would only ever increase when Link's action was "attacking" and his attackclk was frozen at a certain value.

[jman2050]

16b is out.

[CJC]

Figures, 12 seconds after I download 16a. Oh well, at least I hadn't unzipped it yet.


Oh, and Koopa? What did you mean when you said 'Inactive' tile modifiers? (It was in the middle of your post, next to the Link Tile Modifier and about the A and B item selection. I'd quote you, but I'm too lazy to go find the post.)

[Stungun]

May I also suggest a quest upgrading thing, for when betas start to cut new items into the Z# slots? Cause if I make or modify a test quest from a beta using the first 'Z#' items and then a new ZC beta is released that takes up those slots, then I have to do a LOT of editing to get things working again.

Perhaps when ZC imports a quest from an older beta it shifts all Z# item references forwards a few?

[blue_knight]

Hey jman, is there anyway I can get a quick function and argument list for the new ZScript Drawing functions? Even a list would be fine if you don't have time for a full explaination. Thanks :)

[Revfan9]

I would really, really like a list of Zasm functions for the drawing features as well.