Take MX

JCR6

Take MIX

Sys

Take MVIII

link 404

Take MVII

The console data should tell me if this is loading properly (at least, for the time being)

Data load. The enemies themselves should NOT yet appear on the map. This is all under-da-hood!

That take was only needed to check a some debug data

take

I see that (likely due to scripting bugs in the Kthura configuration at the time, and I never saw before) the spots where the enemies will appear are not tagged for the always still enemies. This is is not necesarily a problem, but I must keep it in mind. The data the data generator produces allows me to work around this. As a matter of fact, the game itself no longer needs those spots anymore, as the data generator covers this up now, and only that data counts now.

Now these banners are not my prime concern at this moment. The foes are.

The Data generator has been programmed to it to add these banners to the compiled Kthura files, if available.

New will be that in Star Story too banners will now appear when entering a dungeon for the first time. These banners have been created

Ah, this was just a bug in the console output. The generated data is fine.

Take MVI

But let's check what is stored in the maps

I don't like what console output shows me

Take MV

I've also transferred the "Under Attack" version of Excalibur so I can test this on two maps. Of course, this map is not yet accessible in runtime.

I've set the data generator to configure the foes more easily

All output data I got shows what I wanted to see. So far, so good!

Take MIV

I only forgot to put in if the enemy would chase you or not, and that has been done

Take MIII

I have made a data gatherer for enemies

A note is in order. There were 4 settings of enemies. VT, HZ, SS and AS. VT=Vertical Move, HZ=Horizontal move, SS=Stand Still, and AS=Always Still. This denoted their movement, and except for AS, these enemies would chase after you when you came close. Now some important things are to be taken in order. Constantly having to check these enemies led to slowdowns, and checking the distance requiring the Pythagorean Theorism was also a killer. So it pains me that I will have to remove their movement, I will still check if they chase after you or not. Checking the level of the enemy comparing it to yours will only be done while loading a new map, this too in order to save time. Please note that when loading a savegame, the enemies are reset so then the checkup also takes place. The distance check will now likely be done by area check rather than Pythagoras. Pythagoras is a more realistic approach and therefore better on all accounts, but if it slows down the game like that, it can be more of a chore than a help. Life's full of nasty choices, we don't wanna make, but sometimes... we have to.

