Welcome to the ZDoom Forums!

... but much of it happened to be something I wanted to port myself for a long time but never managed. (meaning the MBF bouncing code.)

The largest influx of new features recently was the stuff adapted from my custom build, which was [i]not[/i] a code submission.

[quote="Graf Zahl"]I have to be honest here: I'm not too fond of the feature creep caused by code submissions recently. But somehow people seem to expect that if the code is available it's supposed to be added to the engine...[/quote]
I think everyone who has submitted code understands (or at least [i]should[/i] understand) that it's still a request and not an obligation for you or Randy to add it in within any kind of time frame, or even at all in the case the submitted code isn't stable enough or just doesn't cut it for some other reason. Maybe a notice on the code submissions forum reminding posters that while it is nice to provide code, there's still no guarantee that it's getting in would help to alleviate any impatience on the part of the posters.

The way I look at it, a code submission is exactly the same as a feature request with the requestor going to a bit more effort to increase the chances of it being accepted. Nobody should be demanding the addition of a feature when there are bugs or more important additions that need to go into an official release first.

Just badly written code.

What was causing this particular bug btw?

Noted. So no new features for the upcoming weeks - unless it's trivial stuff that's easy to verify.

I have to be honest here: I'm not too fond of the feature creep caused by code submissions recently. But somehow people seem to expect that if the code is available it's supposed to be added to the engine...

Anyway, I don't really see that many things that caused major changes. The 2 biggest ones in recent weeks were the ThingActivation feature and the extended MBF support - and these 2 are the only ones which I believe may be problematic. So far I haven't seen any problems though.

All the rest was trivialities or had no interactions with other code (e.g. new DECORATE or ACS functions.)


Regardless of all this I still think that a new release is necessary. The weapon code in 2.3.1 has some serious game breaking issues that IMO need to be addressed immediately, even if it may expose some insufficiently tested code to the public.

Well, I don't like doing releases unless the only recent activity has been bug fixes, and that most certainly has not been the case lately.

[quote="Xaser"]Though I suppose the SBARINFO rewrite is important enough to wait for... perhaps we should use that as the final point for release?[/quote]
I don't know. The new SBarInfo code is bound to be buggy so waiting until then would only delay the release further. Of course it seems to be doing fairly well since my thread about it has no comments.
[quote="Graf Zahl"]Don't tell this to me.[/quote]
Sorry if it wasn't clear, but my comment, like yours, was directed towards Randy.

[quote="Graf Zahl"]Remember, we can't fix what we don't know. Just saying that no recent ZDoom release was stable is not enough. We need to have precise information what to check.[/quote]Right. Well, that's kind of the point in trying to assemble a list. Tap the recollection of the ZDoom community, specifically the contributing programmers. What was being worked on recently? What was talked about recently that had some stuff added for it? Maybe some people want to look over the change list? And few extra brains and eyeballs should hopefully be able to come up with a reasonably comparable list.

Remember, we can't fix what we don't know. Just saying that no recent ZDoom release was stable is not enough. We need to have precise information what to check.

But one thing is clear if this is supposed to happen: A stop of adding new features that go beyond minor additions.

It would probably be a good idea then to come up with a list of everything that definitely could and reasonably should be stabilized or completed before an official stable release. If only to get a neat checklist that can be yay'd and nay'd and check in with multiple as to what's missing or not (and maybe draw our freelance contributors to some of those items).

[quote="Blzut3"][quote="Graf Zahl"]I think Randy should do another release.[/quote]
I would think releases need to become more frequent in general.[/quote]


Don't tell this to me. I'm in full agreement. 2.1.7 was fine because it was the eighth release within a relatively short time period. All following versions weren't frequently updated for fixes, 2.3.1 being the notable exception due to some really serious problems in 2.3.0 - but it still got some serious issues that make it unsuitable as a proper 'official' version - which mostly concerns the weapon slot code. Much of that only got fixed afterward.

On the other hand, stabilizing ZDoom would mean to discontinue adding the more complex feature submissions which are the main root of the stability problem. The improved morphing code is a good example for that.

If his SBARINFO still has some work left to go, I say update [i]now.[/i] Not to push anybody but it's been quite some time since the last update.

Once any rewrites are done, you can probably push another update out the door.

I agree, naturally. Though I suppose the SBARINFO rewrite is important enough to wait for... perhaps we should use that as the final point for release?

[quote="Graf Zahl"]I think Randy should do another release.[/quote]
I would think releases need to become more frequent in general. According to Torr Samaho, there hasn't been a version stable enough to synchronize Skulltag to since 2.1.7 (hence why we've been at odd revisions for some time now).