Take III

Another

Take II

Declaration Syntax Error

And then we can commence test take I

That is the most important action every single day, folks!

Making coffee

And now I'm first gonna take a quick shower

A few last minute errors

That should do it!

And the linker has been written

Next step, the link-up code

The mapscript has no access to it yet though... Well strictly speaking it has, but it's quite a hassle to work with.

The class to handle all this has been set up

That covers the C++ part

API adapted

Now for Apollo

Now this might be one of the few times (if not the only time) you see multiple targets beam out in once, still I think making the beaming script a bit dynamic could still be a good idea.

This is important! Otherwise Kthura would automatically always set the frames to 0 automatically, killing the beam effect

Yeah, NotInMotionThen0 can also be read... ;)

NotInMotionThen0 in actors can now be set

Now in order to make the transporter thing possible I think I may need to dive a bit more into the core of Kthura

I've converted the teleport into a jpbf

No crashes so I must assume it to be working

All I can test now is if the game starts up at all...

And scripted it to load the beam sound

Audio included in start-up loader

I will put this as a standard sound effect in the main loader... This sound is gonna be used many many times in the game after all.

The "beam" sound

Since the beaming effect is gonna take place a lot... wel technically in all dungeons, I think it's best if I script that in the main field flow... I am still a bit wondering about the best method

The feature would be added soon afterward anyway ;)

I see I did work with one useless texture in order to ensure a few blocked spaces. The objects in question were supposed to be invisible anyway. I must really laugh about this now, as it makes me realize how primitive Kthura was back then. Don't get me wrong, it was already hard work to make Kthura able to do what it did back then. Zones were back then not supported

Layered Yaqirpa

Yaqirpa textures

Running

Up-to-date ... i think

Like I said, transporting will be a later thing

That work snow

Take XIV (take XII and XIII were not mentioned due to the confusion I got myself in)

Is it fixed now?

What happened now is beyond me

At least I hope so!

And now this issue should be fixed

Still a crash, but the error message at least confirms the issue I was going for is fixed...

Take XI

Forcefully voiding an issue... I really need to sort out why optional parameters randomly refuse to work

Take X

GRRR!

Take IX

Adapted

I think I voided this issue

Case solved and this one is not very easy to get fixed

Take VIII

Expanded info a bit

And I now need to find out why

The scheduled actions are however not being executed

I can at least confirm at the request to perform that script is scheduled, or at least the scheduling function has been called

Take VII

Moar debug lines will have to confirm that the scheduler is working

Extra line to make sure the transport function is being called

The logs show that the waiting for moving actors is not to blame... that turns off as soon as all three actors arrive at their destinations

Take VI

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