• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Code Suggestion Box

Jump to latest Follow Reply
Sort by date Sort by votes
#23
Massacrer said:
I dunno if it's a good place to put it here, but if you guys are doing a GunGame mode, make it so that it would scramble the order of the gun for each GunGame session. Also, it would be great to have the ability to dual wield two different pistols, like a MK23 and a M9.
Click to expand...

And also maybe be able to alter the weapon order ourselves.
 
Upvote 0
#25
Some epic suggestions here, and I can only echo what has already been said.

As far as hosting custom servers, a damage calculator would be nice. By damage calculator I mean, If a sharp shooter class has 50 custom levels and the gun that is used (eg SA80) also has 50 custom levels is it possible to have a script auto write the code for the levels.
As an example:
Sharp Shooter at level 1 = 2 Damage
Sharp Shooter level 50 = 100 Damage
Rather than write the code fifty times for each class, it would be nice to script this time consuming feature of balancing classes. I know that it's not hard to work out, but it's just more opportunity to make an error in the syntax and spend hours looking for the reason it won't compile.

The same calculator could be used for weapons for the inevitable and enjoyable levelling of weapons, just like levelling individual classes.

It's not important, just nice to have :)


Modular classes, because a few updates break custom servers due to base changes.

Zed syntax/modular zeds. I remember one time we had the only linux custom server running for a few days because the names of the zeds got changed from lowercase to uppercase and it broke all the custom servers because none of the calls et al, could be found.

That's all I can bring to the table for the time being but I'm sure my buddy Lasvegaspunk could add to this more than I can.
I realise my points aren't that important and are generally just nice to have but I'd like to see a tiny bit more custom server type stuff.
 
