Debug line added for investigation!

Nobody turned around

Take V

Compiling

Fixed that

API didn't return value when it should

Take IV

Sigh!

Take III

Neil syntax error

Take II

Identifier crisis

Let's go!

Take I

I will try to test if this all works though

Now the beaming effect may be a nasty obstacle to tackle, but that won't be for today... I'm getting tired.

This also enables me if waiting for beaming down works

It's not much but at least I made the characters turn around while standing on the transporter

The schedule library withing the field flow will merely make events wait for the next full cycle to be executed, this to prevent conflicts

Schedule function

Mouse pointer also set to appear when game field is in normal motion

Entire routine set up

Set up a basis for waiting while moving

No errors returned, but that does not automatically mean everything's okay.... Not just because C++ sometimes lets syntax errors through, but also because C++ cannot check script errors for obvious reasons.

Compiling

And that should link it all together

Property for Neil

Linked to the API

I needed a function that can check if any actor is moving at all. In order not to take up needless RAM or CPU capacity I did hardcode that function in the engine, as this function is bound to have too much negative effect when scripted (no matter if you use Neil or pure Lua).

I've also done this for the "WalkTo", however I'll have to test later if that actually works

Well, now some parts of the real work have only begun, but at least this part is done, and created hope for the future of this project

All's well that ends well...

Take X

I need a few more features before I can move on to the next step, but first I need to make sure this actually works

After the introduction scenario Briggs and the two girls should walk to their respective transporter spots

Crystal will now also step forward and step back when Briggs asks her to

Spots placed

Let's script things out some more

NOW it appears to be working!

Take IX

I mustn't forget to adept the WalkTo too on this

I *THINK* I solved the mystery

And the crash I got now makes even less sense, but it only seems to confirm more that something is definitely wrong here.

Take VIII

Extra line will have to confirm my concern

For extra verification I've made sure the name of the layer the way it was upon creation is copied into the layer

The crash I get now seems to confirm that somehow an non-existent layer made its way in

Take VIII with another debug line!

It's suggested the tagmap is empty ... I wonder wtf is going on here, as that cannot be!

Debug information not given while requested

Take VII

And let's take over the testing here

Extra debug line

The system insists no such object exists, while it does

Take VI

Copy and paste must ensure this is really a lie

The Tag Map list confirms the error is a lie

Take V

I've dummied the walker code, so I can check how things work out in the TagMap

The computer lies... It says the Fwd point for Wendicka doesn't exist

Take IV

Done

I had to run "barf"

Take III

I think....

Kthura internal linkup script error

Take II

Syntax error

Take I

Crystal will not yet make these movements, but if it works for Wendicka Crystal will only be easy

Wendicka should now move forward and back when Briggs requests her to....

A better way inside the Map linker to call the main feature

MoveTo method to field state group

This is gonna be scary, but if it works we got one of the most important Kthura issues tackled

Before I got to work on Star Story today, the cockroaches I had to deal with here kept me away from working on Dyrt, so that comes first!

#9 Should be fixed now

I need a break now, so I'll get back to this later!

Issued as #9

Nope

Well, does it work?

I've replaced the actor picture files with jpbf files

Briggs was looking the wrong way

The reason why this happens is still

I think... I think the altframing is bugged

Now the actors are still in mini form, so the bugfixing is not over yet, but my most pressing matter at had has been fixed at least

Take L

Now I did undummy the actors, but I forgot to rebuild the game resource

the TiledAreas show now

Take XLIX will have to confirm all this!

It was just a typo in the loading function.... Since the starfield was modified manually that bug was bypassed in Lovejoy's story

KLABAMMO! Just as I suspected

Well, if you eliminate all the impossible, whatever remains, however improbable, must be the truth!

Actors undummied

Take XLVIII

Temp dummy on the actor generation...

Checked the entire chain and the only error I found was a scale defintion not in order... This could indeed be why i got the feeling my actors look so "flat", but that doesn't seem likely

Given the state of the error I now must find out if the actors are to blame for all this or not.

There's indeed something wrong with the Tiled Area.... According to my log the height of all TiledAreas is 0

Take XLVII

The Annoying line I likely no longer need

It is now heavily implied it's only the tiled area that is to blame

It appears I made assumptions too soon

MOAR DEBUG!

Take XLVI

Well?

The core drawer does seem to address it all... or at least the logs say so

Take XLV

Another annoying debug line has been put in place

But what then?

Visibility does at least not appear to be the problem

Take XLIV

Syntax error

Take XLIII

Visibility verification!

They confirm though that only the actors are drawn and that the rest is ignored.... Why!

Take XLII

Very annoying debug lines

The results confirm everything the computer does regarding this matter is bullshit

Take XLI

Dominance experiment

The log confirms that all stuff should be present

Nothing relevant

Cosmetic output error....

Take XL

run barf script

Ref error

Take XXXIX

Code typo

Take XXXVIII

Rebuild

Added to the game script

Links it all

Neil link up

I'e added an API routine which may give me some ansers (I hope)

Take XXXVII

I've deactivated the actor scaler as it does not appear to work the way it should

Other closure routines still got issues, though, so there's still work to do

Well it appears I got the lua closure fixed

Take XXXVI

I am required to do rebuild the game itself for that, though

I need to find out if the animator is what causes things to turn invisible

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

Take XXXV

An extra debug line should confirm if indeed most of the map was killed (for no apparent reason)

Now the question is, of course, why this all happened

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

Half of the blockmap is gone, which may indicate half of the map is gone as well

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.

Take XXXIV

Syntax Error

Take XXXIII

Kind

The destructor should be obsolete now

Constantly All objects are being destroyed, I see

Now I do have a few ideas to make the destructor obsolete, but still I need to check things out!

Now the destructor is called while it shouldn't be (causing a crash in the process).

Take XXXII

!= is not the same as ==, Jeroen!

It KEEPS insisting not not working!

Take XXXI

Whatever causes this bug, it's persistent!

Fucked it all up AGAIN!

I am not definitely pissed off!

Even now that the actor could contain nothing but the correct data I get garbage

Take XXX

I hope

I think I solved the case! (or is that wishful thinking?)

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

Aha... Now the log makes more sense.... The layer for dominance remapping is declared a null pointer....

Take XXIX

I do need to re-test as a few things in the IDE went wrong

Ah... C++ placed the error marker on the wrong spot (what else is new?)

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.

Apparently.... no work at all! I guess fate is against me after all!

I can at least confirm that normal objects appear to be working under the new code

Well We're still counting on... test XXVIII

I needed a break before the great test would commence

And now it even deems the compilation succesful? Is it really done?

Hmm, it has stopped giving me errors in the Kthura library and now wans the adaptions for the API

That's only half the work, though!

I think the core part of the operation is done....

DUMBLE-ROLLED!

:-P

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!

That experimental line was exactly where C++ didn't like me, at all

As expected

Take XXVII

I've tried something but I expect not much from it...

Take XXVI

MOAR stuff

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!

Take XXV

I've added a debug line in the iterator... Hopefully it answers a few questions

Is the iterator still broken?

The data in the debugging screen doesn't make sense at all.... What the fuck is going on here?

Returning a string is reason to crash?

I see now that the system does follow a different traceback route though, so that is a bit odd

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!

With no more reason to crash, it still crashes

Take XXIV

That was take XXIII btw

Will backspace is a handy key, but still

Why did an identifier get cut in two over two lines?