The Betas are slowly getting worse for some reason....

That and bugs that were fixed by one developer, are brought back again once another developer puts his code into the compiled program. So its like we're taking two steps forward with bug fixing but one step back when the very bugs that were just fixed are re-introduced again. Which gives rise to the absolute need that all devs need to be on the same page.

The last beta to be released was beta 16c. It was pretty bad I have to say as it is halted my game. However, the builds/Alphas are buggy but it is okay if they are. Usually when they make the builds they test it themselves and then release it as a beta. But they thought it would be easier if we could find the bugs for them, so they could spend more time fixing and programing it. But it is going a little slow because they are people and people have lifes and since it is the middle of Feburary, they may be busy with school or something.

Anyways, the reason why the item feature was working perfect then not is because of the fact that when the items were working, they were hard coded. And when they add things like the small shield, they may have had to change the whole program for the shields. Also, since they are making scripted items they would have to change the code. That is why you would see bugs in there. For example, they are adding the things in the subscreen, and that is why it has a bug, as they changed a code but didn't catch a mistake there. Also, when developers are making one thing and the other is making another, it may not match up or something which would cause a bug.

But yes, I agree with you that bugs are evil, but I think they will do there best to release a stable version of ZC. It may not be out for a while but hey they are doing there best.

Edit: DFW beat me to it! :P

I totally agree, and in my opinion, PLEASE CAN WE HAVE NO MORE NEW FEATURES! The new features are causing the bugs, as I'm sure you're aware, Devs, so please stop hiding them under the carpet and hoping we don't find them by adding more features.

Actually, 16c has been one of the best ones for me (beta 10 was better, and b15 in 3rd place.) I'm not implying that the alphas/betas should be bug free, what wories me is that the number of bugs is climbing, and for little things too, like drop-down menus.

Yeah, we really do need more co-ordination between Devs. As for features, well, only certain kinds of features are causing bugs. There arn't really that many bugs in small features that modify/add to existing features. It's only big, impressive things that mess with the code in ways that cause bugs.

EDIT: MW, yeah, there come bugs from stuff like drop-down menus, but I get the impression that those are the bugs that can be fixed in like 10 minuites just by looking at the code.

I'm *this* close to simply locking topics like this on sight.

If you can't stand the heat, get out of the kitchen.

If you want to lock this one, go ahead:sweat: . I've stated my opinion, from now on, whatever happens, happens. If 2.5 is released in a year (or two) so be it.:shrug:

:uhoh:

I won't lock it... if it stays civil.

i just can't believe petoe made a feature request...

Heh franpa... you mean that "screen shake" idea? Well I only want to see it added IF it is an easy addition. But i know it won't be added as none of my suggestions get added, lol.

But other than that, I'm still as frustrated and apalled at this whole situation as ever. I know these builds are supposed to be buggier than betas, but right now it seems that every build is just buggier than the previous one, and as Wolfie stated, sometimes a bug that has been fixed by one developer is brought back by another one. Now how am I supposed to have any faith left for a stable 2.5? After jman left, things have really gone downhill.
But I'm not gonna pull a Freedom stunt and leave just yet. I'm gonna keep on testing, at least that way I can honestly say I've done everything I could have done about this situation. But I can't help but feel that all my + other tester's effort is a time gone to waste. Oh well... you can just ignore me if you want... I'm just a frustrated quest developer who is afraid his almost finished quest will never see its release...

jman2050 wrote:I'm *this* close to simply locking topics like this on sight.

You might as well. Topics like this tend to deteriorate into flamewars rather quickly. The people who start these topics are just out to tarnish ZC's reputation anyway.

The people who start these topics are just out to tarnish ZC's reputation anyway.

EDIT: A quick aside, how could we even tarnish ZC's rep here in the beta forums, where most of the people who read this are already tried and true supporters?

But other than that, I'm still as frustrated and apalled at this whole situation as ever. I know these builds are supposed to be buggier than betas, but right now it seems that every build is just buggier than the previous one, and as Wolfie stated, sometimes a bug that has been fixed by one developer is brought back by another one. Now how am I supposed to have any faith left for a stable 2.5? After jman left, things have really gone downhill.

