| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | ||
| 01:01:28 | TODO | |
| 01:01:08 | TODO | |
| 00:57:32 | NOTE | |
| 00:56:22 | SCRIPT | Average party level calculation |
| 00:40:50 | VOID | Take MXVIII |
| 00:40:46 | VOID | ![]() Pure Lua will always fall over the fact that arrays start with 1 in pure Lua. I needed to void that. Now the exact order in which foes are loaded doesn't really matter so it's not that much of an issue |
| 00:38:49 | INVESTIGATION | |
| 00:38:42 | BUG | Good, but not good enough! Only ONE foe gets actually listed. |
| 00:34:46 | TEST | ![]() ![]() Take MXVII |
| 00:34:44 | FIXED | Missing static |
| 00:33:46 | TEST | Take MXVI |
| 00:33:43 | FIXED | Wrong table |
| 00:31:11 | TEST | Take MXV |
| 00:31:10 | COCKROACH | And this in particular must turn into a cockroach? |
| 00:29:49 | TEST | Take MXIV |
| 00:29:48 | FUCKYOU | |
| 00:28:43 | TEST | Take MXIII |
| 00:28:36 | FUCKYOU | Worked too much with both C++ and Pascal for awhile, so forgot operators work a bit different here. |
| 00:26:58 | TEST | Take MXII |
| 00:26:56 | VOID | ... |
| 00:25:32 | TEST | Take MXI |
| 00:25:30 | LINK | |
| 00:23:43 | TEST | Take MX |
| 00:23:43 | LINK | |
| 00:23:01 | TEST | Take MIX |
| 00:22:59 | LINK | |
| 00:20:04 | TEST | Take MVIII |
| 00:20:02 | FIXED | link 404 |
| 00:16:55 | TEST | ![]() Take MVII |
| 00:16:52 | DEBUG | |
| 00:02:57 | SCRIPT | |
| - = 10 Jan 2025 = - | ||
| 23:47:30 | NOTE | |
| 23:47:07 | TECHNO | ![]() take |
| 23:35:36 | TECHNO | I see that (likely due to scripting bugs in the Kthura configuration at the time, and I never saw before) the spots where the enemies will appear are not tagged for the always still enemies. This is is not necesarily a problem, but I must keep it in mind. The data the data generator produces allows me to work around this. As a matter of fact, the game itself no longer needs those spots anymore, as the data generator covers this up now, and only that data counts now. |
| 23:33:25 | NOTE | |
| 23:32:58 | C++ | |
| 23:32:18 | ART | |
| 18:31:04 | DEBUG | |
| 18:08:34 | DEBUG | |
| 18:07:34 | DEBUG | |
| 18:07:22 | BUG | I don't like what console output shows me |
| 18:07:00 | TEST | Take MV |
| 18:06:40 | KTHURA | |
| 18:06:11 | C++ | |
| 12:38:29 | CONFIRMED | All output data I got shows what I wanted to see. So far, so good! |
| 12:36:12 | C++ | |
| 12:36:10 | C++ | |
| 12:32:32 | C++ | |
| 12:32:29 | C++ | |
| 10:15:49 | TECHNO | A note is in order. There were 4 settings of enemies. VT, HZ, SS and AS. VT=Vertical Move, HZ=Horizontal move, SS=Stand Still, and AS=Always Still. This denoted their movement, and except for AS, these enemies would chase after you when you came close. Now some important things are to be taken in order. Constantly having to check these enemies led to slowdowns, and checking the distance requiring the Pythagorean Theorism was also a killer. So it pains me that I will have to remove their movement, I will still check if they chase after you or not. Checking the level of the enemy comparing it to yours will only be done while loading a new map, this too in order to save time. Please note that when loading a savegame, the enemies are reset so then the checkup also takes place. The distance check will now likely be done by area check rather than Pythagoras. Pythagoras is a more realistic approach and therefore better on all accounts, but if it slows down the game like that, it can be more of a chore than a help. Life's full of nasty choices, we don't wanna make, but sometimes... we have to. |
| 10:09:01 | C++ | |
| 10:08:57 | C++ | |
| 09:54:58 | NOTE | |
| 09:52:39 | STATUS | ![]() ![]() Right, that being said, now the time has come to set up the enemies, which I was planning to do from scratch. I can only hope Visual Studio will hold out long enough to get things on the roll. |
| 09:50:01 | NOTE | |
| 09:49:55 | COSMETIC | |
| 09:46:50 | TEST | Take MI |
| 09:46:48 | COSMETIC | |
| 09:46:36 | CODEROT | |
| 09:41:12 | OFFTOPIC | |
| 09:36:44 | TEST | Take M |
| 09:36:24 | CODEROT | |
| 00:38:31 | TEST | Take CMXCIX |
| 00:38:30 | CODEROT | |
| 00:36:56 | TEST | Take CMXCVIII |
| 00:36:55 | SCRIPT | |
| 00:14:32 | STATUS | We're getting somewhere (at last!) |
| 00:11:21 | TEST | Take CMXCVII |
| 00:11:17 | NOTE | |
| 00:10:58 | VOID | More cases like these |
| 00:09:42 | TEST | Take CMXCVI |
| 00:09:40 | VOID | XSplit in stead of Split |
| 00:06:54 | TEST | Take CMXCV |
| 00:06:52 | FIXED | ![]() .DATA. |
| 00:05:28 | TEST | Take CMXCIV |
| 00:05:26 | FIXED | ![]() Syntax error |
| 00:05:00 | TEST | Take CMXCIII |
| 00:04:59 | SCRIPT | |
| 00:03:25 | MYSTERY | Life's fully of mysteries, eh? |
| 00:03:14 | HUH | The enemy spots were not yet converted, so I guess the compiler was suddenly fixed. |
| - = 09 Jan 2025 = - | ||
| 23:59:39 | TEST | Take CMXCII |
| 23:59:39 | TECHNO | Of course, a runtime test will have to tell me if this works |
| 23:59:18 | C++ | |
| 23:58:48 | SOLVED | ![]() I see that the idiots as Microschoft did want to make things difficult about UNICODE. I need to see what the best approach is to void that issue when compiling with SCons. For now I could get the MapDataBuilder to compile in VS itself (suddenly stuf JUST WORKS). |
| 23:46:29 | FAILURE | For some reason it won't compile with SCons but it DOES with VS. Odd, since both use the same compiler. |
| 22:46:09 | VISUALSTUDIO | |
| 22:45:34 | SYSTEM | |
| 22:45:01 | SYSTEM | |
| 22:44:43 | SYSTEM | |
| 22:41:59 | BUG | In the meantime I can still conclude that my Kthura Compiled reader is still not really cooperative when it comes to custom items. I don't like that. However, as these items also bear a tag, I can can still convert them to exists. For the game that won't make a different as long as they as spot based objects and not area based. I could even use an obstacle (although that's not the best of ideas). |
| 22:38:50 | FAILURE | At least I got some new hardware at the ready, the current planning is that things will be installed next Sunday. However, it's still a bit shaky how things will turn out. After that my main system will also be Linux, and what that will mean for my upcoming Windows releases is hard to tell at the present time. To be continued. |
| 22:35:54 | SYSTEM | Not only that, but my file association linkups have gone completely busted, some apps don't work anymore and I need to minimize the programs I use. So all-in-all, things are still fucked. |
| - = 07 Jan 2025 = - | ||
| 23:02:58 | STATUS | Well, at least the game can start up again, but I've been warned that the .exe file may be faulty. I hope I can however resume my work, but you understand that given the time right now, and me being full of rage, that this is not really an option. Unfortunately, my schedule is pretty full the rest of the week with other things requiring my attention. I also have a book to finish correcting. At least I can use my old mac for that one, but still. |
| 21:43:58 | FUCKYOU | |
| 21:30:40 | FUCKYOU | |
| 18:00:26 | FAILURE | Well, it appears that MicroSCHOFT has finally done it! They killed my PC completely, and it's very likely beyond every form of repair. So fuck you MicroSCOFT! |
| 17:26:40 | FUCKYOU | |
| 17:22:41 | FUCKYOU | Well let's first run the update and see what happens. (sigh) |
| 17:21:07 | FUCKYOU | |
| 17:18:25 | FUCKYOU | |
| 17:17:27 | FUCKYOU | |
| 17:17:10 | FUCKYOU | |
| 17:16:52 | FUCKYOU | |
| 17:16:16 | STATUS | ![]() At last! |
| 16:37:34 | FAILURE | And now I wonder how much playtime I lost on Tomb Raider what I was playing to kill some time, while the cleanup operation took place. (GRR!) |
| 16:33:02 | FAILURE | Thanks to the boys and girls at MicroSCHOFT I will likely waste A FULL DAY (which I could NOT afford this week), as another Blue Screen Of Death is now the reason that the entire cleanup operation got corrupted and cancelled as well, and that I have to start it all over! So FUCK YOU, MICROSCHOFT! |
| 16:14:43 | STATUS | The packing is running, but it can take awhile.... The corrupted file was not part of anything important anyway, so best to ignore that. |
| 16:08:24 | STATUS | ![]() Ah, something is on the move |
| 16:07:53 | REPORT | Cannot read contents of E:ProjectsApplicationsVisualStudiovs_templates.gitobjectsce.vsWell, what can I make out of THAT? |
| 16:05:22 | NOTE | |
| 16:02:27 | TECHNO | No idea if this will work, but I did find out that when you delete the .vs folders you can quite often fix internal compiler errors that the C++ compiler in VS quite often frabricates. It's my guess some files in there easily get corrupted when a BSOD occurs, which, is of course, since VS is a microsoft product, very extremely ironic. |
| 16:00:56 | STATUS | Restart done |
| 15:56:50 | FUCKYOU | |
| 15:56:31 | FUCKYOU | |
| 15:54:46 | FUCKYOU | Take CMXCI |
| 15:54:24 | FUCKYOU | |
| 15:51:57 | TEST | Take CMXC |
| 15:51:51 | VISUALSTUDIO | |
| 15:50:04 | KTHURA | |
| 15:45:00 | RESULT | |
| 15:42:27 | TEST | Take CMLXXXIX |
| 15:42:25 | TECHNO | ![]() As new data has been generated I need to do another run-time test |
| 15:34:04 | TEST | Take CMLXXXVIII |
| 15:34:01 | ANALYSIS | |
| 15:33:32 | RESULT | |
| 15:33:16 | VISUALSTUDIO | |
| 15:26:09 | FAILURE | MicroSCHOFT, THANKS FOR FUCKING EVERYTHING UP! |
| 15:25:51 | FAILURE | There never any telling how things will work after a restart due to a BSOD, especially not when it came right after a system update. |
| 15:25:10 | FAILURE | And meanwhile it even crashes completely. |
| 15:24:59 | FAILURE | Without any reason at all VS restarts stopping my debug |
| 15:24:43 | VISUALSTUDIO | |
| 15:24:37 | DEBUG | |
| 15:18:31 | FAILURE | ![]() Cool.... Visual Studio crashes on searching a solutin |
| 15:16:59 | REPORT | |
| 15:13:24 | TEST | Take CMLXXXV |
| 15:06:13 | REPORT | ![]() |
| 15:03:29 | TEST | Take CMLXXXIV |
| 15:03:28 | DEBUG | |
| 15:02:41 | RESULT | |
| 15:00:04 | TEST | Take CMLXXXIII |
| 15:00:02 | DEBUG | |
| 14:45:36 | INVESTIGATION | That taken in mind, I can at least rule out the absence of the required icons as an impossibility. But what next? |
| 14:43:15 | RESULT | (Although honesty requires me to note that I actually didn't even expect otherwise). |
| 14:39:36 | TEST | Take CMLXXXII |
| 14:39:34 | NOTE | |
| 14:39:18 | ART | Bandage roll (new art) |
| 14:39:10 | TRANSFER | Adhesive bandage |
| 14:26:55 | RESULT | |
| 14:25:50 | KTHURA | |
| 14:25:20 | SEARCH | |
| 14:20:20 | INVESTIGATION | Quick investigation shows that the code is present. The question is of course if the icons are all present already. I need to sort that out. |
| 13:27:37 | FAILURE | The day starts nicely with 2x BSOD. Cool! (Not!) |
| 00:48:43 | STATUS | For now I see what I wanted to see, and it's not very fruitful to continue right away. The next step will be to make sure the random treasures and the monsters are in the field. Both can cause me a lot of trouble, so I guess it only makes sense to take some reas first, eh? |
| 00:30:56 | TEST | ![]() Take CMLXXXI |
| 00:30:55 | COSMETIC | |
| 00:27:57 | TEST | Take CMLXXX |
| 00:27:56 | CODEROT | |
| 00:26:22 | TEST | ![]() Take CMLXXIX |
| 00:26:21 | VOID | List issues |
| 00:17:04 | TEST | Take CMLXXVIII |
| 00:17:01 | FIXED | It was not super handy, byt yeah, that debug line did save me! |
| 00:13:28 | TEST | Take CMLXXVII |
| 00:13:27 | VOID | Sigh! |
| 00:08:54 | TEST | Take CMLXXVI |
| 00:08:53 | DEBUG | |
| 00:00:56 | TEST | Take CMLXXV |
| 00:00:54 | FIXED | ![]() Did I fix it? |
| - = 06 Jan 2025 = - | ||
| 23:57:06 | DEBUG | |
| 23:57:03 | FIXED | Core syntax error |
| 23:55:55 | DEBUG | |
| 23:55:50 | DEBUG | |
| 23:51:20 | TEST | Take CMLXXII |
| 23:51:18 | CODEROT | |
| 23:48:19 | TEST | Take CMLXXI |
| 23:48:18 | FIXED | .ini suffix |
| 23:47:00 | TEST | Take CMLXX |
| 23:46:57 | FIXED | Not good.... no .neil, but .lbc |
| 23:46:01 | STATUS | All compiler crap appears to be accounted for, but what will the run-time do? |
| 23:45:19 | TEST | Take CMLXIX |
| 23:45:07 | FIXED | Syntax error |
| 23:43:50 | TEST | Take CMLXVIII |
| 23:43:48 | VOID | Unsupported intern function |
| 23:42:05 | FIXED | ![]() ![]() Variable transfer mistake.(Hello again, Wendicka. Back on the right side of the screen?) |
| 23:40:44 | TEST | Take CMLXVII |
| 23:40:43 | FIXED | WTF? |
| 23:40:08 | TEST | ![]() Take CMLXVI |
| 23:40:07 | VOID | ? |
| 23:39:19 | TEST | Take CMLXV |
| 23:39:17 | LINK | |
| 23:38:25 | TEST | Take CMLXIV |
| 23:38:25 | VOID | Loads of voids |
| 23:38:21 | FIXED | loads of fixes |
| 23:36:04 | TEST | Take CMLXIII |
| 23:35:30 | LINK | |
| 23:34:39 | TEST | Take CMLXII |
| 23:34:38 | FIXED | Scope error |
| 23:33:46 | TEST | Take CMLXI |
| 23:29:10 | TEST | Take CMLX |
| 23:29:09 | EXPERIMENT | |
| 23:28:54 | DONE | |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | ||