[BETA-FA]Community Bug Fix Patch v4

FuryoftheStars

Keep up the good work Brute.

FuryoftheStars

Brute, dunno how much time you got on your hands lately, but your links for the 3603 files are broken (File Front says it can't find the file). Also, any idea how compatible it'll be with the 3603 patch mod that LD has come out with? Do we just gotta make sure that yours loads last?

brute51 · **Joined:** 08 May, 2008 **Posts:** 821

Sorry for the late reply. I read your post earlier but I was to busy to reply.
I have a bit more time now but I've been working on a few other mods. The CBFP v4 for 3599 is as good as ready but I spotted another bug the other day which I might want to fix first (if it's easy enough). The one for 3603 is also nearly done, just the finishing touches :wink:

I'll put in some effort today and the coming days to make a final CBFP version.
I don't know anythign about LD's mod so I can't help you there. In general the CBFP should be the first mod to load.

edit: About LD's 3603 mod. Yeah it's probably a good idea to load that mod first. The only way I know how to do that is by having a mod UID that starts with 02 (or less).

Mithy · **Joined:** 19 Jul, 2009 **Posts:** 2972

brute51 wrote:

edit: About LD's 3603 mod. Yeah it's probably a good idea to load that mod first. The only way I know how to do that is by having a mod UID that starts with 02 (or less).

There are also 'Before' and 'After' tables in mod_info.lua that can be used to force mod load order, but I'm not 100% sure they work.

Edit: Welp.

BulletMagnet

the common consensus is that they don't work.

maddad4ever · **Joined:** 19 Jan, 2010 **Posts:** 2

Hello.

The links for the 3603 version of your patch appear to be broken

Please provide an updated link.

Thanks!

Legion Darrath

How about you use the search button for the official link?

maddad4ever · **Joined:** 19 Jan, 2010 **Posts:** 2

I was referring to the CBFP v4 Beta for Forged Alliance v3603. I searched the forums but could not find any link to Brute's bugfix. Unfortunately, as a poster above has mentioned, the links appear to be broken. Please update the links when you can, Brute.

Moritz2 · **Joined:** 03 Jun, 2009 **Posts:** 228

Get it below.

Direct Link Mirror (3603 version)

Moritz

Mithy · **Joined:** 19 Jul, 2009 **Posts:** 2972

I'm getting some odd behaviour from Sparkies with the CBPv4 running.

When more than one Sparky tries to build something, whether via assist or via group order, the unit build/rebuild restriction code immediately destroys the structure that they're attempting to construct, but only about 50% of the time. I've looked over the code, and mostly understand what it's intended for, but not why it's triggering in this particular case.

No unit restrictions are enabled, and while I originally assumed this had something to do with a mini-mod I have running that gives Sparkies the ability to build intel+counterintel structures, disabling that didn't change the behaviour. It happens with absolutely any structure that groups of them try to build, and only when the group/assist chain contains more than one Sparky. Other engineers, including other factions' engineers, do not cause the problem even when assisting Sparkies.

I also just noticed that when issuing group orders, even when the structure does begin building, generally only one or two of them is working on it, and in fact the others attempted to build it one tick earlier and had their attempt canceled by the structure's destruction. I have no clue why this is so erratic.

Manimal · **Joined:** 11 Apr, 2007 **Posts:** 1915

Code:

# The altered factory unit class would be ideal except that it doesn't work. The code in this file gets appended at 
# the end to the existing file from stock FA. Because the air, ground and naval factory classes are generated before 
# this script is even executed the altered factory class won't be used. I can ofcourse re-generate the factory 
# classes but that will affect already loaded mods that change this code aswell. So the best solution [color=orange](fixed a typo)[/color] to the problem
# is to apply the bug fix that was originally meant to go in the factory unit class to each dedicated factory class.

The "do <my Modified stuff> end" thing is OK but it's never been a (good) way to overload a class or one of its internal methods.
(check how to do that thru Google)

The altered code you're talking about (from CBFP v3) :

Quote:

#This doesnt work for some reason so I moved this script to all factory unit classes
#and now it does work!

#CBFP_oldFactoryUnit = FactoryUnit
#FactoryUnit = Class(CBFP_oldFactoryUnit) {
# OnKilled = function(self, instigator, type, overkillRatio)
# StructureUnit.OnKilled(self, instigator, type, overkillRatio)
# if self.UnitBeingBuilt and not self.UnitBeingBuilt:IsDead() and self.UnitBeingBuilt:GetFractionComplete() != 1 then
# self.UnitBeingBuilt:Destroy()
# end
# end,
#}

