[Public Beta] Ultimate Simplicity (Episodes 1-4)

[HotWax]

Discussion is thrilling. There isn't anything quite like exploring views which are not your own.

That's valid. It's when the knowledge is not your own but you insist on arguing it that it begins to bother me.

Exchanging information with someone whose perspective does not exactly match yours. An admission that the world is inhabited by other people, and there is a need to discourse with them; to understand them. A forum happens to be a nice setting for that too, provided it doesn't dissolve into flame war drivel.

Again, discussion is a wonderful thing I tend to participate in quite often, but you won't see me discussing the merits of one type of automobile engine over another because this is a topic I have not bothered to become familiar with, and I wouldn't want to seem an ass trying to discuss things of which I know nothing. This is the mistake you seem to be making here.

Ok, let me try it like this. I'm maintaining that the flipside of "wait to develop it later" has its own problems. Taking it to the extreme, for the sake of example, would of course be developing and putting in all that you can, immediately, little bits at a time. The big problem is that there's no eye for design with regards to future development. What's going to happen is that you have a loosely tied together engine that lacks stability.

This would seem to be disproven by the fact that despite the addition of numerous features, ZDoom is one of (if not the) most stable source ports out there. It is very easy to code by adding "little bits at a time" so long as the project is being maintained in such a way that these bits are consistent and don't break anything existing. Most open source projects are developed by many different programmers and still manage to maintain stability.

Moreover, you're increasing your own workload as you'll have to constantly go back to old code and rewrite it to work properly with new things coming that you hadn't exactly planned for.

Show me one case where this occurred and didn't have something to do with Dehacked. If we were speaking more generally you might have a shred of a case. As it is I'm talking about a very specific and simplistic lump that would require no maintaining whatsoever once implemented.

This is especially true for a project like ZDoom, where there is a large degree of backwards compatibility to maintain. And this isn't just Dehacked we are talking about. With every new version, it seems to me, the developers are activately trying to make it so a map produced with any previous version of ZDoom will work in any future version. Admittingly it falls short in some areas; this is reality. But they're trying. This requires trying to maintain backwards compatibility with all features. So no decision to add or remove something should be taken lightly, especially if it's going to interact with other parts of the engine. If the extreme of waiting for DoomScript is death by development starvation, than the opposite side is death by a thousand development wounds.

Quit trying to play the backwards compatibility card. It doesn't apply here and nothing you're saying makes any sense.

To illustrate, let's say at some future point the HUDDEF lump becomes entirely unsupported. The side-effect is that the player can't select a custom HUD. The map will still function otherwise entirely as intended. And give me one compelling reason to cease support for a very simple lump. I can guarantee you that the difficulty of maintaining compatibility is not one such reason. It'd be like dropping support for LOADACS. Why would you?

So which way do we go here? Obviously not either of the extremes, but somewhere in the middle, and probably closer to one side than the other. I think holding off is the better choice. As suggested by Graf, there are some inadequacies in ACS, and another, more powerful language would do the job better.

ACS is a more powerful language than it was six months ago. It's far more powerful than the ACS Raven used to create Hexen. Why should Graf go to great lengths to design another language when ACS will just catch up with it eventually? Then you'd have two languages that are just as powerful, which creates redundancy. If anything, this is what we should be avoiding down the road.

We know something like DoomScript is coming. If we wait for that to begin to surface, and begin to get a better idea of just what it will be like, then we can start working on some kind of HUDDEF lump.

Really? Do we know that? Because I've been waiting for DoomScript for around 6 years, and I don't see any progress in its direction.

On the other hand, we already know that ACS works to create custom HUDs because it's already been done.

And why not add some kind of HUDDEF right now as a precursor?

It wouldn't be a precursor. It would be the HUDDEF we use now and continue to support in the future. If more features are needed down the road, it can be extended, it need not be replaced. Think about it: We have a lump named Decorate which does far more than let us define decorations. DoomScript might eventually replace it, but that's not a compelling argument for getting rid of it... or did you want to wait until you're 60 to play KDIZD?

There's a few reasons I think something like that shouldn't be done just now with ACS. One, as mentioned before, is backwards compatibility. It would have to be maintained.

Do we intend to maintain backwards compatibility with ACS? Yes? Then your argument just fell flat on its face.

This goes bad with the second reason: with not a lot to DoomScript (or some other language which would later be the focal point of a HUDDEF lump) right now, it's hard to tell just how a HUDDEF lump should be started.

No it's not, I just told you.

HUDs done with ACS may be done entirely differently in another language.

Redundancy. If it works, why break it?

