Difficulty implementation

[DDL]

However I'm not sure how that would work for placed ammo and such that doesn't extend tnm classes.

Exactly my concern. That's why I figured playerclass. It's the one thing you can be sure WILL be in any given map: even missionscripts aren't always present (though they might be for all your maps). If you know that all your maps are 'bemissionscripted', then that can work.


As a reference, what I did for chronos was basically an iterator that checks through all pawns, crates, and placed inventory on a map, and replaced various items with their chronos equivs as and when necessary. Initially I thought it was introducing a second or two pause at the start of each level, but once I removed the clientmessages telling me everything was going hunky-dory, it made no noticeable difference to start up time whatsoever.

I had the function in the missionscript and the playerclass there, using the MS for preference, with the PC only doing it (in initializesubsystems, I think) if it couldn't find a valid MS for the level..but anyway.


Also, just sticking one big ol' function in one or two classes makes it a lot easier for you to see what I've done. God knows I don't want to screw anything up.

[that guy]

well I don't like it but its up to you. I'd at least investigate my way, particularly given that each class is goign to have a different filter anyway, basically.

as for level.difficulty. From memory, level is an Engine.GameInfo. doing a quick text search I found references to that field in the method
event InitGame( string Options, out string Error )
in game info. It seems feasible that that would be called somewhere in your menu system ust before startinga new game, or as jonas said, it could be called natively. There appears to be no mention of the field at all in the deus ex package however there's also no mention of Initgame. So yeah, conclusion is that I have no idea how its doing it and in fact am surprised that its doign it at all.

[Jonas]

To be honest, I'm partial to Shane's system too, it seems more efficient and even more straight-forward. We wouldn't have to change the filter settings of the items at all, and we could keep using the filter properties for the items, and then you'd implement a specific difficulty check in TNMPawn, which all our characters (all of them) extend.

And hey: Don't worry about fucking things up, we keep backups 4 years back

[DDL]

Ok, bumping this again:

Right, let's just assume that somehow DX magically manages to convert the assigned combatdifficulty into something it can use to filter items with the bDifficulty1 etc etc setting, since apparently it can.

This leads to the problem that, well: if this is the case, how can we separate the two, to allow, say, the player to take realistic damage, but with easy items?

So: since the ONLY thing combatdifficulty apparently does outright (as opposed to via magical backgroup mystery stuff that I'd love to find an explanation for) is multiply the amount of damage poor old JC takes, I propose you use a different variable for that.

So your playerclass would use, say, TNMCombatdifficulty for damage taking.

RE: filtering pawns: if you set bGameRelevant=true (which can simpy be put in tnmpawn defprops), it ignores the current filter settings, allowing us (in theory) to then exert different criteria on the existing filters, allowing you to keep your current filter settings for pawns.


Finally, enemy pawn health: a minor quibble, this, but I thought I'd mention it: I'm thinking it'd be far easier to adjust the amount of damage pawns take, rather than adjust their actual health values, since an awful lot of pawn code uses default.healthwhatever as a reference, and I'd rather not fuck with defaults in-game if I can avoid it.

Finally, a place to actually store the variables. I have a suspicion that playerclass is not actually the best place for this, as sometimes playerclass travel vars don't get initialised quickly enough to be referenced against. At least in my experience. Thoughts on this, please.

[Jonas]

My thoughts are that you should indeed remove combat difficulty (that is, damage inflicted on player) from the difficulty settings. Then, implement a new setting for that and a setting that controls NPC damage as you proposed.

What we then have is an old difficulty setting that controls the number of items and enemies, a new one that handles player damage and another new one that handles NPC damage.

Then you simply implement a new setting into our pawns that can control whether or not they appear. Make sure it also removes their shadow as the built-in filter functions do not appear to do this. We will use this new setting to control enemy amounts, using the bGameRelevant to make sure they ignore their filter settings, and only use the filter settings to control items.

That's the solution I'm voting for.

[that guy]

sounds reasonable.

As for storing things in the player class I think the current method is (I haven't looked into this thouroughly) to store the things in the gameinfo. It seems like there is a function in the game info that determines if actors are relevent to the current game and destroys them accordingly.

We already have a tnmgameinfo so make whatever changes you like to that. I suggest, instead of trying to understand it, simply experimenting with it.