almost bug free?

Well then, screw it, I would be more than willing to start on a rewrite, but only if people would absolutely be satisfied with a new version of ZC that's missing 90% of its intended functionality but without random crashes and quest corruption bugs. I'd have to convince myself to do things that way.

I'd be satisfied. But here is my 2 cents about it:

We really just want a release, that is stable as possible. There has been a lot of things added since 2.5. Some of course, still hasn't been added yet. So why don't we do what you are saying, make a new version of ZC with some of its intended functionality not working, but do get rid of the crashes and big bugs. Release that, and then finish the 10% functionality for another release. Because we all know that 100% intended functionality isn't coming for a long time. So why not split them up into 2 releases? It is just it has been 6, 7 years between a release. I don't think people would be mad about 2 releases as 1.92 183, 184, and 2.10 were pretty close to each other.

I just want there to be a good release so we can start uploading games like on PureZC, get some fresh games on there. I will help test it out to make sure the bugs are minimal if that is what we are aiming for. It is just, at this point, when I know things are still going to get added, it is hard to bug test for a stable release when additions are changing things. that's just me though.

I second what Shoelace implies.

He's right. People are looking for stability. Let them have it and take it from there. I can't imagine that it was this bad during the 193, 183, 182 era. Before 2.10.
By taking an insane amount of time to send one out, you risk losing the fanbase and spark new interest.

rocksfan13 wrote:I second what Shoelace implies.

He's right. People are looking for stability. Let them have it and take it from there. I can't imagine that it was this bad during the 193, 183, 182 era. Before 2.10.
By taking an insane amount of time to send one out, you risk losing the fanbase and spark new interest.

^^^ I 3rd it... BIG CAT DADDY knows where he speaks
;O)

franpa wrote:There are very few quests designed for the ZC beta's, you won't be affecting much by removing backwards support as there is already 2.10 for 2.10 quests, 1.92b183/4 and 1.90 etc. for there quests.

If anything, stability under modern O/S's is where the problem lies for legacy quests but for 1.90 there is always DOSBox.

edit: anyways that likely wont happen at all or any time soon so for now, I 4th Shoelace's idea.

edit: What I meant was to develop a program that aims to play quests from 2.10, 1.92 beta 184, 1.92 beta 183 and 1.90 reliably using the latest version of Allegro or whatever. The editor would have presets (like we have rule sets now) where you choose what version your quest is to be made for and the appropriate restrictions will be made, the outputted QST file will be 100% compatible with the original player as well as the new unified player.

The Editor can sport new things like Dungeon Carving and the large interface etc. and also fix the stuck midi note bug for 2.10 quests without destroying quest compatibility.

Then once that is done, develop a separate project aimed at being a generic game maker with scripting and other advanced features etc. and no compatibility with old quest files.

I 5th Shoelace's idea also. We don't care about features that are waiting to be added. All we want is a fresh stable release. My quest is temporarily on hold because i just became a bit lazy at keeping up with the changes, updating every beta, and rewrite certain scripts that broke due to certain changes in ZScript. Right now, 2.5 has features that are great and doesn't need any improvement for now. I'll gladly help beta test the program also as long as we know that we aren't doing it in vain. I'd say finish whatever's going to be added at the moment, release the builds, and us testers will give out reports on any bugs we encounter to smash most of the bugs in 2.5.

Just my 2 cents on it.

Here's my opinions on the matter:

-I'm still a bit sick of the bickering about the lack of a stable release, but I can understand where you all are coming from. I'm pretty sure the devs have a good reason for moving slowly, though...well, most of them.
-I'm getting sick of all this "YOU report the bugs, THEN we fix them". Aren't the devs suppose to look for the bugs THEMSELVES before releasing? I know these are all just builds, not big releases, but it still makes no sense to me at all. I would NEVER release something to people that had a glaring bug in it without trying to find if it's even in there, or even FIXING it. It does not. make. sense!
-Enough with the new ZScript commands! Don't we have everything we could possibly need in it RIGHT NOW?
-Finish up just the things that are unfinished, and add just one final thing: Sideview ladders. Oh yeah, sure, we have a script for it, but think of it this way: Does it really make sense to force us to script what should LOGICALLY already be built-in? Sideview isn't exactly good enough for the most part because it has no built-in ladders to climb up and stand on. (That's one problem I have with the script- you can't climb on top of the ladder and stand on it.) Doesn't that, then, make sideview incomplete? Just my opinion on it. (Besides, how hard could it be to add that kind of combo in?)