I have no problem with people voicing their opinions, and welcome constructive criticism, but I don't see the point in attacks such as "omg ZC is getting buggier by the day" which clearly contradict the facts, and make me wonder why I'm donating my time to this project.

*sigh* yeah, your probably right DD. However, as a dev you are much closer to the project, and can't be super mad at us for what we in our, ummm, naievete, non knowledge, somthing like that. That changelog helps out a lot to.

(At this point, someone will point out that we can be blamed for just not paying close enough attention to notice this stuff. I have no comment.)

Spiffy Enigma wrote: The people who start these topics are just out to tarnish ZC's reputation anyway.

Now wait a minute, I'm not trying to tarnish ZC in ANY way. DarkDragons response is the kind of reaction(s) I'm after. I would consider myself a passionate fan to Zelda Classic. Trying to tarnish it would be against my principles. When I heard of the program, It was like a dream come true. I hope this can stay civil, but in a way where instead of cursing out/attacking each other, we say stuff like "I strongly disagree" or use words where it's obvious you're refraining from being... un-civil.

*sigh* I don't know... maybe it's just the fact that people tend to only notice bad things that happen and belittle the GOOD things (trust me, that happens to me A LOT).

DarkDragon wrote:...
I'm perplexed as to how you've reached that conclusion. The only NEW bugs introduced since the start of the public alpha builds was the problem with ZC requiring random .dll files, which I've fixed and take full responsibility for. Every other bug was there before. Yes, there is a problem with MIDI loading, which wasn't as visible before as now, but I'm working on that one. On the other hand, excluding the ZCL (which is being worked on exclusively by Sean and thus is not taking any time away from the other developers), I count
- 21 bug fixes, nearly half of which are for critical, crash bugs
- only 2 new features (integrity checker and romview)
- 2 minor cosmetic tweaks (scripts menu and logo)
That's an average of around 2 less bugs per day, with 90% bugfixing and 10% new features. Seriously folks, what more do you want?

I have no problem with people voicing their opinions, and welcome constructive criticism, but I don't see the point in attacks such as "omg ZC is getting buggier by the day" which clearly contradict the facts, and make me wonder why I'm donating my time to this project.

o_O or something like that?

DarkDragon wrote:...
I'm perplexed as to how you've reached that conclusion. The only NEW bugs introduced since the start of the public alpha builds was the problem with ZC requiring random .dll files, which I've fixed and take full responsibility for. Every other bug was there before. Yes, there is a problem with MIDI loading, which wasn't as visible before as now, but I'm working on that one. On the other hand, excluding the ZCL (which is being worked on exclusively by Sean and thus is not taking any time away from the other developers), I count
- 21 bug fixes, nearly half of which are for critical, crash bugs
- only 2 new features (integrity checker and romview)
- 2 minor cosmetic tweaks (scripts menu and logo)
That's an average of around 2 less bugs per day, with 90% bugfixing and 10% new features. Seriously folks, what more do you want?

I have no problem with people voicing their opinions, and welcome constructive criticism, but I don't see the point in attacks such as "omg ZC is getting buggier by the day" which clearly contradict the facts, and make me wonder why I'm donating my time to this project.

This is because users don't understand the concept of a Beta/Alpha. Beta and Alpha is ment for you users to help us find the bugs so we can fix it. If you don't post a bug report. Of course we will not know what is going on. It's that simple.

DD you left Koopa out on the ZCL project;

Also same applies with ZCL.
Here is some reference

Obtained from WikiPedia wrote:
Alpha

The alpha version of a product still awaits full debugging or full implementation of all its functionality but satisfies a majority of the software requirements. It often lacks features promised in the final release but demonstrates the feasibility and basic structure of the software. As the first major stage in the release lifecycle, it is named after the Greek letter alpha, the first letter in the Greek alphabet.

The alpha build of the software is usually the first build delivered to the software testers.

In the first phase of alpha testing, developers test the software using white box techniques. Additional inspection is then performed using black box or grey box techniques. This is usually done by another dedicated testing team sometimes concurrently. Moving to black box testing is often known as the second stage of alpha testing.

