|
Post by zaimoni on Jun 1, 2019 4:48:36 GMT
The May 31 2019 June 1 2019 unstable release has been cut. The test game backing this release was pushed to Day 6 Hour 10 Day 7 Hour 4. The newer development machine's CPU loading per turn is in the 5-15 second range, but usually below ten seconds. (It is only 14 months old, and noticeably slower than it's near-dead 9-year-old predecessor.) Commands of note: - The self-order command (CTRL-SHIFT-O). If we can agree how a task that isn't here should work, it can land in the next release.
- R)un and W)alk, accessible from the Waypoint command (ALT-SHIFT-I). These use the same pathfinding as the AI (and thus cooperates better with AI). If you are controlling a civilian, you even get the close door behind me behavior during these commands.
R)un is not quite as good as manual control at long ranges.
Both commands have the notable defect that they do not yet allow for a maximum turn/step count (e.g., if you want to run for ten turns towards the subway entrance 40 steps away, that is not yet supported).
If R)un or W)alk stop early, look around -- either the game thinks you're "in combat" (you may disagree) or there is someone who would do an ai-ai trade with you in sight. In the latter case, hover over the would-be trader to get what they want and what they offer. (They likely would take "more important things" if offered.) - Item memory (SHIFT-I). Tells you where you last saw something. R)un and W)alk commands work here as well, with the same limitations. Currently available only to players and police (and if you become a cop you get their item memory).
Unstable releases before August 18 2018 have been removed.
|
|
|
Post by zaimoni on May 24, 2019 21:55:44 GMT
Test games take weeks to grind properly, so I have to make a choice with 20/200 vision. This change is radical enough that an unstable release should be cut before it is attempted.
I'm leaning towards the XCOM3 option, because RS Revived is already ammo-starved.
|
|
|
Post by zaimoni on May 16, 2019 23:26:33 GMT
Finally got time to schedule testing (the public repository is suddenly updating again). Turn times on the new development machine are running 15-25 seconds at Day 2 Hour 10. Known stability issues on trunk are: - Multi-threading enumerator crashes involving Map::m_ActorList. This is a research-and-development issue; C# does not have the language support to fix this directly. I hit this twice in the current test game.
- Pathfinding chokepoints. Pathfinding tends to get stuck when two AIs are navigating 1-wide corridors in opposite directions; fix strategy known but unsure whether it involves a savefile break.
- Trading hairballs. Aggravated by cheating police AI (those police radios are incredibly advanced technology)
Also: I'm considering a new game mode: Classic (instant zombification, no infection) with corpses. Main problem is, of course, what happens when a zombify-on-kill z bites a corpse that is already dead by some other means. This doesn't come up in true Classic because of that 1960's Hayes code (for murder mystery movies) keeping actual corpses off-screen. I haven't done a detailed genre check yet. The technically obvious options are: - XCOM 3: it's hard to brainsuck someone who has no vital signs. Replacing the just-eaten brain with a z-brain may not be enough without other vital signs on-line. I.e., works like Infection mode.
- Ahem...the z clearly have bioweapon capabilities just from instant zombification on the killing blow. Since they're "already dead", the instant zombification should work fine (just reduce the hp to account for the condition of the corpse...may want the scaling factor to be square or cube rather than linear, however. That is, 50% corpse condition might rate only 25% or 12.5% of the starting hitpoints).
|
|
|
Post by zaimoni on Mar 6, 2019 3:15:15 GMT
Test game technically unblocked (all required AI fixes have been prototyped). There has been a significant regression on CPU in trunk.
|
|
|
Post by zaimoni on Feb 15, 2019 3:50:02 GMT
Commit rate is going to be down for the near future (after fixing the pathing issue and dealing with the root cause, I had to restart the test game. There is one remaining AI issue before I'm comfortable with resuming the test game. The AI needs to be able to use the give-item order to prevent some oddities I saw at the police station.)
When the vaporware feature of helicopters lands in RS Revived, both the hospital and the police station are going to get helipads on their roofs. Unfortunately, helicopters will need aviation fuel (flying is just too energy-intensive for CHAR to electrify). So very much an early-game thing as a helicopter without fuel is going nowhere. [As aviation fuel is functionally diesel, implementing biodiesel synthesis would remediate this flaw.]
|
|
|
Post by zaimoni on Feb 7, 2019 22:18:23 GMT
Current test game has a debug-mode intentional pathing crash ("unhandled case" rationale), whose correct fix is making exit destinations fully visible. A large proportion of the next few changes to land will be for this purpose. I'll be using some of the unused screen space in the minimap block for this.
|
|
|
Post by zaimoni on Feb 5, 2019 2:24:42 GMT
So far, the hyperactivity check has triggered only once in RS Revived, for a situation that does not exist in RS Alpha. (Athletic undead like rats can get free walks; the heavily altered RogueGame::DoLeaveMap was not accounting for this.) I don't know what a release mode version of the check would be like.
|
|
|
Post by zaimoni on Jan 31, 2019 19:14:09 GMT
Loop detection ... yes, I did not actually port that to RS Revived (it's parked in an #if PROTOTYPE block). It'd be more reliable if SelectAction never returned zero-TU actions because they were handled within SelectAction, but that is an invasive change that isn't always correct (e.g., turning on a flashlight is zero-TU but requires an explicit action to trigger FOV update cleanly). I did do that change for equipping/unequipping armor, weapons, etc. as a garbage collector mitigation.
The implementation as copy-pasted, needs thread-local static variables to be correct, and only addresses same-turn action stacks rather than more complex action loops.
Original AP issue ...have not been seeing that in RS Revived. Note that I had to adjust the loading code to explicitly de-duplicate Map::m_ActorList on load (there's an issue with the auto-generated C# serialization code and that was the fastest way to de-crash that integrity check when it went in). That said, a check for hyperactivity (ActionPoints exceeding the doll's speed at turn start) is obviously correct; next push for RS Revived will include that.
EDIT: Idea with the hyperactivity check is that if an actor gets duplicated in the actor list (multiple references to the same Actor object), then (s)he will get more than one dose of AP in next turn processing and get multiple turns from exceeding the intended energy limit.
|
|
|
Post by zaimoni on Jan 30, 2019 20:32:14 GMT
Yes...RS Revived had a revamp of melee tactics (several releases ago) that, among other things, requires a free run, melee attack sequence, with adequate stamina to not get tired, for this setup. (Stamina cost estimation is jump-aware and night-aware.)
@.S
BehaviorWander: adapted for RS Revived (there was a check for previous location almost immediately, but it didn't compensate for exits)
|
|
|
Post by zaimoni on Jan 26, 2019 20:56:45 GMT
Fix for RS Revived, is for the import of RS Alpha 10(.1) BehaviorExplore. ########## #>.#..P#.. #=.#..1#.. #..'.@.'.. #=.#...#x. #..#...#.. #=.#######
|
|
|
Post by zaimoni on Jan 25, 2019 17:14:28 GMT
Ugly. The GetHashCode implementation for System.Drawing.Point (currently line ~252) is XOR of fields as of time of writing; this makes the hash codes symmetric about the line y=x. (Profiling indicated about 4% of CPU was going up in the position-based lookup for map objects which is a TryGetValue call; was checking for how this could go non-performant). Bypassing this for the Location type was a ~40% improvement. This suggests the time cost for outright replacing this type (outside of the GDI access calls) can be rationalized for CPU, not just savefile size. Also, Microsoft has ported the Windows Presentation Framework classes Rogue Survivor relies on, to .NET Core 3.0. I'm not going to switch build process to a preview, but have run the compatibility checker. Only change required would be dropping the dead code supporting save to the SOAP XML dialect.
|
|
|
Post by zaimoni on Jan 14, 2019 20:25:54 GMT
Trunk has roughly a 25% speed improvement per-turn from profile-guided optimizations. Nowhere close to the 90% improvement that would bring things back to pre-subway network.
|
|
|
Post by zaimoni on Jan 9, 2019 18:53:14 GMT
Have just verified that System.Span<T>'s public relations is actively misleading: github.com/Microsoft/dotnet/issues/770 . Announced Oct 2017, won't reach .NET Framework in foreseeable future[sic]: Unfortunate, since anything that reduces garbage collector loading would be very useful for Rogue Survivor Revived. I'm considering bumping the required MS C# version to 7.3 to lock in the ref struct types, but the time cost to deploy safe stack-allocated temporaries is much higher without System.Span<T> . The RS Revived commit log also has some preliminary changes towards being able to cache pathfinding results sensibly, but a key early stage there for code correctness is a measurable de-optimization (and thus in a PROTOTYPE conditional block).
|
|
|
Post by zaimoni on Dec 28, 2018 19:54:36 GMT
0.9.8/grenades: looks like this was designed out of 0.10.0 unstable with a savefile breaking change. (The map class is on hand-crafted save-loading, so I could do an importer for this to bypass the policy of not breaking savefiles within stable releases.)
Trunk was updated yesterday. The AI change did improve the speed slightly through day 0 hour 2, but otherwise was a wash on CPU. Test game is at Day 0 hour 5 (unclear whether to abort or not; CHAR Guard AI wasn't nearly as effective as desired.)
|
|
|
Post by zaimoni on Dec 16, 2018 18:33:46 GMT
HMM...acknowledged. It's likely the grenade not counting down on the map, and the savefile issues, are from the same problem.
Grenade timing logic was one of the things I had to be technically invasive about altering when implementing cross-district line of sight, etc. but that's specific to the 0.10.0 release series.
|
|