Sword of Moonlight > Devs

EXIT: Layer feature unearthed, now restored

(1/6) > >>

Holey Moley:

--- Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2018/09/layer-feature-unearthed-now-restored ---I feel like there should be a lot to say about this, but I am perhaps too exhausted to say it. So, in brief, some months ago (I can’t recall how many) I began to notice some mysterious code within Sword of Moonlight, that I thought must indicate something was removed, to do with playing more than one level at a time. I thought it could be “layers” or a corridor between levels, or both of these things. I looked into it once or twice since. I even felt it may have been a load balancing system.

A month or so ago a person appeared who was working on figuring out the contents of King’s Field II’s disc for the PlayStation. Speaking with them got me to take a look myself, since it’s something I’ve been meaning to do. I wasn’t much help, but I did notice that there is two layers on each of the game’s zones. The other layer is interleaved with the first. I realized that’s the only place it could be, going by the size of the files that remained. That was a few weeks ago or more. Ever since then, I began work on making a layer system available to Sword of Moonlight, starting with its strange code from before.

I didn’t stop at getting the extra layer working, since layers is actually a big deal for Sword of Moonlight! I stopped everything to complete work on it. It also gave me a chance to investigate the MPX file format containing level definitions, and the MapComp program that produces its file format. I had pictured myself doing this at the beginning of the year, in fact, but couldn’t help from getting sidetracked. And so, I was glad to have gotten the year back on track, right on schedule.

By now I know everything there is to know about that code from before. I kept coming across it in different forms time and again. I think I’ve seen every trace of it by now. It was a layer system more or less identical to the newly developed feature. In fact, I used what bits and pieces of it I could, in order to not waste it, and to be able to say that it is a part of Sword of Moonlight having origins in its earlier days with From Software.
--- End quote ---

EDITED: This release's devlog: http://www.swordofmoonlight.net/bbs2/index.php?topic=67.0

Please SVN Update and follow the updater. While there go into the language settings and update your TOOL language package. Alternatively the files directly involved are listed below.

http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip

Language packages
English (TOOL)
http://www.swordofmoonlight.net/text/English/Neutral.zip
Japanese (TOOL)
www.swordofmoonlight.net/text/日本語/最新.zip

To add layers, go into the Map menu, and select two maps. Doing so enables the Compose toggle/button. The map with the lower number is the base map. Only the base map has EVT and MPX files. It is the level. Its layers are subordinate. To add more layers, up to 6, clicking/toggling the Compose button for each.

After this process the layers will become shortcuts to the base map, which will open to the chosen layer. Where the map title is shown on the main screen is now a layer switching menu.

A layer gives you more freedom to flex your creativity as an artist. They let you put tiles on top of tiles (or even right on top of each other--inside one another.) Layers are not above or below each other. That would be too restrictive, and pointless. They can intersect at any point, and are just useful for having more combinations of tiles.

The map's starting point (for testing purposes) is assigned to a layer when right-clicked, and likewise everything on the map lives on a layer. This notion of belonging to a layer is lost on the MapComp program, and unlike the original system is not passed to the player via the MPX files...

All that it is for is so when tiles are moved up and down, if things live on the same layer* as the tiles, then they will move up and down with those tiles.

*Technically layers can belong to a group, which I've called a z-index. If you make your layers out of order, the current system shows the raw z-index in the sliders that change what layer(s) that things belong to...

This z-index system isn't going anywhere, but I've thought about sorting the z-index values according to the layer order, to make them more intuitive. However, really, changing what layers things live on is something that is not normally required.

There is a new LYT file format added to the MAP folder. LYT stands for "layer table" and I took the name from the LVT (level table) file format. Likewise, there is an MPY file format that complements the MPX format. And MPY file is so far identical to many MPX files stored back-to-back in the file, but without things that are stored in the MPX file, like the vertex buffer, and MHM files, and all of the level's NPCs, etc.

SOM_MAP makes LYT files, or you can make them by hand. MapComp makes MPY files. Once you add layers to your MAP file it will not work with MapComp without SomEx.dll. This is because it tries to incorporate the layers, but it crashes because the memory the code wants to use for layers has been removed from the EXE, i.e. MapComp.exe.

SOM_MAP's "objects" are the only thing that used the layer field for a different purpose. I was able to determine at the very end that it was definitely intended to be used as a layer field, but for some reason the field had been changed so that when the MAP file is saved, the object-type from the PR2 (PRF) file ended up in that field instead. Because it only writes the field, it means that SOM_MAP doesn't use this field this way. And neither does MapComp use it. So, I determined it best to restored the field to the layer use-case...

