And now let's void this bug, by making Tile call to ITile..... I REFUSE to call that a fix, but at least stuff should work this way

The boxes use "ITile" in stead of tile, that explains why it can work there, since they use a different function

Let's see what happens THIS way

However a checkup of the code, also renders THAT into the impossible... Meaning the truth doesn't exist.... Now that's odd....

1. RelPos.Y is not bugged
2. This shows by the floor being as big in height as it should be
3. And also because the trees were properly placed in the center
4. And my debug line also confirmed this
5. Once you've eliminated all the impossible, whatever remains, however impropable must be the truth, and that truth can only be that the Tile function is bugged

A debug line must explain the floor position

Width issue

Let's make up the balance:

1. Sky and floor are swapped
2. Width floor is not correct
3. Trees are so close that it doesn't work out the way it was intended.
4. The horizon is too low, although this could be the effect of the floor misplacement
5. In short only the sky color is correct
6. I don't see any clouds, but I think it's the floor bug doing this

Another test is in order

Another case error

Let's see....

Case error

RIIIIIIIIIIIIIGHT!

Did I void it?

Now the arena itself is bugged, but that was not part of the tests I just did

That link works

Take II is still required I guess

A typo I keep making for some odd reason

Take I (And only take, I hope)

Link code for showing the background arena

NOW it works

Take III

Code Typo

Another test

That wasn't done the right way

And let's test the mouse pointer

Eaten my lunch

Mouse pointer added and will get to sleep if the stage asks for that!

But that was acutally the easiest part to take care of

Works

Party status bar shown at the bottom of the screen during combat

A moment of silence for those who died 18 years ago in this horrible, cowardly attack

This does indeed create the basis combat settings

Let's see if it's picked up!

More code in this direction

Okay, okay, I made a skeleton for the Combat IDLE stage... Happy now?

I went to a the theme park today.... Allow me some time off, will ya?

So all is fine for now and I'm gonna call it a day!

It says no stage set, which *is* actually what I wanted to see for now, as in order to get the IDLE on the move I need another coding session (I forgot about that)

Take XXIX

Delegate created to void another crash (which was needed from the beginning so pretty stupid actually).

Combat music starts already, which is a good sign!

Almost there....

Take XXVIII

Is both :P

.

.

Take XXVII

Roundingissue

Take XXVI

A true error.... Bad sprintf definition

Take XXV

Voided it

Impossible error

Take XXIV

A REAL parse error!

Take XXIII

more

Take XXII

And another one

jpbubble/NIL-isn-t-Lua#49

Take XXI

More?

Take XX

And another

Take XIX

NIL bug

Test Take XVIII

Invalid variable declaration (at least in accordance of the current variable declaration rules)

Take XVII

Missing

Take XVI

Misformed table

Take XV

Missing "self"

Take XIV

Invalid delegate my ass

Take XIII

?

Take XII

Missing "end"

Take XI

More link issues fixed

Take X

And now I could easily fix this all

Expanded error data on link error

Take IX

Use definition

Take VIII

Missing self

Take VII

Misformed formatted string

And Take VI

A little void code

Something's definitely wrong with the static local translation

The outcome of the debugger shows me data, that should NOT be possible

Take V wil thus have to provide me some answers

Added some extra data in the error thrower allowing me to properly debug this crap

Okay, it was NOT fixed

Take IV

Color error

Take III

Should fix another crash

Another liblink

"Anyway" as indeed the issue

Take II

Did I forget Anyway?

Take I

And the Random encounter routine is now linked to the combat routine, meaning combat SHOULD start, or at least the black empty screen and the music should play

Debug features should work though

Nothing that will lead to "playable" results yet.... Once the combat starts all that will happen is that the combat music plays and further than that a black empty screen.... I can't do all at once you know

I've done a few work-outs on the combat start up

Not much, as the major part is being done elsewhere....

Worked them out

skeletons for callbacks in combat

I've now linked up the prework to the routine that will ignite the battle at least... That is in basic, as this function linked to will also forcefully throw and error... for now! ;)

versioning

All parse issues accounted for!

Take V

...

IDIOT!

Take IV

Multi-Array definition fault

Take III

Type requirement not followed

Take II

Module conflict

And as this is a new chapter in development, let's have another Take I

My forced error has another exclamation mark for my own references

And the random encounters will now also be able to pick which foes you'll meet in battle

In stead of setting up a mathematical formula I decided it was just better to use my collections module in order to create a 2 dimensional array in which I manually set stuff up. The reason is simply because this was easier to come up with a well-balanced solution for all difficulty settings, and most of all the hard version. The hard version must be hard, yes, but experience also told me that there are sometimes mathematical impossibilities, and I don't wanna see those... Hard != impossible!

