Blue Screen Of Death!

I will backup while Dyrt is running though

After I do more testing work here... Yeah, it really sucks, but I need to sort out my priorities

Next stop... Enemy sprites

Well, what does it do now?

and made sure the X is a bit more to the right

Y position to the middle

Bug fixed indeed, the result is good, but not quite

I think I found the bugger

Stack overflow thorugh by C++ for something that happens inside Lua, eh?

But what is it then?

Ok, I was wrong

Complete crash.... I think I know why this is, but I need to look that up

Let's see, shall we?

these are the hardest to tell if they are right, but as I put in placeholder circles to mark their positions, this should not be that hard.... At least, I hope not

I've set the enemy's automated X and Y postions...

Calling it!

Running

Should be up-to-date, I hope

Take XI

Yeah that was a mouthfull, couldn't think of a better description

C format communication error

Take X

As a result I did have to recompile the enemy set up, oh well

Ah, some old BlitzMax leftover code now leading ot incompatibilities

Take IX

That links it all together

Extract Dir

Compiling

Link API

Extract Dir

Take VIII

Illegal Function Call

Take VIII

Forgotten overrides

Take VII

I hope

Sigh!

Take VI

Oh well

Take V

Code typo

Take IV

I need to fix the bug in Neil about base members in extended classes

Take III

Override error

Take II

Identifier issues

Well I can start with the tests, but I am tired now so I hope this'll be short

I've linked the foe compiler... or that is the little it has now as it cannot yet prepare the data the (future) battle engine will need to the start up routine... All it does not is the pre-load of data. Once this is done it will go into the next step which is to compile and process the data into workable data the combat engine can actively use

This is dirty code straight from hell and is only possible due to Neil relying on Lua and having to do most of its stuff run-time.

For the enemies I've set the level as a readonly int, this is to make it easier to get the actual Foe Stat compiler to create the stats the enemy should have on the start of the battle. Remember, that Foe records do not exist prior to the start of the battle so this was only the easiest way to go. Now to make things easier, I've used a property on the heroes which reads the level directly out of the character record, since that does exist prior to battle. The battle engine won't notice the difference at all, as the respective classes both know what to do.

This won't bring any noticable effect now, but it will safe me some headaches later.. or at least, I hope so

Quick Link HP

Well it appears to be working now

Take III

WTF?

Take II

Syntax error

Take I

This should conclude #47 but before I go there, first a little test!

Combat music should now start UNLESS the system has been instructed not to

Before anything else,first another test of Dyrt.... See ya soon

But it's late now.... More comes later!

A basis has been set up for the foe compiler

The original Lua exporter I wrote in Blitzmax.... Looks pretty straightforward.... I need to see how I can best make this accessible for Neil... I have a few ideas....

Analysis of the original datafiles was easy... That's just GINI and I do have a GINI parser, so that shouldn't be a problem.

A new compiler is however needed, due to the new game using Neil in stead of pure Lua, and to allow it to blend in better with the current Apollo Engine

It might not be needed anyway.

The original Foe editor was written in BlitzMax and as the original game was developed on a Mac only compiled for Mac, making the code entirely useless... Now technically speaking I can try to manually translate the editor to C++ and attaching it to my June 19 system, but I got a bit of a bad taste in my mouth from that attempt after things went completely beyond my scope with TFT... Of course an entire engine and only a simplistic database are two different things, but still....

Since Star Story works with a dynamic enemy system, this unlike Dyrt, 63 fires and TFT. That makes the Foe Compiler I coded for Dyrt completely useless and even in an adapted form I cannot do anything with that. The dynamic system is what allows enemies the have different levels based on where you encounter them, your difficulty setting or your chosen game cycle. A very few enemies can even level based on your level (this is only reserved for bosses where this level has a kind of scenario meaning), all in all, this requires a completely different approach....

Enemy data

Some more Dyrt testing.... That game is close to completion, but then I mustn't neglet it now, as then it'll never get finished...

And let's see if that works

Double size

FINALLY

Take X

WILL THIS WORK!?

This is REALLY getting on my nerves now

Take IX I think

I really should find a way to get that one fixed

Oh wait a minute... It's the table pointer bug

NEXT!

Oh wait, that was just a misplaced debug line

Another thing is... it only had to retrieve the picture ONCE, and according to the log it did so every draw frame, which is also not the way it should be

Once, twice, three times a lady..... In this case Wendicka.... WTF is going on here?

Well let's see how it work snow!

I guess there MUST be trouble, eh?

I'll investigate that later for now I'll just give both Foes and Heroes their own Tag variable hoping that'll solve things

It seems that when classes get expanded they all share their pointer... That was not what my test script pointed out, though

An extra line must show me a bit of info here

WHY!

But their image files are not alright as I see three times Lt. Briggs, in stead of Briggs and the three girls

