Welcome to the ZDoom Forums!

2. ZDoom has been beta since 1.23.

I assume the next version is simply not ready for beta testing yet.

Don't assume - it makes an Ass of U and Me!

Don't jump to such a conclusion without a look at the evidence. The test source from August was perfectly ready for testing so 4 months got wasted by now.

Hirogen2 wrote:2. ZDoom has been beta since 1.23.

That depends what you consider a beta. The current versions are neither called or considered such. ZDoom is in such a state of flux that there is no point to declare any version more finished than the previous (or next.)

Graf Zahl wrote:Right now Randy is sitting on a huge change to the code apparently without any intention to release it any time soon. In August he did an unofficial source release but since then he released 2 new versions of ZDoom still based on the old code.
And since he is doing even more changes to that unreleased code I fear that a gigantic problem is arising.

Geez. You don't need to be so negative. I've barely touched that code since then because I've been too busy fixing bugs in the fixed point code trying to get something considered "stable." Applicable bugfixes have also gone into the 2.1.0 tree, but there have been no new features added to it since that source release. So what you have from fptest is still basically what I have. Hopefully once 96x features are integrated, I'll get back to 2.1.0 again.

randy wrote: Geez. You don't need to be so negative.

Sorry, I am getting a little frustrated. Working with code that I know will be obsolete rather sooner than later is not particularly motivating.

I've barely touched that code since then because I've been too busy fixing bugs in the fixed point code trying to get something considered "stable."

See, that is what I don't understand. Why don't you release a floating point version and work to make that stable? In the end it would be much less time consuming than handling both code bases at the same time. From my tests the FP-test version seems quite stable already and I even got a GZDoom version working with the code (which obviously has become obsolete in the mean time ) so why not release it and iron out the bugs that are in there?

Hopefully once 96x features are integrated, I'll get back to 2.1.0 again.

Is there really any point in doing so?

I can sort of see the logic of why you would want to fix the bugs in the non-floating point version, as i assume it gives randy a batter base of reasoning when trying to slove bugs using the floating point math version. Not to mention it will probabily be another massive number of "beta builds" until zdoom is declared "stable enough" for an offical release (remember each one of these 2.xx builds is still a "beta").

But i am no programmer, so one fix for the non-floating math version will not necessarily be the same fix for the floating point type. Thus, you will have to re-fix the same or similair parts of a bug that has already been squashed.

But look at the bugs in the forums. Honestly, what are the worst one that are still present? As far as i have read and understood, there are a set of random crashes, graf-zhal found crashes or problems (that almost always include a fix), and then just every little inconsistency that deathlike2 can possibly find. To be honest randy, the entire community has been pretty confused about your agenda after you released .96.

I understand that it takes a lot of modivation to make it through the hard spots of any project, and that zdoom right now is going in a lot of different directions because of what you plan on doing with the code, but i honestly feel that it is time to prioritize.

What do you still want to do before working on the floating point math version? Is zdoom really that unstable?

randy wrote:Oh, yeah, stuff from 2.0.96x is in the pipe for inclusion with 2.0.99. I even decided to include support for Pickup, Drop, and Use states, but only if you inherit from CustomInventory. Combined with being able to have autoloaded ACS libraries, that should hopefully cover everything you would want to use them for, even if they won't work if you inherit from existing items.

What does this bit mean? Does that mean that clones of the Hexen inventory items that have altered properties (eg. max amount) won't work anymore unless you create them from scratch? (which I'm not sure is possible)

That's excactly what it means.

So something like this wouldn't work anymore?

That restriction only affects the Use, Pickup and Drop states. Your examples will still work.

What this sounds here is the need for some source control software of some kind. Or maybe I misunderstand.

Yes, some SCCS would be needed. But given that Randy did not use one in the last three years, I doubt that is going to happen any sooner now that someone else besides me raised concern.

Is possible new map format which allows more advanced functions like chained linedefs like door and crusher at the same time

and is possible to make vertical bounce on ceilings and on floor like shooting BFG at the ceiling next bfg bounces off ceiling

You can do that with ACS