Topic: EXIT: Escape from Sword of Moonlight (Read 12626 times)

Holey Moley · « **on:** September 29, 2017, 09:10:20 PM »

Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2017/09/escape-from-sword-of-moonlight/

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

The world (the people in) (their behavior patterns in aggregate) boggle my mind ~~sometimes~~all the time. I'm sure the creator(s) trying to make a point. I just can't understand it

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.

Holey Moley · « **Reply #1 on:** September 30, 2017, 01:43:18 PM »

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.

Holey Moley · « **Reply #2 on:** September 30, 2017, 04:26:55 PM »

EDITED: I bungled that patch

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

Holey Moley · « **Reply #3 on:** September 30, 2017, 06:44:52 PM »

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.

Holey Moley · « **Reply #4 on:** October 01, 2017, 07:47:32 PM »

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.

Holey Moley · « **Reply #5 on:** October 02, 2017, 08:58:13 AM »

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.

Holey Moley · « **Reply #6 on:** October 02, 2017, 11:16:42 AM »

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.

Holey Moley · « **Reply #7 on:** October 02, 2017, 06:58:14 PM »

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.

Holey Moley · « **Reply #8 on:** October 03, 2017, 09:16:07 PM »

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.

Holey Moley · « **Reply #9 on:** October 05, 2017, 02:11:22 AM »

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

EDITED: I should probably start (tomorrow) by see what some older releases look like....

Holey Moley · « **Reply #10 on:** October 05, 2017, 02:23:18 PM »

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

Holey Moley · « **Reply #11 on:** October 07, 2017, 01:12:59 PM »

Not-a-patch

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.

Holey Moley · « **Reply #12 on:** October 08, 2017, 02:05:00 PM »

Patch!

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

Holey Moley · « **Reply #13 on:** October 12, 2017, 01:28:35 AM »

I can't Escape from Sword of Moonlight

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

Quote from: new demo information

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

Holey Moley · « **Reply #14 on:** October 12, 2017, 04:36:38 AM »

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

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

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Escape from Sword of Moonlight

Author Topic: EXIT: Escape from Sword of Moonlight (Read 12626 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Escape from Sword of Moonlight

Author Topic: EXIT: Escape from Sword of Moonlight (Read 12626 times)

Sword of Moonlight|

Devs|

EXIT: Escape from Sword of Moonlight