[Please split to threads] Several feature requests

Moderator: Developers

Several feature requests

Postby Bubuche » Mon Sep 11, 2017 6:57 pm

Hello everybody.
I did some things with gzdoom builder and slade, made a map etc.
Here is some requests, for past and present problems I met.

  1. SetLineTexture : the first parameter is the line tag. However, you can't use "0" to indicate "current line". It just doesn't work. Same goes for several other function working on line, so here are two solutions:
    1 - "fix" all of these functions, make 0 means "current line" and basta. It may break compatibility however, as you can imagine a code where the "id to change" is determined with a switch, with the value "0" in default (to cancel the action). So, let's go to solution two :
    2 - Create a function like "GetCurrentLineTag". that will return a line tag for the current line. To make this perfect, the function should take a parameter (optional, default to false for example) indicating whether a tag should be created if there isn't already one on the line. Yes, it means dynamically create a tag, which create other problems I think. But this solution is the least prone to create bug, as as long as you don't call it, it does nothing (so existing map will not break).

    Why someone would need such a function ? Well, we are happy to be able to create door without needing to add tag to every door. But if we want to change the texture of the door while it's open, we can't do it without a tag.
    (we CAN do it with a tag : open the door, change the texture, wait the sector becoming idle, change the texture back).
    You would also be able to create "breakable screen" (like in strife) very easily, just by attaching the script to the texture without create a tag and passing it as a parameter.
  2. 3d Model in wad.
    I DID read topic about this. Especially this one:

    The answer is :
    Graf Zahl wrote:The reason is that without a decent naming structure using models degenerates into a total mess very quickly. Referencing skins in a totally unstructured resource is messy at best and impossible at worst.

    Which is a perfect answer. However, here is my suggestion : what about a lump (in the .wad) which would be a zip. Or a 7z, or a tar.gz. it's not the point of my suggestion. With that, you can have, in this lump (which is a zip), the md3, the texture and everything else you want. Like a self sufficient lump which define a model.
    There is a lot of proprietary format which has this kind of "everything bundled in one file" aspect.
    Well, i need that to make a statue, but ... other people may need it, yeah ? :D ... no ? ...
  3. inline functions (it maybe already exists, shame on me i didn't check)
    I do know that you can't "wait" in a function (I am talking about ACS). And the reason for this is not hard to understand : everyframe, when the "script" step is over, every script are either over of in "sleep" mode, but all of them are at "level 0", there is no stack. And, big advantage, there is no stack to store in the save file, only the "pointer to next instruction" and "what does this script is waiting for".
    This make perfectly sense for mathematics functions. cos(pi) is a synonym for "-1" it would not make sense to "wait". However, we, computer scientists, love to use function to factorize the code, to "name" thing and, somehow, comment the code.
    The inline function would solve this problem. What is an inline function ? It's pretty much like a "define" (a bit cleaner, however). It's a piece of code somehow copy-pasted where the function is called, at compile time. From the VM point of view, it doesn't even exists.
    There is technical limitation, like you can't do recursive inline functions. But nonetheless, without modifying the VM byte code, it would be something nice to add. And it wouldn't break compatibility.
  4. Draw to texture.
    Well, this one has been asked already several time, I am just "pushing" the request. We can draw to the hud, but we can't draw to a texture the same way. It would allow both optimized view (as someone would be able to draw to the texture once and then display the result (the texture, the "cache") on the hud many time) and in-game screen. I am really fond of in-game screen (way too much) :P . And with that we would be able to play soon to doom in doom, as I have no doubt that someone would then port the original doom code in acs and render it to a texture. Doomception !!!
  5. "vertical filtered interaction".
    I don't know how to call this one. If you have two interactive linedef in front of you (for exemple a stairs where every step is an interactive line : you can have 2 or more line close enough to you for activation), only the closer will receive the interaction, right know. There is a checkbox saying something like "check vertical blabla for interaction" but it doesn't work. It seems that this checkbox mean "check the player is not too high or too low for interaction".
    What I am talking about is ... raycast (only a single raycast from the center of the camera, nothing cpu/gpu intensive).
    What is the advantage of this ? You would be able to have a wall (a screen, whatever) with many interactive buttons. For example, the digital code of a door, or the buttons of an elevator (yes, it's where I met this problem).
  6. Add information at runtime on linedef.
    Well, it's close to the "add tag at runtime". Right now you can't "decorate" linedef to keep trace of a previous interaction.
Joined: 06 Jun 2016

Re: Several feature requests

Postby Rachael » Mon Sep 11, 2017 7:19 pm

Combining multiple reports, issues, or suggestions into a single post is never a good idea, and it is a nightmare for devs to track. While it may be a good idea to group together feature suggestions which are very closely related, these clearly aren't.
User avatar
QZDoom + Webmaster
Joined: 13 Jan 2004

Re: Several feature requests

Postby Bubuche » Tue Sep 12, 2017 6:38 pm

Hmm ok, I can understand this position.
But try to understand mine : I am a newbie here. If I make 6 topics with request for features, I'll just get a big "stfu, noname".
You can lock this topic (you don't need my permission ^_^) I'll post again these suggestion, one by one, with one or two day between each.

(And I could also have had an answer like "no, no, no, already done, no, no, already in dev. Thank you, 'nice day")
Joined: 06 Jun 2016

Re: Several feature requests

Postby Graf Zahl » Wed Sep 13, 2017 2:15 am

And 6 in one will get it closed outright, as you see, because we cannot work with that.
User avatar
Graf Zahl
Lead GZDoom Developer
Joined: 19 Jul 2003
Location: Germany

Re: Several feature requests

Postby Bubuche » Wed Sep 13, 2017 7:18 pm

Ok, no problem please close it. Please.
I mean : I can't close it myself (I don't have the power to do that, it seems). I would already have done it if I was able to.
Joined: 06 Jun 2016

Re: Several feature requests

Postby Rachael » Wed Sep 13, 2017 7:36 pm

Most people don't need us to arbitrarily "close" (or as you seem to want, for us to lock) threads just because they become uncomfortable with the responses. But keep in mind such responses are meant to be helpful - so please don't be so nervous about them.

We aren't judging here. We're just telling you that we can't manage 6-in-1 threads - it's a logistical nightmare. Open up separate threads for each of your suggestions and they'll be evaluated on a case-by-case basis for their merit and desirability. Some might be closed - don't take it personally if they are. Some may actually be accepted.

But please don't ask us to lock the thread just because you don't want to see responses to it. That doesn't do anyone any good. Take a deep breath, and try again - and you'll be fine.
User avatar
QZDoom + Webmaster
Joined: 13 Jan 2004

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest