This is the official Trismegistus with Ex 0.9 download thread

[Holy_Diver]

The collosseum has a high number of npc/enemies that appear dependant on counter triggers...every other map has very few if any.  I dont know if that may have anything to do with it.

Other things the game may monitor that could affect your numbers randomly between maps that are not event based -
-dropped items staying on the map, including gold that is not picked up.
-whether or not single appearance enemies have appeared, im sure there must be some variables tracked for that
-the status of a chest that has/has not yet been opened.
-the status of a door that has/has not been unlocked.
-enemies that only appear a limited number of times is probably tracked in the memory you are looking at

Another thing, are the number of polls at all affected by the draw distance in a map?

Sorry... a few posts up I figured out what was causing the extra polling... apparently its a bug caused by "always on" events.

I reckon the players movement must be synced with the clock (which is already pretty evident) or otherwise the extra polling would've made the player move twice as fast and 3x as fast and so on per each always on event. In which case at least the bug would've been noticed

PS: Are you suggesting each of those bullet points are known to cause problems?

PPS: Just to be clear... when I say "polls" I mean specifically when Som checks the state of the keyboard and or joypad. There seems to maybe be some confusion.

So basically Ex has to filter out the extra polls somehow, and also deal with the bug that's especially wreaking havoc with the Take this item? screen.

I'm hoping it won't be necessary to go the the extreme of counting the always on events per map

BTW/Offtopic: Ex is just getting into snooping around the memory. The only really useful memory I know of atm is the counters and the basic player stats. Mainly the gauges and the stuff you see on the first menu screen, excluding ailments. The ailments might well be in the same memory but I haven't setup any scenarios to make them stand out. I probably have a lead on the clock, but it won't be practical to fix that bug until we can find out where the clock data is in the save file. It would be funny to sync an in game clock with the game clock / maybe make a puzzle of it. You could do other weird stuff as well of course.

[Holy_Diver]

Well....

I really tightened up the input today. That did not much help the "Take this item?" screen however in and of itself. But it created a much more sound environment for banging out a kludge that basically takes over input for the player.

I have no clue what circumstances cause this bug. It doesn't seem to affect Dark Destiny, but it may be very map/timing dependent. The input polling is not synchronized with framerate at all, but all of Som is single threaded. It makes for a pretty chaotic environment. Ultimately it would be nice to basically just hand off Som's "jobs" to different worker threads for sound/input/drawing. Which is an odd way to program since everything comes from a single thread, but would not be too hard, because Som is pretty much oblivious to just about everything it does. It doesn't seem to ever check the failure or success of an API even. Call it blissful ignorance. Anyway, I think that will happen at some point. Probably before upgrading to anything better than D3D9.

Anyway, the kludge I worked out is very voodoo, but it seems to have a nearly 100% success rate, and doesn't seem capable of doing anything destructive... though very rarely it kicks the player back into the Take menu when cancelling with the NO option (how often will that ever happen right?)

It doesn't seem to affect working games in any way.

There is definitely a huge bug going on, but I don't have the diagnostic tools to make sense of it at this point. The way SomEx is setup to take over the controls so to speak if necessary tends to run for about 200!! frames on average. But it happens in nearly an instant. That means Som is basically going totally out of control. The take over basically hits the button every 3rd poll, which should be one or less frames. I guess I should get some data on how many actual polls go by during that 200ish frames (because the two are basically unrelated)

Basically it seems like half of Som doesn't realize it's in the Take this menu? and the half that does just steps in and out at random.

I tried to deal with the frames getting smashed on top of one another but generally that just led to a bunch of frames you probably don't want the player to see. Basically Som doing shit its not supposed to be doing, but no one ever noticed because the frames are never actually displayed...

But ultimately working around that led to a number of input innovations which are really very nice.

Anyway, probably I will upload a new SomEx.dll build tomorrow-ish with these fixes.

[Holy_Diver]

Here is a build that should fix the Take this item? menu and some other odd stuff. Also you can use a custom resolution as low as 320x240 and not have the option menu go wonky... well in D3D9 mode anyway. D3D7 mode is generally not up to speed on a lot of stuff. Assuming your monitor is wider than it's tall... I recommend taking the height of the resolution you want, and multiplying it by 1.333333 to find the width that should work for you.

I'm thinking about adding a maximize button sometime soonish. Or playing around with the idea anyway. Just on the odd chance it turns out to be pretty straight forward/breezy.

EDITED: The D3D9 mode also fixes a bug where there are more than one resolution option of the same size. Anyway, it sees to it there is only one option per resolution so that the selection seems responsive. Though in general in the menus things never seem 100% responsive. There's probably not a non memory fix for that.

[Holy_Diver]

Hmmm, the save game menu in KF1 seems to act more or less similarly to Take this item? in Trismegistus. I suspect it has more to do with any menu that basically exits out of the menu system. Well that's the way the Take menu was, and I haven't seen it act any differently for the most part. Exiting the menu via backing out always seems fine. It may be only double menus affected. Anyway, let me know if you have any more trouble (after applying the attachment in the last post)

Also please let me know if the text in the window caption (says Trismegistus) ever disappears on you or anything else weird.

[Holy_Diver]

PS: It occurred to me probably only the popup save game menu is affected. Ie. saving via an event. If you think about it that works pretty similarly as a one screen menu. I think probably these menus not being officially part of the menu framework suffer from some serious oversight bug. I have not had any problem with shop menus as of yet. Those anyway are the only standalone menus I can think of than a talk screen with a decision branch.

[Holy_Diver]

I'm thinking about making a custom menu border for Trismegistus... basically by using the borders from the picture background. I have a feeling it will look better in matching the background

EDITED: Also I seem to have fixed the saving bug in KF1. I'm not going to upload a new build just yet, because I don't think it's needed for Trismegistus since it's anytime save afaik.

PS: I'm a little more worried about taking over controls in the save screen as in theory anyway it's possible your top game could accidentally get saved over if things went south. But it seems to work reliably on my present machine anyway.

[Holy_Diver]

I will have to upload a new SomEx.dll later for the Take this item? fix. Turns out I'd left something out for the keyboard which makes it a little less reliable.

It may be just as good for escaping / choosing YES, but I'm not 100% sure. Joypad/mouse should be fine still either way.