Especially in 1 and 2 character parties this easily happens. With 3 or more, this danger is out of the air, and not to mention then you must be able to properly cover it up as a player, but below that (especially in starting dungeons) this can be an issue!

This way I can more easily balance things out and even edit things.....

Right-o, I've set up a list of how many foes can appear in a random encounter based on the difficulty setting, and the number of party members.

All parse issues accounted for!

And let's move on into take VII

that one came out in take VI

Well that was very very stupid

Forgotten // in comments

Missing "self"

Take V

Anyway regenerated... (I guess that was obvious).

Forgotten anyway generation

Take IV

Illegal function call

(I did announce take II before, but somehow it didn't appear on the log... how odd.... That or I'm getting senile at a too young age).

Take III

missing data to map added

It was late in the evening when I wrote that code, so cut me some slack, will ya!

Unless of course you don't put the proper returns in the meta-table script

"nil" value? Now this is impossible from a metatable, so I wonder what has happened here!

Re-linked the script but now to a different spot... Maybe that will help!

Clearly the class required was not seen

Take I

I did add an extra exclamation mark in that error as a mark for myself to see if the entire routine did get executed.

I now must test if everything works the way it is intended, however that is not yet possible... All I can test is if no errors pop up, except for the one forced to happen

Some pre-battle config has been taken care of now

Well, now that all parse errors have been fixed, the "real work" has only just begun.
Now I can make the field routine actually configure the combat routine. This will be hard to do, as no visual effect will take place at all during this process. However the combat routine cannot start up without the data generated in this process...

A few early tests can be done in the form of drawing the arena and making sure the combat music will play, after that I will have to put in the foe compiler, which is very important as there the foe's stats and abilities are properly defined

Once that's all done, we're still not there, as then I need to position everything out, and well after some more preparations, I might be able to actually start to code the combat itself, which will even then still remain complex, but at least possible.

Of course, once the combat routine works, the long boring stuff will finally come to an end, allowing me to focus most of all on game content.

Let's first make the Random Encouter routine ine routine call out to the combat routine... Hey, no combat is yet possible I know, but at least I can see if things run accordingly ;)

Running... It was backlogged!

All parse errors accounted for

Take VI

A missing )

A cosmetic issue inside the class parser was to blame

It seems some line numbering issues in NIL have been fixed AT LAST!!!!

Take V

Which fixes another parse error in the process

Illegal "end"

Take IV

Bad function naming

Unfortunately that doesn't end all misery

That fix

Take III

?

Library not found?

Take II

The issue for now, taking away a parse error

jpbubble/NIL-isn-t-Lua#48 -- Really!

Take I

I've now linked the combat start linker into the main field flow.... I've not yet made any callouts to it, but this way I can a least check if all parse errors have been fixed

Calling it a day... Tomorrow is a busy day for me in general, and the work coming up now is very very complex... This is the hardest part of RPG creation, you know...

The receiver for the link has been written.... All it can do (for now) is receive the data, so I can later compile it into the "core" of the combat routines. This won't be an easy thing to do, though, so expect some long periods of time passing without anything spectecular happening (at least not for the naked eye).... And the number of bugs... Oh, I already feel them coming....

Some link up code has been written.... It links to non-existent stuff for now, so calling it now WILL lead to a crash, but.... writing that all out will be a lot easier now, so that's a good thing... right?

No idea if it works now, since I cannot yet test, and it will take awhile to reach that point!

Scipted the forest arena out in full....

Grass

Cloud

And a generator for forest arenas.... They will look different every time... :-/

Set up the loader for Arenas

I love my script

Rebuilt

Issues with NIL modules.... This will mean that no multiple modules can be sent anymore, but maybe that was a bad idea from the start, anyway....

Arena script loader!

I've setup a RelPos library, which can help me on the arenas.... Far from ideal, but hey, it will work out.... right?

In order to make sure the combat routine will always work, no matter how the screen settings are done, I've decided to set up a dynamic arena system.... This can automatically enlarge or reduce arena sizes and fighter positions.... It should be noted though, that this can (and likely will) tax slow computers with big screens, but then again, that combination was a bad idea from the start, if you ask me!

Added tag BRAINSTORM

Time for me to take a break

Not yet entirely happy, but for now it has to do... It's easy to lower or to raise the encounter settings in general, so it shouldn't be a big big issue....

Take VII

Unlike what the name implies to those who do not know the technical background of this routine, this actually LOWERS the frequency of random encounters

Doubled MaxRate for random encounters

Take VI