|
Post by zaimoni on Apr 26, 2016 5:10:53 GMT
RC 5 out, to make flashlight/tracker recharging work as advertised in RC 1. If there are no easy-to-fix problems reported within the next week or so, this will become a proper release.
Savefiles should be 100% compatible between RC 4 and RC 5.
|
|
|
Post by zaimoni on Apr 25, 2016 8:41:43 GMT
Looks like the flashlight/tracker recharging change was botched. I'll wait and see if there are other problems before doing an RC 5.
|
|
|
Post by zaimoni on Apr 25, 2016 7:45:01 GMT
RC 4 out... actually had time to playtest after getting off work. Trading verified to not crash (turned out there were three different failure points, RC 3 only got one)
|
|
|
Post by zaimoni on Apr 24, 2016 23:14:06 GMT
The systematic error, is that all of the action-implementing functions should use their guard-clause functions as argument checkers in DEBUG mode (which is how these are being released). Each of the AI action classes documents the guard clause to be used for its action.
It is not fixed in RC3 because I responded too fast; however, it should not materially affect things (the trading function was the only one where I had to explicitly think about guard clauses so far).
EDIT No, not safe to fix before final release. There is at least one case where one action recurses to another, but the legality checks are different for the two actions. The trading one had to be dealt with because the original error test was "too deep" (was in code I was rewriting).
|
|
|
Post by zaimoni on Apr 24, 2016 22:39:23 GMT
*Sigh* ... systematic error. RC 3 uploaded, but I expect to fix the systematic error before final release.
I wouldn't have found these two bugs quickly even if I had delayed the release to test locally.
|
|
|
Post by zaimoni on Apr 24, 2016 20:58:51 GMT
RC 2 is out; I've pulled the RC 1 as known-bad.
|
|
|
Post by zaimoni on Apr 24, 2016 20:34:42 GMT
Acknowledged; that's going to need a fairly fast bugfix release.
|
|
|
Post by zaimoni on Apr 24, 2016 5:13:24 GMT
Time to do a release; the next set of planned changes is very invasive.
ALPHA FORK RC1 CHANGES ------------------
Recharging: nothing takes more than 8 turns to recharge. If it has really long life (cell phones, small flashlights) it's efficient. Short life items are not penalized.
Line of fire/line of sight display stops at the blocked point, not the target. This is a side effect of changing the line of fire/line of sight to intelligently swerve to avoid being blocked.
Giving items no longer merges against ground inventory.
The civilian and gang AIs have had some micro-optimizations regarding flashlight usage and related situations.
Trading is in the middle of a rewrite. Further changes require very invasive restructuring so they haven't been attempted.
The alpha 9 savefile viewer should work as-is with alpha 9 fork RC1.
|
|
|
Post by zaimoni on Apr 22, 2016 20:34:55 GMT
It's using the Windows GDI functions that have been present since Win95, in the operating system core. The current build has no sound.
The decompiler was selected because it was both monetarily free, and it advertised being able to create a Microsoft Visual Studio project as part of the decompiling process. So it quite literally was just "decompile, open in Visual Studio, recompile".
The decompiler targeted an earlier version of Visual Studio; this is what triggered the one-way upgrade warning, twelve syntax errors from a redefinition of the ^ operator, and a number of errors from unnecessary raw pointer manipulations that were also mechanical fixes.
|
|
|
Post by zaimoni on Apr 22, 2016 4:26:56 GMT
Wow that code is kind of thick and not at all self-documenting. Welcome to the jungle. You're talking about make LoS sane, do you mean you're cleaning it up so we can see whats going on in the code, or making it more performant? I take it you're talking about the " AsymetricBresenhamTrace/AngbandLikeTrace" lines in Los.cs? There was some effort at a literate programming style (most function names are English phrases). Besides all comments going away when compiled, the C# compiler is very aggressive about constant replacement. The only reason the constant definitions are still there, is that the C# MSIL format is designed much like the *NIX unified executable/library format. That is, the Rogue Survivor *.EXE is *also* a library that a C# compiler can link against. That's how the original configuration utility got its SetupConfig class; it simply imported the definition from the main Rogue Survivor game. I'm guessing that the original alpha 9 release was a debug build; the erratic exception throwing checking would be within #if DEBUG ... #endif blocks in any reasonable coding style. The living AIs need re-documenting before doing anything remotely interesting to them (like remembering to turn off flashlights when going to sleep).
|
|
|
Post by zaimoni on Apr 21, 2016 20:51:07 GMT
Yes, AsymetricBresenhenamTrace [sic] is the old implementation. It has the slight disadvantage that whether these work, depends on your exact coordinates in-game:
...... ###@## .S.... s.....
..@.. ##.## .S... .s...
That is, whether the wall blocks your shot is not constant. A correct implementation, would be consistent (good) but probably not allow both (bad). (Both should not block shooting the S)hamber, because if you could manually target the s)keleton, the path could be forced to be hit the S.)
There are corresponding spatial asymmetries in the field of view, including seeing squares that are geometrically blocked from view. This is before the "los fuzzer" that makes not-seen squares with three adjacent seen squares, visible.
|
|
|
Post by zaimoni on Apr 20, 2016 23:16:33 GMT
It's too early to talk high-level plans. I need to see how things look after the savefile has been de-bloated and minor tweaks made (in particular, line of sight (LoS) and line of fire (LoF) need basic symmetry properties working). Any significant AI improvements will be very memory hoggy, and that has to be paid for somewhere. The manual garbage collector calls have visibly improved response times, so a spot release once LoS/LoF are sane is indicated.
The current maximum district size of 100 appears to be closely related to the minimap. The rash of time-related constant back-substitutions yesterday (April 19 2016) was to set up everything "scaling properly" just by changing WorldTime.TURNS_PER_HOUR , but with the current level of resource usage it can't really be dialed up even if the minimap is revised to cope. (Right now, food and sanity should scale, but stamina and district dimensions won't.)
|
|
|
Post by zaimoni on Apr 20, 2016 20:08:25 GMT
Link to this from other forums: Thanks.
It's mostly self-taught. (Perl and PHP are most of how I'm self-employed.) I do have college credits for about three-fourths of a bachelor's degree in computer science as course work, but they're 20 years old. (I had to drop the computer science major when the mathematics major coursework got too demanding.)
|
|
|
Post by zaimoni on Apr 18, 2016 18:40:00 GMT
Ah...but there are corner cases. dotPeek decompiled the Zombify function so there's something there. Right now what's scheduled is a basic "read every single line of code for a good reason" overview. It appears that the alpha 9 release was forced by external circumstances; the heuristics backing the AI dropping items (new in alpha 9) look like they need only an hour or two of systems analysis to specify how to improve dramatically.
I had to disconnect DirectX as well; the latest version of DirectX that interoperates with C# is DirectX 9. (Microsoft found out the hard way that garbage-collected languages and realtime graphics don't mix.).
My fluent languages are : C++ (first one, have been using on-and-off since 1986), Perl (using since 2000). Second-tier languages: JavaScript, PHP, Ruby, Python. Third-tier: various flavors of Pascal and BASIC, and FORTRAN.
This is the first time I've touched C#. It's a conventional C-syntax language, so the only slowdown I'm taking is from looking up syntax and memory model. It should promote from third-tier to second-tier within two months or so.
|
|
|
Post by zaimoni on Apr 18, 2016 1:57:34 GMT
RS alpha 9 fork still crashes on open. (It's no longer Windows stomping it, it's a plain old runtime error that would be compile time in C++.). Fixed. RS alpha 9 fork is now reanimated, with exactly the same intended features as RS alpha 9. I was wrong about the cause of the runtime errors. I hope it was a subtle bug in decompilation. C# does not cope with multiple enumeration labels with the same numeric value.
|
|