MOAR!

Take MCLXXXVIII

I know

Vies Bah!

More self

Take MCLXXXVII

Sys

Take MCLXXXVI

Self

An extra run now to check the line number of the Scyndi code!

An UNRELATED error! Progress!

Take MCLXXXV

Nope! But perhaps now!

Take MCLXXXIV

Whiner?

This better?

Take MCLXXXIII

Wrong ref

Take MCLXXXII

I think....

The source of evil has been found though.

Take MCLXXXI

Manual update

too many takes to count

Take MCLVI

The story is now really getting strange!

Take MCLV

I need to narrow it down even more, I guess

it appears a segmentation fault occurs when the translation is being updated. Now THAT's odd!

Take MCLIV

I guess I need to narrow it down some more

Take MCLIII

I think I fixed a case of a wrong variable, yet the response to that is still odd!

Take MCLII

) too much in C++ code

Take MCLI

;

Take MCL

More debug

Take MCXLIX

I think I fixed it... I cannot be sure, though!

Take MCXLVIII

Now the debug info obfuscates something, but I think I narrowed the thing down, that's the source of all evil

Take MCXLVII

The info I get would almost imply that the for-loop having to find the identifier for the abstract was not executed at all. This needs further investigation!

By a stroke of magic it now provides more info.... Did it not compile before?

Take MCXLVI

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).