?

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

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

Recompiling

Just copied the definition in the C++ API

This is REALLY getting annoying

Take XIX

.....

Take XVIII

I hope!

Cockroaches.... fresh cockroaches.... over here!

Take XVII

Does that make it work?

WTF?

Take XVI

I don't wanna talk about it

Take XV

Idiocy

Take XIV

Extension error

At least it's now whining about the mapscript

Some things are to be done... No matter how much ya don't want it.

Take XIII

This is getting on my nerves

Take XII (again, as the take announced before never took place, at all)

Real life stuff got in my way

Take XII

Okay now?

CODE REMOVAL IGNORED!!!!

Take XI

Something is definitely wrong here!

Take X

USE YOUR EYES! DORK!

Fix ignored

Take IX

I hope I did it right, this time!

If you fix something do it right! Dork!

Take VIII

Core Arf

Take VII

Another syntax error

Take VI

Syntax error

Void

Take V

Can I void that?

Lies

Take IV

Code order