Ignoring KEYCONF?

[Ed the Bat]

I've been poking at this one on my own for a long time now, but a truly satisfying solution has so far eluded me. Is there any solid method for ignoring or overriding a KEYCONF lump?

Sometimes, when I do a mix-'n-match with more than one mod (such as loading my own project on top of an existing mod/mappack), I run into trouble because a mod might use KEYCONF to change what weapons can be wielded. As I understand it, this means it gets the last word on what a player is allowed to use, crippling any other arsenals defined with, for instance, a player class' Player.WeaponSlot fields. I've tried a couple of different workarounds, but I'd like a cleaner solution to this issue. I don't suppose I'm missing out on something really powerful? Like a command to ignore all previously loaded KEYCONF lumps? That would sure be useful for this...

Anyone have any suggestions or advice?

[Enjay]

If you are mixing and matching mods, sooner or later you are going to run into incompatibilities. Personally, if I felt like trying to force two incompatible mods to run together, I'd just open one in SLADE and rename the KEYCONF lump to something that will get ignored. It only takes a matter of seconds to do.

[Ed the Bat]

I've done that in the past. Cracking open and changing other people's existing mods doesn't really seem like the cleanest approach, does it...

[Enjay]

Cracking open and changing other people's existing mods doesn't really seem like the cleanest approach, does it...

Actually, to me, it does. As I said, it's a matter of seconds to do it and I'm very happy messing with the contents of a WAD/PK3 so, I find it a very easy, very clean way to do things.

When it comes down to it, what you are trying to do, isn't a particularly "clean" thing. You're trying to force incompatible mods to run together. In the examples that you are working with, it's the KEYCONF that is causing the problem but next time it could be an aspect of the DECORATE or whatever. It's likely that, sooner or later, you're going to have to mess with the contents of the mods somehow.

[Ed the Bat]

Actually, so far it's proven most frequently that the KEYCONF lump is the ONE thing stopping the mods from meshing, and it seems like a very small reason for a make-or-break scenario to occur. Most everything else can be patched over very easily. KEYCONF is a rare thing in that it can have the final word when it's not even the last item loaded; most other things will either mesh together or overwrite each other in order of load.

Don't get me wrong, I'm not saying that what you said is incorrect or anything. It just doesn't sit with me, personally, that the best course of action is to fiddle with the inner workings of other people's stuff.

[Enjay]

It just doesn't sit with me, personally, that the best course of action is to fiddle with the inner workings of other people's stuff.

I guess it doesn't bother me because I actually enjoy that aspect of working with Doom stuff. As a matter of course, I open up most of the files I download and dig around inside them to see what I can find, or to figure out how something was done or (less commonly) just to alter something that I dislike.

[Ed the Bat]

That's perfectly valid, and to a point, I agree enthusiastically. I've seen myself sometimes spend entire days rebuilding other people's projects from the ground up to add/repair features I felt needed it. Of course, as an unusually shy fellow, I never work up the nerve to go to them and say 'Hey, look what I did with your work! " I've even had the honor of polishing up some of your own works from yesteryear!

So it's not that I'm opposed to the work, or anything. Mostly, it's a matter of a few personal issues:
-Due to the way I archive downloaded mods, I'm often having to make entire duplicates of projects (sometimes very large) just to make one small change
-I typically believe that the problem of compatibility is my responsibility when it's my own project I'm trying to mesh in, so rewriting someone else's work seems like the wrong way to approach it
-If I ever publicly released my own project, I'd want it to be readily compatible without having to force the user to do extra work (making changes to the older projects)

Mainly, I was just looking to see if there was some magical fix I was unaware of, but if there isn't, then there isn't.

[Enjay]

A fair enough point of view too.

To get back to the original question, I'm not aware of an "override keyconf" ability in ZDoom. I'm not sure from your original post what exactly you have tried. I take it that one of your attempts was to write a new keyconf that takes all the loaded mods into account and load it last?

[Ed the Bat]

I take it that one of your attempts was to write a new keyconf that takes all the loaded mods into account and load it last?

Exactly! This is the solution I'm currently working with. However, it still seems sloppy to me, primarily because it not only means I need to maintain essentially a second list of all weapons, but the althud becomes a gargantuan mess, since it will show the ammo capacities for EVERY weapon, wheras without KEYCONF, it would only show the ammo for whatever weapons are available to the current player character.

[Enjay]

You can also tailor the AltHUD to remove any items that you don't want shown but given that you already find adding your own KEYCONF inconvenient, making yet another control lump to modify the AltHUD would, presumably, not be suitable.

[Ed the Bat]

You can also tailor the AltHUD to remove any items that you don't want shown...

You seem to know my thought processes pretty well! This is something I've done before as well. And I'm not saying these solutions aren't valid ones. It's just that I'm always looking to see if there's a better way to do things, and when I can't find one on my own, I come to this forum to ask those with more experience.

I know sometimes I ask too much of myself/the engine, but my ideal solution involves:
-Fewest add-on files required (for simplicity on the user's part)
-As little "slop" as possible (such as when I mentioned having every ammo listed at once (or as in one of my previous solutions, no ammo at all) on the althud)
-Universal compatibility, to as strong a degree as possible (such as, when having to use add-on patches, covering the most contingencies with the fewest possible)
-Fewest outward signs of messiness (trying not to have too many load-time warnings, for instance)

So I know I'm striving for very difficult and sometimes impossible things. But, once in a while, I miss out on an obvious solution, so I figure it can't hurt to ask around, right?

[Gez]

The reason KEYCONF has the last word is for compatibility with old mods.

If you're worried about publishing your "glue" mods, kinda like Ventris' Doomvengers does, then you could fight fire with fire and use a KEYCONF lump yourself.

Otherwise, if it's for your own use, feel free to clean up and update old code using deprecated features.

[Ed the Bat]

Gez, that all pretty much sums up what I had figured was the situation. I was just hoping I was wrong and there was a better solution I didn't think of. But, I guess what I'm doing about it now is about as good as it'll get. Ah well, not the end of the world.

Thanks for your input, guys!

[Xaser]

I think I remember complaining about this when playerclass weaponslots came out. I think it needs to be done this way, though, or else the default weapon slots defined in DoomPlayer (and all the other players) would retroactively override anything that used KEYCONF in the past. That'd indeed suck worse.

[Ed the Bat]

Yeah, I knew there were important reasons for KEYCONF to exist the way it was. I was just kinda hoping that maybe there was some kind of magical "ignore previous KEYCONF settings" command I could use to get the slate clean. Most of KEYCONF is okay, but the "setslot" command totally ruins stuff.