So yeah. I haven't given up ZC yet, but I'm going to have to agree that this has gone on long enough. We've got just about everything we need, why add much more past that sideview ladder? (And I still refuse to accept that we HAVE to use the sideview ladder script. That's just being lazy on your part, devs.)

pikaguy900 wrote:-I'm getting sick of all this "YOU report the bugs, THEN we fix them". Aren't the devs suppose to look for the bugs THEMSELVES before releasing? I know these are all just builds, not big releases, but it still makes no sense to me at all. I would NEVER release something to people that had a glaring bug in it without trying to find if it's even in there, or even FIXING it. It does not. make. sense!

Etc, etc.

It's not feasible to examine every aspect of the engine every time you do something. It would be like playing through your entire quest every time you fix a combo problem in Level 6. That would be madness! Fortunately, there's a lot more people using the program than developers, so the idea is that the masses, in their wild and varying use of the program, can test every aspect of it. If not every build, than every few builds.

THAT is how bugs are found.

More to the point, I am a terrible tester. At least 90% of the bugs on the forum are found performing activities that I never would think of trying out on my own. Furthermore, at least half the bugs I personally find are by accident.

Just because we're developers doesn't mean we're particularly good at bug testing.

Gah.. let's not get into a role debate. The betas were publicly released for ZCers to test. Simple as that. The most important task at hand is the lack of direction or a goal in general, which needs to be addressed now.

with all of that in mind then I think you all understand how I got to feel testing, you'd find a bug, report it, it was fixed, then back again a few releases later

Freedom wrote:with all of that in mind then I think you all understand how I got to feel testing, you'd find a bug, report it, it was fixed, then back again a few releases later

"Bug is STILL present in xyz."

Works for me 😊

they weren't "still" present, they were reintroduced in version after version after.....

I don't want to be a professional bug tester, I want to finish my quest, and a stable version is the best route for me to do that.
Then if it has a few bugs, I'll figure them out, work around them, and GET ER DONE.
That's all I care about doing right now, I have a set amount of time I can invest in my quest and I don't want that time going into countless releases that aren't intended to be considered as stable, been there done that, wasted 2 years, WON'T do that again.

As things stand right now, I'm working on my quest again, in the 1099, and I will finish it in the 1099 and release it in the 1099 unless a version is released that is considered to be a stable release, like 210 or 183 were.
If a release hasn't come by the time this quest is done, I'll know not to bother ever starting another.
This one has set in my computer far too long, and since it has about 2 years work in it then it really needs finished and released, but I won't go through this again with another one, with corruptions, and repairing and rebuilding and waiting....

Yes the best way to find bugs is to build quests using the beta's however there is no secure backup system implemented (something I suggested back a bit), so it is very easy to lose the entire project due to corruption etc.

Once the final build is ready, release a Release Candidate with the secure backup system changed or removed if you want and further test for regressions.

I use an amazing program to keep backups of all my important files I wouldn't want to lose. It's called copy-paste. Or if you use a usb drive it's worth the upgrade that includes the Drag-n-drop mouse functionmahandler majigger.

There is auto-save and auto-backup options in zquest last time I checked.

Yes, but the program has some way to access previously made files else how does it manage to corrupt them all? I remember Freedom saying that all his backups for a quest were corrupted.

http://armageddongames.net/showthread.php?44852-almost-bug-free&p=430975&viewfull=1#post430975

Maybe theres a hard coded limit or something and it started overwriting old ones at some point? kinda silly approach for beta testing builds.

how that happened to me franpa is I manually do my backups
I have 3 folders in my zc folder called back1,2,
as I progress I I save copies and over write the back ups in order.
what got me was combo corruption that didn;t show up in an area I wasn't working in.
another time it was freeform combos moving from one version to another.

It has never been so bad that it couldn't be repaired, but at what price.....

at the moment I have 8 backups of my quest just in the folders that I'm working on, and more back ups elsewhere

The point is, strange things happen and you never notice it for God knows how long.
I just added a sfx sound last night and noticed at some point that it removed the names of the ones I had added previously.
I had to click on all the sfx numbers and find them again and rename them, then I had to go back to an old version and see if I had just overwritten one with the new one I added.

For those who don't visit PureZC, am I am administrator over there. I have lurked here for a while, and I finally thought to register and share my thoughts on this very long term issue.

Yes, it has been about 6 years since the last "stable" release, which has been frustrating for plenty, so you have to admit that people have waited longer than they should ever be asked to wait. I also understand that developing is hard work, despite me having zero expertise in programming.

