SomEx instructions thread for Rathmor demo

[Holy_Diver]

EDITED: Verdite neglected to explain that you can change the analog mode by pressing the Esc key. There are probably other things like this to know (that should be explained in a game manual) but this is a fairly important point for the demo. See Reply #7 for more info.

I must be off for holiday business, but I did not see anything in the OP per some matters that we require feedback on.

Namely Verdite reports that the Take item? and popup Save Game menus effectively ignore controller/keyboard input. This is a bug in SOM that Ex does its best to mitigate, I do not personally experience this trouble thanks to Ex. If you play the demo please report whether or not these menus are able to work for you. If not you will get stuck. The game isn't freezing. But it seems that if you click on another window then click back you can get unstuck.

Obviously this is unacceptable, and since at least one person is not able to play SOM games due to this, finding a new way to deal with this bug is agenda #1 from now on.

Again, we could use a census of who is having this problem _and not_ and saving from inside the Main Menu does not count. Edited: There is now a poll here (http://www.swordofmoonlight.net/bbs2/index.php?topic=119.0)


Also please don't try to make the game play in non-window (fullscreen mode) by editing the Ex.ini file. There are Ex bugs (that will be fixed shortly) that you will run into. You will need a fairly beefy computer to run the demo at a constant clip... or as close to SOM ever gets to that. My computer is still choppy at the lowest resolution, so probably a very high end CPU will make a big difference. Verdite reports no troubles at 1600x900. After making SOM presentable next gen SOM/Ex goals are to make SOM fly on low-end hardware (by stripping as many cosmetic duties away from som_rt.exe as possible)


EDITED: Also I recommend sharing this (http://www.swordofmoonlight.net/holy/Rath%20Crags.htm) link. No guarantees that the .zip link will be around forever but links on the internet have a way of being just that!

[Holy_Diver]

I haven't really suggested (or even thought about) any non-technical changes to this demo outside of the kind of bugs that any game tester would report. But I recommend adding the following two lines to the [Adjust] section of the Ex.ini file for a more realistic and more enjoyable walking/running experience. If for no other reason than to better evaluate the improved locomotion provided by Ex's new (and undocumented) do_sway extension.

Code: [Select]

[Adjust]
pc_walk_speed_multiplier = 0.5
pc_dash_speed_multiplier = 0.7

;edited: for while dashing
fov_frustum_multiplier = 1.35
If you want a more athletic PC you might use .6 and .8 instead. I think these settings are more manageable for keyboard players too (try WASD+mouse and see for yourself)

EDITED: added fov_frustum_multiplier = 1.35 to keep tiles from disappearing along the edges. Necessary because the dash speed is made proportionally larger with these settings. You may need to increase this if you monkey with the turn/dash speeds. In theory decreasing it improves performance.

Bear in mind if the demo itself is updated WRT walk/dash settings, then these adjustments will then adjust the new settings potentially resulting in undesirable settings.

The demo doesn't tweak the locomotion at all, the defaults simply mirror SOM's "bob" sine wave, which is probably not ideal, but it's practical as far as defaults go. In the future it would be nice to have the locomotion based upon actual measurements for humans WRT height and movement speed, as they are the target audience after all 

[Holy_Diver]

PS: I've noticed some twitching due to the walk effect provided by Ex. There's no reason to account for it beyond the frame rate being irregular. In theory it should go away if your PC (probably your CPU) is powerful enough. It doesn't happen with my (miniature) testing project anyway. Unfortunately SOM is not really cut out for low-end PCs. If your game is very basic like the KF remake it may stand a chance, but authors tend to be much more ambitious/irregular in terms of map layouts.

Without Ex the performance would be even much worse, and there are no extensions that weigh on the CPU with the exception of do_lights / do_fix_lighting_dropout without which SOM's lights don't really work well and go out as soon as you change the Options.


On the bright side,

Very shortly it will be possible to optimize MDO files, many of which (especially custom files) are unnecessarily broken into many many pieces which could very well be having a very negative impact on communication between the CPU and GPU. That may make a big difference CPU wise and would take a large load off of do_lights as it would have to deal with a lot less model pieces.

EDITED: SOM's MDL files are also probably broken up into pieces. However the custom models produced by x2mdl.exe are not. Optimizing SOM's MDLs will be possible to do too. 

[Holy_Diver]

I've made a poll here (http://www.swordofmoonlight.net/bbs2/index.php?topic=119.0) per the menu bug. Feedback is good for SOM

A poll here would probably be more accessible, but it's not my topic.

[Holy_Diver]

FYI: You can change the "Analog Mode" by pressing your Esc key while in-game and not in the menus.

Sorry this just occurred to me. Verdite should have explained this in the announcement. A game would need to explain this in a manual I suppose. Mode 2-A gives you two sticks to work with. 2-B inverts the look axis. You can add more modes by editing do_escape_modes in the Ex.ini file if your controller is not represented. You can also calibrate your controller but for a demo it's probably not worth the bother.

A player can also add [Joypad] to gain near total control over the controls. [Keypad] for the keyboard. And the mouse is setup with [Detail] via several mouse_... extensions.


PS: Probably by sometime next year do_escape will access a PS3 like system menu that will replace SOM's System menu unless do_system is used. The new system menu will use [Joypad] and make Analog Mode obsolete.

[Holy_Diver]

I am in some agreement about the healing...I am not a fan of downing 10 sea herbs to get to full health.  But i also realize this a very early demo and it does showcase your customs.  Holy.. the issue i experience with menu/ picking up items is SOMs inherent need to queue keypresses so since the cancwl nutton is the same as the interact button i often find picking up items a pain.  Perhaps a keypress debounce could be added?

Ex already divides SOM up into input "contexts" to prevent this sort of thing. So if you are experiencing issues its because of this bug that happens when exiting from a menu into "the field". This kind of thing sometimes occurs when exiting the main menu, suggesting that the bug is in play there too. It seems to happen because SOM is schizophrenic about its different states of play, in other words sometimes it is simultaneously in the menus and not in the menus, and when that causes noticeable interference it manifests in this way. Anyway if you leave a menu and the exit button makes the player do something in the field (with Ex) it's because SOM can't make up its mind what it is doing. And if the movement is very pronounced, it's because several frames went down the memory hole during the long pause that you likely experienced.

It's the last serious bug doing visible harm, and unfortunately its far more vexing than any of SOM's other bugs as there is no obvious way to attack it. It's like the last boss of SOM game mode wise. I'm confident that it will be bested but to be honest I can't in good conscience encourage people to make games with SOM until this bug is definitively out of the picture (if you just want to play with SOM of course that's another story)

Either way there will eventually be an emulator that won't be plagued by any of SOM's bugs, and I inadvertently spent a large part of this year working on that. I hadn't planned on it, but as soon as I started programming a model viewer I knew I didn't have the time or patience to maintain two separate ways of displaying SOM's models on a desktop. And displays are like wallpaper... in that it doesn't make sense to put up wallpaper if there is no house, so that's most of the 3rd and 4th quarter of 2012. I only started working on SomEx.dll again because I was inspired by the control work I did for that and wanted to get SomEx.dll's control stuff finalized while controls were still in my mind (and it occurred to me how an extension added for what later turned out to be an Ex bug affecting Hearts Collide could be used to do analog controls; which is of  course essential to any 21st century game)

PS: The cancel button is the same as the Menu button but its not the same as the Action button; the one used to pick up items. It's a good theory that when you hit the confirm button SOM picks the item up again before its been confirmed, but it doesn't explain why the input in general is non-responsive. The likely reason for that is SOM can't decide if its doing menu or field input, as if the input system is out of sync with the state/presentation system, probably because 2 different programmers worked on them and did not compare notes.

EDITED: I was forgetting that the Action/Menu button is configurable. I'm also not 100% sure that my assertions are in line with the default configuration. They probably are, but it may be based on a configuration which I once used, but I doubt that because I never use the first few buttons for Menu/Action because they are the face buttons on the PS2 controller I use. Anyway I don't suppose that changes the prescription, but it's a technical correction.

[Holy_Diver]

I haven't really suggested (or even thought about) any non-technical changes to this demo outside of the kind of bugs that any game tester would report. But I recommend adding the following two lines to the [Adjust] section of the Ex.ini file for a more realistic and more enjoyable walking/running experience. If for no other reason than to better evaluate the improved locomotion provided by Ex's new (and undocumented) do_sway extension.

Code: [Select]

[Adjust]
pc_walk_speed_multiplier = 0.5
pc_dash_speed_multiplier = 0.7

If you try/like this you should probably also change fov_frustum_multiplier to (=) 1.35 to keep the tiles from disappearing along the edges. This just adds a gutter for this sort of thing. It's necessary here because the dash speed is made proportionally larger, so this must increase too...

The reason why is because Ex's camera is lagging behind SOM's camera while dashing. Ideally the analog camera would keep pace with SOM except that would make it dip even further into walls requiring a larger player radius, so it's like the dog is pulling its master at this point. You don't notice the difference at that speed anyway, and dashing is expected to be a bumpy ride.

There is another problem when walking backward at the slowest speed where the analog camera does not reach escape velocity so to speak.... so there is a lurch after the slide momentum builds up. There are no extensions to adjust this yet so there is not much to do about it other than turning off do_walk (which has the player move slower when going backwards / sideways when walking)

There is also the twitching especially noticeable when walking sideways at 90 degrees. I intend to look into this. There's probably something that can be helped whatever is going on. Doesn't happen in my test project (again) anyway which probably moves at nearly the same speed.

You can also add bob_distance_multiplier to decrease the eccentricity of the bob. I recommend this because SOM's bob is quite eccentric. Something like 3.5in in all. You don't move that much when walking. Maybe while in a mad dash. sway_distance_multiplier can be used to adjust the sway, probably making it larger than the bob is closer to how you walk?

FYI: for sway its bob_distance_multiplier*sway_distance_multiplier; IOW sway is not independent of bob. A serious author would adjust these as long as the default behavior is to go with SOM's numbers (the Ex.ini file really needs a way to tie it to a particular version of SomEx.dll)

*Where "*" indicates multiplication. Ie. x times y.

[Holy_Diver]

So I figured out what was making the walk effect twitchy in the demo...


Basically if you are using a Sony Dualshock controller... for some reason or another the sticks do not produce linear output. I don't know if that is considered to be good or what. But I've never played a PS game that I can remember where I was at all happy with the analog calibration with respect to sensitivity/ramp.

For instance with Demons' Souls and Dark Souls its nigh impossible to walk, so I don't even know why the animation is in there. I prefer to not run everywhere like a spaz given the option. For some reason towards the edges of the sticks there is a lot of sensitivity but not towards the middle.

So in my test project I added the following...

Code: [Select]

[Detail]
escape_analog_gaits = .2 .25 .3 .4 .55 .75 .95
To make the sticks more linear so not to jump past gaits. If your sticks are twitchy you might try adding this to the [Detail] section (note: not the [Adjust] section this time)

What was making the twitch was the gaits hopping back and forth every other frame. So in the upcoming SomEx.dll release (shooting for a few days from now) I intend to add some logic to make the the gait switching more discreet (like quantum leaping)

But until then, you can just add this if your controller is twitchy. Why this helps twitch-wise is it just puts more space between the boundaries. If you happen to keep the stick over a boundary then it will still be twitchy. The problem with the dual shock is just that all of the boundaries in this case are near the edge.

[Holy_Diver]

I am in some agreement about the healing...I am not a fan of downing 10 sea herbs to get to full health.  But i also realize this a very early demo and it does showcase your customs.  Holy.. the issue i experience with menu/ picking up items is SOMs inherent need to queue keypresses so since the cancwl nutton is the same as the interact button i often find picking up items a pain.  Perhaps a keypress debounce could be added?

PS: The cancel button is the same as the Menu button but its not the same as the Action button; the one used to pick up items. It's a good theory that when you hit the confirm button SOM picks the item up again before its been confirmed, but it doesn't explain why the input in general is non-responsive. The likely reason for that is SOM can't decide if its doing menu or field input, as if the input system is out of sync with the state/presentation system, probably because 2 different programmers worked on them and did not compare notes.

Correction: I was forgetting that the Action/Menu button is configurable. I'm also not 100% sure that my assertions are in line with the default configuration. They probably are, but it may be based on a configuration which I once used, but I doubt that because I never use the first few buttons for Menu/Action because they are the face buttons on the PS2 controller I use. Anyway I don't suppose that changes the prescription, but it's a technical correction.

[Holy_Diver]

 

FYI: There is an Ex bug in the demo that makes walking sideways/backwards slower than it should be... and slide forward further than you should. I'll post a link to a new SomEx.dll file to be dropped in the EX/SYSTEM folder as soon as r1.1.1.5 is released tomorrow or the next day (fingers crossed)

Basically what it boils down to is I apparently forgot to locate the dash state in som_rt.exe's memory. So the player seems to always be dashing from the point of view of the do_walk/dash/pedal extensions. You can disable those to move at normal speed but the slide extension (do_pedal) will still behave as if the player is dashing