Corpse / Wreckage Decay /w download links

[Resin_Smoker]

v0.1 Download Link: http://www.mediafire.com/download/pnyzykfjtey72fo/corpse_decay.rar
Un-zip and install to: /mods

v0.2 Download Link: http://www.mediafire.com/download/zl57dpd2d2jffe8/corpse_decay_v0.2.rar
Un-zip and install to: /mods

Questions / Answers

Q: What is the "corpse decay" mod?
A: This mod attempts to improve SIM speed by removing unit corpses that have been left un-reclaimed an excessive amount of time. The more mass a unit and later it's corpse has the longer it will take to decay. Example: The fatboy would take just over 3 hours to decay, while most T1 units are removed in about 6 minutes.

Q: Why is this important?
A: Units, props, projectiles, most special effects and yes unit corpses are all considered "entities" and thus are controlled via the game's SIM engine. If there are too many entities in play, it will have a noticeable impact of the speed the SIM will run. Hence your game quality will gradually diminish as well as increase the likelihood that a player will eventually desync.

Q: How does this work?
A: Magic
Kidding aside, this mod works by /hook'ing the unit.lua function that controls corpse creation. This /hook calls for my custom file Wreck_Utils.lua to run a specialized version of the corpse creation scripts.

Q: What changes can i expect to see in game?
A: See list...

--> The unit corpses that are part of the map are not affected but corpses created 10 seconds after the game has started are.
--> Each corpse has a 3 minute (180 second) delay timer before it is allowed to decay.
--> Corpses will decay at a rate of 2 mass per second.
--> Corpses reaching ZERO mass will explode (no damage) and thus be removed from play.

Future plans / ideas

--> Adding custom faction specific effects to corpses. (fire / smoke / oil puddles etc...)
--> Scripting a corpse decay rate that increases as SIM speed decreases. COMPLETED /w v0.2
--> Creating a mouse-over event so a player can see how much mass a given unit, rock or tree has.
--> Depending on demands this could be re-scripted as a lobby option

Your feedback is welcome, so long as it contains reproducible and factual details.

Enjoy!

Resin

[Sheeo]

First of all, nice idea and nice work!

I've been reading through the code, and I have some concerns.

1. Destructive hooking of the AddWreckProp function on Unit disallows any faf wreck reclaim balance changes, and they'll need to be kept up to date in the mod. I think a mod should do one thing and do it well--messing with stock reclaim values seems out of scope.

2. I'm concerned that the overhead of a ForkThread call per wreck shadows the potential performance gain of removing wrecks in the long run. I haven't yet tried running the profiling tools (There are some goodies in /lua/system/profile.lua), but I'll try and do some tests when I have time.

3. You call AddProp instead of AddBoundedProp, which I suspect (There's a comment about this in the normal code) will cause issues when too many wrecks are added.

[Resin_Smoker]

First of all, nice idea and nice work!

I've been reading through the code, and I have some concerns.

1. Destructive hooking of the AddWreckProp function on Unit disallows any faf wreck reclaim balance changes, and they'll need to be kept up to date in the mod. I think a mod should do one thing and do it well--messing with stock reclaim values seems out of scope.

2. I'm concerned that the overhead of a ForkThread call per wreck shadows the potential performance gain of removing wrecks in the long run. I haven't yet tried running the profiling tools (There are some goodies in /lua/system/profile.lua), but I'll try and do some tests when I have time.

3. You call AddProp instead of AddBoundedProp, which I suspect (There's a comment about this in the normal code) will cause issues when too many wrecks are added.

Excellent post!

1) This mod was released as more of a proof of concept just to show that the idea could work. Of coarse I'd like to have the mod use the stock FAF values at some point but for now it's ok.

2) The fork threads are done so to separate the the "wreck" thread from the"unit" thread which is about to end. Normally the default scripting creates a dumb wreck entity and then end. Being that this mod requires the wreck entities to be dynamic, keeping the thread alive to decrement the mass and trigger effects is essential to the mods operation. However I'm always open to suggests for improvement.

3) I'll look into this... do you have any thread you can cite as examples as I'm curious as to the specifics.

Resin

[Resin_Smoker]

