For some unexplainable reasons, the success is and remains "false"

Take VII

In order to translate classes well, some "end" keywords are translated to } as classes are nothing more but enhanced tables in the Lua translation, and so that error came to be, as I forgot an "end" command on a crucial point, but as I did use a "#pure" tag this confused NIL and so this can happen... A very important reason why you should never use #pure in NIL unless you really know what you are doing!

Ah, now I got why the } error popped up while there wasn't any } nearby in that NIL script

What the.....

Take VI

Syntax error (wasn't there prior to the building issue, while that false code was there, so that proves things are running now... Did that make sense?)

Take V

Rebuilding

Ah, the NALA rebuild was not given in the build sequence, and that was in this case required.... Doh!

Take IV

Let's add another debug line as this is getting insane... Not a single reason exists why this can happen, and yet it happens.... So what excuse can the computer come up with?

I guess this is test III now?

an extra debug line

Now I wonder.....

And let's test as soon as that's done!

Rebuilding

This SHOULD be fixed now, but who knows

The error can be traced back into the Kthura class for Bubble, so yes, fixing this requires me to recompile NALA

That is indeed the case....

Kewl ... The walk routine always comes to "false"... Did I set a void where it should be a book?

But does it work?

This should be fixed now, however a test is in order!

Yup, just as I thought.... The delegate attacher does not check the outcome of the boolean returned stating if the walk was succesful or not....

That was also the most logical reason for this to happen.

But at least I think I got one thing tackled

It should be noted that since this is complex code, making me have to dig through a source file of 912 lines long (and maybe even more files) this will take awhile to track down....

Bug below issued as #87

Updated

Updated

When you walk to a clickable object out of the player's range, the player won't walk to in, and the event tied to it will run anyway. Now with the swords that revealed the bug, this is not a true issue as the spot should never have been blocked anyway (that is a bug on its own), but it allows me to debug this, as when things are out of range thanks to bugs or deliberate blockades this should not happen. Especially in Gagolton where bonuses are out of range while the city is still populated....

The bug with Rebecca and the swords has been fixed

Okay, now I can test this

Real life distraction

That should be fixed now.

For Rebecca that didn't

FOr Eric that worked

Does it all work? Let's see!

And I wrote the link code that will link the swords to the scenario

Object tag

Right now, only Eric and Rebecca can respond, but later in the game you can re-enter this place (not that you have much reason to, though) and then the others can respond too, so I had to enter them already, although I can right now only test Eric and Rebecca.....

I've set up the scenario for the swords....

Well, that issue took the best of my day, so I guess I'll need to call it... Tomorrow I hope I can configure the swords on the floor out, and do some more work on the rest of the dungeon, as this was a complete waste of time, but at least a very crucial bug has been fixed, and that counts for something.... right?

I hope all external repositories are up-to-date now

THAT was indeed the source of all "evil"

And then take L has to confirm my theory and fix this crap for once and for all!

Did that make sense?

As Dijkstra was compiled into Kthura which was compiled into NALA, I have to recompile NALA

Of course, now I need to test if my theory works

I think I found the source of "all evil".... And if I'm right the bug was in my Dijkstra pathfinder.... It actually does not go from start to finish, but from finish to start.... That seems odd, but it was easier to backchain everything that way in the ending result.... And the position from where it had to start calculating the route did not take the passability of this start (read: end) position into account for possibilities, and so this could happen... I was already thinking in this direction, because when the impossibilities came past halfway the impossibility WAS taken into account.... I guess this sounds needlessly cryptic, but trust me, there's logic behind it....

But I got a plan, but I need to check a few things, before I go for that!

Which also goes for North

same issue

Take K

Now to test left and right

this also seems to happen with too far right....

for some reason, the block lower is not recognized as such, but yet once passed in, it DOES count, sealing the player in... It's beyond me why this happens

Take J

I'm trying to trace where it goes wrong with this data

And suddenly I see the diagram I want.... And why... that's beyond me....

WTF!!!!

Take I

Wait... I think I made a little mistake in scrolling (should not justify and entirely full screen)

Let's sync to my VS engine,as this is not gonna work....

Clearly it seems the entire level as "blocked", meaning that it thinks that the entire area is blocked... That is not possible, as that would mean the hero wouldn't be able to walk in this area at all, and that is possible

Take H

Set up some class calls differently in the console command

Take G

I've added a field only debug console command which should show me the stuff I need to know... Well, if no bugs in this feature occur of course....

compiling.... again!

global/local issue

Compiling

Syntax error

As this is a more complicated debug feature, the debugger itself can be bugged

And I've linked that to the main initator

Link API set up

Part of the linkups done.... This will allow NALA the get things done, but now to link everything to the internal console

I've set up the class in C# to make this happen.... Please note though that I did not yet link it entirely in the engine... That's always a thing in C#

Since I never had this bug acting upon me on this level, I'm a bit in the dark here... The BlitzMax version, which used the same mathematical formulas never gave me this trouble, so that is the hard thing here....

I fear some VERY drastic measures are what it takes to get this particular bug fixed

Dat hielp dus geen MOER!

And onto Take F

Recompiling NALA

No idea what'll happen, but I gotta try this

In order to fix that I'll need to "hack" Kthura itself, and that will of course require me to recompile NALA as a whole when done

Although I think this is the same issue that caused me to suffer in Xenor Bushes at a few spots.... And I think the way the y-coordinate of actors is determined might be the "evil" here...

But that doesn't explain the lack of movement

That fixes the fact that stuff won't show

Take E

I've set the tag once more on the map, as the data shown here can sometimes betray you.... Well at least in this particular case

And not only that, but it also doesn't allow me to leave once I'm in the hidden part, and I wonder why

Showing does not work, though

the top hider also works

Take D will tell be about the North

showing does not

Hiding appears to be working at least when entering from the south

Take C

Someday the moment will come that is no longer needed!

But I need to rebuild NALA

I fixed that

I think I found it! Some values switched in the Kthura Bubble API!

Extra debug lines must shine some light upon this

And don't ask me why I said that in German (which is NOT my native language peeps... Contrary to popular (read: idiot) belief, Dutch is NOT a dialect of German....

Ich denke dass ich eine Tasse Kaffee brauchen....

Nothing happens :-/

Take B

I hope

And the hide feature does not work in the bottom zone... WHY?

Misnamed methods

Take A

Linked to the respective zones

Hide and show the secret

Now to alter the mapscript

Of course, I can still compile NALA first (which I have to do anyway)

Now I need to adapt the mapscript, but as it's 6 o' clock now and time for the new, I guess that has to wait... ;)

