Realistification of KF mod -- Thoughts?

[artyom.anon]

Last night I started playing with UDK, with the ultimate goal of fixing the recoil system - getting rid of the obnoxious bopping up and down, and making the crosshair point where the next round will hit, as well as removing the 'wtf' rounds that hit WAY away from the average group. Also, getting rid of the, in my opinion, bad feature where as your weapon shakes side to side as you walk you still always shoot straight.

I thought of adding some of my work I do in the process of learning into a mod/mutator pack. Such as, for the time being, I accomplished a bleed out system and (partially) a sprint system.

Would anybody like to see a complete mod like that? If so, maybe someone can help me overcome 2 problems Im currently having a hard time with

If you are interested, please feel free to check out my prototype.
Compiled mutator to play with in solo mode. I think thats all you need? Just drop those 2 files in your steam/steamApps/common/killingFloor/system? (Please correct me if Im wrong):
1) The .u file -- http://www.filedropper.com/mymutatorpack
2) The .ucl file -- http://www.filedropper.com/mymutatorpack_1
I think thats all you need to add it as a mutator in solo game?

Archived source files:
http://www.filedropper.com/mymutatorpack_2

At this time I added the following features (with a little description):
1)Bleed out system
If taken 10+ damage in one hit, you bleed at a fraction of that amount every .5 seconds.
If takes 16+ damage from multiple hits, you start bleeding at a slow rate.
If already bleeding, rate you bleed at increases with every subsequent hit.
If you use quick heal, you stop bleeding.
Idea is to try to made players be "safe", and, honestly - the bleed out rates I used may be way too quick. On the other hand, since Im trying to "realistify" the game, you may survive being attacked with a chainsaw but you will die seconds after.
2) Sprint system:
Basically you gain 60% speed boost for limited time.
Need to use User.ini to set a key to "Sprint" to use it.
Known issue is you can still fire, which is one of the things I need help with -- overriding the fire() function with a custom controller.

Thoughts?

 

[mmnicolas]

I like bleeding, I used to torture players with that along with friendly-fire, everybody was always complaining but I think it made them better team players. Tough luv.

 

[mrsirr]

I'm in favor of this if it is still playable. The bleedout thing might not be necessary. Although if you could just apply bleeding to certain things like Partriarchs bullets, explosives, and Gorefast blades; maybe scrake chainsaw, that would be pretty neat. If things are being made realistic I would like firearms damage values to be tweaked.

 

[Reallifeh8er]

Inbefore just my 0,02

 

[mrsirr]

Inbefore just my 0,02

 

[artyom.anon]

Yeah, damage and recoil amounts would need to be changed. Dumping 2 AK magazines to the face to kill a dude with a chainsaw is kind of ridiculous imo. Ultimately Id like people to rely much more on aimed shots and recoil to actually feel natural, as well not being able to run and shoot and hit things in the center of the forehead. But that is kind of one of the last things I want to play with. I think before that Id fix/complete sprinting, add some sort of feature that it takes you longer to pick up speed with more weight, make you not be able to take 90 degree turns while sprinting (kind of similar to Gears of War mechanism), etc.

Ultimately when I say make the game more realistic, I mean make it feel more similar to things like AA or ARMA then UT. Not necessarily attempt to make a full blown simulator

 

[Skell]

Should use Tick and its delta time to do stamina calculations, sprint handling and bleeding. Timer is already being used by KFHumanPawn and you're overwriting it without removing SetTimer() calls from the class. Make sure you don't need the functionality it provides before removing it.

A lot of functions I see without simulated in their declarations. Read this now or you're going to have to redo all of your code so that this mod can be used in multiplayer.

 

[artyom.anon]

Thank you, thats some good to know info.

I would just like to clarify - In a nutshell, the article you sent the link to states that there is no guarantee that another client (or even the server? -_^) will execute a non-simulated function that is called inside my pawn? Or is it that another client is GUARANTEED NOT TO execute it? Since all member variables inside any actor are important to all other actors, what is the point of having non-simulated functions? It would be kind of like not synchronizing on multiple threads and expecting constant memory consistency errors - just bad practice.

Also, since you actually read my code, you'd notice I did not use any constants, and just hardcoded values. Again, that kind of approach would marginally reduce space complexity but in all reality make code a little less readable. Do or no? As well as Im altering a Pawn's default.GroundSpeed, which, to me, seems like not the greatest idea or at least not a very pretty way of getting desired effect. Is there something of the like of current GroundSpeed, as well as other similar variables?

And a little more about optimization for a bit - time and space complexities:
Basically, which should I minimize? If I use some sort of caching for repeated function calls it would increase space, but reduce time complexity. Beneficial or no? On one hand - it would reduce execution time by mere microseconds, but increase space complexity just ever so slightly. Since on my machine my CPU usage is roughly at 50-60% when I play KF and memory usage is always over 80%, it seems like I got CPU time to sacrifice. On the other hand - the microseconds that it takes to execute a function cannot be gained back in any way and directly would effect perceived performance no matter what.

