I did some things with gzdoom builder and slade, made a map etc.
Here is some requests, for past and present problems I met.
- 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. - 3d Model in wad.
I DID read topic about this. Especially this one:
viewtopic.php?f=18&t=27665
The answer is :
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.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.
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 ?
... no ? ... - 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. - 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)
. 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 !!! - "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). - 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.
