I must make sure that end is ONLY recognized as a key word when not a string

It's probably more as I didn't count a few

Take XVII

One more fix?

It's good to see tha map file and the layer are stored in the Game Vars... That saves me a LOT of trouble!

"end" in gv missing

The fix was not in C++ but in the game script.... moron!

Let's see then!

The GameVars script was not correctly generated

Moar debug!

Nothing should have made it possible for that NULL value to end up in that map spot, yet it happened.... The map is an protected variable, so it can only be defined from inside the class

I already suspected that, but how this could happen is now the qustion

For some reason, the data inside a Data field is NULL

Not a clue what is going on

Take XVII

I've avoided direct vector creation calls, to make sure the foreach does not have to face a recreation all the time, but is sure to use the same data sequence all the time

Take XVI

Next stop fighting the issues with the save game manager itself

The Illegal Directory that was produced in the process

Finally I see the directory data I wanted to see

Take XV

I think I fixed all this crap now

Not there yet, as for some reason Windows does not give its environment data to C++, but at least the replacer appears to work now and that's half the battle

XIV

I hope I fixed the TReplace routine

Take XIII

???

Clearly NONE of the Dirry values appear set?

What is clear though, is that stuff is not operating the way it should....

At least the infinite loop is broken

CRASH!

Take XII

I think I tackled that one!

I think I fixed the infinite loop, as the replacer didn't like empty strings for substitution... not to mention there was more wrong there... However that does not explain why was an empty string in the first place!

even more interestingly, the setting appear to be where the crap freezes

Interestingly, the results Dirry produces are not what I wanted to see...

Take XI

This line should provide some answers on that

I wonder if Dirry is to blame... The routine has not yet seen that much action after all

Does not get any furhter than receiving the request.... But where does it go wrong then?

Take X

Extra lines added

No console output generated... I do fear I will have to analyse this in Visual Studio

But now the system is freezing, and I wonder why

fix confirmed

Take IX

?

It is strongly implied by the log that the routine which has to read out integers is not called at all!

Take VIII

Some extra debug lines must tell me wtf is going on as never in the world should a "nil" have been possible here!

WTF?

Take VII

Code typo producing a syntax error

Take VI

Syntax error

Take V

Busted #use clause

Take IV

Syntax error

TakE III then

But it compiles now

More issues here

Take II

I think I fixed that....

A very old code error.... never produced errors before, and now suddenly it does.... Odd!

Well, let's see what this does, eh?

My debug console now supports it!

This is not much, but this will allow me already to set up a few debug test routines

SaveGames should now at least store the party data, and the gamevars

Since this is a JCR6 file, remember that I can easily check things with tools such as Stach

Given the current timing I don't think I can get the savegames fully done today, but that doesn't matter too much.... If I can at least get a few things on the road, then it's fine!

Some needed real-life stuff

And what I said is only the core stuff.... The actual data is compiled by the game scripts, and the scripts doing that have not yet been written!

Technically saving should now work... that is if the game asks for that... Data cannot yet be loaded though, so we still gotta work on that.

For good reasons!

So I had to do this with my Go app, and I hate that!

This is Microsoft for ya

Looking for a good directory creation routine - Failure C: The follow up-method though is not compatible with my C++ version, which is with the old deemed deprecated even stranger

Looking for a good directory creation routine - Failure B: Second one is official, but deemed "deprecated"

Looking for a good directory creation routine - Failure A: One method is Windows only, and does therefore not fit in my Cross-Platform approach of matters!

SaveGame Manager link up code

Like In all RPG games I created before (well, the most of them at least, as my very first will likely be different), the savegame routine will be using JCR6 to bundle all data, but still keep it seperate.

Here I'm going to create the save game routine, now it should be noted that I'll work out the save game routine in several portions....

First of all, to make sure the Nizozemska version of the savegame routine remains 100% compatible with the regular way, and also to make sure all everything can work on its own.

In order to make this all possible, I will need to write hugh poritons of C++ code, however that should not be too much of an issue... I think.... ;)

Like I said before today is entirely reserved for Dyrt...

And will be it for today

Due to some complexities I was facting today I could not get things done on the monster encyclopedia for Dyrt, and since that is something that requires my full attention, I'll focus on that tomorrow first, and now that the savegame routine is the next step in Star Story which is equally as much of a hassle I cannot really combine the two projects until both are done I'm afraid.

