How many of these cases are there?

Take MLXXIII

Code typo

Take MLXXII

Another TrSPrintF fucker

I'll test later if this all works out the way it should

One API function in Kthura for SCI didn't return a value. I hope that fixes the Segmentation Fault

In House of Cards things appear to be going well. That's good!

Take MLXXI

Segmentation Fault when loading a savegame. Well, that's a later concern. First some more testing on House Of Cards

At least no more errors from Scyndi

Take MLXX

I'm going crazy

Take MLXIX

It never ends!

Take MLXVIII

Generated syntax errors in translations

Take MLXVII

Laaaalalah!

Take MLXVI

Dang! That was a hard one to find

Take MLXV

They just keep on coming!

Take MLXIV

code typo

Take MLXIII

Did I find the most annoying source of evil now?

Take MLXII

GRRR! Letter seen wrong!

Take MLXI

Another occurance of a TrSPrintF mess up

Take MLX

And NOW to resume the ACTUAL testing!

It's about time.

Take MLIX

;

Take MLVIII

GRRR!

Take MLVII

Code that may never fail, fails when touched by gcc

Take MLVI

When idiots declared code my not work... it never will!

Take MLV

another occurance voided

Take MLIV

Another TrSPrintF call removed.

Take MLIII

More false alarms

Take MLII

False alarms

It appears to be needed (sigh)

Take MLI

I've added a warning in TrSPrintF when non-ASCII characters come past. I don't want to say any of those after all.

One important fix has been done to the SCI runtime, which caused a lot of Segmentation Faults in Linux. Lua API functions do require a return, and quite a lot had none.

The Scyndi compiler did use TrSPrintF a lot, but it turns out to be allergic for strings, and this is a huge problem, as it's hard to find all occurances. In Windows things did turn out not too bad, but Linux is by far more sensitive, and that shows.

Well, well, well, it seems Azor has finally understood how to handle the CODE::BLOCKS tag (about time).

To tell the truth, more takes took place, but it was too much (even for me) to note them all here.

Take MLI

Only a small part now I had to redo... I think!

Okay, I never had any respect for the sheep-like behavior in the Linux community when it came to the "saint" status Linus Torvalds could get himself, but I must thank him properly, and the work he saved me now, really justifies no less than this.

He gave us GIT

Linus Torvalds, my savior!

Thanks to git and all the crap already being in commits I could easily recover most of the crap I just did....

It was ENTIRELY MY FAULT

An act of TOTAL STUPIDITY from my side makes that all I did so far has been lost, so I gotta start all over.

Icon works, styling doesn't... Oh well, I'll dig into that later!

The icon and the layout for CODE::BLOCKS should now also work. Let's see.

Suddenly Azor DOES save the project dir it its global config... Miracles DO happen

and more stuff is not right, I see

I really need to sort out why Azor doesn't save the project directory in its global config

Things go well so far!

Several things added, but not nearly there YET!

I've looked a few things up about what to put in .gitignore for Code::Blocks and bin, obj, *.layout and *.depends was exactly what I thought, and what some sources also confirm, so here goes!

And Gwendolyn works, by the way, so I can now get to focus on, tadaa.... SCI_Run

I'll see to it later that the CODE::BLOCKS tag gets its own icon is is styled like the rest

Take ML

Added tag CODE::BLOCKS

Converting Gwendolyn into Code::Blocks and see what happens

I will investigate later what the right approach will be for my SDL2 based apps, such as the SCI_Run app, which is of course for the run-time of Scyndi games. I am thinking to make Gwendolyn my actual test case.

This because Gwendolyn is a lesser vital app, so less dangerous to mess up. When I got Gwendolyn well-covered, things should get easier. Code::Blocks does have a template for SDL2, and perhaps that can make my life a lot easier.

Now if SCI_Build cannot find scyndi by itself it will ask for its location, but that's a later concern for when I actually get all this crap on the move.

Scyndi as now been compiled in Code::Blocks as well.

I have to note that the Scyndi compiler itself is NOT part of the SCI project. It's a dependency, so Scyndi will have to be compiled separately... Well, I think it won't be that much trouble.

Well, I couldn't resist... The SCI builder has been compiled for Linux.

I'm not gonna get SCI compiled for Linux today. (The SCI versions I have for Linux are HOPELESSLY outdated)

I've converted Syldeyn into a Code::Blocks project. That went pretty well. So far.

I've been giving Code::Blocks a try.

Not as good Visual Studio all all stuff, but it is, certainly for the time being a very decent IDE, and it may also save me a lot of scons files, and it can rid me of MicroSCHOFT.

On Windows it never worked for me. On Linux it fortunately does.

It looks like, this is gonna be a long run. I guess it's back to the command prompt (for now) when it comes to this one (sigh)

fatal: Unable to create '/run/flatpak/doc/2e443796/Script/.git/index.lock': Permission denied

Fantastico

Not really happy... all it can do is browse... Let's try GitFriend

Of course, new system new apps. As for Github (or possible other repository sites), I am currently giving gitg a chance for a quick gui interface, to keep my repositories up to date.