We could wind up with something that becomes totally worthless as a starting point later on.

More likely we'd wind up with something that continues to work but is supplemented with more features as it's used and people come up with ideas for expanding it. See also: Decorate.

I don't think it's worth it to put it in just to make HUDs done with ACS scripting more easily togglable. This is a case, I believe, where a little bit of patience would serve us better in the end.

If it's not worth it, then why are there so many threads asking for how to disable this or that HUD, or to provide a better way for mappers to put optional HUDs into their maps? Why has Graf complained about people creating custom HUDs that can't be disabled? Since this is exactly what everyone is asking for, a method of easily toggling custom HUDs or selecting between multiple HUDs in a standardized fashion, and especially since the changes required would be so easy to code, I fail to see where you come up with the argument that it's not worth it.

[Nash]

I would definitely love the HUDDEF lump.

Right now I am doing tons of checks and drawing the appropriate graphics for every HUD possibility. Player is using statusbar? Is it scaled? Player is not using statusbar? Is it scaled? Player is using alternative HUD? Is it scaled? Player turned off HUD completely?

It's crazy!

[Zippy]

A whole lot.

Blast you! Don't make such long posts for lunch break forum checks! Now I don't have the time to answer. I'll get you next time, Gadget. Next time!

(Tonight, that is.)

[NiGHTMARE]

Wouldn't it be possible to have multiple ACS hubs selectable via a menu constructed with ACS (ala RTC-3057)?

If so, then a "hub resource WAD" should be possible even if Graf and Randy don't want to implement the HUDDEF lump.

[HotWax]

I assume you meant HUD, not HUB.

Yes, it's definately possible to construct a menu via ACS that would allow the user to toggle a custom HUD on or off, or even allow them to select from multiple HUDs. However, this is far from the optimal solution, for a few reasons:

1) It requires that each mapper that wants to do this provides the code to do so (reinventing the wheel) in every map they release.
2) It requires custom keybindings, which are overridden by the user's keys and therefore may have to be manually set for each map.
3) It would be a custom menu driven by ACS with no standard set of rules and no official support.
4) What Nash said above. Doing this for a single custom HUD is overly complex. Doing it for multiple HUDs would be an even bigger pain.

The proposed solution would be a menu inside the standard options area, navigatable by the user's chosen menu keys (by default, the arrows), and wouldn't require the mapper to provide the same code over and over again. Standardization, where possible, is A Good Thing(tm).

A "HUD resource WAD" would also be infeasible because, as Graf pointed out, there is currently no way to obtain all the information necessary to support custom weapons. You could make a HUD that works with Doom's standard inventory, or you could make one tailored to a specific WAD (which is what my idea would be designed for, at least until further additions are made to ACS), but under no circumstances is the intent here to provide a way to make a generic HUD that would work in all cases.

The entire point is that the custom HUDs present in (and tailored to) certain WADs cannot be easily disabled in many cases. The HUDDEF lump would provide a simple way to do just that, and down the road could be expanded to support more complex HUDs, eventually leading to the point where we can provide generic HUDs that could be used in most situations. This would be accomplished by extending ACS rather than coming up with a whole new language.

[Nash]

Hmmm... one thing, though. ACS has to be compiled... that would also mean that the HUDDEF has to be compiled.

Doesn't sound too productive...

[HotWax]

No, the HUDDEF would work similar to LOADACS. It would be a plain text lump that tells ZDoom what scripts or functions generate which HUDs. ZDoom would take these text entries and use them to form a menu. When the appropriate HUD is selected, ZDoom would then skip its internal HUD generation and instead call the specified script/function whenever the HUD needs to be updated.

At first glance, yes, this means the ACS behind the HUD will have to be just as complex. However, with the HUDDEF lump in place that would give us room to make further changes that would make life easier for people wanting to make custom HUDs.

For example, being able to specify separate scripts/functions to be run based on the user's settings, or automatic handling of the "HUD space" by ZDoom so that the settings are automatically incorporated into the HUD. (e.g. The ACS could just draw to a set region and ZDoom would automatically scale it (or not) based on the user's preferences.)

[NiGHTMARE]

While my proposed solution does have it disadvantages, the major disadvantage of HUDDEF more than makes up for them: namely that you're probably not going to get it .

[HotWax]

Just because Graf doesn't like custom HUDs doesn't mean randy wouldn't consider implementing the idea.

[Graf Zahl]

Let's see. Any good programmer should be careful when it concerns adding half-assed 'solutions' that later might turn into some ugly baggage that has to be maintained.