I had to face that OnKilled related problem and I came to the following considerations :

IMHO, Kill() invokes Destroy() INTERNALLY, so this makes useless any other calls of the method Destroy() except in some specific cases, i.e. by overloading the method OnKilled (e.g. within DefaultUnits) with NO reference to Unit.OnKilled.

# MY SOLUTION THAT SEEMS TO WORK FINE :

I simply REMOVED ALL Kill() and ALL Destroy() from methods of ALL of the Classes that are within defaultunits.lua

Also, I changed Kill() for Destroy() in Unit.OnKilled because UnitBeingBuilt should not count as a Kill since it is NOT "alive" yet !
(that sounds logical, doesn't it ?)

Now a closer view to the changes :

lua.scd/lua/sim/Unit.lua

Code:

Unit = import('/lua/sim/Unit.lua').Unit

Unit = Class( OldUnit ) {
    
    OnKilled = function(self, instigator, type, overkillRatio)
        
        #< etc >
        
        #If factory, Kill or DESTROY ? what I'm building if I die
        if EntityCategoryContains(categories.FACTORY, self) then
            if self.UnitBeingBuilt and not self.UnitBeingBuilt:IsDead() and self.UnitBeingBuilt:GetFractionComplete() != 1 then
                
                # NO UnitBeingBuilt:Kill() since UnitBeingBuilt is NOT "alive" yet.
                self.UnitBeingBuilt:Destroy()    --self.UnitBeingBuilt:Kill()
            end
        end
        
        #< etc >
        
    end,

lua.scd/lua/defaultunits.lua

Code:

MyUnit = import(My ModPath .. '/hook/lua/sim/Unit.lua').Unit

StructureUnit = Class( MyUnit ) {
    
    #< etc >
    
    OnKilled = function( self, instigator, type, overkillRatio )
        Unit.OnKilled( self, instigator, type, overkillRatio )
        # NO self:Kill(), NO self:Destroy() since this is INHERITED from Class Unit.
        
        < etc >
    end,
    
    #< etc >
}


FactoryUnit = Class( StructureUnit ) {
    
    #< etc >
    
    OnKilled = function( self, instigator, type, overkillRatio )
        StructureUnit.OnKilled( self, instigator, type, overkillRatio )
        # NO self:Kill(), NO self:Destroy() since this is INHERITED from Class Unit through StructureUnit.
        --if self.UnitBeingBuilt then
        --    self.UnitBeingBuilt:Destroy()
        --end
    end,
    
    #< etc >
}


# INVOKED BY AirUnit, LandUnit, SubUnit, ETC...

MobileUnit = Class(Unit) {
    
    #< etc >
    
    OnKilled = function(self, instigator, type, overkillRatio)
        
        #< etc >
        
        # NO self:Kill(), NO self:Destroy() since this is INHERITED from Class Unit through StructureUnit.
        Unit.OnKilled(self, instigator, type, overkillRatio)
    end,
    
    #< etc >
}

Conclusion :

Again, I underline the "do ... end" problem and you see from my code above that I never used that way to do.

Hoping this would help in some way :wink:

Post Scriptum:
Invokation of the method Destroy() from within Unit.OnKilled needs to be comfirmed by some Devs @ GPG, especially if I'm right regarding the Kill() that calls internally Destroy() (after increment of the victims counter)

BulletMagnet

very interesting.

Manimal · **Joined:** 11 Apr, 2007 **Posts:** 1915

Now about the other part of lua.scd/lua/sim/unit.lua that OnKilled is related to :

By following that reasoning above about Kill() calling internally Destroy() which last one fires OnDestroy :
we can logically conclude that the portion of OnDestroy below is a useless duplicate of the same portion of OnKilled until game ends up or shuts down, because it is called twice whenever a Factory building up something is killed.

The only time it happens to DIRECTLY destroy a Factory that's building up something WITHOUT KILLING IT, is when player quits/restarts the game.
I didn't implement a FLAG that tells the script when this event is fired, so it is required or the code below won't work properly.

ORIGINAL Unit.OnDestroy

Code:

    OnDestroy = function( self, instigator, type, overkillRatio )
        
        #< etc >
        
        #If factory, destroy what I'm building if I die
        if EntityCategoryContains( categories.FACTORY, self ) then
            if self.UnitBeingBuilt and not self.UnitBeingBuilt:IsDead() and self.UnitBeingBuilt:GetFractionComplete() != 1 then
                self.UnitBeingBuilt:Destroy()
            end
        end
        
        #< etc >
        
    end,

By the way I also noticed the another part is duplicated in their respective scripts :

Code:

self.Dead = true

For being sure, I made some tests after I made some changes :
¤ I made a copy of the original [gamedata\lua.scd] and then renamed the orignal as "lua.scd.ORIGINAL".
¤ Then I unzipped + altered lua.scd/lua/sim/unit.lua by adding "marker" lines that told me each time the OnKilled and OnDestroy function are invoked, and last I zipped back the SCD.
¤ then I did not forget to run the game by using the /PurgeCache command line parameter.

This allowed me to ensure myself in sandbox mode (with no AI players) that OnKilled and OnDestroy are doing their job whenever a Factory that building up something is killed.

So here's the new code of the overloaded OnKilled

lua.scd/lua/sim/Unit.lua

Code:

OldUnit = import('/lua/sim/Unit.lua').Unit

Unit = Class( OldUnit ) {

Code:

    OnKilled = function( self, instigator, type, overkillRatio )
        
        #< etc >
        
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      # MODIFIED by MANIMAL : 
      # LOGICALLY CHANGED Kill() FOR Destroy()
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        #If factory, DESTROY what I'm building if I die
        if EntityCategoryContains(categories.FACTORY, self) then
            if self.UnitBeingBuilt and not self.UnitBeingBuilt:IsDead() and self.UnitBeingBuilt:GetFractionComplete() != 1 then
                self.UnitBeingBuilt:Destroy()    --self.UnitBeingBuilt:Kill()
            end
        end
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        #< etc >
        
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      # MODIFIED by MANIMAL : 
      # LINE BELOW IS USELESS, AS IT IS DUPLICATE OF THE ONE IN OnDestroy
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        #self.Dead = true
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        #< etc >
        
    end,

Code:

    OnDestroy = function( self, instigator, type, overkillRatio )
        
        #< etc >
        
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      # MODIFIED by MANIMAL : 
      # PORTION BELOW IS A DUPICATE OF THE ONE IN OnKilled
      # THIS SHOULD BE FIRED ONLY ONCE WHEN GAME ENDS UP / SHUTS DOWN.
      # AFAIK we can't and/or don't need to spawn (by hand or through scenario) a Factory that's building a unit...
      # FLAGS GameShutsDown + GameEnds ARE TO BE DEFINED.
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        #If factory, DESTROY what I'm building if I die
        if ( GameShutsDown or GameEnds ) and EntityCategoryContains(categories.FACTORY, self) then
            if self.UnitBeingBuilt and not self.UnitBeingBuilt:IsDead() and self.UnitBeingBuilt:GetFractionComplete() != 1 then
                
                self.UnitBeingBuilt:Destroy()
            end
        end
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      # NOTA by MANIMAL : 
      # LINE BELOW IS THE DUPLICATED ONE IN OnKilled
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        self.Dead = true
      # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        #< etc >
        
    end,

Could anyone double check that ?

DeadMG

One of them is used for killing a unit as in leaving wreckage and such, and the other is used to totally eradicate the unit from the game. It seems logical to me that the second would call the first, then just clean up.

Also, Manimal is entirely right about the uselessness of do-end flags. They're only useful if you want a persistent global variable- never otherwise. People use them around here like they're the holy grail and don't actually know what it does.

Manimal · **Joined:** 11 Apr, 2007 **Posts:** 1915

DeadMG wrote:

One of them is used for killing a unit as in leaving wreckage and such, and the other is used to totally eradicate the unit from the game. It seems logical to me that the second would call the first, then just clean up.

That's not exactly the matter.
I'm talking specificaly about the behavior of the script when Factory with unit being built are killed.

Destroy() fires OnDestroy so there is no need to perform the conditional Destroy() twice, except if game ends or shuts down in which case ONLY Destroy() is fired.

Mithy · **Joined:** 19 Jul, 2009 **Posts:** 2972

So why do the check in OnKilled at all? If you want to insure that the unit being built is destroyed both on Kill and Destroy, and Kill calls Destroy, why not just hook OnDestroy and forget about the flags? Is there ever a situation where you wouldn't want factories to destroy their units being built?

For that matter, why is the CBPv4 even adding OnKilled -> UnitBeingBuilt:Destroy(), when that already exists in Unit.lua, which StructureUnit (or any variants thereof) would inherit? It looks as though it would only need to change the OnKilled inheritance from FactoryUnit to StructureUnit. FactoryUnit (and its factional variants) are the only classes in that chain that add the bogus check to OnKilled.

Edit: I guess what I need explained is why it's a problem that factories are calling Kill() in OnKilled, and then 'unnecessarily' Destroy() in OnDestroy. Is the second Destroy() even happening? Wouldn't Kill() internally result in a Destroy() on that unit, causing the second set of checks (if UnitBeingBuilt, which is false if it is destroyed) in OnDestroy to not pass and as such not do anything anyway?

Also, someone please look at that build restriction code. I still cannot figure out why it's causing multi-building Sparkies to fail.

Manimal · **Joined:** 11 Apr, 2007 **Posts:** 1915

Mithy wrote:

So why do the check in OnKilled at all? If you want to insure that the unit being built is destroyed both on Kill and Destroy, and Kill calls Destroy, why not just hook OnDestroy and forget about the flags? Is there ever a situation where you wouldn't want factories to destroy their units being built?

For that matter, why is the CBPv4 even adding OnKilled -> UnitBeingBuilt:Destroy(), when that already exists in Unit.lua, which StructureUnit (or any variants thereof) would inherit? It looks as though it would only need to change the OnKilled inheritance from FactoryUnit to StructureUnit. FactoryUnit (and its factional variants) are the only classes in that chain that add the bogus check to OnKilled.

Edit: I guess what I need explained is why it's a problem that factories are calling Kill() in OnKilled, and then 'unnecessarily' Destroy() in OnDestroy. Is the second Destroy() even happening? Wouldn't Kill() internally result in a Destroy() on that unit, causing the second set of checks (if UnitBeingBuilt, which is false if it is destroyed) in OnDestroy to not pass and as such not do anything anyway?

Also, someone please look at that build restriction code. I still cannot figure out why it's causing multi-building Sparkies to fail.

Read again my explanations about the uselessness of a Kill() !
(in short : a unit that's NOT 100% constructed is NOT an "alive" unit, so it shouldn't count as a kill)

Kill() fires { OnKilled + victim counter increment + Destroy() }.
Destroy() fires OnDestroy wherever it was called from...
So the engine currently perform TRIPLE Destroy() in case of a Killed Factory + unit being built within it.

About the inheritance system in SumCom's engine :
it seems to require in specific case that you hook a whole "chain" of LUA files for them to work properly.
For instance, if you hook Unit.lua ONLY this won't work 100% correctly in some cases.
This is due to inheritance of the original Unit.lua in DefaultUnits.lua -among others- that makes your hooked Unit.lua does NOT apply at start.

But if you hook Unit.lua the way I shown above, then you hook DefaultUnits.lua like this :

Code:

#######################################################################
local Game = import('/lua/game.lua')

#VARIABLE ''GLOBALE'' (par Manimal)
local MyModPath = Game.MyModPath
local mesUtiles = import( MyModPath .. '/schook/lua/system/mesUtiles.lua' )
local tablePrint = mesUtiles.table.print
#######################################################################


#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# NOTE :
# HOOK HERE IMPORTED MODULES , for want of anything better
# IN ORDER TO FORCE StructureUnit + FactoryUnit TO TAKE IN COUNT MY MODIFs
# OF THE CLASS Unit RELATED TO OnKilled + OnDestroy (see /hook/lua/sim/Unit.lua)
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#local OldUnit = import( '/lua/sim/Unit.lua' ).Unit
local Unit = import( MyModPath .. '/hook' .. '/lua/sim/Unit.lua' ).Unit
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# THERE COMES THE ENTIRE ORIGINAL CONTENTS OF THE FILE
# EXCEPT FactoryUnit that requires the Destroy to be removed from OnDestroy.

then the things WILL work

Nota Bene: why would FactoryUnit call Destroy() once more from DefaultUnit.OnKilled right after it called StructureUnit.OnKilled(self, instigator, type, overkillRatio), knowing that -by default- Unit.OnKilled is called back. :roll:

So I disabled the conditional Destroy() within FactoryUnit. (only one alteration of the defaultunit.lua)

That what I did in my recent work for ExpWars v2 (WiP) and it works nicely until now.
However my tests didn't covered 100 % of the situations, since I can NOT perform online tests due to my 7 years old PC.

EDIT :image inserted

Code optimization doesn't needed useless duplicates of functions or even conditional actions. (e.g. duplicating the test + the call of Destroy() through Kill() via OnKilled)
Also this helps in spotting troubles and I guess I found -through my work above- another bug... if not already found + fixed up in CBFP v3 or v4 beta.

I'll post evenutally something about that.

the86th · **Joined:** 01 Dec, 2008 **Posts:** 244

I saw some odd behavior yesterday. On two seperate occasions I had Ythotha storms make a beeline straight for my firebase, normally they drift around almost aimlessly. I also saw a storm get EMPd by a dying Loyalist.

I'm posting here because this is a bugfix thread, and the only other mods I had running were BlackOps. Lt. Hawkeye said he hasn't modified the storm units, so it's either an issue with this beta or with vanilla FA.

http://i129.photobucket.com/albums/p237 ... nger/1.png
First Ythotha dies a fair distance out
http://i129.photobucket.com/albums/p237 ... nger/2.png
Storm made a beeline for my firebase and had enough time to do 25k damage to a monkeylord
http://i129.photobucket.com/albums/p237 ... nger/3.png
2nd Ythotha approaching, it was moving onto a shield generator
http://i129.photobucket.com/albums/p237 ... nger/4.png
Storm blows up a Loyalist on the way and gets stunned
http://i129.photobucket.com/albums/p237 ... nger/5.png
Storm comes to a stop right where the Ythotha's move command was

Lt_hawkeye

hmmm, interesting. well in BlackOps we did not alter the storms in anyway. actually i think it may have been the AI somehow was able to continue the move order or gave the storm a move order, even though they are supposed to be unselectable i think the AI can still command them. also loyalist will stun any unit, that's because its stun is set to ALLUNITS

FuryoftheStars

I've observed this same behavior before with the storms moving on a direct line of the Ythotha's before death. The mods I've used vary, but I can say that CBFP v4 beta was not one of them and neither was BOs. I can say that I've always had Sorian's AI on. Not saying that his AI has issues, but maybe test this with you controlling both armies vers another test with you against an AI?

stuartpierce · **Joined:** 22 Feb, 2007 **Posts:** 167

I don't know if this is considered a bug or AI problem, but submarines fire endlessly at transports which land on the water. The subs never do any damage, and it distracts them for firing at any other targets that they actually can hit.
This is with 3603, bugfix patch modified 12/4/2009, no other mods.

Stuart

Mithy · **Joined:** 19 Jul, 2009 **Posts:** 2972

Torp launchers would need AIR category added to their target disallows to fix. Could be done via blueprints.lua loop, assuming all torp launchers have this problem.

Also, I'm running into the multi-build failure pretty much any time I try to build a structure with multiple non-T1<->T3 engineer units selected - this includes multiple SCUs of the same race, SCUs selected with identically-upgraded ACUs, and Sparkies. It's definitely the CBP rebuildbonus/buildlimit code, but I really cannot fathom what the purpose of this code is (cheating prevention?) or why it's affecting these other units that are clearly able to build these structures, but not normal engineers.

Either way, it needs some kind of fix or reimplementation.

Manimal · **Joined:** 11 Apr, 2007 **Posts:** 1915

I brought a solution to a little problem that occurs whenever ACUs were enhanced, which causes the loss of Build Restrictions made through scripts.

Manimal's fix that prevents loss of Build Restrictions after an ACU's Enhancement

I guess it should be a tiny piece of the CBPF v4

Manimal · **Joined:** 11 Apr, 2007 **Posts:** 1915

Me again ... with a couple of Bug Fixes :

:arrow:

[FA] BUG FIX for Factory Units definitions of OnstopBuild

:arrow:

[FA] BUG FIX AirUnit Class missing OnKilled Callback

Hoping this helps :wink:

Wintermist · **Joined:** 13 Jun, 2009 **Posts:** 134

Nice ones Manimal, hopefully there'll be a new release soon with these changes

[BETA-FA]Community Bug Fix Patch v4

Quick Tools