almost bug free?

[pkmnfrk]

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

Then bitch repeatedly.

"Bug is STILL present in xyz."

Works for me :)

[Freedom]

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

[Nicholas Steel]

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.

[Gleeok]

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.

[Nicholas Steel]

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/showthrea...l=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.

[Freedom]

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.

[Nathaniel]

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.

[Nimono]

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

[Nathaniel]

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.

[Freedom]

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.