It's not yet all cool though as linker errors occur... Clearly I didn't yet cover it all up properly yet

And also done the same with Apollo

I've adapted TQSG to make this all possible

#50 - Nope nope nope - definitely not! But already better than crashing ;)

Take VIII

And fixed it!

I think I got it

Take VII

I've added a more dedicated error message I can see more properly what's happening here

"Nil" value

Take VI

whiner!

Take V

I've voided that issue for now...

It appears that internal definitions in classes do not work when data is delivered by fellow class members.

Take IV

Syntax error

Take III

That's three

Syntax conflict - That's TWO!

That's one!

Take II

It was to be expected this wouldn't go right in one go!

Illegal redefs

Take I

At least I can see if the time gauge appears at all

It will NOT yet work.... For starters the icons and tag letters won't yet appear, and second I need to initiaze all the timers based on all combatents speed values, so we're not yet getting anywhere on that department

And NOW the time gauge should appear

Class link ups (this will not yet make the gauge appear. Only to make it access the fighter table)

Please note, if no errors occur nothing will happen. This because I need to link this up first

I've set up the time gauge... I do not yet expect it to fully work though, but hey the basis is set

The next stop will be the calculation of the speed over the time bar... Although more balancing is in order here too, like in Dyrt, I won't do that... The reason is simple, I want the experience to be the same as the original, and rebalancing the time bar would undermine that, especially since the older setup was not a bug but a choice... Not the best choice, but still a choice. Since Dyrt was completely rewritten and has a complete new experience apart from the story line, this wasn't an issue there

"floating character" in Rayal removed... He was never supposed to be there anyway

All crashes appear to be accounted for

Take XV

ANother bad class call, but of a different kind this time

Take XIV

Another case?

Take XIII

Bad class call?

Take XII

Syntax Error

Take XI

Misreference

Take X

?

?

Take IX

Fucking for the sake of fucking

Take VIII

Some word ik hier zo MOE van!

Take VII

Voided that issue

Crap!

Take V

Missing line

take IV

ID issues

Take III

Lua!=Python, and neither is Neil

Take II

Compatibility conflict

Take I

All I can test here too is the absence of crashes, but that's all

Quick access metatable for Stats and Stat Buffs

Since I only adepted the original Lua code to Neil and the differencies of this engine for this (this because I want the game experience in Star Story to match the original game as much as possible) I don't expect too much trouble here, but, ya never know

Now what is very important to note is that there's no way to know if this actually works the way it should as this is all "under the hood" code. In other words when it doesn't crash, I must assume it works

Compile Raw Data into the actual stats the enemy needs based on its level

WONDERFUL!

Well take VI then to fit all needed formalities then?

Placeholder circle

And NOW it works the way it SHOULD work

Take V

now then?

i thought so

Take IV

There you go!

But now I gotta deal with a file referrence error, but that's looks like an easy one

Apparently that is indeed fixed

Take III

I think it's fixed then

Let's run the crap and see

?

The data is not properly compiled I see.... I will have to investigate to find out why this happens

Syntax error

Take II

linked Lua's "error" function into the main routine, as this is driving me nuts!

GRRRR!

Let's see

The aim circles will still be desplayed. I'll remove them once this works

Anyway, the enemies should now appear on the screen

Now I must hope nothing bad happened to the backup due to that BSOD...

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