Upvote 0
#26
Make it possible to add new weapons without need for source code changes in veterancy classes.
For instance:
Code: 
static function float GetHeadShotDamMulti(KFPlayerReplicationInfo KFPRI, KFPawn P, class<DamageType> DmgType)
{
	local float ret;

	// Removed extra SS Crossbow headshot damage in Round 1(added back in Round 2) and Removed Single/Dualies Damage for Hell on Earth in Round 6
	// Added Dual Deagles back in for Balance Round 7
	if ( DmgType == class'DamTypeCrossbow' || DmgType == class'DamTypeCrossbowHeadShot' || DmgType == class'DamTypeWinchester' ||
		 DmgType == class'DamTypeDeagle' || DmgType == class'DamTypeDualDeagle' || DmgType == class'DamTypeM14EBR' ||
		  DmgType == class'DamTypeMagnum44Pistol' || DmgType == class'DamTypeDual44Magnum'
          || DmgType == class'DamTypeMK23Pistol' || DmgType == class'DamTypeDualMK23Pistol'
          || DmgType == class'DamTypeM99SniperRifle' || DmgType == class'DamTypeM99HeadShot' ||
          DmgType == class'DamTypeSPSniper' ||
		 (DmgType == class'DamTypeDualies' && KFPRI.Level.Game.GameDifficulty < 7.0) )
	{
See above we have about twenty tests... this for vanilla servers. Would be nice if we have a configurable array of DamTypes. And a native implementation of hash tables for testing if a certain DamType is in array. Using hash tables will speed-up things (and consume less CPU power) instead of looping through the entire array (in worst cases ofc).
 
Upvote 0
#27
King Sumo said:
Make it possible to add new weapons without need for source code changes in veterancy classes.
For instance:
Code: 
static function float GetHeadShotDamMulti(KFPlayerReplicationInfo KFPRI, KFPawn P, class<DamageType> DmgType)
{
	local float ret;

	// Removed extra SS Crossbow headshot damage in Round 1(added back in Round 2) and Removed Single/Dualies Damage for Hell on Earth in Round 6
	// Added Dual Deagles back in for Balance Round 7
	if ( DmgType == class'DamTypeCrossbow' || DmgType == class'DamTypeCrossbowHeadShot' || DmgType == class'DamTypeWinchester' ||
		 DmgType == class'DamTypeDeagle' || DmgType == class'DamTypeDualDeagle' || DmgType == class'DamTypeM14EBR' ||
		  DmgType == class'DamTypeMagnum44Pistol' || DmgType == class'DamTypeDual44Magnum'
          || DmgType == class'DamTypeMK23Pistol' || DmgType == class'DamTypeDualMK23Pistol'
          || DmgType == class'DamTypeM99SniperRifle' || DmgType == class'DamTypeM99HeadShot' ||
          DmgType == class'DamTypeSPSniper' ||
		 (DmgType == class'DamTypeDualies' && KFPRI.Level.Game.GameDifficulty < 7.0) )
	{
See above we have about twenty tests... this for vanilla servers. Would be nice if we have a configurable array of DamTypes. And a native implementation of hash tables for testing if a certain DamType is in array. Using hash tables will speed-up things (and consume less CPU power) instead of looping through the entire array (in worst cases ofc).
Click to expand...

No need in hash table, because basically class'DamageType' is a pointer, i.e. it is a comparison of two integer values (not strings), which executes super fast. No need in hash tables or binary trees.

But I agree that perked bonuses should be checked by iterating through arrays, not by adding "if then else" statement for each weapon.
 
Upvote 0
#28
Personally I would really like if every function had a max line length (not forced of course but more a rule of thumb sort of thing).

Basically resulting in a lot of functions calling smaller sub-functions, the main reason being when making a mod on something I often have to copy and paste 4 pages of text to make one small change in the middle.

This makes alterations to functions i create colossal beasts of text, which makes it more difficult to keep track on what I actually changed. And once the game gets updated and said function got changed there is a high chance that my mod will break somewhere.

As being a modder you of course never change the source files, this means that from the gameinfo on you have to create your own tree of extensions. It would be nice if minimal changes there could result in a minimal amount of copy pasting. To keep things clean, and lower the chances of things breaking with a new update.
 
Last edited:
Upvote 0
#29
Zetsumei said:
Personally I would really like if every function had a max line length (not forced of course but more a rule of thumb sort of thing).

Basically resulting in a lot of functions calling smaller sub-functions, the main reason being when making a mod on something I often have to copy and paste 4 pages of text to make one small change in the middle.

This makes alterations to functions i create colossal beasts of text, which makes it more difficult to keep track on what I actually changed. And once the game gets updated and said function got changed there is a high chance that my mod will break somewhere.

As being a modder you of course never change the source files, this means that from the gameinfo on you have to create your own tree of extensions. It would be nice if minimal changes there could result in a minimal amount of copy pasting. To keep things clean, and lower the chances of things breaking with a new update.
Click to expand...
I like this a lot :eek:

This is extremely prevalent in the trader stuff!
 
Upvote 0
#31
If I may punch out of my coffin for a bit, I can think of a few things that came up during my stint as a modder a few years ago:
  1. An abstract interface for perk/stats providers, of which the default behaviour is an implementation, so that alternative providers that have their own perks and store their own stats can be seamlessly dropped into place. Give it functions for adding perks and so on to make it more readily extensible by mutators other than the original provider. (Really, anything that doesn't require significantly ripping the guts out of the engine and replacing them wholesale just to add custom perks will go a long way here, but if you're doing modular, you might as well do it sincerely.)

  2. A better way of attaching custom data to players. If I recall, that was done by subclassing KFPlayerReplicationInfo, which wasn't so bad for small changes, but turned into a real mess when five different mutators all tried it at once.

    A more scalable way of doing it would be to give KFPRI (whatever it's called in KF2) some sort of string-indexed map of custom data objects. Now, my memory is hazy on the details of the old system, but I think KFPRIs were Actors, which meant they could Tick() and so on; ideally these new objects could do likewise, though for performance reasons, it might be best to avoid making them Actors themselves if possible (they're expensive, aren't they?). Throw in a hook that fires on KFPRI creation (if there isn't one already) so that multiple mutators can attach those objects individually in the first place, and you're set - no KFPRI subclassing and especially no awkward code merging required.

  3. Programmable perk description creation. KF's vanilla perks had static arrays of perk description strings, one per level; ServerPerks had a function instead (or did we add that?). Of course, having a function create strings out of thin air as the mod did creates a problem for localisation, so the way around that is to have a bunch of string properties that describe one perk bonus each, complete with printf-esque placeholders for number substitution, which the function can then transform (including locale-based number formatting) and concatenate based on perk level.

  4. Someone mentioned The Problem With Dualies earlier, which definitely needs addressing. It's really part of a bigger problem with the way item pickup and disposal interacts with the rest of the player's inventory, which also encompasses things like holding two differently-skinned versions of the same weapon at once. A few things would really help here (some of these may already exist but not have been used to full effect):

    • A function in the Inventory class for checking whether or not the weapon can be picked up. Doesn't modify the player's inventory; just returns a bool.

    • An "exclusion group" property checked by the superclass implementation of the above function, for easily making alternate versions of the same item mutually exclusive without massive if statements.

    • A function that is called when an Inventory item is actually added to the player's inventory. The various special cases for dualies would all be handled here, not hard-coded at the call site like they are now.

    • A function in the Inventory class that is called when the weapon is dropped on the floor for any reason, and is responsible for actually dropping itself. May create a different Inventory actor instead and modify its properties. Alternatively, the code for physically ejecting the dropped item is not inside this function, but the function returns the Inventory actor to be dropped (itself by default). Especially useful for preventing sale price exploits.

    • A function that is called when an item is sold, which would be similar in purpose, minus anything to do with manifesting the item in the world.

    • In combination with the above three, a function for calculating sale price, which is called only when the item is created, not when it's picked up off the floor.

    I'm probably forgetting something here, but I think that should cover it.

  5. Less wonky burn damage mechanics. Fire damage should not automatically set targets on fire; it might have been convenient to a point, but it made for some pretty awkward hacks if the default behaviour wasn't desired. Also, if I recall, the way it colonised the burning target's Timer function caused that silly burning Crawler bug.

  6. More flexible damage calculation. That's a broad brush, I know, but KFMonster.TakeDamage() was an old enemy of mine.

    Back in the Sharpshooter Dark Ages, when everyone was trying to figure out what to do with the Crossbow and the then-redundant Berserker, I had the idea that there should be an extra headshot damage multiplier that specifically affected damage to the head, so that head and total health need not be damaged equally. In hindsight, I could've worked that into a mutator by fudging the target's head health in the fire mode or projectile instead, but nevertheless, it would've been nice to have more control over the way headshots were handled. (I still think that two-multipliers mechanic would be useful, by the way. The Chainsaw still needs it.)

    Similarly, the way specimens react to hits (flinch, stun, etc.) should be moved into its own function for ease of customising. Actual stun behaviour is already in its own function (KnockDown, was it?), but the conditions that trigger it are not, and are thus a real bastard to replace.

That's all I can think of for now; hopefully it all sounds reasonable. Thanks for reading.
 
Upvote 0
#33
Entangler said:
Programmable perk description creation. KF's vanilla perks had static arrays of perk description strings, one per level; ServerPerks had a function instead (or did we add that?). Of course, having a function create strings out of thin air as the mod did creates a problem for localisation, so the way around that is to have a bunch of string properties that describe one perk bonus each, complete with printf-esque placeholders for number substitution, which the function can then transform (including locale-based number formatting) and concatenate based on perk level.
Click to expand...
Server Perks had both. If there was no array for the corresponding perk number, it would use the custom string.

It was just a small string manipulation function but it was useful. Really made my 50 level server perks server easy to do descriptions.
 
Upvote 0
#36
Some more mutator hooks

Some more mutator hooks

Recently, three more hooks came to my mind:

void(/bool) WaveEnd()
is called when a wave ends and gives the possibility to to extend on a wave. So one can easily integrate e.g. mid-game bosses or special events.

void(/bool) WaveStart()
Is called when a wave starts. Can be used to e.g. modify the used squads.

float RateTrader(ShopVolume Trader)
Can be used to set the trader to your liking, leave all traders closed (all ratings = 0.0), maybe also to open all shops (all have same ratings).

Here is an interesting thread I found that also addresses this topic very well: Extended mutator class for KF
 
Upvote 0
#37
Warishell said:
From what I understand its UE3 and pretty close to the latest UDK builds with some custom TWI code.
Click to expand...

Since it's based of UE3 but has some custom TWI code is there a possibility for a KF2 SDK (as opposed to just the UE3 SDK)?

I'm a little unsure if that's a possibility as [TW]Strago's post a little further down in the thread said, "We're a little hesitant about opening up the game to new and exciting types of hacks." I'm not sure if that was in the context of DLLbind or if it explicitly meant showing TWI's in-house UE3 code would open a huge hacking hole, but it sure would be nice to be able to use TWI's SDK build.

I suppose some highly exploitable code could either be removed from the public release KF2 SDK or perhaps be encrypted until build-time (believe it's in the directory as BrewedPC lol) if it is a feature that is really useful specifically to KF2. Any encrypted bits of exploitable code would of course require more coding to implement the features it would provide in slimmed down easy to use (non-exploitable) way in which the variables would then be inserted into the exploitable code. Of course it's pretty easy to read RAM in which the full now unencrypted and exploitable code would reside so this may entirely be a moot point. Perhaps there could b a webservice that you send your variables out to that inserts it into the exploitable code and brews it for you so no one ever sees anything naughty.

Can someone from TWI chime in? I'd really love to see an SDK more KF2 relevant over just the UE3 SDK as I think it would offer greater mod flexibility and ease of use for the modders. :)
 
Last edited:
Upvote 0
#38
FZFalzar said:
Can you do us coders a favor, and stop changing base classes every now and then, it screws our mods up and we have to constantly update and refactor everything. Once or twice is okay, but throughout the history of KF it happens so frequently it really pisses me off when something breaks after every revision.
Click to expand...

This is probably my main issue, It's the reason I moved away from KF and running custom servers (first post here in well over a year!)

I understand that it's required from time to time in order to implement new features and such, one of the great things that the community was doing was uploading source code changes version to version. It would be nice if this could be provided from TWI, at least when an update hits. Even an earlier headsup to any core functions/classes have had would be excellent.
 
Upvote 0
#39
de1337er said:
Since it's based of UE3 but has some custom TWI code is there a possibility for a KF2 SDK (as opposed to just the UE3 SDK)?

I'm a little unsure if that's a possibility as [TW]Strago's post a little further down in the thread said, "We're a little hesitant about opening up the game to new and exciting types of hacks." I'm not sure if that was in the context of DLLbind or if it explicitly meant showing TWI's in-house UE3 code would open a huge hacking hole, but it sure would be nice to be able to use TWI's SDK build.
Click to expand...

When it's ready the KF2 SDK will include all .uc files just like RO2/KF1 did. I was commenting on DLLBind which is highly susceptible to hacks.
 
Upvote 0
#40
Thanks everyone for all the input so far!

King Sumo said:
Make it possible to add new weapons without need for source code changes in veterancy classes.
For instance:
Code: 
static function float GetHeadShotDamMulti(KFPlayerReplicationInfo KFPRI, KFPawn P, class<DamageType> DmgType)
{
	local float ret;

	// Removed extra SS Crossbow headshot damage in Round 1(added back in Round 2) and Removed Single/Dualies Damage for Hell on Earth in Round 6
	// Added Dual Deagles back in for Balance Round 7
	if ( DmgType == class'DamTypeCrossbow' || DmgType == class'DamTypeCrossbowHeadShot' || DmgType == class'DamTypeWinchester' ||
		 DmgType == class'DamTypeDeagle' || DmgType == class'DamTypeDualDeagle' || DmgType == class'DamTypeM14EBR' ||
		  DmgType == class'DamTypeMagnum44Pistol' || DmgType == class'DamTypeDual44Magnum'
          || DmgType == class'DamTypeMK23Pistol' || DmgType == class'DamTypeDualMK23Pistol'
          || DmgType == class'DamTypeM99SniperRifle' || DmgType == class'DamTypeM99HeadShot' ||
          DmgType == class'DamTypeSPSniper' ||
		 (DmgType == class'DamTypeDualies' && KFPRI.Level.Game.GameDifficulty < 7.0) )
	{
Click to expand...

In KF2, we do this with by adding a value or function to DmgType and asking the DmgType for it's HeadShotMultiplier. This gets rid of the hardcoded class conditions. Of course there is a lot of code in the game so it's not perfect, but that's been part of our coding standard since day 1.

Zetsumei said:
Personally I would really like if every function had a max line length (not forced of course but more a rule of thumb sort of thing)....
Click to expand...

Indeed. Our rule of thumb is one monitor screen length. For moddable functions shorter is even better to mitigate the problem of us changing parent code.
 
Upvote 0
You must log in or register to reply here.
Top Bottom
Back
Jump to latest Follow Reply
Jump to latest Follow Reply
Community News
Forums
Merch
Menu