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

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49094
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

ACS is far too limited. For example, you can't retrieve the ammo a weapon uses - and you can't retrieve all the valid weapons so way to much had to rely on guessing. I don't consider this a working solution.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

All of this could easily be remedied via new ACS functions (including some that are specific to HUD scripts) or extensions to existing functions. It still beats coming up with a whole new HUD scripting language.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49094
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

No, it could not. Not unless full string support was added.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

IMO, it'd still be better to have a semi-working solution than none at all. If full string support was added for some other scripting language, it'd make sense for ACS to get it anyway, and when that happens the two languages would become redundant. At the very least this could be used to quickly and easily port HUDs over from existing mods that already use them, immediately giving them official support and the ability for the user to choose between the custom HUD and the standard one.

Even if this couldn't yet be used to make generic HUDs that could be used anywhere, it would still be useful to make HUDs specific to the project they're designed for, which is what the point of the conversation was.
User avatar
TheDarkArchon
Posts: 7656
Joined: Sat Aug 07, 2004 5:14 am
Location: Some cold place

Post by TheDarkArchon »

Does "semi-working" include the inability to check the ammo type properly? Because that is what it would involve.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

"Semi-working" means the custom HUDs that are already possible and in use in certain mods (such as this one) would work just as well as they do now, but would be selectable by the end-user.

New functionality can be added later. Right now all I'm suggesting is a way to provide the existing functionality with the automatic benefits provided by a selectable HUD interface.
User avatar
DoomRater
Posts: 8265
Joined: Wed Jul 28, 2004 8:21 am
Preferred Pronouns: He/Him
Location: WATR HQ

Post by DoomRater »

Not to talk about how useful full string support would be (because who wants to write it?), but I'd love to see custom HUDs.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49094
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Semi-working is enough to not make it an official feature. If we'd do ZDoom would quickly degenerate into a hack-job. Not with me.
User avatar
Cutmanmike
Posts: 11338
Joined: Mon Oct 06, 2003 3:41 pm
Operating System Version (Optional): Windows 10
Location: United Kingdom

Post by Cutmanmike »

What is wrong with the old HUD :?
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Post by Zippy »

I agree that with this case it is better to hold of out for a full complete solution later on in the future than get a temporary "fix" soon. Partial solutions implemented now means that they have to be maintained into the future for backwards compatibility, which is a pain. It certainly isn't worth it in this case. It isn't really that bad right now, in so much as if an author neglects to make a custom HUD togglable and you really can't stand the HUD, you can still dive in and make the change yourself. Even if the plaintext scripts lump(s) are not included, there is still the chance you could pull one over on them and replace all their HUD graphics with invisible ones (and restore the original status bar graphics if need be.) It seems to be too much trouble to implement a partial solution for something which isn't that big of a problem.
User avatar
Ryan Cordell
Posts: 4349
Joined: Sun Feb 06, 2005 6:39 am
Preferred Pronouns: No Preference
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia (Modern GZDoom)
Location: Capital of Explodistan

Post by Ryan Cordell »

Cutmanmike wrote:What is wrong with the old HUD :?
It gets boring after a while, already did we me. I still accept new skins even, just to get away from the normal, original one that iD drew.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

Zippy wrote:I agree that with this case it is better to hold of out for a full complete solution later on in the future than get a temporary "fix" soon. Partial solutions implemented now means that they have to be maintained into the future for backwards compatibility, which is a pain.
I am talking about what is already there and available for use, which has to already be maintained for backwards compatibility, and isn't a pain because it uses standard ACS functions that should be around forever.

The only additional feature is a small lump similar in concept to LOADACS would which specify which scripts or functions to use as HUD displays. This wouldn't be a pain to maintain compatibility with because it would be useful forever and would merely be extended as further features are added.

As I've said before, if we go with the attitude of "I can't make it work 100% the way I want to now so I'm not going to change anything" then we'll have no progress on ZDoom. Why were custom classes added before all the features that were necessary to support them were available? Why was Decorate created but only made to support very simple decorations (hence the name) when randy could have just waited for DoomScript? Progress doesn't happen in giant leaps, it happens a little bit at a time until before you know it you've created something completely new, one piece at a time.

Or to be more cliche, "A journey of a million miles begins with a single step."
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Post by Zippy »

To go a million miles, all you need to do is walk. The case isn't quite as simple here.

On the outside it looks straightforward. An extra lump that just does some organization and creates a list of available HUDs based on some scripts yadda yadda yadda. It's the inside, however, where compatibility has to be maintained. Once you put that lump in and tie it to ACS internally in the engine, it has to remain that way for the rest of development to maintain compatibility, even if DoomScript were to come along and make the same process 1000% easier and more efficient. Rather than forcing this upon ourselves now over something which is admitting pretty trivial at the moment, we can just wait for a much better solution to become possible as DoomScript comes along.

This isn't "I can't make it work 100% the way I want now so I'm not going to change anything." This is the knowledge that beginning right now with what we have would be a poor first step towards the process of making definable custom HUDs. With a little patience, we can hold off for a little while, and when the time is right, then we can start taking baby steps towards some kind of HUDDEF lump. The point is that the time to lay down the first piece isn't now.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

Zippy, why do you insist on arguing about things you don't understand?

Graf's issue is it would require alot of work to come up with a full-fledged scripting language that would support all the things needed by a custom HUD. My suggestion is that rather than come up with another language (or, far more likely, not come up with anything), we just extend ACS and use it to draw the HUD. People are already doing this with great success, but it has the negative side-effect that the HUD is typically impossible to disable unless the author goes to great lengths to provide a method of doing so. This is a simple lump that would allow a custom HUD official support, and therefore an easy ability for the user to turn it off. That is all. No complex features that will break any backwards compatibility, or that will require any extra code to ensure backwards compatibility. The only major stumbling block in that area so far dealt with is Dehacked compatibilty, and that is because Dehacked is a complex language used to directly hack the original executable. Maintaining compatibility with Dehacked is problematic because it does such direct modifications that are expected to work a certain way. When new features or fixes are put in, alot of these modifications (read: hacks) break down and cease functioning. This makes certain levels unplayable, and that is why maintaining backwards compatibility is something of a priority (even if at times there's nothing randy or Graf can do to ensure it). With this lump, that does no direct modifications and that specifies no complex language, maintaining compatibility would not require any work on the programmers' part. Further, if compatibility were to be dropped at a future point, it would still require no work on the programmers' part, and it wouldn't break anything major. A fix would be as easy as an ACS_Execute on the HUD script that is now no longer being called by HUDDEF.

Throughout ZDoom's development there have been countless features that have been added, despite the fact that DoomScript would arguably be a better place for them. Thanks to going ahead with the changes, we can now define new actors with almost limitless freedom, and more features continue to be added a little bit at a time. If we had maintained the attitude of "WFDSROFLZ" instead of implementing these "incomplete" changes one at a time, we would be far more limited in what we could do today.
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Post by Zippy »

HotWax wrote:Zippy, why do you insist on arguing about things you don't understand?
Discussion is thrilling. There isn't anything quite like exploring views which are not your own. 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.
HotWax wrote:a big honking paragraph, followed by a conclusion
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. 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. 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.

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

And why not add some kind of HUDDEF right now as a precursor? 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. 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. HUDs done with ACS may be done entirely differently in another language. We could wind up with something that becomes totally worthless as a starting point later on. 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.


Now then... I should probably actually get around to playing Simplicity. Seeing as we've soiled its shrine by making it a field of battle, I think I owe AgentSpork something.

Return to “General”