|
Post by zaimoni on Jun 19, 2016 8:23:26 GMT
Detailed item memory appears to be working properly (if completely ignored by the AI).
The AI support for police sweeping districts is very RAM-intensive (39MB of savefile on day zero). It may have to be redesigned before building out.
|
|
|
Post by redrook on Jun 22, 2016 0:42:53 GMT
Police sweeping? So the police actively search; for undead or lawbreakers or what? Sounds good and makes them a bit more a threat to undead players.
|
|
|
Post by zaimoni on Jun 22, 2016 5:42:44 GMT
Yes, police sweeping for undead. I prefer to assume that any panoptics are down. (Which does imply that the data representation for murders needs an overhaul because the current implementation is panoptic. The only reason that the police reaction rate to murderers isn't 100%, is that their look-at rate isn't 100%.)
The plan is that whatever AI support the police faction AI needs, will be exposed to the player. Thus the new SHIFT-I command for locating whatever items have ever been in line of sight. (If an NPC takes the item in the meanwhile, the memory will not auto-update.)
That 39MB came with save and load times of ~15-20 seconds on day 0 for my test game, which I wasn't prepared to commit to. There is at least one cheaper non-cheating way, it just wasn't reliable enough to try building out.
|
|
|
Post by zaimoni on Jul 17, 2016 14:58:05 GMT
Those of you who are watching the commit log will notice that has resumed; I will be holding it at ~1 commit/day while my work schedule is out of whack. [The server migration motivating 1 commit/week has finished.] Weapon juggling is the immediate target. Zombie detectors, and noise, are up for a combined overhaul. (I'm trying to find a way to implement police sweeping for z that doesn't cost 39MB of savefile and should "work as designed") What I inherited from alpha 9: - Very loud noises have a game range of 15 i.e. walking distance half an hour. The only ones you're guaranteed to hear when awake are explosions. The others are not reliably heard as a "message spam prevention" measure. Very loud noises are oblivious to walls.
- Zombie detectors have a detection range of 6 (walking distance 12 minutes). The others have whole-district detection capability. I've already nominated police radios for a major overhaul (not yet completed). Cell phones and blackops trackers have not been scheduled for a major overhaul (yet).
- Neither livings, nor zombies, make significant noise when moving.
From a game logic point of view, the second point requires the third. Otherwise, z detectors approach completely useless. The third point enables the following ambush: z.. #.# @.. In order to enter the choke point safely, @ must use a running free move NE to enter the choke point. In terms of sweeping the district, it would be very convenient if z were noisy movers. The alternative is playing games with the item memory cache recency times (directing a policeman on "kill orders" to check "sufficiently old locations" would have the desired effect), or a similar boolean-logic taint system, both of which don't look like they would cope well with the last one or two threat on the map. (The 39MB reject would have coped well with that.)
|
|
Fool
Junior Member
Posts: 58
|
Post by Fool on Aug 20, 2016 20:13:19 GMT
Q - is the sweeping search memory requirement district wide (39mb total?) or per policeman?
You've been really steady zaimoni. Keep it up mate.
|
|
|
Post by zaimoni on Aug 21, 2016 7:49:06 GMT
The 39MB RAM cost was for 25 50x50 districts. It was an example of cheating AI (it associated a probability distribution with each and every threat), but lesser means were impossible to demonstrate reasonable behavior a priori. Right now I'm looking at other AI issues when work schedule dies down. (I have been losing 4-5 hours to 80F indoor temperatures with AC per day the past few weeks, except for days with thunderstorms; heat-related impairment of productivity is expected to continue through mid-September, erratically.)
The long-term intent is to have one set of AI data for each and every "communication network". Right now all PCs are assumed to be "in communication" (supernaturally, no-one initiates trades with PCs because they're clearly "possessed"/"crazy"), and all police are assumed to be "in communication" through their implicit police radios. A police PC benefits from dual membership. NPC civilians are not updating the new AI data structures at this time, but plan is for one instance per civilian NPC. A civilian NPC will have to be in talking range with another NPC/PC to share AI data, and may share important information only when leadership is involved.
CHARGuardAI and SoldierAI are critically broken anyway so the corresponding adjustments will be done when fixing them up. GangAI is somewhat broken, and will be adjusted when it is fixed. Gut reaction is that National Guard will be a single AI dataset, while CHAR guards and Those Guys will be per-squad, but I won't commit to that. Gangs will use the NPC civilian idiom.
Radios are up for re-evaluation, since I have already re-implemented police radios as CHAR-marketed hypertechnology. This will be after the current AI repair program.
I haven't decided whether Army Radios would be a reasonable addition to the game. They're "logical" (drop rate from National Guard should be same as drop rate of police radios from police, 50%), but I don't know if they actually add play value since the currently off-screen National Guard base is taken out by the Z apocalypse. Those Guys' Radios are even more questionable. Do you really want Those Guys to track you? (The Those Guys detectors in CHAR emergency supplies, are not full radios and do not allow Those Guys to track you.)
Vehicles that are subject to the C:DDA munchkin gaming veto: Easy case: Hueys. Helicopters that actually sniped while on the way to their drop-off point would be Cheesy (National Guard, Supply Drop) or Interesting (Those Guys). Since their aviation i.e. diesel fuel has to be set up offscreen anyway, the absence of gas stations inflicts no plot holes.
Hard case: Bikes (bikers), cars (gangsters), or vans (Survivors). Unlike the wrecks in the city at day 0 midnight, these are gasoline/diesel fueled -- and thus *cannot* be refueled within the viewpoint city. Drop rate of keys from drivers not decided.
|
|
|
Post by zaimoni on Sept 14, 2016 11:09:11 GMT
Two bugfixes have landed in trunk that should be relevant for 0.9.7. Note that trunk has had a number of savefile-breaking changes, but the heavy AI lift has not happened yet. I'll make a decision on how to handle this within a day or so.
|
|
|
Post by zaimoni on Sept 16, 2016 3:59:41 GMT
REVIVED 0.9.8 CHANGES ------------------ * savefile corruption fix * bluffing being a cop in single-PC mode fixed * pointless retreating by firearms users mitigated * unnamed multi-PC bugfixes * CivilianAI and GangAI theoretical bugfix regarding left-hand items ** Triggered by NPC civilian having two or more of: cell phone, flashlight, stench killer. As bikers/gangsters do not use stench killer, it cannot trigger the theoretical bug. This is a savefile-breaking update. Level generation has not been changed yet (a seed value read off the I)nfo command and fed into the command-line --seed option will recreate the map unchanged).
|
|
|
Post by zaimoni on Sept 29, 2016 19:24:10 GMT
Take #2 on police tracking of undead was started two days ago; build out will be resumed when work schedule permits.
This attempt is just a highly cheating taint tracking. In the very early game, it costs about 5MB of savefile size and is moderately laggy (2-5 seconds pause between player turns, from waiting for the player district to be scheduled). I have a suspicion this won't work out past week one or so on performance grounds.
|
|
nope
Member
Posts: 150
|
Post by nope on Oct 12, 2016 11:32:50 GMT
Well, I've only been gone a bunch of years, and already a bunch of madmen have managed to decompile the game itself and pick up where RJ left off.
I'm actually pleasantly surprised. Good work, hope to see more.
|
|
|
Post by zaimoni on Oct 24, 2016 16:54:29 GMT
Well, trunk has to get back to a releasable state first. It's starting to look like savefiles and C# events don't mix cleanly. (The simulation thread is stopped cold during save and load, but C# events run on their own implicit threads that aren't so easy to intercept.)
I.e., the new AI support data structures can't be updated by events because the resulting savefiles usually won't load.
|
|
L33TMaster
Member
I lurk and mess with tiles, not much else to say.
Posts: 108
|
Post by L33TMaster on Oct 24, 2016 20:30:42 GMT
Glad to see that work hasn't stopped, and that a lot more of the "older" members are coming back.
|
|
|
Post by zaimoni on Oct 25, 2016 19:54:35 GMT
Right...have tracked down the failure (and adjusted regression testing procedure to intercept a repeat). There's a crash bug whose full fix triggers a bug in the Microsoft standard library for C#, which blocks loading games. Slightly over 100 diffs to re-apply with new testing.
|
|
|
Post by zaimoni on Oct 28, 2016 1:02:59 GMT
Summary of what's going on: anyone looking at the repository will see that there's a new branch, 20161025-saveload ("October 25 2016 saveload"). This is to resolve the following failure to load savegames: 85 run main : load exception : System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at System.Collections.Generic.Dictionary`2.OnDeserialization(Object sender) at System.Runtime.Serialization.DeserializationEventHandler.Invoke(Object sender) at System.Runtime.Serialization.ObjectManager.RaiseDeserializationEvent() at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream) at djack.RogueSurvivor.Engine.Session.LoadBin(String filepath). At first sight, unfixable: this failure is in library code. However, it is typical for critical C memory management errors to explicitly damage stack traces like the above, so it's not utterly hopeless. Other testing found that the game had *completely* loaded before this exception was thrown. - I made a *second* checkout of the repository to my hard drive, on Oct. 25 2016.
- I did a bisection of that copy, using the release day of 0.9.8 (good) and the last commit shortly after I upgraded Visual Studio (Oct 19 2016; things had gone wrong close to immediately after Visual Studio upgrade). The "first broken revision" with the current Visual Studio install is September 23 2016, "deal with a contract failure for FOV". I made Mercurial export all patch files after three revisions earlier, September 22, "non-replicable GangAI crash hit in playtesting. Reformat in preparation for introducing code contracts", then made the branch at that revision and started applying the required changes. Note that there are multiple breaking revisions; counter-adjusting just for the first broken revision doesn't restore loading savegames.
- But...saveload is known-working before-upgrade on Sept. 27 2016 with "object orientation: Rules::isEnemyOf -> Actor::IsEnemyOf". What gives?
Rogue Survivor Revived triggered a bug in the just released Microsoft C# compiler, that didn't exist in the previous release. This is morally unrecoverable without source code control. With source code control, it's merely a large time cost to recover.
|
|
|
Post by zaimoni on Nov 1, 2016 16:21:39 GMT
Trunk repaired (i.e. if I have to do a snap release it should be feasible). The key features for the next planned release aren't close to ready yet.
While I was doing the re-apply of the changes, I took a careful look at the turn zero setup of the hospital. The spawn layout looks completely normal -- as if the electricity failure had just happened. That (and the evident curfew, only cops are outside) will have to be accounted for.
|
|