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 | ||
19:19 | POWERSHELL | I am required to do rebuild the game itself for that, though |
19:18 | EXPERIMENT | I need to find out if the animator is what causes things to turn invisible |
19:11 | NOTE | I've put in an extra precaution that should make sure all Kthura Maps are unloaded (this because Lua is on the rampage here and I don't want more trouble than I already got). |
19:01 | TEST | Take XXXV |
19:01 | DEBUG | An extra debug line should confirm if indeed most of the map was killed (for no apparent reason) |
19:00 | COCKROACH | Now the question is, of course, why this all happened |
18:59 | CHECKED | CWRITE> ____________XXX___XXX_________________X CWRITE> ___________XXX_____XXX________________X CWRITE> __________XXX_______XXX_______________X CWRITE> XXX______XX__________XXX___XXXX______XX CWRITE> ______________________________________X CWRITE> ______________________________________X CWRITE> ______________________________________X CWRITE> ______________________________________X CWRITE> ______________________________________X CWRITE> ______________________________________X CWRITE> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHalf of the blockmap is gone, which may indicate half of the map is gone as well |
18:57 | STATUS | At least the actors appear, but now we do have some other bones to pick... They are shown far too small, and their environment has gone.... I'd like to know why that happened. |
18:53 | TEST | Take XXXIV |
18:53 | FIXED | Syntax Error |
18:52 | TEST | Take XXXIII |
18:52 | FORCE | Kind |
18:43 | TECHNO | The destructor should be obsolete now |
18:26 | NOTE | Constantly All objects are being destroyed, I see |
18:25 | NOTE | Now I do have a few ideas to make the destructor obsolete, but still I need to check things out! |
18:25 | COCKROACH | Now the destructor is called while it shouldn't be (causing a crash in the process). |
18:12 | TEST | Take XXXII |
18:12 | STUPIDITY | != is not the same as ==, Jeroen! |
17:55 | FUCKYOU | It KEEPS insisting not not working! |
17:54 | TEST | Take XXXI |
17:54 | COCKROACH | Whatever causes this bug, it's persistent! |
17:54 | C++ | Fucked it all up AGAIN! |
17:40 | FORCE | I am not definitely pissed off! |
17:15 | COCKROACH | Even now that the actor could contain nothing but the correct data I get garbage |
16:59 | TEST | Take XXX |
16:59 | FIXED | I hope |
16:59 | SOLVED | I think I solved the case! (or is that wishful thinking?) |
16:53 | INVESTIGATION | Elementairy, my dear Watson! This can only mean that the parent layer is somehow not properly set in the Actor record, which should have happened... The question is, of course, why... |
16:52 | INVESTIGATION | Aha... Now the log makes more sense.... The layer for dominance remapping is declared a null pointer.... |
16:48 | TEST | Take XXIX |
16:48 | TEST | I do need to re-test as a few things in the IDE went wrong |
16:47 | SOLVED | Ah... C++ placed the error marker on the wrong spot (what else is new?) |
16:43 | HUH | The location where the crash is noted (a debug line just containing a "cout" and a constant string, is what surprises me the most , though. |
16:42 | COCKROACH | Apparently.... no work at all! I guess fate is against me after all! |
16:39 | NOTE | I can at least confirm that normal objects appear to be working under the new code |
16:38 | TEST | Well We're still counting on... test XXVIII |
16:38 | DONE | I needed a break before the great test would commence |
15:28 | C++ | And now it even deems the compilation succesful? Is it really done? |
15:28 | C++ | Hmm, it has stopped giving me errors in the Kthura library and now wans the adaptions for the API |
14:47 | STATUS | That's only half the work, though! |
14:47 | C++ | I think the core part of the operation is done.... |
13:00 | OFFTOPIC | DUMBLE-ROLLED!
:-P |
10:44 | TECHNO | With C++ desperately trying to get EVERYTHING in a bad manner, there is only one thing left for me to do... I'm gonna fuck up the Kthura library ENTIRELY! |
10:38 | COCKROACH | That experimental line was exactly where C++ didn't like me, at all |
10:36 | COCKROACH | As expected |
10:36 | TEST | Take XXVII |
10:36 | EXPERIMENT | I've tried something but I expect not much from it... |
10:33 | TEST | Take XXVI |
10:33 | DEBUG | MOAR stuff |
10:30 | RESULT | Things appear to go wrong when the actors are being called.... It was to be expected, yet, I wonder what the fuck is going on here! |
10:29 | TEST | Take XXV |
10:28 | DEBUG | I've added a debug line in the iterator... Hopefully it answers a few questions |
10:26 | NOTE | Is the iterator still broken? |
10:25 | FAILURE | The data in the debugging screen doesn't make sense at all.... What the fuck is going on here? |
10:22 | FAILURE | Returning a string is reason to crash? |
10:21 | TECHNO | I see now that the system does follow a different traceback route though, so that is a bit odd |
10:19 | TECHNO | I've ruled out possibilities for memory conflicts now, so NOTHING and I repeat NOTHING could have caused anything here.... Yet it still happens.... and the computer will have to clear up why! |
10:17 | COCKROACH | With no more reason to crash, it still crashes |
10:16 | TEST | Take XXIV |
10:16 | TEST | That was take XXIII btw |
10:16 | FIXED | Will backspace is a handy key, but still |
10:15 | HUH | Why did an identifier get cut in two over two lines? |
9:58 | TECHNO | The blockmap builder has NOT been done. It would a) be too much hassle and b) Actors were ignored by the blockmapbuilder even before this update because c) including actors in the blockmap builder is in 99% of the cases beyond stupidity to do anyway. |
9:56 | C++ | Labelmap builder updated |
9:56 | C++ | Tagmap builder updated |
9:54 | C++ | Dominance regenerator has been updated |
9:34 | TODO | But first a natural break |
9:33 | TECHNO | This will NOT yet affect the mappers, that will be the next step |
9:33 | C++ | The Kill All has also been set to clear both lists |
9:32 | C++ | And the killer will already respond to the correct vector in order to remove actors if they should be.... This should happen automatically |
9:32 | DONE | I've put the actors in their own vectors |
9:26 | TECHNO | And while I was in bed I realized why I've been stupid with the object list... After all, and I should have realized that, C++ is primitive, and so a memory conflict in using the way I used vectors was only bound to happen.... Since the listing system in both C# and BlitzMax only store the pointers and have a completely automated memory system around that I never realized this... C++ is, of course,a different story.... |
1:13 | TEST | Take XXII |
1:13 | MYSTERY | ALthough as an intelligent person, I don't understand how this could happen |
1:13 | FORCE | I've forced the actor spawner to rebuild the ID map though |
1:13 | MYSTERY | On Crystal the system crashes on being unable to find the object ID, on Wendicka this didn't bother the system |
1:10 | TEST | Take XXI |
1:10 | FIXED | Internal fixups |
1:02 | TEST | Take XX |
1:01 | FIXED | I hope I got it now |
0:56 | COCKROACH | The actor IDs remain 0 |
0:54 | HUH | texture ""? |
0:52 | TEST | Take XIX |
0:52 | FORCE | This should prevent it |
0:52 | FAILURE | The bug that happened now should not be possible, but did happen |
0:33 | TEST | Take XVIII Confirmed |
0:33 | FIXED | Well I fixed it! |
0:31 | FAILURE | I guess that's Microsoft for ya! |
0:31 | FAILURE | VisualStudio complained about bugs in strings, while the fault was made in my vector usage.... |
0:19 | VISUALSTUDIO | The error gets picked up in the xstring library on the tag of Wendicka's actor... Why this is happening is something I cannot tell, as the traceback only limits itself to the function where the fatality happens, but it doesn't tell me which function called the fatal function. |
0:17 | TEST | Take XVII |
0:15 | VISUALSTUDIO | Inside visual studio then and hopefully that produces some useful insights |
0:15 | NOTE | Stuff gets even stranger now as the game now crashes without any notice |
0:14 | TEST | Take XVII |
0:14 | C++ | Compile |
0:14 | EXPERIMENT | Part II done |
0:12 | EXPERIMENT | Part I done |
0:11 | NOTE | I see my API has a few advancements that now work against me, so I need to experiment on a bit |
0:08 | TEST | Take XVI |
0:08 | C++ | Adapted API to this experiment |
0:06 | NOTE | I think my entire approach may be faulty and if I'm right I guess I may be lucky I didn't get a segmentation fault |
- = 21 Sep 2020 = - | ||
23:56 | TEST | XV |
23:56 | NOTE | Can't be it, but here goes nothing |
23:56 | EXPERIMENT | I wonder what happens if..... |
23:54 | TEST | Take XIV |
23:54 | NOTE | Why the tags do not change I cannot tell though |
23:54 | FIXED | I've at least fixed the ID... |
23:51 | DONE | a few more things |
23:49 | NOTE | A few issues do arise here.... First of all not the correct object ID(), which should happen... But I guess that's only natural, and second NO TAG! |
23:46 | TEST | Take XIII |
23:46 | C++ | Done |
23:46 | STUPIDITY | Forgot to compile and that debug line was in the C++ code |
23:45 | TEST | Take XII |
23:45 | DEBUG | Ultimate debug line and let's see if this provides some answers! |
23:42 | COCKROACH | The forcing didn't help and the created output by the tag list confirms the actor is not listed in the tagmap |
23:40 | TEST | Take XI |
23:40 | DEBUG | Extra debug line |
23:40 | FORCE | I've forced the system to always rebuild the tagmap whenever actors are being created, regardless of underlying configuration settings |
23:38 | MYSTERY | So far the logs confirm the entire claim is nothing more but bullshit |
23:36 | TEST | Take X |
23:36 | TEST | Let's see |
23:36 | DEBUG | Extra debug line |
23:09 | TEST | Take IX |
23:09 | FIXED | Field name != Object tag |
23:08 | CONFIRMED | That at least covers the issue of having no actor with the specific tag |
23:00 | TEST | Take VIII |
23:00 | FIXED | But I think I got it now |
23:00 | COCKROACH | Nope! |
23:00 | TEST | Take VII |
22:18 | FIXED | ? |
22:14 | MEDICAL | No this has NOTHING to do with corona... I am just traumatized about things that happened over the entire course of my life, and that is getting onto me. |
22:14 | MEDICAL | My stress is really getting the best of me |
19:14 | TEST | Take VI |
19:14 | FUCKYOU | Link up error |
19:12 | TEST | Take V |
19:12 | FIXED | no "return" |
19:09 | TEST | Take IV |
19:09 | FIXED | Syntax Error |
19:09 | TEST | Take III |
19:09 | FIXED | Forgotten declaration? |
19:08 | TEST | Take II |
19:08 | FIXED | Fixed Syntax Error? |
19:06 | TEST | Take I |
19:06 | STATUS | Does it work? |
19:06 | DONE | Actor texturing |
15:56 | MEDICAL | Stress got the better of me... I need a time-out! |
13:40 | NOTE | I still need to texture them out, though |
13:40 | DONE | Actor spawning |
13:35 | STUPIDITY | It does appear I forgot a few things |
13:20 | CONFIRMED | Well, I guess that appears to be the case... Of course, there's still le moment supreme |
13:18 | TEST | Take I |
13:18 | STATUS | Now before I get to the actual testing of the actors I wanna test if the link script compiles now. If the title screen appears without question I guess it does. |
13:05 | C++ | Compilation gives no errors... Is that a good thing? |
12:52 | NEIL | Script part taken care of! |
12:48 | STATUS | Not there yet! I need to make sure the Kthura classes are able to work this out properly. |
12:47 | LINK | WalkTo and MoveTo linked to scripter |
12:46 | LINK | Spawner linked into scripter |
12:41 | APOLLO | API functions have been written... Not yet been linked to the scripting engine.... |
10:41 | STATUS | That finishes the hardcore stuff in Kthura, Apollo cannot yet handle all this as the APIs that allow Kthura with the scrips have not yet been written, at least not where actors in particular are concerned |
10:27 | C++ | Code compiles, and that's all I can test now, so far: Geen bericht is goed bericht! |
10:27 | KTHURA | Driver updated |
10:05 | STATUS | And thus that will be the next step, and also a crucial one as I cannot test anything without that driver being updated |
10:05 | TECHNO | Now the actors only work from core, the draw routine will call the driver to actually show the actor and that's also where the road ends for now, as the driver has not yet been updated for that. |
8:24 | OFFTOPIC | |
1:25 | BACKUP | Running |
0:50 | STUPIDITY | And I'm writing in the wrong devlog I see |
0:50 | SASKIA | Empty base script |
0:44 | STUPIDITY | HOLD THE SHOW! I forgot some mortally important things! |
0:31 | TEST | Let's see of the Hall of Heroes works so far! |
0:31 | REMINDER | |
0:29 | LINK | I've linked this map to the world map |
0:10 | NOTE | The ones who you should meet in the Hall of Heroes will NOT yet appear! |
0:09 | MAP | Basis Map Hall of Heroes |
- = 20 Sep 2020 = - | ||
23:58 | DYRT | Time was also not friendly enough to do my Dyrt duties, although I think I can do a few tiny things |
23:57 | STATUS | However the time has come to a point that I'm not really game to test if it works... |
23:57 | KTHURA | The Actor Class has been set up |
22:36 | KTHURA | I will now have to work out the actor class... Now actors are merely an extension to objects, however actors have to be more versatile, and this versatily brings that they gimme more data to cope with... |
22:34 | APOLLO | At least Apollo compiles, and up to this point no news is good news... I will have to see later if it actually works |
22:32 | KTHURA | You've got to keep in mind though that the pathfinder can only be put to the test once the actors work, and the actors have always been a nasty thing in Kthura. They will require some workout before I can put this all to the test |
22:30 | KTHURA | It's all done now |
22:00 | KTHURA | I've created the Dijkstra driver for Kthura |
14:08 | KTHURA | I've added a Kthura point class... The module I'll use path finding will have to use this class to make sure all output regardless of pathfinding module used will aways output the data in the same format so Kthura can understand it |
13:03 | STATUS | Now the next course of action will be to attack Kthura to my Dijkstra routine, now in order to make Kthura even more modular than ever before I'm gonna make Dijkstra a driver for Kthura. Now I will likely stick with my Dijkstra routine forever... (I don't have much need for anything else), I can this way make Kthura operate without Dijkstra when no pathfinder is needed (saves RAM) and if Kthura ever gets adopated by other people, they can then use their own pathfinding routines if they desire, so all in all, it's the better run and not that hard to code in C++ anyway (it was not even hard to code in C#, but I was back then too much in a hurry). |
12:58 | CONFIRMED | The blockmap output shows me what I wanted to see |
12:56 | TEST | Take II |
12:56 | FIXED | That's not good! |
12:54 | TEST | Take I |
12:54 | STATUS | Well, what will this all produce? |
12:50 | DEBUG | My Debug script allows me into this data now |
12:44 | NOTE | NOT there yet, thougg! |
12:44 | LINK | And now the link is complete |
12:44 | NEIL | Neil code |
12:40 | LINK | Part of the link |
12:40 | APOLLO | integrated |
12:33 | C++ | I've set up an API allowing the Apollo Scripter to readout the BlockMap for debugging purposes |
12:21 | DONE | took a shower |
11:33 | FIXED | Minor issues |
11:24 | FIXED | Something was not right in the BlockMap Checker |
11:23 | C++ | The blockmap builder has been done, but is not yet fully operational |
10:58 | TECHNO | No this will NOT compile C++ != C# after all, so I need to adapt things as a result! |
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 |