which links it all together

And written the NIL Code

Especially since this is a feature I use a lot in order to hide secret passages.

I've put in a way to hide and show objects based on their label.... I just figured that doing this hard-core in the engine will make the game much faster

And NOW it all works

Take VII

Whine

Take VI

Link error

Take V

Illegal function call

Take IV

Case Error

Take III

And linked everything together

Next/Prev routines

The linkup itself works, but the function making it happen was not yet completely worked out..... So that will be the next thing to cover

Take II

Getting myself distracted

Bad exit tag

Take I (Let's see)

I did link the left door to the next room, however if that works, I cannot yet tell....

Blockmap issue in the entrance hall

Take F will show if that was succesful

And yes, it should change based on who you put in the lead

And I've linked his scenario to the character on the map

Zack

But it's (almost) 6 o' clock and (almost) time for the news...

Zack's next

And Irravonia DOES adept her speech based on who's talking to her! So far so good....

All errors accounted for, and everything works the way it should

Take E

? Wrong group ?

Take D

I should never read out an array like it were a function

But some testing is required and I count on, as this is part of the same deal.... Take C

And due to this switching leaders should be possible now, and Irravonia should now also change her speech if Rebecca is the leader

And thus I can leave out a lot of needless code that only takes up memory and does not do a thing except for error catching

I've set up a small line which will constitute a link to an AltClick function when the user clicks a character portrait with the right mouse button, if such a function exists.... Meaning that if the function does not exist the link cannot be constituted and the system won't even try.

That works, although this was a kind of code that could (except for a few typos) hardly go wrong....

Take B

Code typo

Take A

As switching leader is not yet supported, Irravonia can technically only respond to Eric now, but her scenario to when Rebecca speaks to her, has already been written.... Saves me work once you can switch leaders, which is a good idea to get done next

I've linked her to the mapscript now, so now Irravonia should respond

Irravonia's replies to either Eric or Rebecca have been written.... I did these from scratch as given the current situation that was the easier way to go

And been fixed!

YAAAAY! The mystery has indeed been solved!

Take VI

I think.... I think the system tries to look up stuff in the wrong layer.... After all this is the first actively multi-layer map in the game.... And also the first with multi-autoclickables, and since the Traveler's Emblem is not on the first floor, it could be the reason for crashing (and that is what it looks like) and it could also explain the (0,0) which are also not on the first floor....

Like expected that didn't solve the issue, however I can see that now the coordinates of NPC Irravonia and NPC Zack are in order now, this in contrast with the swords in room 002, which also act as an NPC, where (0,0) are the given coordinates which is incorrect (and cannot even be true), and the error remains also, and still on the case label too....

Take V

I think I found the issue, but that issue could NEVER produce that data, but if it works it works, so let's see

Then again, NIL is still a bit disasterous when it comes to the line number preserving....

the line given in the traceback refers to a case check which makes the error impossible, as case labels can only contain constant pre-defined values, and can therefore not contact .NET (which based on the error message, did happen)....

Let's first check that traceback

= Compiling auto-clickables
= Clickables on Layer #001
= Converting object with tag SAVESPOT_RED_00001E0D8B into a clickable
= Converting object with tag SAVESPOT_GREEN_0034E04586 into a clickable
NPC Found on ( 512, 160) >> NPC_Irravonia
= Converting object with tag NPC_Irravonia into a clickable
NPC Found on ( 512, 160) >> NPC_Zack
= Converting object with tag NPC_Zack into a clickable
= Clickables on Layer #002
ERROR>Object reference not set to an instance of an object.
ERROR>Object reference not set to an instance of an object.
= Converting object with tag TRAVEL_ee411dc16de39f2d412e8d7619f55b4b into a clickable
ERROR>Object reference not set to an instance of an object.
ERROR>Object reference not set to an instance of an object.
ERROR>Object reference not set to an instance of an object.
ERROR>Object reference not set to an instance of an object.
NPC Found on ( 0, 0) >> NPC_Swords
= Converting object with tag NPC_Swords into a clickable
= Clickables on Layer #003

Makes even less sense, I tell ya

I don't understand what is happening... and to put it even stronger, the data I find in the logs do not even seem to make much sense here.... But let's get some things on the roll, starting with this traceback

Take IV

Some debug lines must give me some clarity

error beyond my understand

Take III

Ah, found the one I missed

Fix set, confirmed by my JCR6 viewer, yet ignored by the engine.... WTF?

Take II

Systematic case error

Take I

As the mapscript the autolinks created refer to do not yet exist errors will be thrown, however the kind of error DOES tell me if the autolinking itself works, from there I can work the scripts themselves out

Extra functionality in the linking scripts was required here, so I'll have to recompile NALA to make sure the embedded scripts are functional again

I've automated the clickability of NPCs in the field...

I've added room 002 to the Exam Ruins

Take XXXVI

That makes that higher skill levels can be read...

Alignment error

FINALLY!

Take XXXV

Well?

I think I'm going to die

Take XXXIV

Fixed now then.... preeeeeeaaaase?

Not quite!

Take XXXIII Let's see....

And that should be fixed as well

Okay... All serious bugs are fixed, but there is one cosmetic bug to be taken care of