Sword of Moonlight > Devs

EXIT: Escape from Sword of Moonlight

(1/7) > >>

Holey Moley:

--- 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.
--- End quote ---

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:

Holey Moley:
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:
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.)

Holey Moley:
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:
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.

Navigation

[0] Message Index

[#] Next page