3. You call AddProp instead of AddBoundedProp, which I suspect (There's a comment about this in the normal code) will cause issues when too many wrecks are added.

Look at Wreck_Utils.lua line 112... Notice there I'm using AddBoundedProp.

Not 100% sure what this does for the prop but I've added it as it was part of GPG's method.

Resin

[Resin_Smoker]

2. I'm concerned that the overhead of a ForkThread call per wreck shadows the potential performance gain of removing wrecks in the long run. I haven't yet tried running the profiling tools (There are some goodies in /lua/system/profile.lua), but I'll try and do some tests when I have time.

Code: Select all

         -- if wreck is in water, some of his mass is removed.
         if self:GetCurrentLayer() == 'Water' then
            mass = mass * 0.5
            energy = energy * 0.5
         end

The above snippet is from FAF Unit.lua, line 1669... I'm assuming this is what you were referring to?

I've added this to my copy of the mod and will be available on the next update.

Resin

[Resin_Smoker]

There are some goodies in /lua/system/profile.lua

I assume your referring to the FAF core files... I did some digging and thus far have come up with nothing on this.

Resin

[Resin_Smoker]

I've uploaded v0.2 (see first page of this thread for the DL link)

As for what's changed...

Code: Select all

--> Attempted to address some of Sheeo's concerns.
--> Added basic FX to wreckage (GPG's default), custom FX will come later.
--> Wreckage health declines as mass does.
--> Corrected an hit-box issue with hit-box settling a bit below the units wreckage.
--> Added more descriptions to the lua.
--> Devised a method to check the games SIM speed and re-scale the decay rate to match the game conditions.
--> Brought about world peace, cured cancer and single handedly saved the world from alien invasion!

Note: The first six statements are all lies.

Enjoy!

Resin

[pip]

I think this is a good idea to improve sim speed over time, and only for this reason. So if you can estimate the sim speed buff this would provide in large team games, this would give more impact to your concept. If the impact is big (like sim speed not degrading below 0 for significant game time), this should be used in stock FAF.

[Resin_Smoker]

I think this is a good idea to improve sim speed over time, and only for this reason. So if you can estimate the sim speed buff this would provide in large team games, this would give more impact to your concept. If the impact is big (like sim speed not degrading below 0 for significant game time), this should be used in stock FAF.

Here is how I've estimating the SIM...

I record the System_Time and the Game_Time at the moment of the Wreckage creation.
Once the wreck starts to decay i sample the System_Time and the Game_Time again and subtract the earlier sample from the latter, then divide the two results into each other.

function Spawn_Wreck_Prop( self, Spec )

Code: Select all

         --> Save when our wreck was create (real time) for later comparison
         Spec.Sys_Time_Spawned = math.abs( GetSystemTimeSecondsOnlyForProfileUse() )
         --> Save when our wreck was create (game ticks) for later comparison
         Spec.Game_Time_Spawned = math.abs( GetGameTimeSeconds() )

function Wreckage_Decay( self, prop )

Code: Select all

         local sysTime = math.abs( GetSystemTimeSecondsOnlyForProfileUse() ) - prop.Spec.Sys_Time_Spawned
         local gameTime = math.abs( GetGameTimeSeconds() ) - prop.Spec.Game_Time_Spawned
         local modifier =  sysTime / gameTime - prop.Spec.DecayRate
         local decayRate
         if modifier > prop.Spec.DecayRate then
            decayRate = modifier
            if decayRate > 10 then
               decayRate = 10
            end
         else
            decayRate = prop.Spec.DecayRate
         end
         --> Set the new mass value                                             
         prop.MassReclaim = prop.MassReclaim - decayRate


As you can probably tell from the above, i'm using the difference between the System_Time and Game_Time thats elapsed to create a ruff estimate of the SIM speed. The greater the difference between System and Game times the lower the average SIM speed must be.

This was the only way to get an idea of the SIM speed as the command that's normally used for this is for UI use only.

Resin

[Ze_PilOt]

What is the proof that wreck impact sim speed?

Other than pathfinding, I can't find any evidence of that.

In a sandbox, 3000 wrecks, still running at +10. (while 1000 units alive run at +8)