Since Dyrt is more pressing at this moment I'll get on the encyclopedia first, and depending on how things in Dyrt are after that, I'll get back to Star Story to get the savegame routine done, but if Dyrt is in a state I need to put emphasis on that game first, Star Story will have to wait.

But when I think about it, it'll be alright.

Well, let's see!

And THAT should do it!

Kill

Kill

Let's see how things come out!

Inventivity is required for the job, y'know!

However, they would cause needless confusion if they were used now, so that's why I chose to remove them from the prologue, but not from the later instance

This also allowed me to make the mapscript "shamelessly" remove the transporter pad... They were only present in the map for later access by the Hawk

So does the JCR6 entry overview output

The builder output seems to spell good news

One of the reasons I loathed the "existing" engine as it was next to impossible to implement it there... Well that an many other reasons.

The first dungeon is a bit different in code than the others, and I wanted to prevent conflict, just duping the map wasn't the right way to go, so naturally aliases had to do, and fortunately JCR6 supports that

this is something I've done with the original game as well, so that's nothing new. I only did it immediately now where I did it later for the original.

I've aliased the Yaqirpa for later access with the Hawk

#11

The base stuff for the Yaqirpa

In a basic sense the save game routine can be set up from here, however that won't be for today, and I need to set up a few things first

So far all is cool

And does it work now.... please?

#use clause

Yawn

Riiiiight!

Well?

Another Dupe

Dupe

Let's see now then

Basis script

Autoscroll activation

Let's see

A few project adaptions will be in order I'm afraid

OCAL

Crash, but the crash confirms what I wanted to have confirmed, and that is good!

again (please note scrolling and visibility things have not yet been set, so the output will, even when everything is the way it should be, odd... as a matter of fact, if it shows things the way they should be in the end, we got a bug, actually).

Compiling

I've forced the API to kill the old map before loading the new, as it appears all stuff is merged.... This will not only inevitably lead to Out of Memory errors, but also to conflicts with data with objects going through each other

Now things get even stranger.... The music of the Yaqirpa loads

I need to make another test, but I do expect the same result

and that music will be 'Opening Theme C' by Kevin McLeod

Music has been set

Old script

Some data returned even seems to point to the map already loaded

The logs say the Yaqirpa is being loaded... yet what I see is DEFINITELY NOT the Yaqirpa

Idiot!

Link issue

Yeah, thanks to the NON-call back structure this cosmetic thing that DOES make the game better was possible

"Loading"

"LOADING!"

The scheduler should now be able to take it

To make #8 possible I've made the link command refer to the scheduler, however the scheduling engine will if I test now throw an error

#8

However that will be done later, I'm afraid!

The next stop here will be the actual appearance in the Yaqirpa

And NOW it works

Take XXXVIII

Did or did I not forget to run barf?

Take XXXVII

I fixed that

API linked to wrong function

Take XXXVI

A few small edges?

Take XXXV

Static/non-static conflict

Kill (Take XXXIV)

Kill Link code

Kill (Take XXXIII)

Kill compile

Kill

Kill

Kill

Ah, there is no Kill link yet.... That will have to be taken care of

Take XXXII

Code typo

Take XXXI

I think I fixed the "Kill" crash, but I cannot be sure

Illegal function call

Take XXX

So I added an extra debug line that must explain why this still happens

Analysis shows this should NOT be possible with this configuration

Keeps going in reverse

Take XXIX

For the short term I can better void it

I really need to sort out the optional parameters, as it appears to be completely bugged

It works now, but backwards, and I need to find out why

Forgot to compile in my hurry

Take XXVIII

That was an error in my C++ code, which must btw also be present in my C# code, but since I never needed that functionality in Dyrt (and especially not in the editor) I guess it never surfaced

I think I tackled that little bugger

Setting ignored

Take XXVII

Well just to make sure then

Was the barf not run?

Take XXVI

Code Typo

Take XXV

But that could be is because I forgot to modify "NotMovingThan0" prior to beaming

They do turn into the "beam" sprite, however they don't animate

Take XXIV

These fixes should fix the "beam" visual effect being ignored

That only fixes the crash I got, but there's more not in order!

Link typo

WORTHLESS!

Take XXIII

Two more of those

Take XXII

A static cannot call non-static without calling an instance

Game still crashes, though

The transporter sound starts, and that is an important marker

Take XXI

Windows was doing something, blocking the C++ linker

Hold the show... C++ Whines

Take XX