ACD HUD messages are not particularly good for drawing HUD overlays anyway because they are far too expensive. To draw a HUD some more direct means are necessary and ACS does not provide them.

[Zippy]

Alrighty. We're hitting on a lot of the same issues, but here goes:

backwards comptatiblity issue

But it is an issue here. It's an issue with every feature of the engine. Certainly some more than others, and many to a negligible degree, but it still is. When you add a feature to the engine, and you want maps that use that feature to work in future versions of the engine, the feature must be maintained to properly work with each revision of the engine, from here unto infinity. That is backwards compatibility. It most certainly wouldn't be a negligible case here if a HUDDEF lump was added to work with ACS, because later on if a reasonably different (and hopefully) better way to do it comes about, then you're going to have to go back and toy with it so they both work. It could be done, sure, but my biggest point is that it has a good amount potential to be a pain in the ass in the future, for not enough gain right now. Also, when you talk about it you seem to be oversimplfying the issue. Just because it would be just a single lump like LOADACS doesn't mean that there doesn't have to be several things in place to make it work under the hood. It's all the more problem to consider if we hope HUDDEF to work with something like DoomScript; we'd want to set it up so that assembling the DoomScript pieces with it, as they become available, would be simple and easy. But, as said, I don't know enough what DoomScript will be, and I'm not sure how much is theory in Randy's head, design on paper, and raw basics already implemented to make it worth starting on a HUDDEF now. DoomScript, however, I'm pretty sure is coming. With all the speed of snail to be sure, but as you've fondly pointed out... little by little it's going to make its way in. Once we get our feet wet with even the basics of it, we'll have a much better idea of how to start something like a HUDDEF lump.

ACS is good stuff

Indeed it is. And it is certainly becoming better and better as time passes. But it still has its share of fundemental weaknesses. Things, as pointed out, such as no dynamic string support, and the fact that it has to draw through hudmessage commands, etc. Some of these are issues down at the very core of ACS, and would take a lot of work to overhaul. If we already have another language which would more powerful than ACS could ever be without some serious redesign making its way down the pipeline, it certainly doesn't make sense to start seriously reworking ACS. So, we could start a HUDDEF with support for the current ACS knowing it's limited, but the point is: why bother? It would have some, but only a little bit, of benefit now for a reasonable risk of a bunch of pain later.

HUDs done with ACS may be done entirely differently in another language.

Redundancy. If it works, why break it?

Don't break it. Do it differently, in a better way.

Final point:

Again, discussion is a wonderful thing I tend to participate in quite often, but you won't see me discussing the merits of one type of automobile engine over another because this is a topic I have not bothered to become familiar with, and I wouldn't want to seem an ass trying to discuss things of which I know nothing. This is the mistake you seem to be making here.

Being that it is a discussion, the burden of proof is on you to show that I don't know what I'm talking about. Admittingly a hard thing to do because clearly your base opinion from what you've read so far is that I don't, making the problem that you'd have to find some actual way to show. Reversing it, I'm sure I couldn't find a way to show that you don't know what you're talking about because I certainly think you know enough. The problem is that we operate on such radically different frequencies. For example, it confuses me slightly that you don't seem to understand the point about backwards compatability. That's probably not the case though. You probably do understand it, just in a much much different way, significantly more different than ways that I have even considered it in. That's what makes some of the talk so awkward sounding sometimes. It's fun though, because I never know what you're going to say next, and any predictions are way off.

[Graf Zahl]

Being that it is a discussion, the burden of proof is on you to show that I don't know what I'm talking about.

He can't because you are absolutely correct. Obviously HotWax doesn't really see the developer's side of all of this correctly. And that is:

- HUDDEF would be a hack
- HUDDEF would suffer severely from ACS's limitations and to make it more useful new ACS features had to be added
- Once real HUD scripting is in place it will only become some ugly baggage that will hinder true progress.

There have been previous occurences of such designs. A few examples:

- Before redoing the inventory system Randy added some code to SetPlayerProperty to give and take powerups. Now that code is deprecated and has to stick around for backwards compatibility. Fortunately it's only one function but it got thoroughly broken and had to be fixed after the inventory rewrite.
- There's several quick'n dirty code pointer addiions in DECORATE for 2.0.96x. Again, they have to stay because they have been used. To be honest, there's a lot of stuff in DECORATE that I'd dump if I could but thanks to it being used it will continue to bloat the code. (Guess, why I 'no' most of the more specific code pointer requests!)
- One thing that did not get into the final code (fortunately) is the original 'Pickup' and 'Use' state design which wasn't particularly well designed. If we had added that to an official build in the beginning we'd have some problems now.

