|
Notes |
|
|
|
|
Oh, and in case I was not clear: I understand zdoom IS Hexen format, and that xlat was originally for compatibility purposes. Simply, what i want is to patch zdoom actioan special numbers to correspond to different action specials, e.g. 243 to correspond to acs_execute rather than exit_normal. Same with UDMF numbers. |
|
|
|
(0007616)
|
|
Empyre
|
|
2013-11-27 03:26
|
|
|
Support for Boom format would be excellent, too. |
|
|
|
|
|
I strongly support this, but shouldn't this be suggested for ZDoom itself instead? |
|
|
|
|
I thought about that, I feel like this is something Zandronum needs more than ZDoom; "patch mods" are more of a thing useful for multiplayer, where server hosts do not want to have to edit thoroughly every single mapset to make it work with a particular mod. ZDoom on the other hand is more focused on all in one single player releases rather than combining multiple different wads from different authors together.
Plus, to me suggesting I take it to zdoom is practically equivalent to suggesting not to bother trying to get this in Zandronum at all, as from what I gather it will take many many year for Zandro to catch up to ZDoom, or possibly may never will (I would delighted to be wrong on this, so please correct me if I am).
Third, for many features I would go to ZDoom first, but I think there are a very small number of essential features for which there absence are significantly holding back Zandronum modding potential and smoother gameplay - this feature would be one of them.
The others include dynamic strings or full backporting of strparam, GetCVarString and GetUserCVarString; access to game mode and countdown states; custom cvar creation, and serverside stats keeping and retrieval. |
|
|
|
(0007627)
|
|
Blzut3
|
|
2013-11-28 05:54
|
|
How fast we can play ZDoom catch up depends on how stable the main releases are and how few out of sequence back ports there are. In other words, the closer we are to upstream, the sooner we can update with upstream.
This definitely sounds like a ZDoom feature to me, although I can't say it's very likely it will happen there either.
|
|
|
|
(0007628)
|
|
Dusk
|
|
2013-11-28 12:55
|
|
|
Doesn't xlat mainly exist as a set of instructions to convert Doom format maps to the internal format properly? As for the "voter" example I think a scripting feature to catch exits would work better. I'd say either an EXIT script whose return value would determine whether exit would happen or not or WFDS. |
|
|
|
|
Yeah that is the function (it also converts heretic and strife maps), but I don't see why it can't be extended, or otherwise it doesn't have to have anything to do with xlat but xlat is just a good reference on how it can be formatted in any case.
An EXIT script also sounds like a good idea. |
|
|
|
|
I think you might need to ask this from zdoom.
If approved, I'd see if Torr then has a problem with out-of-order backporting. |
|
|
|
|
|
I strongly support this as I have hit a wall as well with my Cooperative Exit's mod. xlat does not work with UDMF. Please consider backporting this in! Something like this can really make a breakthrough in modding! |
|
|
|
|
There's a real problem with cooperative games currently. Suppose you're playing with a few people, completing a big map, when suddenly a random player joins, crouches and jumps into exit. Ruined experience. There are a few workarounds -- sv_allowjump 0, sv_allowcrouch 0, sv_noexit 1 -- but they all take away from experience of players interested in completing the map more or less the way it's supposed to be beaten.
This happened to all of us who spent more than one hour total in public coop in Zandronum. Some even stepped into exit by mistake, only to get scolded by other players for anticlimactically pulling them out of an ongoing fight. Yes, understandably it's not viable to build in all convenience options right into Zandronum -- but that's what generalizing features is for. The suggested feature, even if just for the use that OP suggested alone, is enough to drastically improve coop experience in ways currently impossible. Enabling xlat for UDMF would allow modders to patch the problem in any way desired and leave gameplay untouched for the rest of Zandronum users.
Imagine, UDMF is xlat-ed, Exit_Normal is redefined to call a provided ACS script. When any map -- vanilla-style UDMF, or a heavily scripted total conversion -- is played and one player reaches exit, the game doesn't end abruptly for everyone, but instead... something happens, implementation defined. Voting? Countdown? Watching allies who are still playing through security cameras? Enter password to exit map? Enter roots of quadratic equation to exit map? 1% chance to exit? No operation? Everything is possible. This would be a real breakthrough in public coop quality of life.
Yes, it would be great to have it in GZDoom, as Mazter suggests. But GZDoom isn't widely used for public cooperative games. To have this editing possibility would be just nice for GZDoom -- but it's vital for Zandronum. Hypnotoad elaborated on that a few posts above and four years before.
This can also be viewed as fixing a discrepancy. Xlat, including custom mod-provided xlat, already works a-ok for Boom and vanilla maps, which is the majority of currently released maps. But as time goes on, the balance tilts into favor of UDMF -- which is good for everybody. However, xlat doesn't work for UDMF. Therefore, mods using xlat in Boom and vanilla don't work in UDMF, which is unexpected. |
|
|
|
|
|
Indeed, being able to do something like this for exits would be awesome to trigger all kinds of special behaviour |
|