Take MII (well, for good manner, let's count it as a take).

I've at least made the data builder detect all enemies, and that it does.

Thing is, though, that I also have a lot of other matters to take care of today. Oh well.

Right, that being said, now the time has come to set up the enemies, which I was planning to do from scratch. I can only hope Visual Studio will hold out long enough to get things on the roll.

No take for that one.

CD time for mini messages halved

Take MI

Mini messages have been sped up a bit

Some old ImageFont properties replaced

Wow, take number 1000! And I'm still no further than the start of the prologue dungeon. Who could've imagined?

Take M

.GetData

Take CMXCIX

:upper()

Take CMXCVIII

Adaption of Give Item

We're getting somewhere (at last!)

Take CMXCVII

I really need to sort out why the regular Split doesn't work the way it should

More cases like these

Take CMXCVI

XSplit in stead of Split

Take CMXCV

.DATA.

Take CMXCIV

Syntax error

Take CMXCIII

Let's see what will happen if I uppercase all checks

Life's fully of mysteries, eh?

Not only now the items show, but the enemy spots do too...

The enemy spots were not yet converted, so I guess the compiler was suddenly fixed.

Take CMXCII

Of course, a runtime test will have to tell me if this works

I've made the data builder convert the Item spots to exists prior to compiling the Kthura map.

I see that the idiots as Microschoft did want to make things difficult about UNICODE. I need to see what the best approach is to void that issue when compiling with SCons. For now I could get the MapDataBuilder to compile in VS itself (suddenly stuf JUST WORKS).

For some reason it won't compile with SCons but it DOES with VS. Odd, since both use the same compiler.

Second time, no good either

Didn't start up... Good start... Not!

I guess it's rather a blessing Windows 10 updates stop, eh? :P

Wish me luck though, as now I am required to run Visual Studio. An application that has not really be kind on me since the last update Windows did.

In the meantime I can still conclude that my Kthura Compiled reader is still not really cooperative when it comes to custom items. I don't like that. However, as these items also bear a tag, I can can still convert them to exists. For the game that won't make a different as long as they as spot based objects and not area based. I could even use an obstacle (although that's not the best of ideas).

At least I got some new hardware at the ready, the current planning is that things will be installed next Sunday. However, it's still a bit shaky how things will turn out. After that my main system will also be Linux, and what that will mean for my upcoming Windows releases is hard to tell at the present time. To be continued.

It really looks like my computer has stabalized for the short term, but still 19 Blue Screens Of Death is a clear sign things are really getting out of control.

Not only that, but my file association linkups have gone completely busted, some apps don't work anymore and I need to minimize the programs I use. So all-in-all, things are still fucked.

Well, at least the game can start up again, but I've been warned that the .exe file may be faulty. I hope I can however resume my work, but you understand that given the time right now, and me being full of rage, that this is not really an option. Unfortunately, my schedule is pretty full the rest of the week with other things requiring my attention. I also have a book to finish correcting. At least I can use my old mac for that one, but still.

Make that EIGHTEEN Blue Screens Of Death!

Well, my computer went through no less than SEVENTEEN Blue Screens of Death today! All because Windows insisted on an update! Fuck them all! I hope the system has stabalized by now! Like I said, an entire day WASTED!

Well, it appears that MicroSCHOFT has finally done it! They killed my PC completely, and it's very likely beyond every form of repair.

So fuck you MicroSCOFT!

I really hope that worst won't come to worst that I have to re-install VS completely or that my days as VS coder are definitely over due to not having a WORKING compiler available anymore.

Well let's first run the update and see what happens. (sigh)

In the end there are still internal compiler errors, and the story even goes worse. VS is even unable to find its own header files. How about that?

Ah yeah, removing the .vs directory will lead VS to switch back to Debug config (and hence it couldn't find most of the headers, as I configured those directories only in the release config)

Seems like it.... At last!

Finally willing to compile now?

VS immediately crashes. Fuck you!

At last!

And now I wonder how much playtime I lost on Tomb Raider what I was playing to kill some time, while the cleanup operation took place. (GRR!)

Thanks to the boys and girls at MicroSCHOFT I will likely waste A FULL DAY (which I could NOT afford this week), as another Blue Screen Of Death is now the reason that the entire cleanup operation got corrupted and cancelled as well, and that I have to start it all over! So FUCK YOU, MICROSCHOFT!

The packing is running, but it can take awhile.... The corrupted file was not part of anything important anyway, so best to ignore that.

Ah, something is on the move

Oh wait.... I am just using rar to pack and remove all the .vs folders and something funny pops up

Cannot read contents of E:ProjectsApplicationsVisualStudiovs_templates.gitobjectsce.vs
The file or directory is corrupted and unreadable.

Well, what can I make out of THAT?

This operation can take a looooooooooooooooong time, so I guess I will have to wait before I can continue the project. Well, in the mean time I'll eat a bowl of griesmeelpap and perhaps I can play a little game or so.

No idea if this will work, but I did find out that when you delete the .vs folders you can quite often fix internal compiler errors that the C++ compiler in VS quite often frabricates. It's my guess some files in there easily get corrupted when a BSOD occurs, which, is of course, since VS is a microsoft product, very extremely ironic.

Restart done

I fear a complete system restart is in order as more crap is not functioning the way it should

Same outcome!

AGAIN!

Take CMXCI

Internal compiler error

Take CMXC

Recompiling SCI

I've modified the compiled map loader a bit.

Still no good! I think I need to check how the compiled data is being loaded then.

Take CMLXXXIX

As new data has been generated I need to do another run-time test

Take CMLXXXVIII

What I can see in the logs and the hex dumps indicates no issues. No let's take a look in-game.

Well at least no crashes for no reason THIS time.

Take CMLXXXVII

MicroSCHOFT, THANKS FOR FUCKING EVERYTHING UP!

There never any telling how things will work after a restart due to a BSOD, especially not when it came right after a system update.

And meanwhile it even crashes completely.

Without any reason at all VS restarts stopping my debug

Take CMLXXXVI

A debug scan put in

Cool.... Visual Studio crashes on searching a solutin

Not one but TWO issues show in the log. First, all tags are in caps, which is as I suspected. The other is that the items don't show, which could indicate that the Kthura compiler is still having trouble on that department. Since SCI has already been recompiled that couldn't be it, but the map databuilder which also houses the compiler could still have issues.

Take CMLXXXV

Take CMLXXXIV

I have the feeling I know why this is, but I want to make sure and this debug line can help me to confirm that.

The log indicates that the random item generator isn't called at all.

Take CMLXXXIII

There were a few dummied debug lines in the original code. Let's reactivate them (always good not to destroy such lines, eh?)

Once you've eliminated all the impossible, whatever remains, however impropable, must be the truth.

That taken in mind, I can at least rule out the absence of the required icons as an impossibility. But what next?

Well still no random treasures

(Although honesty requires me to note that I actually didn't even expect otherwise).

Take CMLXXXII

No clue if this will do anything, but we'll see

Bandage roll (new art)

Adhesive bandage

Well, enough crap there, so that should not be the problem.

Please note, this is the oldest dungeon ever created with Kthura, and that was years ago, so you cannot blame me for not knowing the entire map anymore, mind you!

Let's first search through the Kthura map to find about a bit more about the map's integrity.

I already noted that the random treasures do not appear. The big question was of course, why.

Quick investigation shows that the code is present. The question is of course if the icons are all present already. I need to sort that out.

The day starts nicely with 2x BSOD. Cool! (Not!)

For now I see what I wanted to see, and it's not very fruitful to continue right away.

The next step will be to make sure the random treasures and the monsters are in the field. Both can cause me a lot of trouble, so I guess it only makes sense to take some reas first, eh?

Take CMLXXXI

Let's alter Wendicka's next spell requirement a little.

Take CMLXXX

Function -> Property

Take CMLXXIX

List issues

Take CMLXXVIII

It was not super handy, byt yeah, that debug line did save me!

Take CMLXXVII

Sigh!

Take CMLXXVI

I do not know why Wendicka in stead of UniWendicka is called for, but perhaps this little line can answer that question

Take CMLXXV

Did I fix it?

Take CMLXXIV

Core syntax error

Take CMLXXIII

Extra info on errors. This should help me to locate some untracable errors a tiny bit easier

Take CMLXXII

array start issue

Take CMLXXI

.ini suffix

Take CMLXX

Not good.... no .neil, but .lbc

All compiler crap appears to be accounted for, but what will the run-time do?

Take CMLXIX

Syntax error

Take CMLXVIII

Unsupported intern function

Variable transfer mistake.

(Hello again, Wendicka. Back on the right side of the screen?)

Take CMLXVII

WTF?

Take CMLXVI

?

Take CMLXV

Sys

Take CMLXIV

Loads of voids

loads of fixes

Take CMLXIII

RPG2Stat

Take CMLXII

Scope error

Take CMLXI

Take CMLX

I doubt it will all work, but I gotta start somewhere, eh?

A lot

I hope this goes well. I have set up a system that will allow ONE value of either String, Number or Boolean type to be returned by an InterState call. All other types will be nil. I don't dare to guess what can happen this way, but let's hope for the best. It can spare me a lot of trouble with the item sub.

There we go... next stop.... SubItems

Take CMLIX

Several cases of :upper()

Take CMLVIII

Sys

Take CMLVII

Ah, the move was never added due to a bad formed Boolean check

Right, at least the game doesn't crash, but I need to figure out why the abilities Wendicka already has don't show in her ability list.

Take CMLVI

FINALLY, just a regular case of code rot. I never thought the moment would come I'd welcome that. MouseX() and MouseY() -> properties.

Take CMLV

gv crap!

Take CMLIV

Same story, different alias

Take CMLIII

Alias! Fuckie fuck! Not gonna get myself more instances of that fucking error as long as I don't have to!

Take CMLII

This is REALLY getting annoying

Take CMLI

Fuck

Take CML