[BUG] Multifaction + Psy Ability

[nurbat]

What the bug manifests itself in:
Cooldown is tied to map number 0, if you leave on a different map from the starting map for 1 month or more, skill rollback becomes infinite. If you roll the map number 0, to the current map on which you play, skills become available again

How to repeat the bug?

1. Create a game Async + Multifaction
2. Log out of the starting faction
3. Create a new faction
4. Rewind time on your new location for a month ahead, use Psy Skill rollback time goes to infinity.

How can I fix it?
Make the binding Colldown psy skill relative to the location where the character is currently bound to game location number 0

We have modified the code to fix this bug by synchronizing the main map relative to other maps.
For those who are playing with friends, you can use this flyhack to synchronize the main location

[Zetrith]

• Which ability exactly does it affect?
• Does it only affect pawns which travel from one map to another?

[nurbat]

Which ability exactly does it affect?
Affects any psi ability, even those that don't have cooldown appear. Colldown gradually increases with time difference at the initial, zero location.

Does it only affect pawns which travel from one map to another?
Doesn't make a difference, pawns are bound exactly to the starting location, no matter where they are.

Additionally
Above made code that would synchronize the initial location, relative to the player who lags behind. When the time was equalized with the time of the location where we play, the bug disappeared. Also saw a neighboring topik with a bug about children who did not grow, it is again that the child is tied to 0 location where it is always paused and there is no one playing and lives in another place.

Need that the pawns, bound to the location where they are and do not count ticks from the initial location

This bug is very clearly manifested when the time on the main map lags by 1-2 months it is very noticeable, just scroll the map to the current time on other maps with a difference of +1 or -1 day from the time of another location then all the bugs disappear until the time on the main map again will not begin to lag behind strongly

[nurbat]

When deleting the initial map via dev Mode, time freezes on the global map and all abilities also freeze and don't move.

[nurbat]

I also found out one surprising thing, we talked about if the time is behind, but now I just found out that the same negative effect is present if the time of the main location goes forward.

As a result, if the time of the main location is behind or ahead, this bug occurs

[Zetrith]

Can you post a screenshot of the affected abilities?

[nurbat]

Any psi ability becomes unavailable after use.

main location (default location)
date: 4th of aprimay, 5500

my location (location use psy-Ability)
date: 5th of Jugust 5500

[notfood]

Psycasts/quests getting negative time or too big values is not limited to multifaction. Some bugs can alter ticksGame (converting to single player). It also manifests as pawns unable to sleep. To easily reproduce, edit the save and change ticksGame under tickManager in decrements/increments. It'll differ from the map's tick creating the gap and causing the AI shenanigans.

        <tickManager>
            <ticksGame>8143625</ticksGame>
            <gameStartAbsTick>30000</gameStartAbsTick>
            <startingYear>5500</startingYear>
        </tickManager>

[Zetrith]

Fixing bugs related to cooldowns with async time is a work-in-progress tracked in #422. The issue with pawns being unable to sleep is already fixed.

@nurbat I was a bit confused because abilities having cooldowns doesn't appear to be a vanilla feature and comes from Vanilla Expanded mods. As such it's a mod compatibility issue but we'll look into it.

[SokyranTheDragon]

I'll be honest, I forgot vanilla abilities don't use cooldowns, so I kept quiet... However, looking at it now, the only vanilla ability that uses a cooldown is the one used by war queen (CompMechCarrier) to spawn other mechanoids.

As for the issue with abilities here - after experimenting for a bit, it seems it's not an issue with timestamps being messed up. What happens is:

• Pawn casts ability
• Cooldown is set during simulation (using map time)
• Gizmo checks for cooldown in GUI (using world time)

So basically, MP Compat related, not relevant to MP itself. However, to fix this issue, we'd likely need a way through API to access time of specific map (or world) on demand, independent of what Find.TickManager.TicksGame would return based on context. I've recently been looking into further API additions to better support async time and multifaction, but haven't really developed anything yet. So far I've been only trying to make a list of what would be useful (and safe) to do from API, as well as looking into code to see the best way to achieve it once I'd start developing it.

[nurbat]

Yes you are right SokyranTheDragon, it uses world time. But as during the game determined that the world time is not stable, it is assigned to different locations each time. Previously it was assigned to 0 location and recently the world time (on the world map) is assigned to the map of a friend and his location. World time is not stable, you can not attach to it. It can change while loading a save

[SokyranTheDragon]

The world time is not supposed to be "assigned" to any location. It increases any time any map is not paused, and it runs at the same speed as the fastest map.

If you only have one map, then world time will generally be the same as the map time (from my experience, it tends to get a bit ahead). When you add more maps then it quickly stops being true (especially when each map uses different speed at different times).

The world time should also only ever move forward (or be paused), not backwards, so if it ever did - then that's a bug somewhere. If it's different before saving and after loading the game then again that's just a bug that needs fixing.

[SokyranTheDragon]

I've decided to look into fixing this again, and have a fix ready. I'll have to clean up the code a bit and push it to MP Compat.

Anyway, I say this issue should be closed. It's not relevant to MP itself, but is an issue with mod conflicts.