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

A few more things to be done before I can test, though

The game should now be able to engage into combat... that is no more than showing the background "arena" picture, but hey Rome wasn't built in one day either

As far as I can trust the logs, the issue should be succesfully voided

Take XV

Ah yeah, that bug within Neal with the declaration of table variables

Take XIV

More debug then!

The log shows that the array in question is really that long.... But why does that happen?

Take XIII

"static"

"static"

Take XII

As that mystery still isn't cleared up

More infor on why the overload on enemies happens though

Each getting a function (sigh)

Highest number I saw was 8 (which is actually already too much, but still withing reasonable limits given the way stuff's been set up)

And the log also confirms there should NEVER be that many enemies

The error I got now I really really odd, I tell ya!

Take XI

And I wanna know more about the enemy overload in the process of the next test so let's put in an extra line, eh?

That does not yet fix the enemy overload, but I gotta start somewhere, eh?

I think I fixed the "nil" issue

The latter is likely an API error, but that doesn't seem likely (as that would mean the music couldn't start either, as that data is also received from the same API function)

And two NIL values, and that makes me worried the most

For started 44 enemies were put into combat for no reason at all

The error message I should see is there at least, but loads of things are not right yet, and need to be sorted out!

Take X

Oh well

"nil" for arena?

Take IX

Too many enemies?

Bad identifier

That's even one more than I counted in the last test

And also confirmed that there are indeed 32 enemies added to combat

Confirming the Neil bug in the process

Boolean issue voided

Take VIII

Oh crap!

Take VII

An extra debug line will have to confirm if this is really what is happening

The logs indicate though that 31 enemies are put in one fight... Even for the hard mode that is way too much (not just for plauyability, but actually much more for the CPU and RAM to process also).

I hope I voided the boolean issue (which should not be possible unless Neil itself is bugged)

Take VI

Extra debug required

Or so I thought

Take V

ALmost there

Incredible eh, how many fixes something trivial as this can need

Take IV

ID conflict

Take III

GRRR!

Take II

And the other fixed

One issue voided

Some bugs pop up that should even not be possible at all

Wishful thinking

(And the only take I hope)

Take I

Now even though the game will crash when engaging into combat, I can try to see if stuff in general works.... I know the exact error I should get when all else works... or at least without crashing, as true bugs cannot be expected until the actual engine itself is set in motion... Oh well....

Good!

And tune number 2 also works

Just waiting for tune number 2 then ;)

At least I can say that boss tune number 1 plays the way it should

Although the game will crash for now, once the combat starts, this because the combat engine has not yet been scripted, and a lot is there to do before I can even make that happen

Right, the foes moving around in the field should be able now to initiate the battle

Right, script set for a random tune for both mob as boss fights

NOT THERE YET THOUGH!

the Script is now able to pick a random tune, just out of the correct folder for the occasions

While the music plays in order to test this all out, I could alter the script

Another test coming up

Eating

HERE GOES!

Another pack is required though so.....

That should be fixed now

And I need to find out why

That didnit work

Well, since that looks like it's in order, the boss songs will now come into play

Mob song 002 works

Mob song 001 works

I am currently listening to hear if all the alterings did go according to how they should go

So far so good!

Script run

I've made some aliases for the music used in combat, this so I can be sure the random tune picker picks this all up accordingly

In order to save myself tons of bugs, I will always add the "kill" attribute to foes on the map as soon as you touch them igniting combat. You cannot run away anyway (you can use ability to force the enemy out of combat in stead) and if you respawn after combat the map is reloaded also, so all in all no reasons not to do this. All that would cause are needles bugs... or rather cockroaches

Now I didn't create that Einstein quote picture that I placed onto this page out of protest for the imbecile way in which the COVID19 virus is being combated, however whoever did misspelled "stupidity"

I've checked the Arena pictures, they look good enough for me to be stretched.... It would save me tons of work... I know I'm lazy, but I gotta face the facts, this project is not worth it to put that extra kind of extra effort into it....

This has NOT YET been linked to the in-field enemies, so don't expect anything to happen there yet!

Some linkup code has been written in order to make starting combat possible

In order not to stress things up too much, I'm going to look into a kind of possibility to fake a lower resolution screen in order to make combat possible without having to redo all arenas, like I had to do in Dyrt, however it is possible that life will be harsh and that I will have to keep that setup going.... This to prevent too much pixellation in higher resolutions... I really gotta sort this out

A start has been set up for the combat.... Two classes that will allow me to configure the start of a combat. Very important... After all, without this data the battle cannot even start at all...

Voila

So my dear Watson, it's only elementary we're gonna find out why

Doesn't work... at all

I had to recompile the engine

Hopefully this works, and if so, I can go to bed

The Scroll value in the savegame screen should now be saved whenever a savegame is accessed... Counts for both loading and saving

We'll never know why, and frankly I don't care... What works that works!

It appears to work now

This is highly unorthodox, but what the heck

This is really really odd

I really must see what happens now... This is a bit of odd way of working

Chasing works FAR from perfect

Missing check

(In the original game this part also gave me nightmares. It was for that reason I never re-implemented this in TFT REVAMPED, Dyrt.NET nor even 63 Fires of Lung)

Let's dig into this a bit more, shall we?