Beta

A beta version or beta release usually represents the first version of a computer program that implements all features in the initial requirements analysis. It is likely to be useful for internal demonstrations and previews to select customers, but unstable and not yet ready for release. Some developers refer to this stage as a preview, as a technical preview (TP) or as an early access. As the second major stage in the release lifecycle, following the alpha stage, it is named after the Greek letter beta, the second letter in the Greek alphabet.

Often this stage begins when the developers announce a feature freeze on the product, indicating that no more feature requirements will be accepted for this version of the product. Only software issues, or bugs and unimplemented features will be addressed.

Beta versions stand at an intermediate step in the full development cycle. Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.

An example of a major public beta test was when Microsoft started releasing regular Windows Vista Community Technology Previews (CTP) to beta testers starting in January 2005. The first of these was build 5219. Subsequent CTPs introduced most of the planned features, as well as a number of changes to the user interface, based in large part on feedback from beta testers. Windows Vista was deemed feature complete with the release of build 5308 CTP, released on February 22, 2006, and much of the remainder of work between that build and the final release of the product focused on stability, performance, application and driver compatibility, and documentation.

When a beta becomes available to the general public it is often widely used by the technologically savvy and those familiar with previous versions as though it were the finished product. Usually developers of freeware or open-source betas release them to the general public while proprietary betas go to a relatively small group of testers. Recipients of highly proprietary betas may have to sign a non-disclosure agreement. A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist. Companies with a formal software process will tend to enter the beta period with a list of known bugs that must be fixed to exit the beta period, and some companies make this list available to customers and testers.

As the internet has allowed for rapid and inexpensive distribution of software, companies have begun to take a more flexible approach to use of the word "beta". Netscape Communications was infamous for releasing alpha level versions of its Netscape web browser as public beta releases. In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production-level [1]. It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006. This technique may also allow a developer to delay offering full support and/or responsibility for remaining issues. In the context of Web 2.0, people even talk of perpetual betas to signify that some software is meant to stay in beta state.

The term beta test applied to software follows from an early IBM hardware development convention dating back to punched card tabulating and sorting machines. Hardware first went through an alpha test for preliminary functionality and manufacturing feasibility. Then a beta test to verify that it actually correctly performed the functions it was supposed to, and then a c test to verify safety. With the advent of programmable computers and the first shareable software programs, IBM used the same terminology for testing software. Beta tests were conducted by people or groups other than the developers. As other companies began developing software for their own use, and for distribution to others, the terminology stuck and now is part of our common vocabulary.

franpa wrote:erm, are you saying that there are more bugs the end user can interact with then before but the number of bugs there is is the same amount?

o_O or something like that?

Well, let's take one of the best examples, the buffer overrun. Suppose ZC is coded to reserve, say, 1000 bytes per screen for combos, but because of a coding oversight, some quests try to save 1100 bytes worth of data. The extra 100 bytes "spill over" and are written somewhere else in memory; this is the buffer overrun. What happens when these 100 bytes are written is completely unpredictable. If you're lucky, it gets written to useless memory and nothing bad happens. If you're unlucky, it overwrites other useful data, such as the next screen's combo, without ZC or the user detecting anything bad has happened. Sometimes the OS can detect a buffer overrun and crash the program, but a lot of the time the corruption happens silently.

Thus, what can happen is that a buffer overrun can lurk undetected in the program for years, silently corrupting data and causing all kinds of weird behavior. Then, all of a sudden, a harmless change elsewhere in the program, such as a fix for another bug, changes the layout of memory slightly, and what use to just silently corrupt data now crashes ZC. It's not that a new bug has been created - the old bug's behavior just changed.

