Really, this is really getting insane! More code to narrow it down!

Take MCXLV

More debug code then

According to the report it doesn't even get to the actual handling.

Take MCXLIV

code typo

Take MCXLIII

Moar debug

Yup, the translation of the abstract is where it goes wrong. How did I know that?

Take MCXLII

Take MCXLI

;

Take MCXL

Harsh debug then

Segmentation Fault - Well that one can cause me some headaches.

Take MCXXXIX

code typo

Take MCXXXVIII

Graphics

Take MCXXXVII

Standard value boolean

Take MCXXXVI

RPG2Stat

InterVar

:=

Take MCXXXV

:=

Take MCXXXIV

Replaced direct Neil references to direct Scyndi references

I really have no idea why Scyndi throws an error if a get and set get mixed up... (If you place the get first and the set after that no trouble)

Take MCXXXIII

not, static local voided, and Font Obtainer replaced.

Well at least I didn't get any complaints about abstracts anymore, but as there are more cases of code rot in this code, I cannot yet check any translations, so I'll have to focus on that first.

Take MCXXXII

Take MCXXXI

Da f....

Take MCXXX

Right-o, now for the Scyndi test

Take MCXXIX

I do see a few fallthroughs that should not be there (I've always hated C and C++ and similar languages for that).

Well, clearly it's not working.... Scyndi doesn't yet understand how to deal with an abstract at all.

Take MCXXVIII

The C++ compiler didn't send anymore. But how about building the game now?

Take MCXXVII

Case sensitivity in C++

Time to start compiling -> take MCXXVI

Basically in the way Scyndi currently is short definitions are easier and safer yet, to prevent code rot in converting Neil to Scyndi and with a few (uncertain) concepts I have in mind for possible future versions of Scyndi, it's better to keep the long versions supported.

Step Three, long abstract definitions SHOULD work now! (once again emphasis on SHOULD).

Step two, short abstract definitions SHOULD now work! (emphasis on SHOULD).

Step one, Scyndi reacts to the keyword Abstract

For starters the compiler has not yet been set up to deal with that.

The Scyndi core code has been adapted to make abstracts and class extensions possible. There is however no way to test this.... YET!

I have a few ideas of how to cover this, but it will not be exactly easy.

And now we have a problem as in the combat engine abstracts have been used, and that's a feature not yet supported in Scyndi.

Take MCXXV

Like always Code Rot will be my biggest enemy. Some occurences have been taken care of now

Take MCXXIV

Simplest of all, but I needed at least one file converted. The rest comes later

ALG_Stage

Bundle renamed from NeilBundle to Scyndi Bundle

Take MCXXIII

Neil -> Scyndi: LoadCombat

Take MCXXII

No longer link to the Neil Script but to the Scyndi script (which does not exist yet, so the next test will always show an error)

Take MCXXI

State.LoadFlow

So far, so good!

Take MCXX

I've set (as safety pre-caution) invisible enemies to being unable to attack (this to make sure no bugs can occur. The Yaqirpa in particular uses a very ugly area system that can cause bugs like these. It was the very first dungeon ever designed with Kthura, and also with enemies in the field. Stuff like this was bound to happen.

Now I do need to get another method to the Flow faker class, but that was not what bothered me

Take MCXIX

Ah, just a silly coderot issue

LinkedList does not have AddLast? That's a lie, but let me check more thoroughly

Take MCXVIII

???

Take MCXVII

Combat should now start. Or at least, the routines triggering combat to start have been linked. Errors are sure to come since the combat itself has not yet been scripted

But that doesn't justify another take

Coloring issue

Take MCXVI

Peace sign would be hidden behind wall

Take MCXV

Monster wouldn't despawn from map (but ignore you from that moment on)

Take MCXIV

Syntax error

Take MCXIII

Namespace mistake

Take MCXII

s

Take MCXI

Misspelled identifier

Take MCX

Graphics

Take MCIX

I've scripted the enemies to call the function that will start the fight, it will deactivate all other foes, and even starts a 'peace' time in which you cannot be re-attacked. The length of this time is (of course) dependent on the chosen difficulty skill. The enemy will also be removed from the screen. The fight itself won't start yet, and only a debug message will appear. This is (of course) for obvious reasons. The starting of the combat is more delicate and comes when all other stuff works.

Hey! RLWrap is a blessing. It makes Azor respond on the arrow keys the way it shoud and of which it was utterly ridiculous from the start no console app could do this (while on Windows all aps do that with the same code. So Windows *is* better than Linux on SOME departments, eh?)

So far so good. Now I have a few other obligations to attend to. Be back soon!

Take MCVIII

VREDE

Ah, yeah, the question I had in my last post is solved. I forgot about Briggs being there at level 20. Silly!

For green and pure green (the latter I wonder how they could end up on this man, actually), do seem to have their radiuses in order. Good.

Take MCVII

Before going to engagement in combat I need to check the activation radius once more

At last!

Take MCVI

And GitHub seems to have fixed its servers too

I think I found the motherfucker

Take MCV

Harsh debug

Take MCIV

Small fix in the setup

Well the website works... Oh well... not my primary concern now... If you can see this message it means it must have been fixed.

And I see the github server has some trouble. Error 500 and error 502. Both are server issues.

This is gonna be a long way to go!

Take MCIII

I really don't know if that fixes all my trouble, but let's get ready to rumble, eh?

One operator was wrong

Take MCII

Logs show that that enemies DO get activated. As a matter of fact, they immediately return to their original positions, and that's odd!

Take MCI

Linked to the console

A simple debug function

and I guess I'll need to figure out why

No response from ANY of them

Take MC

Another one

Take MXCIX

Two more

Take MXCVIII

Missing object reference variable

Take MXCVII

Link

Take MXCVI

The enemies should chase after you when you get too close to them, and return to their original position when getting too far away tfrom that position. They won't initiate combat yet, though.

More configuration done

Take MXCV

Illegal function call

Take MXCIV

Code typo

Take MXCIII

Void a fucking idiocy

Take MXCII

the enemies in the field will now have their ranges set for when to chase and when to stop chasing. Please note, nothing visual will happen yet, it's just under the hood, but some debug messages do appear on the console.

BTW I have also configured jEdit properly for Scyndi already... yay. One very nasty point about jEdit is though that the keyboard input often goes away from it. A typical Linux only issue so far.

I did some study to AppImage. It does look a lot easier to understand than FlatPak, but more studies will be required to give it a true go. But I guess, I'll have to set my priorities where they belong.

Medals has been relinked to Star Story I

and My Medal Studio is now translated from C# to C++. Good!

House Of Cards has been reset for Medals. Other games will come later!

As a result, medal scores and medal rates will be different in all future updates of my games. Never forget that!

More fucking fuckshit is that the data was stored on my old hard drive. Fuck that!

Dang! My medal studio application happens to be coded in C#

I used to be a Mac user, and when Steve Jobbs died I somehow feared that Apple would take this route... and it turned out I was right.

Oh, and a Mac version is not planned at all! Since I don't pay tons of money to Apple as a "sign you can trust me" (read: that I am actually developing software that Apple can use to control you and that they in turn can control me), a Mac version is also out of the question. And no unless Apple changes that policy it ain't gonna happen.

(And if Apple wants to see me for this post, I will definitely not develop for Apple anymore). People who wish to try to port SCI to Mac are welcome to try (since the GPL license prohibits me from banning the practise), but there will NEVER be official support... well, unless Apple becomes the environement it used to be again. (MAGA, Make Apple Great Again).

Oh yeah, important to note is that for the time being, compiling for Windows will be impossible for me. Any fixes to the SCI engine or new features can therefore not take place on Windows. I hope I can resolve that quickly.

Added tag WINDOWS

Take MXCI

That was to see if the butler ignore feature would be compiled. However a code typo was in my way

Take MXC

I've first make sure the builder is able to ignore Butler. This is important as I don't want stuff to be changed on itch.io while I'm still debugging stuff here.

This is also why Linux is deemed so user unfriendly when compared to Mac and Windows.

Well, the builder can build windows apps fine, but in Linux things are more complicated. Linux applications are strongly reliant on dependencies and unfortunately it was impossible to make SCI any different from that perspective. I tried to read the flatpak tutorials, but this simple system is beyond the understanding of people with an intelligence that is not beyond the regular scale of a human being, so for now that's not a realistic option. There are several possibilities. Creating a quick app with needed .jcr files and a list of instructions of the required dependencies. Not really the most beautiful solution, but beautiful solutions do NOT exist in Linux. The system was designed to be as ugly as possible and I'm afraid I gotta deal with that fact. Another thing is to make SCI a dependency on its own, but then with the means I have now that will still require the dependencies SCI needs. Plus is that this way, having the data .JCR will suffice of all games made with SCI. Can also be a nice solution, actually. I can even fake the .KJCR files as if they were apps. This is dirty. All solutions require me to instruct you to go for dependencies, however. Configuring package managers for Linux is (and has always been) a downright disaster.

That appears to be working.

Take MLXXXIX

The map Data Generator, responsible for making sure the data the encounter manager needs, and for making sure the welcoming banners are properly linked to their respective maps has been set up as a Code::Blocks project.

Okay, I updated all crap here first.

A true coder can never resist.

But first a shower... I'm just out of bed, and didn't yet take care of myself... Yeah, that's the life of a coder!

The next step will be to make sure the MapData generator works in Linux

It works.

Take MLXXXVIII

Missing return in Lua API... Well, that was easy... At least, I hope so!

Right-o, I guess HideButLabel is the source of evil here.

Take MLXXXVII

Trying to narrow things down more. At least it's prove the MapScript function has been called properly, but it appears to make some faulty API calls. At least that's my diagnosis so far.

Take MLXXXVI

Now a segmentation fault pops up during the mapscript event. I do know that Interstate calls themselves should work. This was proven by the fact that House of Cards could work without any remarkable issues, and although Star Story tops House of Cards when it comes to InterState calls, it still relies on them.

I've added a few extra debug lines which should provide some clarity on this matter.

Take MLXXXV

I think I solved the mystery. Statistician does support the use of a script function tied to a script. Apparently it was not set to a nullpointer by default

Take MLXXXIV

It's gets even odder. It reads out the levels for the two girls, but on Briggs a segmentation fault. No reason can there be for such idiocy,but apparently the system THINKS there is.

Take MLXXXIII

NULL?

Take MLXXXII

Would getting the level really cause the segmentation fault?

Take MLXXXI

Getting party data is not where it goes wrong... Somewhere in the caluclation of the average party level there must be something, right?

Take MLXXX

Narrowing down where the evil could be

Take MLXXIX

It appears clear that things go wrong while scanning for enemies. I can however not find anything odd in the Statistician routine.

But that's for another time!

The Segmentation Fault remained, though...

Take MLXXVIII

Alright? Really? (How will the game fare now?)

Take MLXXVII

Believe it not, but the same problem pops up... AGAIN!

Take MLXXVI

No errors, then now a build of the game

Take MLXXV

Moar

Take MLXXIV