Expose model frame data to ZScript?

[Rachael]

It's just - this stuff is so far outside my personal field of interest that sometimes I just disbelievingly look at what people actually do with the engine.

No modern AAA game studio who makes a game wants people to install salacious mods on it and post screenshots of those games' characters doing super naughty things. Yet, that's exactly what happens.

No person who makes a scripted IRC Chat Client wants their client to be used as a tool to create a virus that exploits zero-days and poor admin passwords on corporate networks and infects dozens of machines in order to create a botnet. Yet, that happens, also.

No one who has ever worked on or contributed code to ZDoom, QZDoom, GZDoom, Zandronum, Skulltag, ZDaemon, Odamex, or any of the associated ports, ever wants to see their source ports used in the creation of absolutely terrible terrywads that are filled to the brim with foul language and hate speech and nasty shock images and ear-raping sounds. Yet, that's exactly what happens.

Our role in this community is not to dictate what mods can and cannot be created. We do have the right to hold opinions about such things, and express them, but we cannot change what people do with the tools that we create and give to them. We had good intentions in creating it, and if we didn't do it someone else would have done it eventually. Once it hits its first download count, it's completely out of our hands.

It's user-generated content. Meaning - we didn't do it. The user made it. They merely used a tool that we made, which if we did not make it would've been replaced by another tool - for them to do the same thing.

[kevansevans]

It's just - this stuff is so far outside my personal field of interest that sometimes I just disbelievingly look at what people actually do with the engine.

Unfortunately, you've put yourself in a bit of a paradox. I did say you're free to do whatever you want, but you've established yourself as someone who can provide us with what we want. My advice to you? Just get over it. You can't keep this perception of how anything could be only useful to you anymore. You're catering to a community, and the community will always know better than you with what it wants. Side note, I am aware there's a line between a request being reasonable or not.

With that being said, I personally think models all together need a huge improvement. I definitely agree a lot of problems should be tackled now that ZScript is a thing.

[Graf Zahl]

I think you completely misread both of my posts.

[ZZYZX]

It's just - this stuff is so far outside my personal field of interest that sometimes I just disbelievingly look at what people actually do with the engine.

Thanks, I tried Since 2014! And the more generalized the engine gets, the less predictable mods will become.
That's also exactly why certain borderline-[No] features are actually useful, even though you may not see any point in having them. (and useful features might as well end up being pointless)

[AFADoomer]

Also, another question: are you sure that you don't just want to be able to use MD3 tags (or tag-like entities in other model formats)?

This is essentially the end state that I'm actually looking for... I'd love if the rest of the MD3 "standard", such as it is, was implemented in the engine.

I was experimenting with adding something to your ZScript MD3 parser, and was able to implement the initial pieces of tag support (enough to spawn a particle at each tag origin and have it move along with the ZScript version of the model when I specify a frame number), but there doesn't seem to be a way to actually synchronize model frames between an existing animated, interpolated in-game model and the ZScript model data. The alternative that I could think of would be to make a ZScript MODELDEF parser and recreate the engine's interpolation code, but that seems unreasonable if already-existing data could be exposed...

[Rachael]

I was experimenting with adding something to your ZScript MD3 parser, and was able to implement the initial pieces of tag support (enough to spawn a particle at each tag origin and have it move along with the ZScript version of the model when I specify a frame number), but there doesn't seem to be a way to actually synchronize model frames between an existing animated, interpolated in-game model and the ZScript model data. The alternative that I could think of would be to make a ZScript MODELDEF parser and recreate the engine's interpolation code, but that seems unreasonable if already-existing data could be exposed...

This will DEFINITELY have to wait until full C/S support is implemented because the only way I can see this running well is as a client-side script where the objects created are purely volatile and quickly destroyed.

[AFADoomer]

What's the concern? Which objects are you talking about?

[Rachael]

The concern is that model interpolation is handled by the renderer, not by the game sim, which means that interpolation can be off from one run to the next.

Therefore, if you spawn objects based on such data, it would have to be in a volatile environment that the game sim itself would not be able to touch.