Actually, a bug crashing ZC is sometimes very good news; a buffer overrun silently corrupting data is very, very difficult to track down, and might not be fixed for years (take for instance the combo corruption bug; we've never been able to find that one.) Once it has "mutated" to crash ZC, on the other hand, it becomes much easier to pinpoint the bad code that causes the buffer overrun, meaning it is very likely the bug will be finally and promptly fixed.
Obviously when ZC crashes, it sometimes is genuinely the fault of a recent change, and not of a lurking buffer overrun, but you should keep in mind that more crashes doesn't necessarily mean everything is going to hell - maybe the crash will give us an extra angle of attack allowing us to finally nail elusive bugs.

Here's my $0.02:

There was a time when Beta testing was restricted to a closed group of individuals and all the public saw was the releases - perhaps once or twice a year, don't quote me on that though.

Then with the first 2.11 betas, betatesting was made public. And lately, we've been giving everyone access not just to the "betas" but to alphas - our very own development builds.

So, in the "past" a new feature might have been added like this: a developer codes something, producing a new (and less stable) version, tests it a bit, a few weeks later it's released to the beta testers, bugs are found and fixed, then it's tested again, and after all that's done a new version ise released.

It still works that way now, but with one difference: you can see behind the scenes. You can see all the betas and become a beta tester yourself. You can even see the development builds, that's the "really buggy" ones?

I know that any new feature must be tested for bugs thouroughly before a new version is released. The difference is, in the past you'd have only seen the end result, now you can (if you wish) see the work in progress. Anything will look messy before it's completed. By downloading the development builds or betas, you are not getting a stable playable version - you're taking part in that testing that must take place before a stable version can be made.

In short, yes the recent builds are a lot more unstable than the earlier betas/full versions. That's for a good reason. I second jman on this one, if you don't like it you don't have to. As an analogy, if you want to build yourself a new house, it'll be a building site for a while, don't move in then complain about leaks before the roof's been put on.

Once again:

Full versions (ZC 2.10 etc.) : For making and playing quests
Betas : For bugtesting. You can make or play in some of them but expect bugs.
Alphas / Development builds : For bugtesting and reporting only. If you're making a quest don't download these. (Perhaps I should disable saving just to make it clearer. :P No, of course I won't, but you get the idea)

koopa wrote:
Full versions (ZC 2.10 etc.) : For making and playing quests
Betas : For bugtesting. You can make or play in some of them but expect bugs.
Alphas / Development builds : For bugtesting and reporting only. If you're making a quest don't download these. (Perhaps I should disable saving just to make it clearer. :P No, of course I won't, but you get the idea)

Very good post Koopa, that's a beautiful idea you got there, but it's just an idea.

I mean, you compare ZC to a house. Well to me and many others ZC is like a house that never gets finished. It has been under construction for such a long time, and even though the blueprints indicate that the house will be beautiful and comfortable, a really appealing house when it is finished, people interested in the house are getting frustrated and lose faith that it will never be a house where you can live in. Why?
Well the designers of the building aren't co-operating and some of them keep adding stuff that isn't necessary but something very cool to bring up the price of the house. After all, it must be the best house ever because so many people want it to have everything a house can have, and even more. It would be a fine and livable house without all that extra stuff, but now it seems like the house just keeps getting more unstable and dangerous even though the builders are trying to feverishly fix all the problems. But it may be impossible to get the house perfectly stable and safe anymore without taking the whole bulding down and re-constructing it after all those additions that made the structure very unsound.

Yeah, I know, what's done is done and there's nothing we can do about it and I really hope ZC hasn't gotten so complex that it is beyond fixable. I really want to believe that all you developers have learned from all these mistakes, and since currently the main focus SEEMS to be on bug busting, I am still a faithful tester because damn, I want to see that stable release and I want to be able to release a quest that has encountered too many problems already and has been delayed way too much.

The second point this thread raised is entirely valid. When I joined, it was just DN and jman and they coordinated it all via chat or AIM. As we grew to a larger team we needed different tools - a SVN server for one, or coordinating would be hopeless - and it's possible that things could be, and may be, planned and coordinated even better in future.

Towards the end of last year the focus was really on putting lots of new stuff in - scripting, custom enemies and items, ice combos and whatnot. Petoe's right, there's more bugfixing going on right now. DarkDragon being around again can also only help there.

As to bugs appearing and disappearing (Magic Shield etc.) ZC has gone a considerable rewrite recently. Central things like the item system or the enemy system had to be changed - and moreover changed bit by bit - but all in all I think when the newer system is in place it'll actually improve the stability, as it's built on a more solid foundation. For instance, some code that was a patchwork of "a bit of this here, a bit of that there" is now much more clean and organized. Some of this "tampering" was necessary to allow custom items and subscreens, and some of it was more "let's redo it thouroughly while we're at it".

Like DarkDragon said, it's an opportunity to fix things that have been lurking for years and now the new features bring them to light. Another point is we don't always get it right the first time either. Sometimes one person changes a line of code to fix one bug, but it causes another one somewhere else. So that line has to go back out and we have to deal with the first bug somewhere else. Sometimes we have to rewrite half the item system to allow some new feature (think true arrows) to work. One of the consequences of seeing the work in progress is that you see all our trials and errors. I hope that goes some way towards explaining how we "put bugs back in". If I change something and it causes a new bug, I'll take it back out (as happened with the map view in ZC). And so the old line and the bug it caused is back in (DD fixed that one finally, though. thanks). I'm not denying that at other times we do put actual bugs back due to lack of coordination, though.

On the point of whether we should all use one compiler, I don't think that's that much of an issue. Except for the recent dll issue it hasn't caused too much trouble - the bugs we're talking about here are bugs in the code and don't have much to do with whether we use gcc or msvc. If we want a ZC that runs on Windows, Linux and Mac OS we pretty much have to use different OS - but as it all boils down to the allegro library in the end, the actual ZC code is pretty much platform- and compiler-independent.

The community has expressed many times that they would by and large prefer something that works and that in a reasonable amount of time over something with many more features than we have now some time in the distant future. I - and the rest of the development team, as far as I can tell - have noticed that and agree with it. I know we promised a stable ZC by last Christmas. Getting annoyed with the delays since and feeling let down is somthing I can understand.

DarkDragon wrote:Well, let's take one of the best examples, the buffer overrun. Suppose ZC is coded to reserve, say, 1000 bytes per screen for combos, but because of a coding oversight, some quests try to save 1100 bytes worth of data. The extra 100 bytes "spill over" and are written somewhere else in memory; this is the buffer overrun. What happens when these 100 bytes are written is completely unpredictable. If you're lucky, it gets written to useless memory and nothing bad happens. If you're unlucky, it overwrites other useful data, such as the next screen's combo, without ZC or the user detecting anything bad has happened. Sometimes the OS can detect a buffer overrun and crash the program, but a lot of the time the corruption happens silently.

Thus, what can happen is that a buffer overrun can lurk undetected in the program for years, silently corrupting data and causing all kinds of weird behavior. Then, all of a sudden, a harmless change elsewhere in the program, such as a fix for another bug, changes the layout of memory slightly, and what use to just silently corrupt data now crashes ZC. It's not that a new bug has been created - the old bug's behavior just changed.

Actually, a bug crashing ZC is sometimes very good news; a buffer overrun silently corrupting data is very, very difficult to track down, and might not be fixed for years (take for instance the combo corruption bug; we've never been able to find that one.) Once it has "mutated" to crash ZC, on the other hand, it becomes much easier to pinpoint the bad code that causes the buffer overrun, meaning it is very likely the bug will be finally and promptly fixed.
Obviously when ZC crashes, it sometimes is genuinely the fault of a recent change, and not of a lurking buffer overrun, but you should keep in mind that more crashes doesn't necessarily mean everything is going to hell - maybe the crash will give us an extra angle of attack allowing us to finally nail elusive bugs.

So, its kinda like this then. (Bare with me, I get a bit farfetched sometimes, so this is a bit unrealistic)
There's a dinosaur that dies, and then all of it's bones are crushed onto a big rock. And this fossil has bits of the Dino's DNA left over on it, so anything that touches the fossil dies, and it stays in the earth for years and years, but noone knows the fossil is there. Then, the people dig down into the earth to get oil, and this rock is thrown out onto the ground. Then, for some bizzare reason, oil is spilled onto the fossil. Suddenly, the DNA reacts with the oil and a huge dinosaur is formed in seconds, and attacks the people.

Does my metaphor make sense, or just ruin your explination completely?

Ummmm.....Hmmm, maybe I'm interperating your metaphor wrong. I was thinking of filling a huge jug of water over a bunch of delicate equipment. If you overfill, chances are that it's going to mess up somthing.

Hey Petoe, your PM box is full. I wanted to send you a PM but couldn't.

You know, 2.11b10 was a pretty solid beta. When in doubt, if the following betas become too buggy, we could just scrap them and go back to the drawing board with b10. This would be last-resort only, though.

Pineconn wrote:
You know, 2.11b10 was a pretty solid beta. When in doubt, if the following betas become too buggy, we could just scrap them and go back to the drawing board with b10. This would be last-resort only, though.

Whoa there Pineconn... we? When did you become a developer? O_o

Anyways, b10 sure was good, but so is b15. It's just that both of them have those really annoying bugs. It seems like it will take forever for 2.5 to be stabilized and released but I'd really love to release the group quest Lost Isle before that. The problem is that there's always one serious bug preventing the quest to be released for one of the betas. First there was the bomb crash bug, and when it was fixed there was the subscreen/HCP bug, and now that they're fixed there's this Ring cset bug... agh. Otherwise the betas and even the builds are great, so I shoudln't be complaining as much as I am currently.

Anyways, I have to admit I have regained my faith in ZC 2.5 and in the developers now that DD has come back and is doing tons of bugfixing. Oh and I wonder where _L_ disappeared... did he officially take a break or did he just vanish somewhere? No need to answer that question, but even though he has some awesome skills, I kind of like it now that he isn't here adding those features behind everyone's back... everything just seems to go so nice and smooth right now.

Petoe wrote: Oh and I wonder where _L_ disappeared... did he officially take a break or did he just vanish somehwere? No need to answer that question, but even though he has some awesome skills, I kind of like it now that he isn't here adding those features behind everyone's back...

I was about to ask that! Well, _L_, if you are reading this thread, any input?

EDIT: Is their any chance I can become a tester?

majoras_wrath, everyone can become a beta tester now ... just download the latest builds from AGN and don't forget to report bugs! See the box at the top of the beta forums.

DarkDragon wrote:...
I'm perplexed as to how you've reached that conclusion. The only NEW bugs introduced since the start of the public alpha builds was the problem with ZC requiring random .dll files, which I've fixed and take full responsibility for. Every other bug was there before. Yes, there is a problem with MIDI loading, which wasn't as visible before as now, but I'm working on that one. On the other hand, excluding the ZCL (which is being worked on exclusively by Sean and thus is not taking any time away from the other developers), I count
- 21 bug fixes, nearly half of which are for critical, crash bugs
- only 2 new features (integrity checker and romview)
- 2 minor cosmetic tweaks (scripts menu and logo)
That's an average of around 2 less bugs per day, with 90% bugfixing and 10% new features. Seriously folks, what more do you want?

I have no problem with people voicing their opinions, and welcome constructive criticism, but I don't see the point in attacks such as "omg ZC is getting buggier by the day" which clearly contradict the facts, and make me wonder why I'm donating my time to this project.

Although Koopa's already done a great job mediating the situation, I'll step in and say that you guys really need to hire a Community Manager because what we have here is a big gap in communication between the Developers and the general public. It's nobody's fault really. It just happens when the Developers are one level and the rest of us are on a different level, and the Developers assume that the public knows what's going on, and vice versa. Nobody's entirely right, or entirely wrong. It's a situation that's remedied by someone who can act as a liaison between the development team and the public.

For real companies with real products (Blizzard, Valve, etc.), this position is called the Community Manager, and the community manager bridges the gap between these two groups. The Community Manager takes cues from the development team and presents them to the public in a way that is understandable, and goes out of his/her way to make sure the public knows what's going on development-wise. Likewise, the CM takes all important open issues and suggestions and presents the to the developers in a way that they will understand.

In this way, we have someone who can communicate with both sides, and prevent a thread like this from ever existing. For months, there's been a disconnect between what the Developers think and what the public thinks, and it's about time to close that gap for good.

Just a suggestion. There are 1-2 people here who would be qualified for the spot, and you know who those people are.