Seeing that HUDDEF precisely falls into this category of things I hope even HotWax can see that it's not a good idea to do this with a cheap shot.

One more thing: Once Randy has a DoomScript compiler/interpreter in place I promise that HUD support will one of the first things to be added.

[Nash]

Okay Graf, I'll take your word for it.

Hopefully DoomScript will come before the icebergs melt and submerge the entire world underwater.

[Alterworldruler]

Okay Graf, I'll take your word for it.

Hopefully DoomScript will come before the icebergs melt and submerge the entire world underwater.

and before hell frozes over

[HotWax]

But [backwards compatibility] is an issue here. It's an issue with every feature of the engine.

So in your opinion the ability to spawn the player into a map requires maintaining for backwards compatibility purposes?

You need to clarify what you're talking about when you speak of this issue. To me, backwards compatibility is more like what Graf was speaking of -- a feature that has now been deprecated but requires effort to maintain in order to allow older WADs to continue to function unchanged. Dehacked is a great example of something that requires regular maintainance for the backwards compatibility to be maintained. While it becomes a pain alot of the time, randy still makes an effort to maintain it as many levels, including some made for ZDoom, rely heavily upon it. On the flipside, demo playback is something randy makes no attempt to maintain because it would be very difficult to do and doesn't give us enough gain to justify it. HUDDEF is a very basic text lump requiring no maintainance to maintain, and because the HUDs would be drawn with ACS, which does not fall under the category of requiring backwards compatibility, there is no effort to maintain compatibility with it in the future. This is nothing at all like the Use and Pickup states Graf speaks of. The HUDDEF lump can easily be extended if and when a better language for actually drawing the HUDs becomes available. In the meantime, it can be made to work with ACS just as easily.

Also, when you talk about it you seem to be oversimplfying the issue. Just because it would be just a single lump like LOADACS doesn't mean that there doesn't have to be several things in place to make it work under the hood.

This is a great example of proof that you don't know what you're talking about.