As a side-effect of this, in order to work with older MAP files, it is necessary to tell if the files are using the newer layer facility or not. Because of this, the maximum z-index in this scheme needed to be 9. So this set a ceiling on what the limits of the layer system would initially be. Likewise, the player (oddly enough) has room for 6 layers (7 including the base layer) in the memory ahead of where the original layers would have been (where the base layer currently is) and so the new system just uses negative numbers to refer to the layers. This is a pretty weird turn of events. It's hard to imagine why there is so much vacant memory in the data structure (it's not global memory) but there is, and it sets a limit to 6.

As a result, I've decided to limit the layers to 6, and reserve 1 extra z-index for things that you want to not live on any tile (so no tiles/layers can ever move them up or down.) You should use 7 for this purpose, but technically you can place anything on any z-index at any time. New layers take the next available z-index. 0 belongs to the base map. A hand edited LYT file can group layers, but it's not recommended, and is more a provision for later, if the ability to use MAP files other than 00.map through 63.map is facilitated--either for base maps or layers only.

What SOM_MAP currently facilitates is called the "basic layer system" that just uses the simplest workflow possible. If your base map cannot be the lowest numbered MAP file, then it must be renamed in the MAP folder, and any events that connect to it must be reassigned by hand to its new MAP number.

The LYT file can be hand edited to customize the layer menu. The Compose button inserts maps into the LYT file according to their MAP file numbers however. The only part of the layers that is used is the top half of the MAP file. If you make a MAP a layer, the bottom half of its file appears to be missing, but it is retained, and will reappear if made back into a standalone map.

When you work on a layer, you are really working on two MAP files, and so will save both. What you see is a composite of the layer, and the base map. The only thing you can change about the layer is its title. And its tiles of course. Everything else is as if you are working on the base map.

Holey Moley:

(DualShock 4 experience & Last minute control changes info)

EDITED: Earlier today I took out a DualShock4 controller I ordered 2 or 3wks ago. It was not a fun experience. It turns out that the shape of its output is a perfect circle, more-or-less. This differs dramatically from the DualShock3's (or technically what I use is a SIXAXIS) almost perfectly square shape!

It's criminal that controllers can output such different shapes... under DirectInput no less. I have no memory of a controller with a circular shape. I don't know if that is common now or what. The DualShock2's was square also.

The controller code I've developed in the last month or two, somewhat in response to VR that now largely hinges on making the square fit into a circle, when applied to a circle, produces a somewhat smaller circle. As result, the DualShock4 was not hitting the 1/sqrt(2) requirement for moving diagonally at full speed ahead.

Since, I'm far from having a friendly UI for controller customization, I'm trying to just be able to accommodate all controllers... but I think that something must be done in the following months. Since the files I uploaded late yesterday, but before this advertisement, I've update the files, to lessen the mapping from a square to a circle, somewhat because the squares were not quite squares. (Edited: technically it's not even correct, since while not square, the points were still in terms of a square. But it's just a compromise for the time being.)

But I do not believe that this is enough to bridge the gap between the two extremely different controller shapes.

I was surprised that Sony has included DirectInput drivers with the DS4! But I opted to not use them... yet, because I will have to add a new mode to the Ex.ini templates to match them, since they don't use the standard mappings. And the L2 and R2 triggers range from -1 to 1 basically, which is kind of strange, and when they get assigned to turning or moving functions, they just take off hard in the negative direction!

So I tried this software called DS4Windows which I've lately had to rely on just to get my SIXAXIS to work (it shares a component with the SIXAXIS solution I've used for a while now, that expired a few weeks back.) It has settings for customizing, much what I'd like SOM to facilitate. To get the DS4 to play nice I had to set "anti-deadzones" to 0.1 since the DS4's deadzone is much smaller than the DS3's, and its "sensitivity" settings which seems to scale up, I've set to 1.05 so that it is slightly more square like as necessary.

So, unfortunately, this means that the analog controls are still unsuited to a lot of controllers, and it's just going to be a PITA to make things work well. With controllers this disorganized I wonder if PC games stick to their keyboard/mouse guns just to avoid officially supporting controllers.

Unfortunately DS4Windows seems unstable. (Edited: the default BT Poll Rate setting seems to be a culprit here, at least with BT.) But I'm glad I had a chance to test the DS4 with SOM. Running DS4Windows makes it impossible to use my SIXAXIS until my workstation is restarted, so I much choose which to use day by day.

LAST BUT NOT LEAST I was very unsatisfied with how tightly wound the DS4 is. It's impossible to trace anything remotely resembling a circle. I hope it just needs breaking in. I can't understand how FPS people (who apparently dictate controller design now) prefer it over the SIXAXIS. Which I'm still preferring... because cinematic camera control is my preference.


EDITED: I also noticed the "half-gait" system was not ratcheting properly. It is a pseudo gait used to add half diagonals to the first gait. Hopefully it's better now.


EDITED: I don't understand the DS4's analog stick's grip redesign. It just puts a lot open air under my thumb, and so makes it readily loose contact. Don't see how it helps at all, unless it's something to do with sweaty gamers.

Holey Moley:
Running sideways patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip

This patch addresses issues with the recent change from square joystick coordinates to circle shape with regard to speed/movement transitions in the lateral direction when dashing.

Note: these changes are managed by the do_dash extension. But disabling that extension is unpleasant because it also limits turning speeds when dashing so that higher/user-friendly turning speeds aren't unwieldy.

Holey Moley:
Stair climbing patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip

I'm working on KF2 right now. Its setting has many stairs, that are similar to the exterior set's stairs. It's not fun on the stairs. So it is a good opportunity to improve walking on them, which is quite tricky with analog controls that more or less simulate a pair of feet.

This patch goes a long way toward a good experience. It's not bad, but it's just the beginning, and is more or less a bunch of cheats. It started with wanting to be able to move on the stairs at slow speeds. In the present state, the first 2 gaits were denied access to the stairs. So I had to change things so that slow movement could overcome the wall parts of the stairs...

The fight that the stairs provide is kind of cool. So I wanted to keep it when moving at standard speeds, but change the dynamic at slower speeds. The intention is to provide the impression of slowing down to negotiate the stairs, but not to deny access. And slow movements are very cinematic, and so very desirable.

After it was possible to move up and down the stairs slowly, many more problems became apparent, and so have been addressed one by one. Some of the problems include falling off the step before slowly moving to a safe place to stand, and a sense of moving to fast upward, or bouncing too much when going down (which right now is no different from falling down, aside from slight differences in the bounce effect.)

To lessen the interference on KF2's stairs the error_parachute Analog extension is reinstated with a nonzero default value. I haven't noticed any problems because of this, but it seems like it helps to ensure smooth landings when jumping around. I could never put my finger on why, but every now and then a jump will land unpleasantly for a little while, and I think it was because I'd disabled this extension (or set it to 0) and so I hope I didn't disable it for specific reason!


KF2's lighthouse's stairs are especially too steep. They are too narrow to stand on. I think I will have to play around with the MHM models eventually. They are 1/4m tall, but also 1/4m deep, which is not enough space to move on. Fortunately other stairs tend to have more room to stand, as does SOM's exterior set's.


EDITED: There's also a fix for a problem with right-dragging SOM_MAP that seemed to start a few days ago. I'm afraid it's a temporary Windows Update thing. I simplified the way dragging works, which seemed to make the problem mostly go away, and is conservative enough that I don't think it will be a problem for different versions of Windows. My mouse may just be funny, but I can't see the cursor visibly twitching.

Holey Moley:
Patch-patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip

Uh, last night's patch had a change I added yesterday that I don't think I mentioned, that was designed to have more of the "bob" effect when walking very slowly, so that it doesn't feel like gliding like a ghost or a robot on wheels...

I thought it was continuous when stopping (approaching zero) but I noticed today that it was too dramatic when coming to a rest. And so this patch scales back that effect considerably in order to smoothly (hopefully) bring movement to a close...

You can think of it as changing how you move your legs in order to go more slowly/deliberately. The current "bob" defaults are practically imperceptible when walking, and doubly so when moving slowly. I kept watering it down, finding it to be an annoyance. And it's more noticeable in VR, so the current baseline is more based on what VR will be like than otherwise. I don't know if I reduced it further for VR's sake or not. But it's definitely easier to notice.

Even though it's hard to see, I have a feeling that the visual system still detects the motion, and will notice it's absence as "robotic" movement.

(EDITED: I did look for issues yesterday. It's possible I have them now, or can see them, because the computer is in balanced-performance mode. So Windows won't go nuts and rev up the fan.... more to keep background tasks from going wild than SOM. But it does limit game performance also.)

Navigation

[0] Message Index

[#] Next page