Their spots seem to be already

I see three combatnants

Take IV

Illegal function call

Take IV

Can't imagine I didn't bring that one in before.... Dang!

Image.LoadNew()

Take III

And another

Fixed code typo

Take II

Syntax error

Take I

Linked that to the main combat engine (as far as you can speak of an engine at THIS point)

Hero draw should owkr now... I have not yet adapted scaling (which I'm planning to, but hey I can't do all in once).

This will now allow me to show the heroes in combat

AT LAST!

Well we'll only know after a new generation is done

I hope

GRRRR

Generated the walking sprites for the playable characters the way this game needs them

that looks better

Let's see now

Aliased the old Blitz Pictures, but that would lead to rather crazy effects I do NOT want

I hope!

FOUT! OPNIEUW!

Let's do that again, shall we?

I think

Din't work the way it should and it actually failed on Wendicka in uniform, Crystal in uniform and Briggs, the three characters I needed right now (and all the others were succesful... good news, but it rubs the error in even more, so I'm not sure how to feel)

Project adaption in order to create aliases I'm gonna need for combat

So far it all looks good to me

And now I need a good cup o' coffee

Barf required

Okay, that works now

I see that "abstract" is not completely functional... yet!

Back to my Dyrt duties, but I'll be back soon, as things are slowly getting interesting here

It LOOKS like it's working.... Oh my....

I hope....

This should not be due to the way that class work, but rather due to the #use interface being very very buggy

And that is what I wanted to know.... That it does NOT work!

Well Only one way to find out, eh?

Will this work then?

How come?

Now the "fun part" comes... It looks like the files in question have not been seen nor been translated nor executed at all....

Basis for Hero Creation in combat (this should be easy so far, but hey, ya never know)

And I must see if this all works, eh?

A bit of a base for the class for the fighters

Time for a little break

This was significantly harder, but IT WORKS NOW TOO! :)

Now for property overriding

Method overriding works.....

For the time being ONLY non-static methods and properties can be overridden... This to prevent a lot of trouble on the way.

But now the "evil" part.... overriding... I'm sure that doesn't yet work, as that will require some workout

Good, that appears to work as well, good good good!

Now for methods

Variable transfer into extended classes appears to be working

Overriding is NOT yet possible, though

Properties should now be copied properly into the class extension

So far the translation looks the way I want it to be

A few fixes required to recognise this all well

Neil should now recognize the keyword "extends", but it won't have much effect yet

BRB :)

So I only Gotta wait for it

Bread into the oven

Feeding the cat

And I should also have fed my cat a little while ago... Luckily she ain't mad at me for it.

But first time for food.... My stomach hurts and shouts out for food....

Before I get into the combat routine I really need to experiment on extendable classes, as I really don't know if I already properly covered that in Neil... It ain't that much of trouble if not, as I can still work it out by a bit of cheating, but as long as I don't have to... Why should I?

However first I have a few obligations to Dyrt.NET so I guess I should get onto that first

Just like in "DYRT.NET" I'm planning to work with a kind of class that basically houses the data a combatnant should have.... Now Neil is not yet full adaptable with extendable classes, but due to the most of all run-time nature of Neil (due to it using Lua) I can easily get around that... I think.... ;)

Well, from here I can try to get a few things on the move

YES!

YES!

YES!

Take X

This should mean though I am now really close to getting everything to work the way it should.... (Almost sounds too good to be true)

Code typo

Take IX

Okay, This should get me close to getting things to work... I hope?

"Killed" was NEVER supposed to be "read-only" (the system cannot know it has to remove an actor otherwise)

Take VIII

Syntax issue

Take VII

?

?

Why?

ANd still no good! :(

Onto Take VI

Take V pointed those out

Unknown identifier

Scope issue in Neil glue code

And of course, I must compile all that crap first, so here goes....

Some new glue code was therefore also needed, so let's come up with that

I removed the most unsafe one that is bound to cause trouble only from Apollo.... Projects so small the function act act safely are close to non-existent, so why should I care about those anyway?

So I wrote a few alternate API functions which should be a lot safer

I've looked up table pushing, but my analysis says that since must of the same functions are being used as for regular value returns the function is just as risky, so best it not to go there.

I will take a look, as I believe Lua can push tables from C, but I am not fully sure how this works, so I'll require some study for this!

I know what it is..... JCR6.Entries must deal with too many return values... I thought I had taken care of that now... Apparently not....

However given the time, and the fact that I must stop at some moment as I too need sleep this will have to wait until later no matter what the computer wants me to do!

A sudden total crashdown happens without any error message at all.... This mostly refers to serious trouble

Take IV

Group issue

Take III

????

Take II

Mouse pointer unknown

Errorlink

Let's throw this to da test

The development escape... I insist on having that active before running this all up