simple machines forum
Sword of Moonlight => Devs => Topic started by: Holey Moley on September 29, 2017, 09:10:20 PM
-
Seems I just can’t quit Sword of Moonlight! Earlier in September I made up my mind to work on the MHM files that are counterpart to the MSM files from last month. No one really knows what these acronyms mean. I hazard to guess Map Hull Model, and who knows for the S in MSM. Sculpture? Possibly its Japanese.
I thought it’d be a small project, because there is — or ought to be — far fewer MHM to MSM files. I added value to the exteriors set by fitting it together vertically, forming terraces, that look like a strip mine. This is something users like to do with the odd set that is experimental compared to the interiors. It’s the only one that isn’t a level of From Software’s remake of King’s Field included with SOM, an enticement doubling as a demonstration.
I would refine a few 3D sculptures (models) and that would be that. But what I found sent me for a loop; because the hills of the exteriors set were — it turned out — a Frankenstein’s monster of mismatched parts. It was as if SOM’s artists had deliberately applied their craft to solve problems of software; as if the set (set of tiles used to make levels in video games) had been pulled together long after SOM’s software engineer staff would be reassigned to new projects.
I may have discovered this after or before I discovered that my terracing idea wasn’t going to work (without reprogramming) because it wasn’t possible to walk the character along a sloping path that ended at the edge with a shear cliff. This was a kind of geometry that From Software’s developers hadn’t anticipated.
Around this time I was interested in learning more about the MHM and MPX file formats. I think one day I took a look at the MHM files just to have something different to do for an afternoon. I had looked at them before on one or more occasions and what I saw in them never really clicked for me. MPX files are much larger. They are a “map” or a level in the video game. They contain the MHM and MSM files arranged on a grid work, and the scenario for their part of the video game. I am interested in them now because I am certain that they are going to be the main subjects of recent developments going into 2018, aside from the ongoing COLLADA work, that I'll now be returning to, my job done here, and not to mention, overstayed.
Thanks to work I did a while back, but not so long ago in the timeline of releases, the puzzling parts of the MHM files immediately clicked. Before I knew it I was returning to round 2 of that work on a part of the player that I call a “clipper.” I soon became preoccupied with this, and this would last for the rest of September, until today. This release is possibly the most consequential single contribution that I’ve yet made to SOM. It’s a very important part of the player.
Ostensibly I wanted to make my terraces work, and get to the bottom of the scrap metal like MHM models of the hill set. I began by rebuilding those models. And I thought I understood why they were the way they are — or were. But I turned to be wrong. I happened to introduce a doubled-up 3D data point that caused the issues I was experiencing. But in order to figure that out, I had already opened up the hood of “clipper” and climbed deeper down its rabbit hole than in years past.
Amidst this process I began to make unrelated refinements to the clipper and also the motions and movements of the player. Many spectacular in their own right. Too numerous to recount. I kept pursuing the main problem, which basically amounted to bringing sloped features closer to being first-class polygons in the eye of the clipper. But at each turn I would be thwarted, and also find more side projects. So that I just kept taking on more and more until I realized this was going to be a mega release.
Early on I found time to work on the map editor a little more. I added color pickers in classic SOM style to it. The clipper makes the video game a solid world. As a result of this release it is truly solid now, and made perfectly smooth — free of glitches — with complete support for climbable slopes. I event went as far as to try to extend the angle of the slopes that could be surmounted, but those experiments didn’t pan out. My chief concern is that artists should be able to use steeper slopes to construct small, easily trod features. I’m sure I will return to the clipper for another round. I want to wait however until better visualization facilities come online. Presently the MHM information is completely hidden from users. While an interesting act of faith, working with things invisible, it does seem like SOM is really missing something. I try not to carry on with unsound facilities.
It’s not so difficult to see how important a “clipper” is to a body game such as King’s Field. I would say that it is now at a nearly professional level of presentation. And that ambition wise it far outstrips even its most renowned commercial peers. I will include a complete list of developments in the Forum Discussion accompanying this blog post.
I'm still editing this blog post; but enjoy this new release (finally) submitted for the approval of you or King's Field's ghosts.
I apologize for dashing. Something's bothering my eyes. It's either too many days testing movement features (long hours of staring and thinking about how to refine the movements in the computer; repeating them over and over, and trying to find out glitches.) Or it's some damn glasses that I tried anti-reflective coating with because the order form made it seem like I had not choice but to. If I could see out of these things without cleaning them several times a day they'd amount to hundreds of wasted hours... and for what? To not have cool lights reflecting off my glasses :box:
The world (the people in) (their behavior patterns in aggregate) boggle my mind sometimesall the time. I'm sure the creator(s) trying to make a point. I just can't understand it :rainbow:
EDITED: This is 1.2.1.8 and I recommend doing an SVN Update and using the updater to download. It's in the csv directory as always. There's also language pack changes. SOM_MAP's new color pickers require the new packages in any event. They're more a curiosity, though they could be genuinely useful also. But you can get by with or without them. They are just a professional flourish I though would add some color.
P.S. This release's among my best work. Don't miss out. Will say more tomorrow. Oh and for the record, I didn't have time to work on NPCs (although they now enjoy more thorough clipping, especially around slopes) and I stopped short of my list of MHMs to rebuild. I will pick them up later after a well deserved break. They will have to be side projects while I return to COLLADA-DOM. SOM work is so addictive and exciting, but the input problem is the most pressing one. SOM can be nothing without some way to get fresh data into it. :thumbsup:
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This patch does a sound fix for a problem I thought I solved yesterday before uploading. The problem with testing clipper logic is you have to perform the movements, and sometimes the glitches occur and sometimes not, so you just have to do them several times and see if the glitch remains.
The patch lets you cleanly fall off of a slope MHM polygon without landing on the same slope in a weird way, because the slopes really extend beyond the polygon itself. This is kind of necessary, just as the clipping radius can extend out beyond the edge of a platform.
It is a new problem. Previously I guess it wasn't even possible to have this problem unless you had a slope without sides, since the sides would've long spit you off the side of the slope.
A fix meant changing the prior falling logic (extension) so now once you begin to fall as the clipping shape grows the climbing shape is capped at half its size until it reaches full size. Maybe it should stay half size until landing to prevent climbing onto small perches while falling, but it's possible to climb while falling, which would permit climbing onto such perches. These lesser considerations can be addressed later, or at least as soon as a high stakes title materializes.
-
EDITED: I bungled that patch :doh:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
Third times the charm. (I substituted one variable for another thinking it was equivalent--in the context--being a true/false value instead of a real number.)
-
I will try to list the clipper/movement enhancements that are the centerpiece of this release.
* Slopes may have walls on the outside. That is to say, you can build a ramp. Or walk on the edge of a pitched roof or up a mountainside path. These are just examples. Really this enhancement should cover arbitrary geometry equally well.
* Further work has been done so that slopes do not have weird bumps in them. I fixed the problem where slopes meet flat polygons the last time I worked on the clipper. But I think I shot myself in the foot and didn't know it until the same problem came back except only along the edge of walls--which is why it went unnoticed. Later I came to understand another problem of going down slopes from the top of a flat polygon. In that case the polygon had to be cleared first causing you to basically fall down onto the slope. This class of problems is eliminated by this release.
* There's now a dampening filter in the X/Z dimensions meaning that when you turn a corner of a structure the transition from one polygon to the one beside it aimed in the opposite direction is no more an abrupt one. This is actually my favorite highlight of this release. It's something I've long wanted to take a crack at. I'm surprised it works so well. Yesterday I was sneaking around like a spy peeping around corners and the entire experience was perfectly tranquil. You can really lose yourself pretending that monsters don't see you. Corners are still hard, meaning you can't really press on them at 45 degrees. The smoothing can only be short lived. It gets weaker as it is applied, since if it went on the clipper would fail in its function to be a barrier.
* Angled polygons now get a lateral cut out test that hadn't existed before. Whereas flat walls would get this test, angled walls only received a top-down test. I don't know if this yet applies to magic missiles, but just as an example, this means that a fireball should have better clearance passing near angled polygons. Of course NPCs enjoy this too. But it's easier to picture as a ball passing through. This upgrade is required to walk over the tops of angled walls, which are necessarily connected to slopes. It's not just that simple because the shape doing the walking is a cylinder that has a width. The technique I've employed to make this work is good enough for shallow slopes. But I'd like to eventually extend the angle that slopes can be moved over, and the present technique (it basically lifts the cylinder up as far as necessary) will have to be discarded to do this (instead of lifting the cylinder up something like every slope polygon will have to form a hull such that any wall on the wrong side of any slope will have to be ignored. That's a lot more complicated but not impractical.)
* The clipper is somewhat simplified, because I was able to make a list of the hit polygons and exclude them from further testing; whereas originally the only way to not test a polygon was to get out of its way. That could cause problems, especially with walls that face each other, because anything would get stuck between them bouncing back and forth, and it was just unnecessary tests, since the original code always did up to 8 rounds of testing. For example, the wall with a square window in it, would capture you between the two walls of the window, and so the rest of the model would let anything pass through it, never being tested. The original model actually had a five sided hole with a triangular top, whether originally that MSM model looked like that, or the MHM model was changed to workaround this defect. This need to move past polygons before clipping could proceed just made certain configurations infeasible.
* I discovered a bug in an extension that lets one leg stand astride a ledge. It was possible to walk away from this and never have the clipping shape return to its full size (dashing or other things would return) and so you could actually walk into a wall at the wrong size, and so get closer to the wall. This is hardly worth mentioning, but because of it I was able to make this feature look much better eventually, but before that because of a fluke accident, I discovered a change that made it much easier to recover from falling off platforms, and I liked the result, so now you can move much more freely over ledges and things without worrying too much about falling off because it's pretty easy to correct if you take a tumble, but you can't be completely asleep at the wheel. Time will tell to what degree this is a permanent feature, because in truth I would rather that it were not possible to fall at all under most circumstances, as if there were guard rails. But this capability will always be around in some form, even if future developments make it much less prominent. (There will be an option to turn off guard-rails completely, but I think you should feel free to look around without fear of walking backward off something, and technically if you can't look over a precipice it's a blind leap--which is not fair.)
* That feature became an unexpected balancing act between climbing stairs and straddling SOM's cyclopean half-meter ledges and also retaining the unexpected fall recovery ability. So I spent a lot more times with stairs, and I think I improved them somewhat. I also lessened the bounce on stairs, or that is if you are walking down short climbs the bounce is much less. I recall that it was not possible to reduce the bounce before. I think it may be unpleasant without some of the smoothing extensions on, including the one that blends two frames, but by now I think these are pretty much essential. In the end I wanted to time the footfalls with stairs when climbing, since when going down the stairs you basically just fall, and the falling sound effect makes it sound like you are walking down stairs... but really you're not... still I didn't want to go to great lengths to do this, so instead what I did is speed up walking when going up short climbs and slopes, not to go faster, but to move the walking effect faster as if more steps are required. I don't think it matches the number of steps on the stairs, but it's something. If only for time being.
* Now in order to hit a polygon something must be on the side of it facing outward. This makes it possible to make much thinner walls, even paper walls. Like in traditional Japanese houses. But it also makes walls that form acute angles behave correctly. For example the exterior set has a diagonal wall that forms acute angles. You can observe (with older versions) that it has real problems, and there's even an unused MHM model of it that you can tell someone at From Software did some experiments to try to work around this problem, but eventually gave up the effort. I don't know if there was some reason the developers thought that polygons should cover the space behind them also. If a model is well formed it should be impossible to get behind them. There is evidence in the programming that this was intentional. But I think if the clipper is rock-solid it shouldn't be necessary to consider things on the wrong side. And its more flexible to users this way, and in the case of the diagonal wall, essential to correct behavior.
* More than anything else I labored over what's probably the most difficult single problem clipper-wise. That is windows like those in the first set of the KF cemetery. Basically a hole in a wall that can be entered. They are difficult because the clipper doesn't consider polygons in any kind of macro sense. It has no idea what the relationship of polygons are. And the window problem runs counter to how things are organized. That is first there is vertical movements, and then lateral movements. That is to say that there isn't true freedom in three dimensions, the system is divide and conquer, resulting in essentially a 1D and then a 2D problem space. You can approach the window either as a 1D or a 2D problem, but either direction throws a wrench into the clipper, because it's truly neither. So I tried many different ways to conceptualize it, and it just kept proving intractable. Note that the real problem is not climbing into the window. That's a simple problem. The real problem is falling into the window, or jumping into it, which basically amounts to falling. What has to be avoided is ending up in a state where you are in the window but also outside the window, because that's a balancing act that really isn't physically possible, and so stretches the credulity of the enterprise. That's the real problem. You have to figure out how to prevent this state. I've still not perfected it since there isn't a cut and dry solution. But I've reduced the probability of this happening by quite a lot. Sometimes it seems like it just happens (although you basically have to be trying to make it happen at this point) but other times you can try maybe a hundred times and not succeed (now after lots of time and effort and refinements) and so I'm more or less content. And I spent so much time on the problem, and being frustrated with it, that I was eventually able to refine the solutions in large part until I'm quite confident in their efficacy and footprint. Not having a straightforward solution, the solution was basically to find an angle of attack that just felt right, and then to come at it from as many ways as possible. There are probably at least 10 places throughout the code with notes on how this modification here or there plays into the overall scheme of getting stuck in windows. It's really quite funny. It's an entire project in itself. I wouldn't describe it as hacks. It's more like the ultimate edge case in a near complete system. But anyway, if not the highlight, this is the crowning achievement of this release. I feel like if the window problem can be beat, then anything else is a paper tiger. And yes, you can crawl in and out of SOM's windows, even though I think there's only one instance of windows among its stock tiles. BTW: A secondary aspect of the window problem, is how to keep out of windows that are too small to fit in, like the square pigeonhole tile. It may be counter-intuitive, but the same programming that makes it possible to enter a window makes it just as difficult to not enter a window. (Recall that the system only deals with individual polygons, although it can make generalizations, like what is the ceiling and floor height and so on; but you don't really have that luxury in the lateral domain. The ultimate solution to the window problem was to temporarily increase the size of the clip shape so any available walls will knock it away from the inside of the window. This requires the window to have a ceiling, which is really only interesting because normally ceilings only keep things from going up, but here it must do as the walls do to keep things from going in... but it cheats by getting the walls to do its bidding. It sounds straightforward if put this way, but temporarily fattening the shape is very delicate and is not guaranteed to just magically have the desired outcome. It requires a lot of specialized handling that is basically contingent on if the shape is fatter than it's expected to be.)
* Oh! Almost forgot. I worked on jumping off the top of a slope. That is one that ends like a ramp. This is a special case, where you keep going up the slope, but when the cylinder shape reaches the top it is completely outside the slope as far as it is concerned. I fixed this by adding some "air time" proportional to the speed more or less, as if walking off a platform at constant speed. But I realized afterward (and it is a somewhat perplexing problem) that I'm really not happy with it. It would be more correct to make the top of the slope act like an infinitely thin platform. Though that's a little unsatisfying too because teetering on the sharp edge of a slope is a little less believable than on a flat platform. But this applies even to very shallow angled slopes. Ultimately my goal was just to have a good experience jumping off the platform. The code that came out of this could be slightly tweaked to add an extension for giving a little extra time to make a jump. In fact at first I applied it a little to flat platforms. Because first person platforming is notoriously fraught. But I decided that the recommended diameter is 1 meter, and that's plenty of breathing room for jumping. (I also restricted it to having a velocity that is going up, both since going down it might be unwelcome and because I'm pretty sure the problem doesn't apply going down, since the slopes extend downward invisibly---as they cut into the cylinder clip shape.)
EDITED: Rereading this I feel like this is some of my best technical writing I can remember. I'm probably not the best judge, but I feel like I've really described these difficult subjects well here. I might be a half-decent communicator. I don't know. Probably just a fluke.
-
Patch
I guess I added another feature where if you open the same tool using the same project folder, because it's not good to have two, the currently open tool is made the active window instead.
Problem is, SOM_MAIN doesn't have a project folder, so I disabled its sharing test completely (originally SOM only allowed one tool to be open at a time) and (as a running theme) neglected to give it a try. So as a result with this patch its taskbar functionality (minimize/restore) is inoperable.
BTW: One more things I forgot...
Because the clipper is very solid in the final days I changed some warp/glitch detection code to make it treat all warp like movements that happen outside the context of a warp event as suspect and so return the player-character to their prior position to the warp-like glitch.
I did this mainly because of a single double door I knew of that would suck the PC inside it if running between the doors when closed, and spit them back outside the side of the door, where there is not a floor...
In general this means any remaining glitches are removed until I can work on them. Generally it's impossible to see that you are being moved back... it's as if there is a wall, so you just need to go in a different direction.
But this has some side effects. One is if you use F4 and stop inside of something then you are stuck there inside it. Probably I will fix this at some point, by disabling this behavior while turning off F4.
If for some reason you encounter such a warp-glitch (most likely around objects or other non MHM geometry) and do not wiggle free from it, you might have to use F4 to get free yourself. Of course, this is not good if you are a player without F4 enabled. But top priority is a glitch-free experience.
I'm going to be adding a new Alt+Alt system before long. And it will likely incorporate some emergency combos such as Alt+Alt+F4 for example. It's mainly going to focus on keys around the space bar. Since they are closer to the Alt keys.
-
Patch
OKAY! WTF Gives?! Now I feel like the universe is just toying with me....
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
I don't know why but something in the Visual Studio text editor I always DISABLE was enabled yesterday, it does drag-and-drop copy paste, and managed to turn a number from
test dword ptr [ecx+edx+8],80000000h
into
test dword ptr [ecx+edx+8],08000000h
And I'm just damn glad I noticed it before it became something completely impossible to trace back to the source.
So in the last patch, this makes items appear to be invisible.
I'd been trying to make sense of a bug that crashes the Moratheia demo when going into some maps. It has something to do with items.
Off-topic: Yesterday I stumbled across something that appears as if it can only be one thing. I don't want to say what it is just yet. But I'll just tease that it's big and cool and it's basically something everyone's wanted SOM to be able to do that the King's Field games all have, and it's actually inside SOM and working, but SOM_MAP just doesn't have the settings to tell the player what to do with this capability.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This patch fixes a problem where dashing was not accelerating. A "clinging" variable never quite got to 0 and was impeding the dash as if climbing.
I think this happened because I removed a test for pushing against the wall up to X amount, so that any push at all, even residual would climb. I thought that that approach was probably from pre-clipper extension days.
CAREFUL: Like 5 or 10 minutes ago I uploaded a version of this patch that disabled ducking into crawlspaces. I thought the climbing code should be more conservative but while trying to understand this I realized it was for crawlspaces too.
ALSO There's a semi-experimental fix for that Moratheia demo bug I mentioned in the earlier post. I don't believe it can cause any harm, but I still don't know what caused the bug to begin with.
-
Special parting PATCH
This patch enables mouse-wheels! Finally.
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
Some years ago I disabled mouse-wheeling. I think it still worked in drop-down menus. But it was very inconsistent quality wise, and the listboxes (e.g. events and SOM_PRM's main lists) were embarrassingly awful. It's really dumb because the listviews (some of the multi column lists) always worked wonderfully. SOM_MAP's treeview was very bad too. And the custom view ports didn't work at all I think. So for consistency sake I just put it off.
I thought that I would get around to changing the listboxes to use listviews. I don't like how the listbox is highlighted. Since it looks like it's selected.
This afternoon I just wondered, what a really stupid mouse-wheel implementation would look like, and it looked alright. So here it is.
-
Fancy patch
Believe me, I feel foolish to keep spouting off "patch!" in the last few days; but...
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
Technically this fixes an error with the tap_or_hold_ms_timeout extension being limited to 500ms even though the default has been 375ms for a very long time. (Defaults aren't limit checked.)
In the beginning 375 was tantamount to ninja speed. But over time it became simply the most responsive setting; especially for video game veterans.
Today I started to notice, or think that 375 looked kind of glitchy, because it just wasn't enough time to do the dash-step move at 60 frames per second. I'm sure it would look alright at a higher frame rate, but it feels choppy at 60. (It could be a low FOV thing. Many settings feel different depending on the FOV.)
So I tried 400, but it didn't feel right. But just in the middle ... an odd 383.33 both feels right and gives a good animation. It's just one extra frame at 60 frames per second. So don't let any one tell you frame rate doesn't matter. Even 1 frame is visually perceptible.
This extension still exists to convey both speed and heft of movement. But honestly it's so circumscribed down to a single frame that I can't recommend to fool with it, default wise. Some players might be on a different wavelength; but let them do it themselves I think.
ANOTHER little touch is in all my clipper testing I began to sense that the footstep sound was too precise and so sounded like a perfectly timed machine. So I added some randomness to the pitch and volume. It's virtually imperceptible, but you might notice if it wasn't there. There's more variation at slower/quieter speeds.
If it seems too loud, it's just playing at the same volume as the NPC's footsteps. I can't tell a difference in any case. May be the PRF files can't even change the volume level. The volume only goes down. Unless your speakers are very low, you probably don't want to set the sound effects volume higher than 10.
EDITED: For some reason 383.33 can get stuck in dashing mode. I've changed it to 383 until I can figure out what's going on. Assuming this trouble is even because of the fractional part.
-
:confused: I think there must be something very wrong with the walking motion effects in this build. I can't understand what it is. And I don't know how I didn't notice it before. Or how long it's been like this.
I think I've improved the back and forth motion. But whatever is glitching out makes the improvement practically undetectable.
There's something very off. It's just very subtle. But that's all it takes. I'm going to have to tear the whole thing apart at this rate :censored:
EDITED: I should probably start (tomorrow) by see what some older releases look like....
-
Final Patch?
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This patch much improves the walking effect's sideways movement...
The problem from Reply #9 has to do with the frame rate. I don't understand why, but something about it has changed since 1.2.1.6. Probably for the worse.
I can't think of any reason why. But the prior release doesn't exhibit the problem is all that I know.
As for the walking effect, it is more a symptom of the problem. I think that this release is probably polling input faster than it's rendering frames. The average frame rate is still 60 fps, but historically SOM is very erratic. It's only over a very long time become stable. When reporting averages. Unfortunately I don't have a system for getting fps stability info out of past releases.
ON THE PLUS SIDE it brought my attention to these walking effect problems. Which would be exhibited regardless at lower frame rates.
There are two basic problems with the old effect. One is I basically then copied the "bob" sine wave; which is not right I think because this adds a flat period to the wave where the sign reverses. So this was the wobble effect. Kind of.
The real problem (frame rate aside) is the walking direction (the foot) tracks the velocity of the bob basically, in one-dimension, and it can look as if the velocity is going in the wrong direction in the trough of the wave. Depending on how it's sampled. That extra flattening phase in the middle hid this problem because the flatter wave would mask the transition better.
I changed it to an elongated wave to remove the unwanted section, and this made the sampling ambiguity very pronounced; so I added a check for this edge case.
So the walking effect is much more robust. And I hope nothing got broken. But the frame rate problem remains.
The poorer or more erratic frame rate is what made the walking effect issues visible to the naked eye.
I SUPPOSE it's theoretically possible that a more regular (less erratic) frame rate could make the effect more clear, simply by reducing noise that could trick the eye into not seeing. But my instinct is the frame rate is degraded.
(If a computer has well above the minimum requirements, maybe frame rate related things don't happen for that system.)
-
Not-a-patch :biggrin:
I got up yesterday with an idea to solve a *new* problem with some of the double-doors where extension must do the activation test, and I don't understand doors well enough to do it perfectly (it doesn't work with the wider clip radius) so at close range on one side the object's center is actually behind the PC.
My idea was to use the clipper subroutine, just as if walking into the door, to get more information about it, and make sure the test is on the right side.
That worked well enough to remove the problem. And make the activation radius smaller...
But it reminded me about the small swinging doors, which have an awkward cylinder clip radius, and it's actually possible to approach them from the side and get between the rectangle and cylinder.
So I thought I was done, but later in the day I got cocky. I realized that this was a perfect opportunity to experiment with doors.
So, I tried to remove the cylinder first. And that was not so hard, but it made those doors permeable from one side... So I stubbornly redoubled my effort; hoping for low hanging fruit.
EDITED: The permeability was an extension bug. I guess the cylinder is just to give the swinging door a wide berth so not to knock the PC backward. I think the clip shape should match the geometry and that moving out of the door's way enhances the experiences. Perhaps it helps to have a 1/2 meter radius and lots of smoothing.
But I didn't come away successful, and used my entire work day on doors. But I did learn some things...
1) Doors seem to use a generic box test. I don't think the box is at the center of the object though.
2) It doesn't make sense that the door would be semi-permeable. It suggests something really funky (SOM's doors seem like a wad of hacks to me) or that the generic box test itself is flawed. The most likely reason is the test can't work with modestly thin boxes. Like no thinner than these doors if so. I'm going to try making the doors a little thicker in the program this morning.
Strikeout: turns out this was an extension that removed a funky vortex on the corner of objects and adds a slight tolerance like MHM geometry to not stick to objects. I thought I ruled this out, but it was cringe worthy obvious when I realized this was it and it should have been because it assumed the center of the box test was at the center of the object.
3) I lost most of my time trying to improve the box test. The object clipping process is apparently completely stupid. All evidence says that every object is tested, no matter if its 100 meters away. And the tests themselves are awful:
3-2) They don't begin with a basic, Is the box close? test. They do a 2D inside-outside test first. But this test is not doing anything. I modified this test to to reject things on the opposite side, since I thought this would improve the too-thin problem. But the result of this test is not to reject the object, but only to choose a different algorithm for doing subsequent tests.
3-3) None of these tests are lightweight on math. Again, every object is tested, even if nowhere nearby.
4) If every object is tested indiscriminately. I can't see any reason to believe that the same is not done for every mobile NPC. In which case you have a ridiculous amount of clip tests going, like 500+ for every NPC/PC, and the tests are all heavy duty. The cylinder tests are simpler. Luckily NPCs are cylinders, so the fact that they probably test all against all means that they have exponential complexity is less of an issue.
I don't have any spare time to look at this stuff. I was showed lack of discipline to get reeled into it yesterday. But I feel like before very long I want to dig into this all-against-all aspect. And I'm thinking about converting the basic shapes to MHM data as a starting point. Which could facilitate rotating the objects in SOM_MAP.
PS: I wrote about this slight door activation improvement in Random News yesterday, but I wanted to say a little more. Really I did it because of the change I did to prevent warp-like movement resulting from objects now mainly. I did that for a double-door I knew of. And so I thought, this door also has this other problem. So I wanted to better the other half of this door's lot.
I really do not like the cylinder shape in the small doors. I also noticed yesterday that the secret doors are actually much thicker than the wall. So you can get stuck on them sliding along the wall. I think with Ex you do not get stuck, but do hit a speed-table like shape at the door. I don't know if this is a problem in their DATA files or in the program. But I'm aware of it.
-
Patch! :redface:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This patch cuts player_character_bob in half by default. I think half works best with the new sideways sway effect from the last patch. It's a much more round number. I think this is how it is meant to be.
This is as if setting it to 0.075/(2-pc[12]) and this patch also fixes a bug in the number parser, where parentheses were being interpreted as as a "function" and somehow this resulted in the above formula becoming "(2-pc[12])/0.075" and so I couldn't simply recommend a new formula in the meantime. The bug was because when looking to the left of the ( in the formula it was as if / is not there and because the end result of flipping the operands works for * and + but not for / and - it was not discovered until now.
Finally, this patch is the final word on doors. I finally got to the bottom of the permeability problem. It was because of an extension that used the center of the object, but for doors it should have been using their hinges--or disabled. I feel dumb that it took me so many hours to figure this out. I should've seen the logical contradiction...
But in fairness, at one point I did try with the extension disabled, to no effect... but it seems like every so often when doing quick tests I forget to close out SOM programs or the build fails or something that prevents the SomEx.dll from being copied over, and that means that I think I'm trying something with something disabled I really see the results of having said thing enabled. There's really no solution.
The doors are still not perfect because box-objects are not perfect. The double-doors can chew you up and spit you out. It's just random chance if the side or the face of the door gets you pretty much. Nothing in the clipping routine is designed to compensate for moving clip geometry.
The cylinder shape is removed. I think it only existed to meet player's expectations of not getting pushed by the door as it opens.
I applied the offending extension to the doors via the hinges. I wasn't going to. But it should help with the secret doors so that they appear identical to walls. Still they are too thick; but I think that's better fixed in the DATA files. I did at one point make them thinner by recognizing their width in the program, but that is a "hack" and since all of the those experiments got pulled (I was actually able to make the swinging doors behave by thickening them... but thankfully not the double-doors) that did too.
It's interesting to note that the object's width is basically ignored, so this means that the width of the door must be in the model's control-points.
If there's a silver lining to the last 2 plus days of work, I've learned pretty much all there is to know about doors. And also I can probably use them to figure out how to tell if an object is an animation or not, and that could open up the animation system. Which is a first step to extensions that show new 3D stuff (anything like raising a shield will require this step.)
-
I can't Escape from Sword of Moonlight :updown:
Below is a demo post I made yesterday about a new King's Field 3 style extension.
PATCH
This patch (http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip) is a quick fix for a bug that triggers jumping when you might not want to jump. I've long been unable to put my finger on it. I've been playing the Moratheia 2.1 demo lately, and every time it happens I think about it a little.
I thought maybe some code that had converted the new "half-gaits" into 0 might have changed to returning nonzero codes. Actually there is jump code to handle the half-gaits. But I looked at it, and I'm pretty sure either there's a typo in there, or I was being a ditz when I wrote it; leaving some huge gaps in its logic...
Right now, I can't think of a reason to include a half-gait in jump-detection, since they don't appear except to support a full-gait. In which case the full gait should override them. Though it's a little more complicated then this.
Strikeout: I reinstated this. The half-gaits are tracked because the controller has to go on cruise-control to complete the jump. The code looks fine. I would delete this post, but it's bound up with the quote below.
In any event; I want this fix to go out immediately. And I don't want to add anything to disable the new no-stun extension described below. So it's going into this release, warts and all (mainly it disables multi-hitting weapons--which may or may not be a thing--and is effectively compulsory for now.)
Here (http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.9.zip) is a demo of a new King's Field 3 like stun-less attack system.
I was unwinding yesterday after a trip. I've been trying to play with the Moratheia 2.1 demo since it's quite functional now. The monsters aren't balanced for the new damage formula or speeds. They are very aggressive. I thought that if the combat set up was more flexible they could be less so...
And so I realized that after the work on the sky and shadows a while ago, there wasn't anything standing in the way of doing an extension like this.
The caveat is I don't really know how to reason about multi-hit weapons, assuming they are a proper feature. That will require testing specific weapons---and I don't know which if any are multi-hit.
The system is enabled if do_red and do_hit are enabled. do_hit2 enables do_hit.
I think KF3 may not flash red if a stun animation is played. Right now the flash is always done. Personally I prefer if it always flashes. The PC always flashes, so the monsters should too. And it creates an expectation of a flash, and it is like abstract bloodshed. The only down side I can understand is if you want to see the stun animations in full color, you can't.
I've added a factor of randomness to the fighting. I think this is interesting and not really like a "miss!" when a blow clearly lands. Instead, if the blow is halfway between an always stunning hit and a no-stunning hit, it has a random chance of stunning, that is proportional to the difference.
The PC can still attack while stunned so their situation is not changed.
EDITED: I've updated the ZIP to add a fix for NPCs and the F7 overlay ... and also the PC now gets to avoid the stun penalty same as the monsters, but is still knocked off their center. So there is no buckle or loss of the ability to dash...
I think the default setting is alright for monsters. You might think that the PC should do the stun penalty more easily. But I think if so, then the monsters should too. That can be done with the red_multiplier extension. It changes what is considered the cap in terms of HP loss. The default is 50% so it follows that the PC will not stun unless they are hit by at least 25% and up to 50% the stun is not guaranteed. So this means to experience this a monster must hit the PC very hard. And the PC will probably be dead soon regardless if a monster is so damaging. But I think it's not a bad default. Especially if people think the stun is annoying.
Decreasing the cap to 25% means more stuns all around, and redder screen effects and that only 12.5% damage or less will not stun. I just think 50% is a rounder number and a better starting point, and I like that a monster shouldn't last more than a couple good hits if they are doing the stun animation, because fights can really drag on longer than they should otherwise.
EDITED: Fixed some problems with F7's display. Mainly it wouldn't show information for 1-hit kills. I've had to make a lot of changes to it to avoid showing old data in memory and I didn't consider this. It now waits one second longer after NPCs die before returning to the prompt. (This part has changed a lot in this demo, since before it scanned memory, but now it gets information directly from the damage subroutine.)
-
PATCH READ ALL ABOUT IT
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
The change I made for climbing off platforms down onto a slope at the same height wasn't complicated enough... this patch restores the ability to climb onto platforms from off of slopes.
It also adds code to one of the ceiling test for when the platform is itself a slope. In which case the height being climbed to must be projected to where the slope might meet the walls being climbed onto.
For the record; I still haven't gotten to encapsulating all of this stuff so NPCs can do all of this. I'm trying to get that into the next release. But things are slow going. Still lots of great PATCHES of late :thumbsup:
P.S. I'm a little more eager to patch because Verdite is supposed to be trying this stuff with their Moratheia project. But usually I am pretty fast to upload these kinds of fixes just on the off-chance someone is trying SOM for the first time right now :rolleyes:
-
Woops!:doh:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
The last patch wasn't good enough for running over slopes. And I'm currently back to the drawing board on climbing onto slopes as a result.
I had to trek all the way back to that section of the Moratheia 2.1 demo to see if climbing them would work or not. I'll figure something out.
-
The fallout from this release is getting ridiculous. The movement/clipping stuff is getting to be more than I can keep track of!
In any event, I've figured out a system that works per the previous post. It's patched of course.
I had to add some smoothing code to moving up and down over slopes in order to be able to run across the triangle and diamond shaped slope tiles. I don't know if this was always a problem, or a side-effect of the changes I made to be able to have smooth experience both walking/running on and scaling slopes.
I think the slopes are probably not stable in rocky combinations, so this is probably a good enhancement. Thankfully it just has to smooth when going down, which can't be confused for climbing up. The slopes have these weird biases. They need special treatment attacking them from the bottom or top.
I've noticed last moment that jumping+scaling sloped platforms isn't taking right now. The slope climbing code is all pretty new and dodgy and I've not been thorough about it.
I'm trying to patch existing features. And trying my damnedest to not add anything new right now.
I've noticed that jumping seems unsatisfying. I have a feeling it's because of the same irregular frame rates problem that prompted me to reevaluate the walking effect. Some jumps are fine. Some are stunted. There shouldn't be any variation.
-
Final patch?
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This patch fixes item pick up, which sometimes can happen without any special screen appearing. This is very rare, except in the Moratheia 2.1 demo, where for some reason it is not uncommon.
This patch fixes a problem with this release with maps that open up to text events; because I've added code that ignores glitches that look like they are warps... unless they are legitimate warps. Problem is, legit warps were missed in this case. (som_rt/db.exe sometimes stops rendering a "frame" in the middle and begins a new one, which makes it difficult to speculate about its internal state.)
I also tested jumping->scaling slopes. It seems to work. There is probably something funny about the MHM geometry I originally tried it with. It might have double-sided faces or something; Coming from a custom tile in Moratheia. (It was quite tricky to set up such a scenario with SOM's original array of options.) Another possibility is a wall may really be a very slight "arch." There's probably some work to do there. But later.
I also noticed that the half-gaits were accessible by themselves, alone. They should always be paired with a whole gait. So I added code to remove these. I don't know if there is similar code somewhere... I looked for it, but what I was doing was creating a whole gait with the rotational axes and a half-gait with the positional axes, and that shouldn't be possible. This might explain some weirdness hither to now. (The layer that generates the half-gaits at best can only see if another axis has a whole gait, but it doesn't know what the axes are for, so it can't make decisions at this level; if it does at all.)
P.S. I thought the warp bug was an original SOM 2000 bug. But false alarm. Here I'm trying to address anything that gets in the way of enjoying the Moratheia 2.1 demo.
-
OH YESSS :evil:
I feel bad about this. But in the most recent patch I've disabled an AI option that makes monsters turn to face the PC while they are doing their attack sequences...
I realized why Moratheia's demo was so joyless for me in the swordplay dept... How it differed from the previous demo. Why the monsters seemed like pointless, mindless attack dogs. I realized this in the crypt section, fighting with the skeletons... I knew something was just wrong.
I don't know why Verdite switched to using this. But I estimate that there is no good application of this option. It just makes games look poorly made and not fun at all. So I've taken the nuclear option of turning it off.
I wanted to turn this off for myself, so I could enjoy the game. I can't think of how to formulate leaving it on as a configurable extension. And I can't think of any reason to ever use it. I'm hesitant to disable it in SOM_PRM. I don't know what to do in the meantime though. Ideally it can be repurposed. Still AI seems like the last frontier of extension work. So I'm uncertain about when that might be gotten to.
-
EDITED: The items pick-up thing remains. I've re-uploaded an untested patch that does the input context switch directly inside the Take? subroutine. Really should've done that in the first place. I forget what's known territory and what's not.
It's very possible that there's no relationship between the input and frame loops; and so that the input could always becomecome before the frame stuff (drawing) or vice versa. All I know is that there can be multiple input snapshots per frame, and I think I've seen evidence of which comes first being basically random... or at least with the clipper, if not drawing.
-
For the record (I wasn't going to announce this) I've uploaded one last patch that fixes a nonfatal zero-divide when hitting NPCs with 0 HP (causing a fully red flash) but doesn't address invincible NPCs with nonzero HP (I didn't want to track down the memory that makes NPCs invincible.)
Also it removes something I tried for reasons I can't remember why that would change the dip after a jump/fall if landing on the middle of a platform. That was an experiment that's probably obsolete now.
P.S. I've closed out all of my SOM stuff. I'm going to do at least one feature for COLLADA-DOM before I do anything else for SOM. (First I must put back zipped COLLADA archives--ZAE extension--support. SOM doesn't require this for anything, but I have an obligation to restore the feature since I disable it in order to better organize the software library.)
-
And patch...
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
There's a bug in the map crash fix that removes items from maps upon return. I caught this because it removes items that can't be taken too. Otherwise it just seemed like all the items were successfully plundered in the past visit. I think the maps would repopulate with items during play, but any that were saved or left on the map would not return.
The bug seems to affect maps that have never been visited only. Which sounds like something Verdite said once. Luckily, I just had to move the clearing of the old items to a more sensible place (while the MPX file is loading) and this side effect went away.
Also, and I don't know how or why, there was a potential crash in the F6 overlay. Something to do with the pow/mag gauges having too many bars. (This would happen on Loading a game. I don't understand it. F6 limits values to its number of bars--this is impossible.)
I've removed the long input context switch hoping that the idea I had to recognize the context change in the respective subroutine is sufficient. I worried it would have problems with existing extensions that expect the delay to be as little as possible.
I noticed that there was movement happening in the fade in and out screen effects. I'm not sure why, but this patch fixes that too. I may have thought the paralysis code handled it, or that input was not polled during the effects.
EDITED: A new do_save extension found its way into this patch. It's not documented. I might forget about it until asked. It makes the Save function work without save-points. But it doesn't work if the game disables saving with an event. I will later add a do_save2 for that if necessary. This is mainly for debugging, but also for people who're busy.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This patch improves lighting when the number of light sources exceeds what's possible by selecting the closest light sources (which may or may not be the brightest lights relative to distance.)
There is a bug here too since going over the limit pushes lights off the back of the list, so they must be moved to the front or there is flicker or just chaotic lighting changes.
EDITED: For the record, som_db/rt do seem to compute correct ranges for the lights. If an object is not in range, the light is not considered. I first discovered this problem on a Moratheia 2.1 demo map that has pits of glowing toxic something or other, that produces light, so each light had a range of 50m, or they are 100m across, which is a 1/4 of a map, so there was a lot of overlap. And more than 13 such lights for many things.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
Sometimes jumps happen that go in the orthogonal direction. This kind of a jump is usually an accident. It happens because the direction is changed and the positive and negative directions coexist and cancel each other out.
Also, I've made it possible to jump more freely so that jumps in quick succession are more likely to jump and not stumble. I didn't put a lot of thought into it, but I thought I'd restore some functionality I ripped out with the old Jump button. Doing the jump input sequence is not simple, so it just jumps, even if it looks flatfooted, coming off another jump. It doesn't always work, and doesn't apply to the deeper landings. I'd like it to, but it's more complicated. (EDITED: The older system had simulated pressing the jump button immediately on landing. Which was kind of cool admittedly.)
YESTERDAY'S PATCH had a bunch of DLL files in it, because my mouse is old and malfunctioning and does weird things in a blink of an eye. This one replaces it. I just noticed that, accidentally. I noticed it was uploading slowly yesterday.
There's a new feature in the INI file that you can play with if you want to. It must be manually typed into the file right now. It changes the thumb pad orientation in case your thumbs don't agree with it.
http://www.swordofmoonlight.net/bbs2/index.php?topic=267.msg2367#msg2367
It might have some strange side effects because controllers don't report proper circles for thumb pads. So the effect is fuzzy. I think maybe it makes jumping a little bit off, but if the bars match the jumps looks the same. I generally like it. I tend to drift, or not be able to move straight, and this helps to straighten me out. EDITED: It seems to make the gait windows smaller (or larger) and I think I see the two jogging gaits almost disappearing at some angles, which can look bad as it vacillates between gaits. I've set up Caps Lock to disable it in debugging builds so I can spend some time comparing it with and without. My (DualShock3) controller seems weird... at maximum the angles at which it can move at a true 45 is about the size of the head of a pin. It reports 1 for like a full 30 or 45 degree arc across the top, so it's by no means a circle.
-
EDITED: I redid that patch to add a few last second things.
1) I wanted to refine the lights code from the previous patch. Nothing new, just better code.
2) I found a bug that I think may be new that happens when holding down the pick-up and cancel buttons... this would make the two screens flash for one frame apiece indefinitely---proving they work; but not pretty. The problem was I'd foreseen context switches, but failed to consider what it meant if a button originated in one context, and then the context changes, but then the original context returns!
Come to think of it, I only fixed this for buttons... so it might still exist for other kinds of inputs. There is also a bug where holding down the Action button when the menu closes momentarily registers in the new context. I think this is actually something in the player that carries over from the menu.
3) I had a note to rechristen the "do_shuffle" or "do_bicycle" extensions that I never could settle on a name for to from henceforth be called do_stipple2. So simple, I don't know why I don't think of these things. I've updated the wiki information on it and added do_save to it. The old names are gone. Games shouldn't use these extensions... they are for end-users to use.
-
BELATED FEATURE PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
This is a fix for a classic SOM_MAP bug that I wanted to get into this release. I'm patching it in since the bug can make map work tedious and I don't know when the next release will be...
Without further ado it fixes a problem with ctrl+click that arises when the click causes the palette view's scroll bar to move. When this happens if you don't know what's happening it's easy to end up with a bunch of 0 elevation tiles. It also loses rotation, which can be easy to miss with floor/ceiling squares.
And even if you know it will happen, it's an annoyance. Of course, now ctrl-click is the default click behavior (so it happens when not holding down Ctrl.)
-
SOM_MAP KEYBOARD PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
I noticed SOM_MAP's Home key function wasn't working correctly... and while trying to figure out why I noticed that the fix to make the palette area flexible/fill out the last column didn't recognize the right arrow key.
(Which is nuts.)
The patch adds a horizontal wrap-around function to the palette. If you use Home and the keyboard to get around this can speed up your work.
-
KF SAMPLE PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
I noticed text translation bugs in the SAMPLE (http://svn.swordofmoonlight.net/SAMPLE/KING'S%20FIELD/) project that this patch addresses.
Needless to say I haven't looked at these files in a long time, so they've gotten out of whack with the overall project.
I've updated the PREVIEW.zip file so it is a more pleasant experience. The text bugs got worse after a change I made to make the 0 cost appraisal prices go away so they look better for appraiser shops/NPCs that don't charge. I ran into problems with that because of a gettext context bug.
This had never worked properly. But the fix made things worse for untranslated text. But even before the fix such text was appearing with a dot in front of it. I don't know why the dot never appeared for any text using the built-in English translation. It's built-in so it might just sidestep some steps.
There were further problems with item names that are clipped short. Owing to a buffer being reused and so overwritten.
This patch absorbed some recent work around menus. It has an auto-map with Alt+Alt+M and the menus remember their selections. The menus look a little nicer too. There's also a wrap-around feature for item lists, but it only works with the keyboard so it's just a quirk that it's in this patch, but it can be tried out.
(Some of the more extensive menu work I've written about eleswhere is disabled in release builds until it's completed.)
ONE MORE THING is I made the "do_dash" extension enable the dash function at the top of the game. The KING'S FIELD demo doesn't have dashing, but I wanted to enabled it, and also lately a "do_save" was added for enabling the save menu, and I felt that these should be analogous.
EDITED: Quick patch. Something I was working on at the end of yesterday. The appraisal shops put every item on the menu, where prior to this patch my theory was that the items must be in stock. It won't work if they disagree. (I'm going to be adding a filter to this kind of shop. One is needed to keep magics of the menu.)
EDITED: Quick patch. Forgot item must be on the PC :sweatdrop: and to enable up/down wraparound in shop screens.
-
PATCH-PATCH
Yesterday's patches fail to change equipment upon exiting the Equip screens!!! :eek:
(I was in the middle of working on something and had only halfway set up a system for converting item numbers to-and-from a new extension I'm working on that rearranges the order of items in the game. It's a major project... you never really know what will or won't be a major project.)
P.S. I did some work late yesterday that keeps items without descriptive text out of the appraisers shop/NPC menus so that you aren't forced to describe everything (some things are self-explanatory, others are maybe better left unsaid.)
In theory this system can be expanded to do something like KF3's Wisdom Fruit, since the stock of such shops isn't doing anything, and maybe not all NPCs should know about everything/every item.
-
Minor Patch
This patch incorporates equipment into the SELL menu estimates (can't sell equipped items) and handles free (0G) items in the BUY menu, and sold-out items (they're taken off the menu.)
The only danger here is to under count the size of the menu. That will only come about because of free (0G) items. In that case the keyboard extension will wrap around too early. (I probably shouldn't have included the wraparound extension in these patches, but it takes work to exclude things.)
-
:sweatdrop: Patch? (At this rate the next release is going to be the same as the last release. Sorry.)
More menu stuff: Mainly I forgot that SELL items can get sold-out too (by selling all your items) and there's a bad bug I made that's supposed to check an equip slot for an item, for SELL eligibility, but it was using the slot number instead of the item.
THERE ARE GOOD FIXES for classic bugs in this patch. Some odd things like when an item is sold-out either when selling or buying or both the sold-out item's graphic would remain in place of the newly highlighted item's, and when a map is used-up (very unlikely there's such an item) if last in the inventory the highlight would remain where the map item had been--at the end. (All other kinds of items are handled outside of the menu. Probably using a map as a key/event trigger is impossible.)
On top of this, I've now formalized how scrolling works when items are removed from lists, so to be more pleasant than the old way of moving items above the newly selected item down, to having the ones below move up. (I think this is just how people expect lists to scroll. And the original way is just weird.)
-
Last Patch (surely)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip
There's a tripping glitch when walking off half meter ledges at full speed. I don't know how I only just now spotted this. I'm wondering if it is legit or an error I introduced with some of the late clipping work around running on slopes. (EDITED: By "tripping" I mean fall once--briefly--then fall again--for real.)
This patch attempts to address it by softening the threshold for climbing onto a ledge...
The trouble is when coming down off the ledge, technically the ledge is being touched, because the horizontal and vertical clipping radii are actually different sizes. This touch makes the ledge want to be climbed onto even while it's being moved away from (this can be improved later by considering the direction of the touching relative to the heading.)
This logic used to use such a threshold prior to this release. What's funny is it doesn't seem to happen at any other speed. The threshold I chose is pretty arbitrary... just enough to not glitch so to make climbing as sensitive as can be. Trouble is I don't know how it will behave with a different walking speed.
Maybe it's not such a bad fix. I was worried that it would make the new fall recovery function less sensitive. It does I think, but it still works, and it moves more slowly, which is maybe more realistic for falling down and pulling yourself back up.
P.S. As for the menu stuff that found its way into this release via patches, it's all more or less complete. The wraparound works with the controller now. I've completed all of my objectives for the next release, however the reordering function and magics in the inventory are disabled in this patch.
I would just do a demo until I can complete the interactive inventory, except it's been a long time since this latest release, and I want to work on COLLADA-DOM stuff and get something up here before New Years.