I hear plenty of discussion of staying the long course on 2.5 vs. continuing with something brand new from scratch (I will arbitrarily call this 3.0 for simplicity throughout the rest of my post). Some say it is best to stick with what we have, and some say to start over with a new foundation, and some say to wait to start anew until 2.5 is done. But that could be a long ways away, as we all already know. My question is this: Why can't both be done simultaneously?

I can understand there being some sort of "comfort zone" with the developers. 100% understood. Sure, we are in it waist deep right now, so lets just stick to 2.5 right now. Thus starting another project at the same time could be a confusing distraction. What I propose is that there could be two separate independent development teams. One team to continue working on 2.5, and another to start working on 3.0. Those who wish to stick with 2.5 can continue to do so, and those who are motivated to start with a new 3.0 can choose to do that. With two teams, this could also be an opportunity to add some new developers who are ready and rearing to go, especially for the 3.0 project. I have been around to know that there are people only interested in either one or the other, so why can't we let both sides have their way? I guess you can call it the Marge Simpson response to the matter. It could in fact bring forth some sort of friendly competition. Since both are being worked on, we could eliminate the "woulda coulda shouldas" of not going a particular way. At this point, what do we have to lose? If a stable 2.5 happens to get finished first, then that is still good for a 3.0 development, because at that point, while 2.5 is finished (or is hypothetically finished, by some good arguments), instead of starting 3.0 from the beginning, its development will have already gotten underway.

As long as there is a willingness to let both developments happen, there is a way to work on both at the same time. It is ultimately up to the more active developers in deciding if both developments can happen here. If not, then a 3.0 development could still end up happening elsewhere, either in another already existing ZC community or a brand new one. It would just have to take at least one developer to have the drive and motivation to start a 3.0 project and hire people to that team. I am not sure if a similar suggestion has ever been proposed, but I thought I would at least bring that sort of brainstorming to the table. It's better than just sitting here and recycling the same points everybody is making over and over again. Great minds talk about ideas before they ever talk about events or people. I figure that if both such developments could be worked on, with no one developer working on both, then there is at least a slightly better chance of something desirable getting done. And hey, a little competition just might be what the future of ZC needs. Economically, it works for capitalism, provided there isn't a monopoly. How could it all be organized? I am sure that could be worked out. Now that I got that across, I figure the least I could do is now listen to other people.

Nathaniel wrote:
I hear plenty of discussion of staying the long course on 2.5 vs. continuing with something brand new from scratch (I will arbitrarily call this 3.0 for simplicity throughout the rest of my post). Some say it is best to stick with what we have, and some say to start over with a new foundation, and some say to wait to start anew until 2.5 is done. But that could be a long ways away, as we all already know. My question is this: Why can't both be done simultaneously?

I can understand there being some sort of "comfort zone" with the developers. 100% understood. Sure, we are in it waist deep right now, so lets just stick to 2.5 right now. Thus starting another project at the same time could be a confusing distraction. What I propose is that there could be two separate independent development teams. One team to continue working on 2.5, and another to start working on 3.0. Those who wish to stick with 2.5 can continue to do so, and those who are motivated to start with a new 3.0 can choose to do that. With two teams, this could also be an opportunity to add some new developers who are ready and rearing to go, especially for the 3.0 project. I have been around to know that there are people only interested in either one or the other, so why can't we let both sides have their way? I guess you can call it the Marge Simpson response to the matter. It could in fact bring forth some sort of friendly competition. Since both are being worked on, we could eliminate the "woulda coulda shouldas" of not going a particular way. At this point, what do we have to lose? If a stable 2.5 happens to get finished first, then that is still good for a 3.0 development, because at that point, while 2.5 is finished (or is hypothetically finished, by some good arguments), instead of starting 3.0 from the beginning, its development will have already gotten underway.

You know, I actually think this is a GREAT idea, Nathaniel! My only worry would be the size of the dev team as a whole, though. Once 2.5 were to be completed, what would happen to the dev teams? Logically, they would be combined, right? But wouldn't that make the team too big? I'd hate for 2.5 to be finished, the teams combined to work on 3.0, and some people on the combined team be kicked off just because it would be too big...but at the same time, I can't say for certain that this could actually be an issue. :/ Either way, I really agree with this idea, and if the devs were to take you up on this, I'd trust them to find a way to make it all work so no one would have to be needlessly thrown off. Support++;.

Well, if that happened Matthew, that would in fact be a good problem to have, considering that at least something up to that point got done, thus at least the members are happy. The "too many developers" phenomenon would be something to worry about when that corner finally gets neared. You don't need to end up with twice as many developers as before. If the average developer was more motivated due to such planning, then in theory you might only need a few more. Who you need more of where all depends on who is willing to do what in the first place. Only hire more if you feel at any moment in the development that there is a demand for somebody else to join the team.

