[REL][FA]Buff System Fix - Latest Release: v1.2.1, 10/11/10

RxTEAM · **Joined:** 02 Jun, 2010 **Posts:** 188

Hi,

have (i hope

) found the mod that make this things ...
BO:ACU
Strike on the first test game - all your mods on (except ICV) and BO:ACU,
the seraphim full invisible (all units/buildings) - the aeon full visible,cybrian partly
visible.
(have a couple of GUI only mods on too - like GAZ_UI/5EverNukem/Hotstats/w-groups..)

Regards
R-TEAM

FuryoftheStars

Was that with, or without, the multisource mod? I'd say do not use the multisource mod with anything other than my mods for now.

Also, if you get me that log I can track the problem down surprisingly quick (just take a look at the ICV thread! lol). Use only BSF and its required mods as well as the BO:ACU mod and its dependencies.

RxTEAM · **Joined:** 02 Jun, 2010 **Posts:** 188

Hi,

have now testet ONLY with buffsystemfix 1.2.1 and BO:ACU and BO:Globaliconsupport.
Have no invisible units but the blue transparency you know.
Log is at :http://pastebin.com/nmC7vAkd

Regards
R-TEAM

FuryoftheStars

Thank you. I'll get right on it.

EDIT: Interesting.... Even though I only see the three mods in use (BSF, BO:ACU, and BO:GIS), it seems to be loading components from GAZ_UI:

Code:

debug: Loading module '\000/mods/gaz_ui/modules/keymapping.lua\000'

And then that is what generates the warning messages at the end...

Code:

warning: Error running lua command: ...- forged alliance\mods\gaz_ui\modules\keymapping.lua(180): access to nonexistent global variable "UpdateActiveFilters"
         stack traceback:
            [C]: in function `error'
            ...alliance\gamedata\mohodata.scd\lua\system\config.lua(53): in function <...alliance\gamedata\mohodata.scd\lua\system\config.lua:52>
            ...- forged alliance\mods\gaz_ui\modules\keymapping.lua(180): in function `toggleOverlay'
            [string "import("/mods/GAZ_UI/modules/keymapping.lua..."](1): in main chunk

Try removing GAZ_UI from your mods folder and give it another go. If that solves it then I can try taking a look into GAZ_UI... but the only mod I have that even touches the UI is ICV.

FuryoftheStars

Hmm, actually, I think I may have found the issue.

RxTEAM, try running that some combination of mods again only with the following change to my BSF:
Delete (or move) the Blueprint.lua file found in BSF\hook\lua\system\

WARNING: This is not a fix... I merely do not foresee any opportunities to test in the near future.

EDIT: Ok, so after looking through the files more it looks like maybe that won't do it... you can still give it a try, though. I tend to jump the gun a little on some things. Sorry.

EDIT2: Ok, scratch all of that. Do this instead (sorry):
Download this single, updated file: http://www.filefront.com/17444361/Unit.zip/
Unzip it and swap it for the one of the same name in BSF\hook\lua\sim\
Rerun using same mod combo.
Let me know the results.

This time I think I found it.

RxTEAM · **Joined:** 02 Jun, 2010 **Posts:** 188

Hi,

i will test the file.

the gaz_ui thing ... it can be the reason, ingame i try to hit an key that change the display of different range rings , but nothing happen, i think this is a gaz_ui funktion.
but it was not loaded - so the key doing nothing.
But my trying was logged ...
btw - the blue transparency was visible long before i try the keys ....

Regards
R-TEAM

FuryoftheStars

Yeah, after I found the second thing, I kind of figured that might have been the case.

Let me know how that new file works for you, though.

What changed:

In one of my releases (v1.2 I think it was) I moved a couple things around in the functions EnableIntel() and DisableIntel() in the Units.lua file, thinking that their original setup was running too great of a risk of getting bugged. Well, even though I tested it and all worked fine on my end, I'm actually wondering if it isn't playing havoc with BO:ACU somehow. Not sure, but it's worth the shot. It's really the only thing I can think of because those are the only Intel related functions that I touch outside of Buffs.lua, which are obviously only going to be called if there is a buff applied to the specific unit of that specific type. *shrug*

Exavier Macbeth

lol I can tell you the cause of that

BO:ACU's use the counter intel ring to designate max teleport range. To do this I basically give all the ACUs a massive area cloaking field which is then immediatly disabled. Rang is from 150-250 depending on the faction. If another mod (or a bug) happens to "enable" this cloaking field it will cause mass cloaking of all units in the area.

The texture shift is part of the Transparent Cloak system that has been modified & incorporated into both BO:U & BO:ACU core scripts. Essentually it gives a visual representation to cloaked units so players know whats cloaked at a glance

RxTEAM · **Joined:** 02 Jun, 2010 **Posts:** 188

Hi,

lol - i hope we dont try to catch a dead horse ...

The Declaration that Exavier Macbeth is given, he have it already say on 20.Aug ,
and my question from 08.Oct was in relationship to his post, to be exact , if
you have the problem with the BO:ACU self fixed on the new relase 1.2.1, or is this impossible or suboptimal on your end , and so i musst wait for an adapted version of BO:ACU that work fine with buffsystemfix1.2.1 and up ...?

ATM it looks you have overlooked his post from 20.Aug ....

(if i am wrong correct me

)

and , no - have not yet had time to test your fix with the unit file - will try this
next days

Regards
R-TEAM

FuryoftheStars

Nope, didn't over look his post. I remember it fairly well, actually. Problem was that with so many mods running together, it's hard to say for certain which one was causing the issue. Now that you've narrowed it down to just the couple mods, I could take the time to actually paw through code and look for possible conflicts.

The problem with looking through codes and trying to find incompatibilities is that it isn't always cut and dry as to what the problem is. Sometimes it is simply both mods trying to overwrite the same functions... sometimes it's just one mod altering the way a function works which then the other mod has a function that depends on the output from the first function (as seems to be this case). These are not always easy to find.

RxTEAM · **Joined:** 02 Jun, 2010 **Posts:** 188

Hi,

It looks you kill the problem.
Have played 1 test game , only BO:GIS and BO:ACU and BuffSFix1.2.1+unit fix.
Run flawles on all fractions.Then 1 testgame with all my mods on - run flawles
too

So - if not anything dramatical happen - the bug(or better incompatibility) is gone

Looking forward to play BO and you very interesting ICV system if it play well ....

Regards
R-TEAM

FuryoftheStars

Thanks for the report, RxTEAM. I'll be sure to incorporate that fix into the next version.

zinetwin · **Joined:** 31 Jul, 2010 **Posts:** 203

Don't know if it's a problem or not, but when loading this mod there are tons of warnings regarding duplicate buffs detected in the logs. Doesn't seem to impede the functionality though. I wonder if it's happening because you run:
local AdjBuffFuncs = import('/lua/sim/AdjacencyBuffFunctions.lua')
at the beginning of your own AdjacencyBuffs script. Though as you said in the other thread, probably not necessary, but doesn't hurt.
http://pastebin.com/DNwQpeEj

FuryoftheStars

I'm aware of it and it's perfectly fine.

The reason behind why it does that isn't because of the local declaration, but rather because as part of my Buff System Fix, I fixed GPG's adjacency buffs. Unfortunately, the only way to do it was by overwriting them. Thus, you get the warnings saying that it is detecting a second buff by the same name for every adjacency buff that I overrode. I assume this was an error detection method that GPG introduced to help debug possibly creating two buffs with the same name. Thankfully (for my purposes anyway), it goes with the second buff it found and tosses the original.

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

It's possible to alter BuffBlueprints' metatable __call in such a way so that it can merge buff blueprints like Blueprints.lua merges unit/etc blueprints. Should just be able to override BuffDefMeta.__call in lua\system\BuffBlueprints.lua and add a check for arg[2].Merge + a table.merged into the check for Buffs[arg[2].Name].

FuryoftheStars

I'm good with how it is. I needed to wipe their Add value to 0 while changing the Mult value anyway, so either way their buff has very different values.

zinetwin · **Joined:** 31 Jul, 2010 **Posts:** 203

It seems that with this mod. When the UEF ACU gets his shield, enters a transport and is dropped off. He looses it. The toggle button is still there but the shield does not reappear. The only mods that were enabled were TV 1.17, the three powerslave mods, and BSF.

zinetwin · **Joined:** 31 Jul, 2010 **Posts:** 203

Scratch the previous post. Seems like Powershields was the cause. I has been remedied I believe.

zinetwin · **Joined:** 31 Jul, 2010 **Posts:** 203

After further research it seems that TV 1.17 is the cause of several issues. One: shields will insta-heal when using my shields mod. Two: ACU's and SCU's will not get their shield back after turning it off, having it dropped, or entering a transport. Not a clue why this is. But it's definately a conflict between BSF and TV1.17.

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

Hah, you didn't tell me you had TV running. I was about to crosspost that bug here and blame Fury, but I couldn't figure out how the hell it was happening. TV is definitely not compatible with the BSF, because it's doing a lot of the same things.

Regardless, I'm not a fan of the non-proportional shield health handling in UpdateShields(). I'd suggest something like this:

Code:

        if (shield and shieldMod) then
            local NewMaxHealth = (shield.OriginalMaxHealth * shieldMod.HealthMult) + shieldMod.HealthAdd
            local NewRegenRate = (shield.OriginalRegenRate * shieldMod.RegenMult) + shieldMod.RegenAdd
            local adjustRatio = NewMaxHealth / shield:GetMaxHealth()
            shield:SetMaxHealth(NewMaxHealth)
            shield:SetShieldRegenRate(NewRegenRate)
            --If online, adjust hp proportionately
            if shield:IsOn() then
                shield:SetHealth(shield, shield:GetHealth() * adjustRatio)
                shield:UpdateShieldRatio(-1)
            --If manually offline, adjust offhealth proportionately
            elseif shield.OffHealth > 0 then
                shield.OffHealth = shield.OffHealth * adjustRatio
            --Otherwise do nothing
            end
        end

..which adjusts offline health properly, keeps the ratio of current HP to max HP the same across both positive and negative transitions, and insures that nothing happens to a damage-offline shield.

zinetwin · **Joined:** 31 Jul, 2010 **Posts:** 203

Well I had TV running so that I could get real information from the shields other than just a bar. I didn't think a whole lot of it until we were playing a game and someone was yelling over voice, "why won't my damn shields turn on" After further testing and elimination I determined it was TV.

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

Use GAZ_UI for that. All of the same info in a UI-only mod that's compatible with just about every major sim mod (other than TV and TVg).

FuryoftheStars

Thanks, Mithy. I didn't realize offline shield healths were handled differently.

Otherwise, the

Code:

if NewMaxHealth > oldmax and shield:GetHealth() == oldmax then
   shield:AdjustHealth(shield, NewMaxHealth - oldmax)
else
   shield:SetHealth(shield, math.min(shield:GetHealth(), shield:GetMaxHealth())) 
end

method does need to stay. This was actually a common complaint with unit health and veterancy. A unit that is under fire and gains a veteran level would suddenly gain more health and/or heal completely. With that in place, the max health will increase, but the current HPs will remain the same unless it's already at 100%, so it makes gaining a level while under fire less likely to tip the balance as regen already affects this.

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

Well, that complaint was related to the very large, non-proportional bonuses that units got. They didn't keep their ratio of health to max health, they gained as much health as max health, or around 10% regardless of their current health. With a proportional method, a shield/unit at 10% health that gains +10% max will only be gaining 1% actual health.

FuryoftheStars

I'll think about it. The way I've always looked at it in my mind is that we're buffing the MaxHealth, not the current Health. The only reason for increasing the current Health would be if it was already at 100% anyway (for the off chance of a unit with no regen).

[REL][FA]Buff System Fix - Latest Release: v1.2.1, 10/11/10

Quick Tools