Update libs to 1.6 & fix some errors & improve performance #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently repository is tracking lot of obj/ files that are build artifacts and this increases repository size unnecessarily. Add gitignore to remove them later.
After updating binaries compilation works although there was no verification at this point. But this directly fixes lot of issues regarding HugsLib, so it is beneficial to update although it generates some other issues.
settlementScanRangeDivider had reversed 'min' and 'max' thus touching it was always setting minimum value due to how sliders work. We fix it, but we make UI bit counter-intuative, meaning 'Far' and 'Close' positions on slider are reversed.
In some cases whe running lot of factions & settlements, there was following sporadic error: RIMWAR: [OFFTHREAD] error in Destination array was not long enough. Check destIndex and length, and the array's lower bounds Parameter name: destinationArray at [Ref EE89AFEE] at System.Array.Copy (System.Array sourceArray, System.Int32 sourceIndex, System.Array destinationArray, System.Int32 destinationIndex, System.Int32 length) [0x000cb] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 at System.Collections.Generic.List`1[T].set_Capacity (System.Int32 value) [0x00031] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 at System.Collections.Generic.List`1[T].EnsureCapacity (System.Int32 min) [0x00036] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 at System.Collections.Generic.List`1[T].AddWithResize (T item) [0x00007] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 at RimWar.Planet.RimWarSettlementComp.AddSettlementsToTmp (System.Collections.Generic.List`1[T] scanSettlements) [0x00020] in <6046c5c7796447279c2171d9f87fb512>:0 at RimWar.Planet.RimWarSettlementComp.<get_OtherSettlementsInRange>b__54_0 () [0x00023] in <6046c5c7796447279c2171d9f87fb512>:0 [...] This is caused by List being accessed by multiple threads at once. We fix it by adding mutex'es to all common list accesses. While it could theoretically delay some threads, we shouldn't care. We probably should make mutex locks even longer for whole functions, rather than accesses.
In some cases when raided by stronger factions with better tech, sometimes <150 points there is no pawn spawned. It will generate error like: Got no pawns spawning raid from parms target=Map-0-PlayerHome, points=102 [...] We fix it by adding flag to force spawn to existing functions.
When Scouts parties target player settlement with threading enabled, they generate following error: RIMWAR: [OFFTHREAD] error in Accessing map pawns off main thread - this is never allowed due to list pooling and will result in modification exceptions elsewhere in code. at [Ref D3C7DFAE] at Verse.MapPawns.AssertMainThread () [0x0000e] in <1a4764477a744bde81c4adb46c2ccd65>:0 at Verse.MapPawns+FactionDictionary.GetPawnList (RimWorld.Faction faction) [0x00000] in <1a4764477a744bde81c4adb46c2ccd65>:0 at Verse.MapPawns.PawnsInFaction (RimWorld.Faction faction) [0x00000] in <1a4764477a744bde81c4adb46c2ccd65>:0 at Verse.Map.get_PlayerPawnsForStoryteller () [0x0000b] in <1a4764477a744bde81c4adb46c2ccd65>:0 at RimWorld.StorytellerUtility.DefaultThreatPointsNow (RimWorld.IIncidentTarget target) [0x00038] in <1a4764477a744bde81c4adb46c2ccd65>:0 at RimWar.Planet.RimWarSettlementComp.get_RimWarPoints () [0x0007a] in <68354fd538124b18ab00733e625e062b>:0 at RimWar.Planet.WorldComponent_PowerTracker.AttemptScoutOffMainThread This is caused by accessing pawn count by non-main thread which is not allowed. Proper solution would be to process raids against player on main thread and others on separate threads, but rewriting this would be lot of work. So currently just process all Warbands & Scouts (aka parties that count colony pawns) without multi-threading.
Current code does poll all settlements on map and selects all within range for processing. This is very inefficient as this does lot of unnecessary processing for single action. Reduce this to arbitrary value (currently 20) so avoid excess processing. This had disadvantage that only first 20 settlements will be targetted, so some will never actually get attacked in some cases.
In testing, calculation of RelativePowerCostAdjustment does take 100-200ms and it effectively freezes stuff running on main thread. This adjustmenet did reduce parties strength by some amount, so this change will make game harder/parties bit larger, but improves performance a lot (fixes freezes).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.