| 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 | ||
| 21:11 | NEIL |  Glue code |
| 21:07 | LINK |  Part of the link done that way |
| 21:07 | APOLLO |  Attached as an API |
| 21:06 | C++ |  Is in zone function for Apollo |
| 21:04 | VOID |   I hope I voided that no CONSOLE flow issue |
| 21:01 | STATUS |  Yeah, with IsInZone a valid error pops up |
| 21:00 | TEST |  Take VIII |
| 20:59 | LINK |  I've linked the ZoneAction to the main flow |
| 20:58 | HUH |  I do not know why it complains about the CONSOLE flow, as there is no reason for this to happen |
| 20:55 | TEST | Take VII |
| 20:55 | VOID | Did I void this? |
| 20:55 | HUH | Member is not static... Of course it's not... it was not even a static call.... |
| 20:51 | TEST | Take VI |
| 20:51 | FIXED |  Init needed |
| 20:40 | TEST | Take V |
| 20:40 | FIXED | Wrong variable |
| 20:35 | TEST | Take IV |
| 20:35 | FIXED | Fixed that |
| 20:35 | FUCKYOU |  I do need to set this right, eh? |
| 20:31 | TEST | Take III |
| 20:31 | STUPIDITY |  Ah! |
| 20:30 | HUH | FUNCTION VALUE????????? |
| 20:26 | TEST | Take II |
| 20:26 | FIXED | Syntax error |
| 20:21 | TEST | Take I |
| 20:21 | NOTE |  Now it comes down to hiding and showing by labels.... Something the API does not yet support. I did however put a debug line in the first event.... It should cast a message if it works.... |
| 20:16 | LINK | Zone Action |
| 20:09 | NOTE | Of course, the linker has not yet been set up, and that means that everything it still possible |
| 20:08 | STATUS | No more crashes |
| 20:07 | TEST |   Take VI |
| 20:07 | FIXED | only " make a string in Neil... not ' |
| 19:20 | FIXED | I think I fixed all unknown identifiers |
| 19:18 | VOID | Voided that issue |
| 19:09 | BUG |  I really must find out why Neil doesn't accept "self" in Destructors |
| 19:08 | TEST | Take V |
| 19:08 | FIXED | Destructor definitions are a bit different in Neil |
| 19:07 | TEST | Take IV |
| 19:06 | DUMMIED |  Kettingkaart -- For the short term I won't need it, and when I need it I think I must recode that anyway |
| 19:03 | TEST | Take III |
| 19:03 | POWERSHELL |  BARF needed |
| 19:02 | BUG | This error was in a bug routine, so another error is expected, but at least I can now see what it is, and very likely also WHERE it is! |
| 19:02 | FIXED | Syntax error in Neil itself |
| 18:59 | TEST | Take II |
| 18:58 | VOID | For now I'll void that... I don't need it anyway, and in the rare occasions I still might (I don't expect them) there are tons of ways around this.... |
| 18:57 | COCKROACH | I see that infinity is still not operating the way it should |
| 18:54 | STATUS | All I can test so far is if no errors occur, but that already counts for a lot.... Neil is still pretty fragile, you see.... |
| 18:54 | TRANSFER |  Zone Action main script has been transferred and been adapted for Neil |
| 18:31 | FIXED | I think I fixed the fact that "infinity" was ignored by Neil |
| 18:22 | STATUS | This means that I am ready now to get onto the ZoneAction routines.... And these are very important, as 99% of the stuff happening in the game is bound to that, and don't underestimate it as there are many things taken care of by this routine than you think. Not only the activating of bosses or scenarios, but stairways linking to each other also happen through all this.... |
| 18:12 | CONFIRMED |  It works! |
| 18:11 | TEST | Take II |
| 18:10 | POWERSHELL | Barf |
| 18:08 | FIXED | Fixed |
| 18:08 | BUG | Linkup error |
| 18:05 | TEST |  I need to test if this works, though |
| 18:01 | NOTE | This should also work on if Wendicka walks on while a BoxText is up |
| 18:01 | SCRIPT |  AutoTexPlayer is now part of the CallBack setup.... This should also cause Wendicka to automatically turn her face as she walks |
| 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..... |
| 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 | ||