I can fix the savegame manually

the code itself

WTF? Why was the layer name not saved as a string?

Take VIII

Hmmm

The question is now why the hiding of objects is being ignored

FINALLY!

Take VII

PLEASE!

Fix ignored!!!

Take VI

Why do so many nonsensical errors pop up when I only need to have a savegame linked to Game Jolt?

Take V

!

GRRRR!

Take IV

Hopefully this fixes that

It falls over the fact that the player is not yet present

I do not know why but nothing happens

Take III

Forgotten "end"

Take II

Syntax error in mapscript

Glue error in Kthura Neil linkup code

Take I

I've set the mapscript to show and hide stuff by label accordingly now, and I've also linked them to the ZoneAction routine

VERRRRRY important, you know!

I've set this all right now in the general map link code, so I can easily access it from mapscripts

Compiling

And that links it all indefinitely

Neil glue code

NOT THERE YET!

Linked to scripting engine

API functions

And about 500 error messages disappeared in the process.... sheesh!

Removed a } on a very crucial spot where it shouldn't have been

There's also the Apollo part of the code

That covers the part of the Kthura core code

Showing and hiding by label has now been coded in the core of Kthura

This will require me to dive into Kthura itself, as this is a core feature

The next part will be the possibility to hide and show based on the labels

It seems to work now!

At least I now know that the CONSOLE error doesn't appear anymore

Not sure if this will work, but I gotta try things out

I do see a dramatic drop in the fps....
Now this not always to blame on the current code, so I need to be careful before setting conclusions to this...

I think I got the "No "CONSOLE" flow" error under control now...

Take XVI

Sigh!

Take XV

I see why the MapScript didn't work

First of all is it beyond me why the Zone Action doesn't trigger on the spawnplayer, which is also odd....

"Nil" value is not possible... This is a fully automated metatable...

Take XIV

I think

This is odd... Maybe I linked things differently in Dyrt

WTF????

Take XIII

Hopefully that fixes stuff

I've brought the IsInZone to the collective object

"Main Object must be either Object or Actor (it is a )"

Take XII

The error cannot be happening, but I expanded the error in order to get more clarity on this bullshit

Take XI

Let's NOT talk about that one!

Take IX

I configured Visual Studio to perform the BARF automatically whenever I compile the C++ code

Compiling

And that links it all

Glue code

Part of the link done that way

Attached as an API

Is in zone function for Apollo

I hope I voided that no CONSOLE flow issue

Yeah, with IsInZone a valid error pops up

Take VIII

I've linked the ZoneAction to the main flow

I do not know why it complains about the CONSOLE flow, as there is no reason for this to happen

Take VII

Did I void this?

Member is not static... Of course it's not... it was not even a static call....

Take VI

Init needed

Take V

Wrong variable

Take IV

Fixed that

I do need to set this right, eh?

Take III

Ah!

FUNCTION VALUE?????????

Take II

Syntax error

Take I

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....

Zone Action

Of course, the linker has not yet been set up, and that means that everything it still possible

No more crashes

Take VI

only " make a string in Neil... not '

I think I fixed all unknown identifiers

Voided that issue

I really must find out why Neil doesn't accept "self" in Destructors

Take V

Destructor definitions are a bit different in Neil

Take IV

Kettingkaart -- For the short term I won't need it, and when I need it I think I must recode that anyway

Take III

BARF needed

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!

Syntax error in Neil itself

Take II

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....

I see that infinity is still not operating the way it should

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....

Zone Action main script has been transferred and been adapted for Neil

I think I fixed the fact that "infinity" was ignored by Neil

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....

It works!

Take II

Barf

Fixed

Linkup error

I need to test if this works, though

This should also work on if Wendicka walks on while a BoxText is up

AutoTexPlayer is now part of the CallBack setup.... This should also cause Wendicka to automatically turn her face as she walks

Success!

Let's try that again!

AHA!

Compiler didn't like that!

Compiling!

And another API feature richer, I guess

That should link it all together

Glue code

Has Object tag?

I'm gonna push this crap and take a break

Debug code I no longer need

Problem solved!

Here goes!

And then I can now do the C++ test

Before I can test I first need to rebuild my resources, since part of the trouble was in the script

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....

And the script sent through the wrong variables as I had some ready in which the coordinates were already calculated through

That should no longer happen

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...

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?

ANd hopefully I get data now that makes sense!

Well, let's see what this data pops up.....

My list of possibilities to figure this out grows thin..... Nothing makes sense

Well, let's see what we'll get here..... :-/

More workout required, I guess!

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 | end

This is the data inside the savegame.... No way those coordinates could (divided by 32) come to (0,1), really!

Now the start point (0,1) already doesn't make sense, and what (17,4) is based upon, I really don't know

>
> *
> *******
>
>
>                                             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!

Well?

Ah, I see my mistake

That data is USELESS!

Here goes!

MOAR debug lines will have to tell me the truth about matters

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

Well since sometimes the stuff is as trivial as that I need to run another test!

Well, part of the issue was due to an x value being defined as a y... that is fixed at least

And what Dijkstra produces after appears to make sense, but the node translator in Kthura turns it into very strange crap.... really

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....

And let's try that again, shall we?

Well fixed that crap up

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

Placed the debug logging routines in the wrong function, so that's why the data I asked for didn't appear.... STOOOOOOOOOPID!

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....

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!

Let's see now!

Node debugger added

Nothing happens, but at least no crash!

Different approach as this is getting nowhere... When everything about this matter is impossible we do need another way to do things!

So whatever goes wrong, everything points to the Dijkstra routine now

Even the WalkTo line itself works the way it should

That line really rules out all possibilities for this crash to happen....

"Actor PLAYER is walking to (550,111) (real:0) Layer:YAQIRPA"

Ultimate test.... I a good layername pops up, it's proven computers CAN lie

The debug data still denotes the crash is impossible

Let's see....

The only possibility i can think of now is that the actor is not properly retrieved by the Apollo-Kthura-API

This would imply that whatever goes wrong, the WalkTo routine would be to blame, eh?

Nope I do get the same data... it was just a small formula error in my debug line

Now let's see

No output, but no crash either!

I've set up another way to enforce the same crash upon spawning

Bugs that don't exist can also not be fixed...

The crash is indeed a lie

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

More debug lines (not that they can answer much, due the the impossible claims made by the game).

The claims done about the actor's parent layer are beyond ridiculous

Well, let's see....

Well Just as I thought... Exhausted as I am, but I couldn't resist

However I'm tired and I need my rest now....

I need to fully study this one out, and that may not be easy

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.

And see what happens next!

Let's take the testing to VisualStudio now then....

Savegame names will no longer appear through "LOADING"

And I guess I will now have to find out WHY!