This devlog (generated by Azor) can keep itself up-to-date automatically, but with my projects, that's not really how it works, so I need to make sure stuff's alright

Well, the misary Microschoft put me through there, has been solved... for now!

Git base configuration covered

Well, the base config works, but it's not configuring Git I must worry about.

(Once you read this, consider it proof stuff works).

It will take some time before I can work on fully now, though. For starters, I will need to recompile a lot of crap before before I can work on, and not to mention that my current system is not yet up to par with applications in general.

And from now on Linux is also my main system. This also means that Linux will be the primary target of my work for now.

Well, the "surgery" on my PC has been completed.... Well, sort of.

Take MXLIX

Deprecated routine added as the coderot became unbearable and impossible to debug!

Take MXLVIII

Part I works, now to load a savegame done after this, in order to make sure, the banner won't appear again, if it already did so before!

Take MXLVII

CONCAT the Lua way, Jeroen. Not the C++ way and not the Pascal way! Okay?

Take MXLVI

Very bad, Jeroen! You know better than this!

Take MXLV

Done

I must trust on it that the loading and preparing works, but when not part of the DrawScreen routine, nothing will happen.

Take MXLIV

Reference mistake

Take MXLIII

Missing reference

Take MXLII

Code typo

Take MXLI

Well, I was getting bored, so I implemented the "Welcome" sequence. Was easy to do (I hope), and although cosmetic, better now then when I really could spend my time on something important

The next obvious step would of course be that the enemies would be chasing you if you get too close, but before I get to that, an important announcement is in order. My computer is as good as dead. For now it's stable enough that I could work on the game, but when you've had 19 BSODs on one day, you know it's only a matter of time before the system will bust.... AGAIN!

And what I did on the enemies so far was actually the EASY work.

A friend of mine will be getting to operate my computer (surgery, so to speak), and that makes me wonder if it's a good idea to continue now that I'll be getting into such a complex time consuming opreation of the game, when I'm now at a good spot to call it a day, and to continue later. Of course, it's also the question if things go right in the first go (nobody can tell) when it comes to the hardware replacement (which is, after all, always nasty business), so there's also no telling if there are any delays... And I don't want those in the middle of complex coding.

Long story short, I'll have to pause this project until I'm sure it's safe to move on.

Take MXL

Bad return look up

Take MXXXIX

Fuck you!

Take MXXXVIII

Would INTVALUE really return a string? (since when?)

Take MXXXVII

let's fuck this out a little further, shall we?

Take MXXXVI

WTF?

Take MXXXV

Moaning about a string? Not possible at that point. An extra debug line should help me!

Take MXXXIV

Fixed it!

Found it!

Yet the console log not only confirms it to be called, it also gives the parameter types that should NOT go with it!

Take MXXXIII

An impossible error. The function throwing it should not even have been called at all.

Take MXXXII

GINIE

Take MXXXI

Oh, well

Didn't I macro that one?

Take MXXX

misnaming

Take MXXIX

How on earth did I get to numlevel?

Take MXXVIII

Declaration fault

Take MXXVII

Static->Static issue

Take MXXVI

Enemies should now turn green/ember/red depending on their level compared to yours. With Briggs with you, that will likely all be green.

Arrays starting at 1 in Lua, but on 0 in Scyndi. 0 it will be, so Scyndi's Len check will be used, and Lua can just do that.

So far, so good!

Take MXXV

I totally messed that line up

Take MXXIV

ALL I can test now is if this compiles... nothing more. This is all UNDER THE HOOD code.

Set up routines that should color the enemies

Take MXXIII

I've set the enemy's dominance on 20 by default for now, but it WILL be possible for the databuilder to adapt that if it turns out to be needed.

NOW the enemies do appear (at last)

Take MXXII

More information pour moi!

??

Why?

No response at all!

Take MXXI

:= in stead of =

Take MXX

Property declaration syntax error (forgot the keyword GET)

Take MXIX

Enemy objects should appear on the map now, however they are NOT yet colored based on difficulty, nor ar they responsive to the player at all. Encounters will therefore NOT yet be triggered.

Object creation and link up

Encounter markers

Can't check that untill everything else has been done

Labels

And so far the log to myself

I think the data generator also needs to put in the label and dominance information. Labels in particular.

Record destroyer, which also removes the enemy on the map (can't do this with the garbage collector as the enemy will be put on the map all the time).

Create actor on map

Chain the enemies to the foe records

Read-Out levels.ini (needed to set the enemy's levels)

No way to test this until the moment comes the true comparing kicks in

Average party level calculation

Take MXVIII

Pure Lua will always fall over the fact that arrays start with 1 in pure Lua. I needed to void that. Now the exact order in which foes are loaded doesn't really matter so it's not that much of an issue

What's going on here?

Good, but not good enough! Only ONE foe gets actually listed.

Take MXVII

Missing static

Take MXVI

Wrong table

Take MXV

And this in particular must turn into a cockroach?

Take MXIV

I don't wanna talk about it!

Take MXIII

Worked too much with both C++ and Pascal for awhile, so forgot operators work a bit different here.

Take MXII

...

Take MXI

Extern