What about repeatedly checking the same statement? I noticed that for example with quick heal, KFHumanPawn checks if it is allowed, calls super.QuickHeal(), which in turns checks the same condition again. Avoiding this kind of behavior sounds like a good idea, or does it not matter? Or does the language use some form of caching?

Again, in a 'normal people' application those marginal changes would have basically no effect, as waiting a few microseconds longer for a page to load will have no perceived performance loss/gain to the user. In a game, however, I think it may matter, no?

 

[JD0x0]

Someone should just port over the specimens to RO2 remove all perks and use RO2, RS and some realistic modern weapons.

 

[Skell]

I would just like to clarify - In a nutshell, the article you sent the link to states that there is no guarantee that another client (or even the server? -_^) will execute a non-simulated function that is called inside my pawn? Or is it that another client is GUARANTEED NOT TO execute it? Since all member variables inside any actor are important to all other actors, what is the point of having non-simulated functions? It would be kind of like not synchronizing on multiple threads and expecting constant memory consistency errors - just bad practice.

You need to read the documentation a little more thoroughly. The question you've asked can only be answered with "depends" since remote role and function replication decide if the client sees it. It's all covered in the wiki link I sent you, click the links and explore. Your issue will be a combination of all of the stuff that the wiki talks about - so read carefully.

Also, since you actually read my code, you'd notice I did not use any constants, and just hardcoded values. Again, that kind of approach would marginally reduce space complexity but in all reality make code a little less readable. Do or no? As well as Im altering a Pawn's default.GroundSpeed, which, to me, seems like not the greatest idea or at least not a very pretty way of getting desired effect. Is there something of the like of current GroundSpeed, as well as other similar variables?

Use variables. Constants are something else. Readability is much more important than what you consider "space complexity".

Or does the language use some form of caching?

Uses a lot of caching. I don't think it's applicable in this case.

And a little more about optimization for a bit - time and space complexities:

Please never use this terminology ever again.

Just put your repeatedly used code in functions and be glad your code isn't as much of a mess as TWI's. Your code is like 10 lines long anyways; "time and space complexity" is not something you should worry about.

Are you sure you're a software engineer? This along with the thread about how you find the Killing Floor SDK suspicious despite doing very regular and expected things really makes me question the legitimacy of that...

 

[FluX]

Personally if you want a hand, give me a message over steam. I had a huge project planned but I killed it off due to KF2. Will make it for KF2 instead and it was all about making a realistic but hardcore KF version.

Don't have to but if you want a hand or so with the project, let me know. Steam: zifluxiz or [Fs]FluX.

 

[artyom.anon]

@skell - well, worrying about very trivial things in regard to performance might be unnecesay headache, but not keeping it in mind generally results in poopy applications, once you try to scale it in any way. Its more applicable to mobile applications with limited resources and especially extremely limited traffic you can send or receive, but none the less. Or server side development. Still, I cannot think of a situation when minimizing used resources is a bad idea.

Of course added code may be 12 lines long, and a lot of the code written will probably never even execute, but none the less. You are using extra resources when you really dont need to. Again, it might be so minor that it really doesnt matter, but still. I am trying to get an idea of good and bad practices.

The caching question was pretty rhetorical, really. Of course it does. And, some sort of understanding of caching is great to have as well as an understanding of the particular memory model. Always.

Variables change. I was specifically talking about constants.

I have not ever said I thought the SDK was malicious. I have, however, read end user agreements for a number of applications and stopped using them on the spot. Mobile facebook messenger being the first thing that comes to mind.

@Flux - sure. That definitely sounds doable.

Thanks for the input guys.

 

[Skell]

@skell - well, worrying about very trivial things in regard to performance might be unnecesay headache, but not keeping it in mind generally results in poopy applications, once you try to scale it in any way. Its more applicable to mobile applications with limited resources and especially extremely limited traffic you can send or receive, but none the less. Or server side development. Still, I cannot think of a situation when minimizing used resources is a bad idea.

Of course added code may be 12 lines long, and a lot of the code written will probably never even execute, but none the less. You are using extra resources when you really dont need to. Again, it might be so minor that it really doesnt matter, but still. I am trying to get an idea of good and bad practices.

In it's current state, you should not be focusing on how to make your code faster. You should instead focus on making your code work. I don't know if you looked into it any further but, from a quick second look, this will not work on multiplayer - see: the most important part of Killing Floor.

Variables change. I was specifically talking about constants.

Don't need them, might as well make your constants, like damage multipliers for bleeding, variables so that you can make them configurable in the future (ini stuff).