This is what is required under the hood (as I've already stated multiple times):

1: ZDoom reads the HUDDEF (text) lump upon loading.
2: ZDoom creates a menu with a list of the "nice names" of the HUDs given in HUDDEF. This menu could go anywhere at all. We have a previous example of ZDoom using dynamic items via the KEYCONF lump, so this is not something that would be hard to implement.
3: In the rendering code, where normally the HUD is drawn, there is a simple check to see what (if any) custom HUD is selected. If so, the rest of the HUD rendering code is skipped (this already occurs when the HUD is disabled due to maximum screenblocks, and thus would not be hard to implement), and an ACS script/function is executed based upon the HUD selection. Executing an ACS script/function is not a difficult matter to code in by any means, as the engine does it regularly.

Your insistence that this would be hard to code or maintain proves that you don't know what you're talking about. I could do it myself given a little time to poke around in the source looking for where changes need to be made, but I'd rather not waste my time doing that when Graf will just refuse to merge my changes into the source. However, once implemented, it should never have to be revisited, and therefore does not qualify as something requiring maintaince for backwards compatibility.

It's all the more problem to consider if we hope HUDDEF to work with something like DoomScript; we'd want to set it up so that assembling the DoomScript pieces with it, as they become available, would be simple and easy.

This would be a piece of DoomScript that would become available the moment it is implemented. Since DoomScript will need the ability for the user to specify custom HUDs, this lump would just plug in and serve that purpose once Hell freezes over and DoomScript magically materializes.

But, as said, I don't know enough what DoomScript will be, and I'm not sure how much is theory in Randy's head, design on paper, and raw basics already implemented to make it worth starting on a HUDDEF now. DoomScript, however, I'm pretty sure is coming.

Yeah, just like Jesus is coming.

With all the speed of snail to be sure, but as you've fondly pointed out... little by little it's going to make its way in. Once we get our feet wet with even the basics of it, we'll have a much better idea of how to start something like a HUDDEF lump.

How about by making a lump with a basic list of HUDs which would be available for selection by the user? Hey, that suggestion sounds familiar.

ACS is good stuff

Indeed it is. And it is certainly becoming better and better as time passes. But it still has its share of fundemental weaknesses. Things, as pointed out, such as no dynamic string support, and the fact that it has to draw through hudmessage commands, etc.

All things that can be added to an existing language like ACS more easily than designing an entirely new language (reinventing the wheel) to do this in addition to what ACS can already do.

Some of these are issues down at the very core of ACS, and would take a lot of work to overhaul.

Says who? You start pointing me to locations in the source that would have to be reworked, and then I'll start blindly believing like you have a clue what you're talking about.

Any effort put into designing an entirely new language would be better spent updating ACS. It'd be easier and more fruitful. Why make a second language when the one you've got is already so powerful?

If we already have another language which would more powerful than ACS could ever be without some serious redesign making its way down the pipeline, it certainly doesn't make sense to start seriously reworking ACS.

Then why did we start? ACS is nothing at all like it used to be when it was designed for Hexen. There have been a number of fundamental changes and thanks to them, ACS is far more powerful than it has even been before. It is continuing to evolve and change as more advanced features become available. I fail to see the logic in abandoning a language that randy has spent years enhancing.

So, we could start a HUDDEF with support for the current ACS knowing it's limited, but the point is: why bother? It would have some, but only a little bit, of benefit now for a reasonable risk of a bunch of pain later.

Here the burden of proof is on you. I see no reason why there would be any risk later. It'd be different if I was asking for a half-assed scripting language that would be obsolete when the sun explodes and DoomScript is created, but that's not what I'm asking for. I'm asking that we continue to support ACS, which I'm going to reasonably assume is the plan. I further ask that a simple text lump be created as a precursor to JesusScript that allows us to use the ACS we've already got, with the understanding that at some point in the future (2215 or so) DoomScript will magically descend from the heavens and extend it to be able to do more.

HUDs done with ACS may be done entirely differently in another language.

Redundancy. If it works, why break it?

Don't break it. Do it differently, in a better way.

But you know that's not what Graf is suggesting. Graf is suggesting we don't do anything at all, and wait for the glory of DoomScript to awaken us in a Time of Great Need before we do anything to touch this code. I love how he proffers it up like some unreachable golden chalice, knowing damn well it's a promise he'll never have to keep because DoomScript will never happen.

Being that it is a discussion, the burden of proof is on you to show that I don't know what I'm talking about.

That doesn't make any sense at all. The burden of proof is on you not to show you're making stuff up. I've already pointed out several instances where you're doing just that. The only reason Graf is siding with you is that he doesn't like custom HUDs and therefore doesn't want this change made. You're doing a great job of being his advocate just by inventing arguments to counter mine.

For example, it confuses me slightly that you don't seem to understand the point about backwards compatability. That's probably not the case though. You probably do understand it, just in a much much different way, significantly more different than ways that I have even considered it in.

Yes, a different way. I understand it via a method I like to call "Programming experience." You understand it through the wonders of "Stuff I invented one day while I was visiting the Land of Imagination." Clearly these are separate but equal views.

That's what makes some of the talk so awkward sounding sometimes. It's fun though, because I never know what you're going to say next, and any predictions are way off.

I can help you with that. It's called Logic. Look it up.

- HUDDEF would be a hack

Then LOADACS is a hack.

- HUDDEF would suffer severely from ACS's limitations and to make it more useful new ACS features had to be added

This has already been disproven by WADs (such as this one) that already successfully create a custom HUD via ACS. I'm not saying that more features couldn't be added to support being able to do more with the HUD, however if we never have custom HUDs to begin with, we'll never know what features to ask for to extend support. Even if no other features were added to ACS, however, this would be enough to provide HUDs created specifically for a given map that could easily be turned off by the user -- and that is the entire reason this suggestion came about in the first place.

- Once real HUD scripting is in place it will only become some ugly baggage that will hinder true progress.

So will ACS, so why is it there? By comparison a tiny text lump (and more importantly, one that could be used with the new scripting language and thus maintain its own usefulness) would be a tiny speck at best.

(Guess, why I 'no' most of the more specific code pointer requests!)

The pattern I see is that you 'no' whatever you believe is being used for a purpose you don't find worthy and you add whatever you believe to be useful, regardless of how specific a code pointer it is or how difficult it would be to implement or maintain. Adjustable mass is a great example -- it would not be hard to implement as the code is already in place. It is not specific as it could be used for many different purposes, many of which could serve to enhance Doom itself, however because it was brought to you in the context of a modification you don't personally like (as you stated in the very thread it was suggested in), it gets a 'no'. As I've pointed out before, it's your right to 'no' whatever you don't want to work on, however please don't claim you're doing so because of issues such as this.

Seeing that HUDDEF precisely falls into this category of things I hope even HotWax can see that it's not a good idea to do this with a cheap shot.

HUDDEF would not be a "cheap shot". It would be a basic text lump to define HUDs that could be extended when DoomScript becomes available (read: never) rather than fading into obsolesence or becoming a burden to maintain support for.

One more thing: Once Randy has a DoomScript compiler/interpreter in place (never) I promise that HUD support will one of the first things to be (never) added.