| 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 | ||
| 16:28 | STATUS |  Success! |
| 16:28 | C++ |  Let's try that again! |
| 16:28 | FIXED |  AHA! |
| 16:28 | FAILURE |  Compiler didn't like that! |
| 16:26 | C++ | Compiling! |
| 16:25 | APOLLO |   And another API feature richer, I guess |
| 16:25 | LINK |  That should link it all together |
| 16:25 | NEIL |  Glue code |
| 16:23 | C++ | Has Object tag? |
| 11:12 | STATUS | I'm gonna push this crap and take a break |
| 11:11 | DUMMIED |  Debug code I no longer need |
| 11:11 | STATUS | Problem solved! |
| 11:09 | TEST |  Here goes! |
| 11:09 | C++ | And then I can now do the C++ test |
| 11:05 | APOLLO | Before I can test I first need to rebuild my resources, since part of the trouble was in the script |
| 11:05 | STATUS | So this should mean the coordinates are fixed now.... If this is true remains to be seen, since this still does not fully fully explain Wendicka going diagonally, but hey, I've seen crazier things.... |
| 11:04 | FIXED |  And the script sent through the wrong variables as I had some ready in which the coordinates were already calculated through |
| 11:03 | FIXED | That should no longer happen |
| 11:03 | SOLVED |  Dijkstra tried to calculate the start position AGAIN, while it shouldn't do it.... A leftover from trying to extract these from the actor while that didn't work at all... |
| 11:01 | RESULT | Actor PLAYER is walking to (606,418) (real:1) Layer:YAQIRPA KthuraActor.YAQIRPA::WalkTo(606,418,1)! Start point: (976,1728) Calc (if applicable): >> (30,54) -> (18,13) grid: 32x32 Dijkstra debug - succes: 0; Length: 1(0,1) -> (18,13) Dijkstra debug: Node #0 (592(18), 448(13)) This tells me a few things.... First of all Dijkstra does get (0,1) as start position, but that is not the position being sent as that is (30,54), which also appears to make more sense from my own calculations. Second, the destination appears to be calculated from the pure mouse coordinates, but the scroller modifications were not received, and that is very extremely strange at best, as the script did instruct the engine to...... The latter should be easy to work out, the former should not be possible given the parameters I set up, but hey, let's solve these ONE BY ONE, shall we? |
| 10:57 | NOTE |  ANd hopefully I get data now that makes sense! |
| 10:56 | TEST | Well, let's see what this data pops up..... |
| 10:54 | DEBUG |  My list of possibilities to figure this out grows thin..... Nothing makes sense |
| 10:50 | TEST | Well, let's see what we'll get here..... :-/ |
| 10:50 | DEBUG | More workout required, I guess! |
| 10:47 | DEBUG | 000000001 | // Mapstuff 000000002 | Init 000000003 | FldMap.ScrollX = 16 000000004 | FldMap.ScrollY = 1188 000000005 | FldMap.AutoScroll = true 000000006 | GrPlayer.X = 976 000000007 | GrPlayer.Y = 1728 000000008 | GrPlayer.Wind = "NORTH" 000000009 | endThis is the data inside the savegame.... No way those coordinates could (divided by 32) come to (0,1), really! |
| 10:46 | NOTE | Now the start point (0,1) already doesn't make sense, and what (17,4) is based upon, I really don't know |
| 10:44 | RESULT | > > * > ******* > > > XXXXXX > XXXXXX > XXXXXX > XXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXX XXXXXXXXXXXXXX XXX > XX XXX > XX XXX > XX XXX > XX XXX > XX XXX > XX XXX > XX XXX > XXXXXXXX XX XXX > XX XX XX XX XXX > XX XX XX XX XXX > XX XX XX XX XXX > X X XX XXX > X X XX XXX > X X XX XXX > XXXXXXXX XX XXX > XX XXX > XX XXX > XX XXX > XX XXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > X X XXXXX > XXXXXX XXXXXX XXXXXXXXXXX > XXXXXXX XXXXXX XXXXXX XXXXXX XXXXXXXX XX XXXXX > XX XX XXXXXXXXXX XX XXXXXXXX XXXXXXXX XX XX X > XX XX XXX XX XXX XX XXX XXX XX XX XXX > XX XX XXX XX XXX XX XX X XX XXX > X XX XX XX X X XX > X X X X X XXXXX > X X X X X X > XXXXXXXX X X XXXXXXXXX > XXXXXX XXXXXXX X > X XX X X XX > XXXXXXX XXXXXXXXXXXXXXXXXX > X XXXX X X XXXXXXXXXXXXXX > XX XX XXXXXXXXXXXXXX > XXX XXXXXXX XXX > XXX XXXXXX X > XX XXXX  Whatever that is... The blockmap seems good, but the route doesn't make sense at all! |
| 10:42 | TEST | Well? |
| 10:42 | FIXED | Ah, I see my mistake |
| 10:41 | JUDGMENT |  That data is USELESS! |
| 10:40 | TEST | Here goes! |
| 10:40 | DEBUG | MOAR debug lines will have to tell me the truth about matters |
| 10:25 | RESULT | Actor PLAYER is walking to (566,156) (real:1) Layer:YAQIRPA KthuraActor.YAQIRPA::WalkTo(566,156,1)! Dijkstra debug - succes: 1; Length: 21(0,1) -> (17,4) Dijkstra debug: Node #0 (16(0), 64(1)) Dijkstra debug: Node #1 (16(0), 96(2)) Dijkstra debug: Node #2 (16(0), 128(3)) Dijkstra debug: Node #3 (16(0), 160(4)) Dijkstra debug: Node #4 (48(1), 160(4)) Dijkstra debug: Node #5 (80(2), 160(4)) Dijkstra debug: Node #6 (112(3), 160(4)) Dijkstra debug: Node #7 (144(4), 160(4)) Dijkstra debug: Node #8 (176(5), 160(4)) Dijkstra debug: Node #9 (208(6), 160(4)) Dijkstra debug: Node #10 (240(7), 160(4)) Dijkstra debug: Node #11 (272(8), 160(4)) Dijkstra debug: Node #12 (304(9), 160(4)) Dijkstra debug: Node #13 (336(10), 160(4)) Dijkstra debug: Node #14 (368(11), 160(4)) Dijkstra debug: Node #15 (400(12), 160(4)) Dijkstra debug: Node #16 (432(13), 160(4)) Dijkstra debug: Node #17 (464(14), 160(4)) Dijkstra debug: Node #18 (496(15), 160(4)) Dijkstra debug: Node #19 (528(16), 160(4)) Dijkstra debug: Node #20 (560(17), 160(4)) I am not sure if what these numbers show is in compliance with the truth |
| 10:22 | TEST | Well since sometimes the stuff is as trivial as that I need to run another test! |
| 10:14 | FIXED | Well, part of the issue was due to an x value being defined as a y... that is fixed at least |
| 10:13 | NOTE | And what Dijkstra produces after appears to make sense, but the node translator in Kthura turns it into very strange crap.... really |
| 10:11 | RESULT | Actor PLAYER is walking to (553,429) (real:1) Layer:YAQIRPA KthuraActor.YAQIRPA::WalkTo(553,429,1)!Dijkstra debug - succes: 0; Length: 1(0,1) -> (17,13) Dijkstra debug: Node #0 (32(0), 0(0)) NONE of the numbers shown make sense... well except maybe for the destination coordinates the Dijkstra driver produces, and really... that's all.... |
| 10:09 | TEST |  And let's try that again, shall we? |
| 10:09 | FIXED | Well fixed that crap up |
| 10:01 | NOTE | What I do see though is that Wendicka's y coordinate even went to -1.... Negative numbers should NEVER pop up, so things are really busted |
| 10:01 | STUPIDITY |  Placed the debug logging routines in the wrong function, so that's why the data I asked for didn't appear.... STOOOOOOOOOPID! |
| 9:59 | TECHNO | Now these were issues I faced before in Kthura for BlitzMax too, but it's always a big hassle to find out what is causing that.... |
| 9:58 | NOTE | it's clear that Dijkstra did not understand at all what to do, ro that the Kthura is bugged on the data sending to Dijkstra.... Wendicka went to a spot where she clearly should NEVER have gone to, and since she's also not allowed to walk diagonally, stuff is really busted.... I really need to sort this all out! |
| 9:50 | TEST | Let's see now! |
| 9:50 | DEBUG | Node debugger added |
| 9:44 | NOTE | Nothing happens, but at least no crash! |
| 9:40 | DEBUG | Different approach as this is getting nowhere... When everything about this matter is impossible we do need another way to do things! |
| 9:35 | NOTE | So whatever goes wrong, everything points to the Dijkstra routine now |
| 9:34 | DEBUG | Even the WalkTo line itself works the way it should |
| 9:28 | DEBUG | That line really rules out all possibilities for this crash to happen.... |
| 9:28 | RESULT | "Actor PLAYER is walking to (550,111) (real:0) Layer:YAQIRPA" |
| 9:27 | DEBUG | Ultimate test.... I a good layername pops up, it's proven computers CAN lie |
| 9:26 | DEBUG | The debug data still denotes the crash is impossible |
| 9:24 | TEST | Let's see.... |
| 9:24 | DEBUG | The only possibility i can think of now is that the actor is not properly retrieved by the Apollo-Kthura-API |
| 9:17 | DEBUG | This would imply that whatever goes wrong, the WalkTo routine would be to blame, eh? |
| 9:15 | DEBUG | Nope I do get the same data... it was just a small formula error in my debug line |
| 9:14 | DEBUG | Now let's see |
| 9:12 | HUH |  No output, but no crash either! |
| 9:11 | DEBUG | I've set up another way to enforce the same crash upon spawning |
| 9:11 | COCKROACH |  Bugs that don't exist can also not be fixed... |
| 9:10 | CONFIRMED |  The crash is indeed a lie |
| 9:08 | DEBUG | Debug This will enforce a crash upon creation... At least, it has to, because if it doesn't it's confirmed all the more the walk crash cannot happen |
| 8:52 | DEBUG | More debug lines (not that they can answer much, due the the impossible claims made by the game). |
| 8:47 | ANALYSIS |  The claims done about the actor's parent layer are beyond ridiculous |
| 0:06 | TEST | Well, let's see.... |
| 0:06 | ANALYSIS | Well Just as I thought... Exhausted as I am, but I couldn't resist |
| - = 30 Sep 2020 = - | ||
| 23:51 | STATUS | However I'm tired and I need my rest now.... |
| 23:51 | TECHNO | I need to fully study this one out, and that may not be easy |
| 23:49 | DEBUG | The error C++ throws in Visual Studio doesn't make that much sense, but makes me think a NULL referrence is made, and now to find out how this could happen, as that would mean the actor has likely no parent, which should not be possible. |
| 23:40 | TEST | And see what happens next! |
| 23:40 | VISUALSTUDIO |   Let's take the testing to VisualStudio now then.... |
| 23:39 | COSMETIC |  Savegame names will no longer appear through "LOADING" |
| 23:38 | INVESTIGATION |  And I guess I will now have to find out WHY! |
| 23:37 | FAILURE | Total crash upon walking |
| 23:32 | TEST | And well, let's see now then, eh? |
| 23:32 | POWERSHELL |  BARF |
| 23:32 | FIXED | Should be fixed now |
| 23:32 | STUPIDITY | The Apollo linkup features are all in caps, Jeroen, and even Neil cannot change THAT |
| 23:24 | FAILURE | WalkTo == nil value? |
| 23:23 | TEST | And let's see what happens next... |
| 23:23 | VOID |  Right-o |
| 23:22 | FUCKYOU |  Alright, this is an issue with Neil not yet covering orders up well, I guess |
| 23:21 | TEST | And another test will then have to tell me more! ;) |
| 23:21 | STUPIDITY | For starters I forgot to save my code, and then this was nothing more but the only possible outcome |
| 23:20 | NOTE | This is not really telling me much, though.... I just need to check a few things before I can draw any conclusions at all! |
| 23:19 | BUG | Nothing happens |
| 23:11 | NOTE | A lot of under-the-hood coding in C++ has been done before I could actually reach this point... There is as such not telling at all if this will work or not... All I can do is hope for the best! |
| 23:10 | DONE |  WalkTo request |
| 23:01 | CONFIRMED | What the debug log shows is completely in line what I expected to see |
| 22:41 | DEBUG | I've also set up a console command which will tell me the coordinates of the PLAYER actor.... That is the actor representing you (I guess that was obvious). |
| 22:39 | LINK | And I've linked that routine to the callback |
| 22:39 | SCRIPT |  Before I get to the walking itself I first want to test if the coordinates are properly processed |
| 22:35 | TECHNO | Then again, you can only read this post when that update has taken place, hahaha! |
| 22:34 | TECHNO | Will automatically update on all posts on the next update |
| 22:34 | SITE |  "Checked" icon added to this devlog |
| 22:33 | NOTE | I still didn't hide what should be hidden, this is because I need Zone Actions for that, but the zone actions require the walking routines to be fully operational before they can be properly tested, so that's why I'll focuss on walking around first! |
| 22:32 | JUDGMENT | And the blockmap I see is the blockmap I WANTED to see |
| 22:31 | TECHNO | This check is needed to make sure the blockmap will NOT be the factor that messes up walking around, you nsee |
| 22:31 | CHECKED |  I've done a blockmap check |
| 21:29 | BACKUP |   Running! |
| 21:15 | STATUS | But first a little break! |
| 21:13 | NOTE | And in the Yaqirpa (and only there) a kind of "follow-the-leader" system will be in place |
| 21:13 | STATUS | The next step is to make walking around possible... |
| 21:08 | NOTE | Problem solved, hahaha! |
| 21:06 | NOTE | Not too much bother though... It only requires me to resort to a bit of dirty code, that's all.... |
| 21:06 | NOTE | Right.... How could I forget.... Neil only executes group constructors the first time a group is being accessed..... |
| 21:05 | TEST | ... |
| 21:05 | EXPERIMENT |  Well? |
| 21:05 | NOTE | Wait a minute! |
| 21:03 | DEBUG | I've added one more clause to definitely seal this.... |
| 21:03 | CONFIRMED | The mapscript is not loaded.... The constructor in the MapScript group would have been triggered if it was.... |
| 21:01 | NOTE | An extra line the system cannot refuse (no, I'm not the Godfather), should give me an answer. If the system refuses that confirms only more that stuff is not loaded the way it should be. |
| 21:00 | DEBUG | The debug log shows everything SHOULD have worked.... Since it didn't more investigation is needed |
| 20:55 | TEST | And well? |
| 20:55 | DEBUG | One Debug line added I now do need |
| 20:55 | DUMMIED | Debug line I no longer need |
| 20:38 | INVESTIGATION | And now to find the answer the the question "Why!" |
| 20:38 | NOTE | It appears (so the logs imply) the mapscript is not loaded when loading the map from a savegame file.... |
| 20:36 | TEST | .... |
| 20:36 | NOTE | Let's see why the transpad isn't removed! |
| 19:18 | STATUS | I need a break, now! |
| 19:18 | NOTE | That is a later concern, though |
| 19:17 | BUG | Except for the transporter pad that should not be there during the prologue |
| 19:17 | NOTE | Most what I see is what I want to see |
| 19:08 | TEST | Let's see then.... |
| 19:08 | VOID | That should cover that issue |
| 19:07 | DONE | Not the most elegant method, but hey, what works, that works! |
| 19:07 | CONFIRMED | This was indeed the reason |
| 19:02 | NOTE | Although I do have a feeling I know what's happening here! |
| 19:01 | BUG |  Briggs being level 20 (which is a stat) shows the stats apparently load properly... No errors due to divisions by zero seem to indicate the point maxima are loaded properly, but the amount of points the characters have is another story... Or so it seems.... |
| 18:58 | TEST | And another test is in order! |
| 18:58 | FIXED | Unwanted fallthrough |
| 18:58 | CONFIRMED | Seems to be so! |
| 18:57 | TEST | But does that work, now? |
| 18:57 | FIXED | Well that's been fixed now of course! |
| 18:56 | STUPIDITY | Pointer declared and defined as NULL *INSIDE* the loop...... Fuck you, Jeroen! This is BEYOND stupidity! |
| 18:55 | INVESTIGATION | Now this pointer should never possible be NULL, so let's see what's happening here. |
| 18:53 | NOTE | The question is now how this can happen! |
| 18:53 | CONFIRMED | Just as I thought... Not the string was the issue, but the pointer! |
| 18:52 | TEST |  Well? |
| 18:52 | DEBUG | Let's see..... |
| 18:45 | TEST | Well? |
| 18:45 | EXPERIMENT | What does this do? |
| 18:42 | TEST | Well let's see.... |
| 18:42 | FIXED | Fixed? |
| 18:40 | BUG | I see that the directory stripper is bugged..... It puts in the last slash, and it shouldn't be there |
| 18:38 | DEBUG | Moar debug stuff |
| 18:37 | DUMMIED | I've dummed the Kthura object killer debug output.... At the present time I don't need that anymore! |
| 18:36 | NOTE | So far everything in the logs looks like the way it should look |
| 18:33 | TEST |  Well, all I can do now is test |
| 18:26 | DEBUG | I've set up a quick macro which should get up some more clarity on this one! |
| 18:16 | DEBUG | Now the question is WHY this happens |
| 18:15 | BUG | The only thing that could cause this is when maxima are all set to 0.... And that means the party data is not properly loaded! |
| 18:14 | BUG | I see..... |
| 18:13 | BUG | Huh? |
| 18:13 | TEST | Let's see |
| 18:12 | TECHNO | Speed is the reason I chose the way I did |
| 18:12 | DONE | Party Sub auto-load |
| 18:10 | TEST | Well, if this works, we can really get into the game itself |
| 18:09 | DONE |  And now the setup has been done to enter the FIELD flow once loading a savegame is succesful |
| 17:43 | TEST | Well? |
| 17:43 | FIXED | DORK! |
| 17:29 | TEST | Well, let's see! |
| 17:29 | VOID | Voided that issue! |
| 17:09 | STATUS | With this all set, I can make sure the game links through to the Field Flow |
| 17:06 | TODO | |
| 17:03 | NOTE | Please note that during the prologue, only Wendicka can lead the group, but after the prologue all playable characters can be put in the lead |
| 17:02 | SCRIPT | The setup to automatically get the player sprite to have the correct texture based on who is the leader |
| 16:52 | DEBUG | A way to check stuff |
| 16:35 | TECHNO | I did realize that the leader was not yet set... This is a bit of an error on my side, but not one that is impossible to fix, or to void, without having to create new savegames files... Of course, I have not yet a file that can fully login to Game Jolt... |
| 16:32 | STATUS | The effect I was hoping for as what I get now |
| 16:06 | TEST | Take V |
| 16:06 | REMOVED |  Protection can sometimes work against you, and being a bit unsafer can sometimes be the better call, I suppose |
| 16:05 | FUCKYOU | DAMN! |
| 16:04 | TEST | Take IV |
| 16:04 | NOTE | BARF = Build Apollo Resource File What else did you expect? |
| 16:04 | POWERSHELL | Let's run BARF again |
| 16:03 | COCKROACH | Fix ignored! |
| 16:02 | TEST | Take III |
| 16:02 | POWERSHELL |  Barf script |
| 16:01 | FIXED | Illegal API function call |
| 15:58 | TEST | Take II |
| 15:58 | FIXED | Invalid method called |
| 15:55 | TEST | Take I |
| 15:55 | STATUS | Wish me luck! |
| 15:54 | NOTE | Some things are not yet saved though, like achievements and stuff... I simply can't do all at once, you know |
| 15:54 | NOTE | The most notable effect will now be that "LOADING" appears on screen, and that the music changes to the background music of the Yaqirpa. This does not yet do much in sight otherwise, but if all that happens without crashing, it's only a matter of linking things up further |
| 15:53 | LINK | I've linked that now the the save game loader |
| 15:51 | NOTE | That is the code for that has been written now... There's still a lot more to do to make it actually work! |
| 15:49 | DONE |  The map stuff should now also be taken in order |
| 15:29 | DYRT |  Stuff done! |
| 14:57 | STATUS | I'll first get into some tests in Dyrt.... So be back later! |
| 9:53 | FIXED | I *THINK* I fixed #210 for real now, but I'm not sure |
| 1:33 | STATUS | And more work next time! |
| 1:33 | BACKUP | Running! |
| - = 29 Sep 2020 = - | ||
| 21:35 | CONFIRMED | Well at least the GameVars appear to be working now |
| 21:32 | TEST | Taek XVIII |
| 21:32 | FIXED | Oh, not a property, just an undentified metatable not linked |
| 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 | ||