Sounds like a good way to get TWO incomplete projects to me.
I think they all should focus on getting this one stabilized and released yesterday.
STOP making additions to the scripting, and fix bugs period.

I'm pretty tired, so this post might be somewhat incoherent.

pikaguy900 wrote:Here's my opinions on the matter:
-I'm still a bit sick of the bickering about the lack of a stable release, but I can understand where you all are coming from. I'm pretty sure the devs have a good reason for moving slowly, though...well, most of them.
-I'm getting sick of all this "YOU report the bugs, THEN we fix them". Aren't the devs suppose to look for the bugs THEMSELVES before releasing? I know these are all just builds, not big releases, but it still makes no sense to me at all. I would NEVER release something to people that had a glaring bug in it without trying to find if it's even in there, or even FIXING it. It does not. make. sense!
-Enough with the new ZScript commands! Don't we have everything we could possibly need in it RIGHT NOW?
-Finish up just the things that are unfinished, and add just one final thing: Sideview ladders. Oh yeah, sure, we have a script for it, but think of it this way: Does it really make sense to force us to script what should LOGICALLY already be built-in? Sideview isn't exactly good enough for the most part because it has no built-in ladders to climb up and stand on. (That's one problem I have with the script- you can't climb on top of the ladder and stand on it.) Doesn't that, then, make sideview incomplete? Just my opinion on it. (Besides, how hard could it be to add that kind of combo in?)

So yeah. I haven't given up ZC yet, but I'm going to have to agree that this has gone on long enough. We've got just about everything we need, why add much more past that sideview ladder? (And I still refuse to accept that we HAVE to use the sideview ladder script. That's just being lazy on your part, devs.)

jman2050 wrote:...
It's sort of a "damned if you do, damned if you don't" scenario. I've been wanting to do this for a while now but there's always been hesitation because of how incomplete the current build is. If I recall we even made that option public to people, and based on the responses decided in favor of fixing up the current code base before doing anything else. Perhaps that ended up being a mistake.

Well then, screw it, I would be more than willing to start on a rewrite, but only if people would absolutely be satisfied with a new version of ZC that's missing 90% of its intended functionality but without random crashes and quest corruption bugs. I'd have to convince myself to do things that way.

Gleeok wrote:...Drag-n-drop mouse functionmahandler majigger.

On the topic of starting from scratch afterwards, and backward compatibility:

A new engine should not be any type of "clone". I'd ideally like to see a feature set more akin to AlttP, and the Gameboy games. Forget about "NES consistency". Why bother? ZC's GUI is fine. Especially with the way you can make multi layer combo macros now (like a tree). Forget awkward palette limits. Have one of them fancy huge global palettes. People can rip tiles, and essentially it'd be one 32,000 color palette. No recoloring necessary.

Backward compatibility. No. A new version should have nothing to do with the old ZC. Let players use the build the quests were meant to be played on (talking pre-2.5 here). If we ever get a stable 2.5, then sure, have those quests playable. "3.0" should have nothing to do with the old ZC.

Anyway, I'm tired. goodnight.

Well not every dev can work on the program at once. First, you have to want to work on the program, and secondly, you have to actually have time to work on it. Also there is the fact that learning the code to be able to fix bugs is a very time consuming process as well. I'm sure that during 2.10 development this was not so much an issue as it is now, as 2.5 is fairly bloated with lots of goodies all based off of code that was never designed for that aspect, hence the long development time. (Where is that 'pick two' programming chart? -That sums it up pretty well for a graphic.)
Right now we're offering our free time to try and fix these issues which is not always fun or easy. Bitching about how there were fuck ups years ago does not help us right now. Complaining about how the scripting engine took so much time is not going to help us right now.
What will help us right now is limiting the amount of time we spend investigating bogus bugs or bugs we can't reproduce or etc etc by specifying build, program, fullscreen?, large mode?, can be seen with a blank quest or default template? etc., or even just help clean up the bug forum so we can get a better view of where we stand right now.

Thus starting another project at the same time could be a confusing distraction. What I propose is that there could be two separate independent development teams. One team to continue working on 2.5, and another to start working on 3.0. Those who wish to stick with 2.5 can continue to do so, and those who are motivated to start with a new 3.0 can choose to do that. With two teams, this could also be an opportunity to add some new developers who are ready and rearing to go, especially for the 3.0 project. I have been around to know that there are people only interested in either one or the other, so why can't we let both sides have their way?

I can pretty much guarantee that if this happens a few things are going down:
-It will probably not use allegro. (I vote openGL with 'some other lib'.)
-It will in fact be a 32-bit color, 3D, Q-Bert clone!

Gleeok, that triangle was mine, but I can't find it right at this second. But, it went:

1. Features
2. Stability
3. Quick Release

Pick two.

Ladder: I spent a few hours the other day, trying to create a ladder combo. It was like pulling teeth. I got something that suspended gravity, but only as long as yoiu didn't jump on and then off it in one jump, which caused you to float.

I'm still not sure the best way to do this, yet...

New project: I don't think anyone understands the magnitude of difficulty in creating a brand new engine, especially one with LttP's features.

Don't get me wrong. As I said before, I'm down for it, and I have a good idea as to how to do stuff in a new project. But, I doubt we'd be looking at a release before 2013, even if we started this instant.

The new engine will not be backwards compatible with ZC. At all, in the slightest. Maybe, we could support tile and map importing, but that's it. I envision the new engine being very open, and where most interactible stuff in the game world is scripted (along with a large catalogue of pre-written scripts for things like push-blocks).

I see it as where rooms are not defined as chunks of "maps", but are arbitrarily sized maps in and of themselves, and are stitched together to create truely freeform dungeons.

Everything you know about how ZC works, drop it, it doesn't apply any more.

I see it as being an entirely new beast, working on which does absolutely nothing for the scads of quest designers working with ZC, so there's no point worrying about it now.

I agree with Freedom, get 2.5 finished before doing anything about a new program.

Gleeok wrote:I can pretty much guarantee that if this happens a few things are going down:
-It will probably not use allegro. (I vote openGL with 'some other lib'.)
-It will in fact be a 32-bit color, 3D, Q-Bert clone!

franpa wrote:
Do you mean 3D engine with 2D environments? or 3D environments? because we get enough 3D games from Nintendo as is.

edit: Plus..when I said 32-bit color, I mean you only get 32 bits worth of color. So you have to get creative with different ways of upacking it. That's hours of fun right there! 😃

Gleeok wrote:Neither. It will be a 2D engine rendering 3D environments. 😛

edit: Plus..when I said 32-bit color, I mean you only get 32 bits worth of color. So you have to get creative with different ways of upacking it. That's hours of fun right there! 😃

pkmnfrk wrote:
I see it as being an entirely new beast, working on which does absolutely nothing for the scads of quest designers working with ZC, so there's no point worrying about it now.

I don't quite understand why you think it's such a bad idea. Could you please explain? I honestly think this is the time to worry about it, since if it was done, 3.0 would already be in progress when 2.5 is finished, and if it's started NOW, it might even be far along. I could understand the worry of them both taking even longer to finish due to people having to split their time between the two versions, but Nathaniel's idea specifically said there'd be TWO dev teams, one for 2.5, one for 3.0. So what if it takes years? Most good things take a while to make, few exceptions. The sooner it's started, the sooner it can get done, right? The harder the team works, the faster it can get done! I just don't really see how this could be THAT bad of an idea...

pikaguy900 wrote:I don't quite understand why you think it's such a bad idea. Could you please explain? I honestly think this is the time to worry about it, since if it was done, 3.0 would already be in progress when 2.5 is finished, and if it's started NOW, it might even be far along. I could understand the worry of them both taking even longer to finish due to people having to split their time between the two versions, but Nathaniel's idea specifically said there'd be TWO dev teams, one for 2.5, one for 3.0. So what if it takes years? Most good things take a while to make, few exceptions. The sooner it's started, the sooner it can get done, right? The harder the team works, the faster it can get done! I just don't really see how this could be THAT bad of an idea...

That is, if we're doing it properly and having all the other stuff I mentioned. If not, and it really will be ZC 3.0, then having two teams would be utterly retarded, because we'd be working from the same codebase!

pikaguy900 wrote:I don't quite understand why you think it's such a bad idea. Could you please explain? I honestly think this is the time to worry about it, since if it was done, 3.0 would already be in progress when 2.5 is finished, and if it's started NOW, it might even be far along. I could understand the worry of them both taking even longer to finish due to people having to split their time between the two versions, but Nathaniel's idea specifically said there'd be TWO dev teams, one for 2.5, one for 3.0. So what if it takes years? Most good things take a while to make, few exceptions. The sooner it's started, the sooner it can get done, right? The harder the team works, the faster it can get done! I just don't really see how this could be THAT bad of an idea...

already been 6 years waiting for a stable release, and where you going to get all the people for these "teams", pull then out of yer azz?
I think it's a really bad idea.

The problem I see, with 2 teams, is that by the time one of the teams finishes, the other project might be so far along that it is nearly impossible to get familiar with.