Troubleshooting weird shield behaviour

    NeonSturm

    StormMaker
    Joined
    Dec 31, 2013
    Messages
    5,110
    Reaction score
    617
    • Wired for Logic
    • Thinking Positive
    • Legacy Citizen 5
    I built a target practice ship with about 60k shields and 10k power storage.

    I had 0 shield regenerator blocks, but 1200 capacitors.
    I only have 500+25/s initial from core (negligible capacity) thus 25 shield per second regen.

    In my blockBehaviourConfig.xml I have:
    • 1 ShieldExtraRechargeMultPerUnit
    • 1 ShieldRechargePreMul
    • 1 ShieldRechargePow
    • 15 ShieldRechargeTotalMul

    Almost defaults, except that each block should have as much recharge per second as a weapon block has dps in 3 seconds.

    with 5..25 power consumption per regen point, it is pretty expensive (75..375 power = about 0.6..3 blocks) because I wanted to control shield regen and consumption via power storages.


    In my blockBehaviourConfig.xml I also have:
    • 0.5 ShieldRecoveryMultPerPercent
      • MAX % at high health
      • in direct recovery, the shield recharge will be multiplied by (1-((shield/max)*thisValue))
        • shield: 0 to 100% equals multiplier: 1 to 0.5 according to xml-comment
    • 0.1 ShieldRecoveryMult
      • MAX % at low health
      • in direct recovery, the shield recharge will be multiplied: recharge = recharge*thisValue
        • 10% recharge according to xml-comment
    I guess that this means:
    • "direct recovery" = "while under fire".
    • full shield = 50% regen (only while under fire?)
    • empty = 100% regen
    • 10% recharge while under fire.

    Test case:

    I fired with (8 amc, 8 slaved missile (shotgun), 8 ion effect modules) and a plain 8x damag beam - both as dual-guns (4+4) - just 8/5 times and drained 60k shield.

    36 weapon and computer blocks
    8/5 times = 24/25 seconds
    60k shields / 24/25 seconds = 220 dps
    220 dps / 36 blocks = 7.5 dps per block

    It seems correct, but hey - think about it! 36 weapon/cpu blocks drained 1100 capacitors (55 each) too easily.



    And now the weird things start:

    I huried up to get into the other ship (took me about 2-3 seconds) and the shield regenerated to 9%

    Then, sudently after 1 second, it hops from 9 to 48% and I had 38k power left (about 1/3 of the capacity)
    I start adding reactors in build mode, and the shield hops from 48% to 74%
    I start removing reactors and it hops from 74% to 100% - again in one huge step.

    Between the hops, not only more than 3 seconds have passed (a lot more then the configured regeneration cycle time), but also it should not be possible to regenerate 60k shields in less then about 2000 seconds with just 25 shield regen pooints (even displayed as 25)

    I haven't had any additional shield regenerators except my 25 from core.



    Can somebody explain that to me?
     

    AndyP

    Customer Experience Manager
    Joined
    Aug 15, 2013
    Messages
    1,199
    Reaction score
    264
    • Schine
    • Wired for Logic
    I think I can, so I'll try:

    Charging Shields (Combat/Non-Combat)

    recharge.png

    The blue line, is the result of the variable:

    <ShieldRecoveryMultPerPercent>0.5</ShieldRecoveryMultPerPercent> <!-- MAX % at high health - in direct recovery, the shield recharge will be multiplied by (1-((shield/max)*thisValue));-->

    However this line is not used by the game directly.
    (Expected it to be the 'non-combat' recharge line in the first time I read that config, this is wrong)

    It only exists to be sent through this variable:
    <ShieldRecoveryMult>0.1</ShieldRecoveryMult> <!-- MAX % at low health - in direct recovery, the shield recharge will be multiplied: recharge = recharge*thisValue;-->

    Creating the 'orange line'
    And this is your 'in combat recharge' line. Based on % shield you currently have.
    (10% if empty, 5% if full, linear)

    Once the (under fire) timer expires

    <ShieldDirectRecoveryTime>60</ShieldDirectRecoveryTime> <!-- this time is set to the value gives after each hit sustained. In direct recovery, <ShieldRecoveryMultPerPercent> is applied. Otherwise it's running on full recharge -->

    you have 100% recharge all the time.

    Jumping Shields (>20%)

    I'm not sure about your specific time setting, but this looks like a quite unfortunate desync on server and client side for you.

    This may sometimes happen when your client does register a hit, but the server has seen it missed.

    According to server.cfg:

    BROADCAST_SHIELD_PERCENTAGE = 5 //percent of shields changed for the server to broadcast a shield synch

    BROADCAST_POWER_PERCENTAGE = 50 //percent of power changed for the server to broadcast a power synch (not that critical)

    Shield and Power is NOT continuously synced,
    its only broadcasted by the server, at certain limits/thresholds.
    For power this is: 0%, 50%, 100%
    For shield: 0%, 5%, 10% ... 95% 100%

    When your client somehow gets a wrong value calculated,
    the server will correct it, but only when reaching one of those 'barriers'.

    In your case, I expect this to be an issue with estimated and real recharge curve.
    Example:
    Your client has seen a power outage on the first recharge cycles.
    Thus it stopped charging the shields.
    The server although, did see you have the power to charge, and it 'synced you upward' as its calculations reached the limits.

    The root of this is, your server and client got out of sync.
    No idea why.

    How did you implement the balance changes?
    Did your shutdown all starmade sessions,
    and edit the blockbehaviorconfig.xml?
    Or did you 'broadcast' the changed file via Tab + dot?

    In latter case you should note:
    Entities get the new values client side when being loaded or sent to clients by the server. (Cache + New updates the math)
    BUT
    on serverside,
    it will remain in the old values, until that entity is reloaded and thus reinitialized.

    Putting this into Spoiler as it is a bit offtopic,
    tried to use that broadcast config feature to use it as 'disable all weapons' patch,
    for a imaginary large PVP event.
    But unfortunately,
    you had to leave the sector and let the ship reload to get the new values,
    so it was pretty unusable for this, starter signal. ^^°

    Anyway: Broadcast will desync sever/client, when not unloading the entity, in between.
    I feel this or a misunderstanding between client and server on 'did hit' or 'did not hit' caused this.

    - Andy




     

    NeonSturm

    StormMaker
    Joined
    Dec 31, 2013
    Messages
    5,110
    Reaction score
    617
    • Wired for Logic
    • Thinking Positive
    • Legacy Citizen 5
    Yes, I already know most things.
    Just some commends and variable names are a bad choice
    • high health = 100%, low health = 0%, wasn't 100% sure if that means combat-regen vs normal
    • "this time is set to the value gives after each hit sustained" <-- no syntax checks in the code editor? ;)


    Anyway, the point is, that the ship only had 25 shield regen (= 100% full, out of combat)

    It should have needed 2200 seconds to fully recharge and not even 100 seconds lag can explain this.

    I have had about 200% of the required energy for 20 seconds out-of-combat shield regen in power tanks, thus that should neither be the issue - especially as it should have used in-combat regen, because I had the timer at 60 seconds (I hope these are no milliseconds ;))


    I could reproduce this behaviour once again.

    It seems that in the latest non-dev, core shield regen is bugged (for me). Maybe I should test it with normal blocks too.
     

    AndyP

    Customer Experience Manager
    Joined
    Aug 15, 2013
    Messages
    1,199
    Reaction score
    264
    • Schine
    • Wired for Logic
    Core shield regeneration has been removed,
    as the 'idle' power usage of that 'internal shield', exceeded the 1e/s the core generates itself.

    This also made any setup for 'battery type' ships impossible,
    as they would discharge over time even without using them.

    In case you can reproduce this on default config,
    feel free to join the testserver and drop me a message,
    will join and check it serverside and as second client,
    we can easily see 'which' side desynced then.

    - Andy