simple machines forum
Sword of Moonlight => Devs => Topic started by: Holey Moley on September 09, 2018, 09:30:22 PM
-
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.
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 (http://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.
-
(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.
-
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.
-
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.
-
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.)
-
Multi-feature Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
There's a lot of good in this patch. I will probably forget one or two things, but will try to describe what's in it of the top my head...
1) A new deceleration system is added to do_dash. It just uses two variables for the jogging transition and sprinting/running transition to determine if deceleration is required after the Action button is released. All the deceleration means is it will take longer to slow down than when doing a button tap dash/dodge maneuver. It's just so it doesn't feel like running into a wall when you letting off the Action button. If it takes longer the stop is less jarring.
2) A fix for looking up and down is added in order to keep tiles from disappearing on the side when looking down from high places, or up at very tall structures. It may not be ironclad but is well tested for medium range draw distances. In general I don't recommend long draw distances because there is not an LOD system, and things get ugly and performance degrades when triangles become pixel sized or smaller.
It's never really been a problem before, but the fix is needed both for KF2's lighthouse, and the high cliffs and waterfall.
3) I just now worked on a problem with climbing the lighthouse, wherein a system that was put in place to keep from climbing into things like windows when a wall would prevent the PC body from entering was interfering with climbing the stairs while hugging the walls. I am not 100% certain, but I think that I simply never encountered this problem before because SOM doesn't come with any models that put a wall next to proper stairs. It has only the exterior set's stairs, and they don't really touch walls. (I think the problem would have occurred if those stairs were placed beside the exterior column piece.)
EDITED: To be clear, the wall test applies to climbing with the Action button, but not (or no longer) to normal climbing, onto platforms that are short enough to be automatically walked on top of.
4) SomEx.dll now depth-sorts transparent scenery. The way it was originally done I think was very CPU intensive. It simulated drawing everything, so that the depth was in the final screen space. That's a lot of math. I can't think of a reason that just calculating distances is not just as good. The sorting method somehow produced fighting, so that in the Moratheia demo for instance, a glass jar would shift around (fight) as you walk around it, viewing from different angles. This could just be because the center points used by the sort are not very good. I intend to improve upon them before too long. But in any case, the new sort doesn't change the order when center points are close together. It avoids this catastrophic glitch.
Sorting transparent models/parts of models is not an exact science. This patch also has MDO materials for MSM textures. It's added for KF2's water and even though maybe it could have been accomplished with only "objects" instead of level geometry, I have a feeling the ice cave is fully transparent, and would not be possible without the feature. So it's time has come. I'm still working on the new material system, which includes UV map animation. That is not technically part of MDO that I know of, but it's part of the system, and to be used to animate the water in the starting zone. That is not in this patch. (Edited: transparency works, but I haven't investigated MDO's blending modes, and so this patch is limited to standard alpha blending.)
I'm preparing a KF2 demo that will include builds pretty similar to this patch. I'm trying to polish up the experience so that it's serviceable.
P.S. I also intend to do a little bit with VR before putting the demo out. I mainly want to go back to the old system that seemed good at eliminating drift, but did not look as good. I have to develop a system that decouples the image's location from the sensor data, since it's too chaotic with the better anti-drift settings.
P.P.S. I have a new lead on position tracking for PSVR (https://github.com/HipsterSloth/PSVRTracker) which is good news, although it's an unfinished/experimental code base. It's still surely much better code than I could've developed in short order myself. I'm confident position tracking will come online for KF2 before 2020. But don't expect it in a demo anytime too soon.
-
NEW RELEASE PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
:redface: The new layer feature is broken without this patch :redface:
The MAP file is stored upside down. Somehow this never became an issue for the layer system until I noticed a problem today. Without this patch, the tile heights of the base map that is used to produce the starting points for everything on the layer map are inverted along the vertical dimension.
It wasn't a problem for saving the base MAP because it was read right-side up, and then written (saved) right-side up, and so in that case, two wrongs did make a right :drummer:
-
3RD TIME'S THE CHARM
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
:redface: Last patch saves the base map off by 1 row :redface:
P.S. This patch also includes good PlayStation VR upgrades, and I worked all day yesterday on climbing stairs, and climbing around KF2's pier in various ways (with the water plane acting like a frozen ice rink.)
Going down stairs needs work also. It has to better differentiate between climbing and falling, that is a whole new feature. I'm not going to work on it before uploading the first KF2 demo/backup in the next few days. In the meantime it's necessary to walk down stairs slowly, which means tapping with the keyboard. I have mixed feelings about it, but I reckon that walking down stairs at full speed should go smoothly.... and running should probably also.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
This reinstates the ability to initiate slow-moving climbing with the lower 2 gaits.
It's something I worked on, but (mistakenly) thought it was no longer needed, and so removed it prior to publishing the latest patches. It wasn't needed to walk on stairs, but is if you are not already on the stairs (it works on the stairs because the clip radius shrinks down so it's possible to stand astride the steps.)
(I was also eager to remove it because it was causing a glitch, but I revisited the problem, and realized I'd come up with the same solution, except that in the course I'd eliminated the source of the glitch, not knowing it at the time.)
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
In my free-time yesterday I managed to make climbing deplete the gauges, and looked at a problem with running up stairs wherein the last step at the top of the stairs will slingshot you forward in an unnatural way...
The problem with stairs has to do with the difference between the clipper location and the camera location, where when the resistance provided by the stairs gives way the two catch up again and it just feels wrong.
In the middle of working on the problem I used the opportunity to make running up stairs feel more intentional. The solution to the problem is to momentarily tighten the coupling between the two locations. But I went further, and timed it so the tightening ebbs and flows with the walking animation, in order to create the impression of skipping over steps as would be required to move so speedily on stairs...
In addition I was able to loosen up the coupling on the vertical dimension so that it feels more bouncy. This actually helps to make it seem more smooth. Without it feels too glitchy for one reason or another. I think I slowed running down a little on the stairs too, beyond the natural resistance provided by the wall like parts of their steps.
I'm mainly providing this patch because I intend to use it for the first public sharing of the KF2 project I've been sitting on this month.
P.S. I've decided to not specialize movement in the case of descending down stairs. Instead, I will look at how to make falling down stairs less dramatic! So that it's possible to run down them in some sense. I've decided this because it's been possible to make running up stairs work so well, and so I don't want to compromise on going down them. My main concern, is I don't want the audience to have to think about if a platform constitutes stairs or not. If they want to use the top of stairs as a jumping off point, then it should work just as well as any other surface. As should falling off of a stairs like configuration of polygons. At the end of the day I am committed to SOM treating polygons generically for purpose of interactions.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
I noticed a problem with climbing onto corner pieces. At the same time I worked on making the press to climb more forgiving, which is something I've always meant to find the time to do.
How the change works is if the button is pressed while pushing against a wall it can suppress the action button for opening doors (if there is something to climb on) but otherwise, climbing still works (now) if the button is pressed too soon, but climbing is possible by the time it is released. In that case, the Action button still goes through (can open doors) but will also climb.
Without this change, it's pretty frustrating to climb, because it has to be done very deliberately. I have designs to change the buttons so that doors are opened with the attack buttons, however that's not so far come about, and is an unproven design.
For now, I just want to polish movement as much as can be for a KF2 demo.
On one, if climbing accidentally reveals a secret door, or opening a door accidentally climbs, it's not ideal. But on the other hand, if the goal is to climb, and instead a door is opened, then it could be catastrophic if the door prevented the climb (all bets are off if its opening animation ejects the character, but such is the spice of life.)
EDITED: I believe that menu/text screens still cancel climbing. It's possible to fix, but there are a lot of parts involved. It looks better to cancel than to not.
-
SOM_PRM patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
This patch fixes a crash when doing a search from an item slot that is after the last filled slot, which can also happen when doing Ctrl+C for copy, since that was trying to do a search. (For ASCII control code 3, that is ^C I think.)
I also noticed the Cut button throwing up a bogus message that just says the name of the item being cut... I have no idea what this is about, or if it's always been there. I tried to hide the box, since it would be a lot of work to definitively find the code that creates it and remove it that way. Possibly other boxes can be disabled. Hopefully not.
Lastly, I noticed that closing from the taskbar did not bring up the Save? prompt. That is likely a problem for SOM_SYS also.
-
Minor feature patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
This patch keeps MapComp (objects) and SOM_DB (NPCs) from crashing on instances that don't have entries in the OBJ.PRM and NPC.PRM tables.
I thought that this was unnecessary, but it turns out that these types are a problem. In general this is an area of interest that can use some attention. Originally SOM_MAP just deleted these kinds of instances from MAP files without much recourse.
-
Oops! :redface:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
The last patch got objects wrong... seemed to work, sorry. This patch works with the DualShock4 without any third-party service. Still feels funny though... I am warming up to a release built around controller calibration in order to better support a range of controllers.
EDITED: The next patch improves the controller support by defaulting to its circular shape, instead of trying to reshape from a square to a circle as is done now by default. This makes it technically better than using DS4Windows for basic functionality for the time being.
-
DualShock4 patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
This patch disables the new feature that morphs square joystick inputs into a circle shape for the DS4 (not using DS4Windows) since it's shape is known to be a circle! This solves the problem with moving at full speed along the diagonals...
Support for the controller found its way into yesterday's patch by accident, since I'd been working on it earlier in the day. It didn't occur to me to solve the problem in this case, by simply exempting it now that it is detected/given special treatment.
The DS4 and Xbox (XInput) controllers don't use the mapping from the Control Panel, since they are mapped internally to more conventional layouts, in order to be easier to configure, since SOM's control settings are not on a per controller/product basis. Like the X and O buttons need to be remapped to the first 2 buttons, because that's what SOM uses for confirmation/cancel dialogs. I don't know why Sony chose to not make them the first two buttons for this purpose to begin with. Sony mapped Start to the Share button, and Select to the Options button, which seems weird, since they are on opposite sides. The triggers have to be mapped to buttons to be usable. SOM doesn't envision triggers as buttons. Leftover buttons have to be moved to make room for these virtual buttons.
P.S. I think SOM uses the first button for cancel, but in any case, I think I'm biased to preferring the Japanese convention for cancel/confirm, and maybe there should be an extension to flip these. No one has requested it. But I set up the mappings to use this convention.
-
ObjEdit patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
A bug in Windows's CheckRadioButton API makes some of ObjEdit's boxes not get checked off on when opened in maximized picture mode as SOM_PRM does.
(It unchecks "buttons" that aren't actually radio buttons.)
-
Critical SOM_MAP patch :king:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
Turns out SOM_MAP's Save function has been broken since the beginning of this release. I didn't notice it because only the "Release" mode "build" was affected.
What happened is I transcribed an 8B to B8 and a 89 to B9. Something about 8 and B looking pretty close. The cardinal sin is that I neglected to test the code, made worse by the fact that I kept using the old code I dictated from in the "Debug" mode "build" which I tend to favor because I'm always doing work on SOM.
FWIW this has to do with the last minute work I did to use objects' first field in the MAP files to denote the layer that they belong to. For some reason the code was using the field to record the objects' type. But none of the programs actually used this type information, and the way the type information goes into the field makes it hard to tell if it wasn't just an accident that it ended up there, or if it was at one point used to do something. I have noticed lately that if the profiles change or are reassigned that the MAP files must be saved, or else MapComp will not succeed.
-
For the record Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
I'd been messing around with the defaults for the bob effect, not liking the feel of late. Some of the changes I made found their way into the patch yesterday. I didn't have enough time to evaluate the changes.
So I went in and tried to scale things back, because they felt a little weird. What I ended up with is just instead of doubling the effect (by default) according to the dash speed (ramping up with acceleration) is go from 0.3 to 1 instead of 0.5 to 1. If that makes sense. IOW the effect is lessened when walking/now more than doubled when dashing.
In addition, I noticed that because as the gauge drains the running speed is lessened (unless you hold down both both attack buttons, kind of like pumping your arms) that the stepping frequency was not maxing out, so I boosted it artificially, as if the endurance speed change is not in effect. This is fine because running speed is more a function of power than stepping frequency, and if anything the step rate doesn't acknowledge this, and feels like you should be moving faster... but I don't know how much of that is because of field-of-view effects.
I momentarily played with longer steps also, since walking felt too fast to me, but I worry that's because I've long legs, and scaled back to 1 because it's a round number. I kind of like that full speed feels unnatural so that middle speed feels natural.
Again, I don't know how much of this is field of view. I'm more and more thinking that these effects should be in terms of FOV, even though it's not realistic to do that. Especially for the rotation effects, I feel like it really should be a fraction of the FOV instead of an absolute angle. FOV is just a limitation of what displays can fit on the screen, and how it feels I think is more important than a mathematically correct simulation of a camera.
Part of the problem is it's impossible to choose ideal settings since they are different depending on the FOV setting. You just have to split the difference. I know this will have to change sooner or later. I just don't know if it will be limited to rotation effects, or if it will extend to movement effects and speed. It can't change the actual speed, but it can play with cues that we use to judge our speed.
-
ItemEdit/ObjEdit patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
This fixes 2 problems: 1) Setting the menu/drop pose for items had been failing to refresh the picture of the 3D model. 2) ItemEdit's Save function would be disabled if not in the 3D model mode...
I believe (2) is oddly, because the button number I chose for the new 3D model mode (1000) may have just happened to have been a Save Lock feature that enabled/disabled the Save function. If so, this Lock button must have been removed prior to publication. Without it it seems to require the Save-As function to be used exclusively.
After I learned about this, it became more difficult to control the enabling of the Save function. Note, the reason to do so is if you make a New profile from scratch, it doesn't have a file to save to. Maybe there will be a policy for protecting public profiles in the future, but there isn't now, nor any time soon.
Compounding the problem is Ctrl+S doesn't work when the menu is disabled. Windows must perform this check automatically. So, I had worked on a number of profiles, using Ctrl+S only to find that they had not saved. (This was because I was editing drop poses, and so was in that mode instead.)
-
IMPORTANT PATCH + CLASSIC BUG FIX
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
1) I discovered an original (From Software) bug where projectiles (e.g. fireball) hit cylindrical type objects, wherein the object's radius and height are swapped. I think there are larger problems with this interaction, that seem to cause the impact point (point of explosion) to be funny and also, cylinders that are wider than they are all tall seem to behave strangely, so I plan to investigate this further.
I ran into the problem making new objects like KF2's Magician's Lamp, which would not interact at all with a fireball (not good since part of the games has you shooting them with fireballs) and generally could not get any cylinders to interact! I wonder if the reason that so many cylinder objects from the KF sample project are shorter than their models... I thought this was just laziness, but if wide cylinders have problems, and originally the height/width were swapped, then making them square might have been a harebrained way to deal with the problem. If so, the art team and programming team must not have been talking to one another.
2) Projectile interaction with layers was disabled by another "Debug build" check.
3) Reading the MAP files can still fail because one of the checks I added a while back to prevent peeking (looking ahead in the file buffer) was written wrong (like *rd-- instead of --*rd) so that it fails to remove the carriage-return.
Funny I've worked with SOM all this time not noticing the cylinder problem... I really have a feeling the funky cylinders are an artist hack to workaround the problem.
-
EDIT
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
I thought to get rid of the funky impact points it would help to set the vertical coordinate back to the projectile's position, but ultimately I simply copied over the original position, since it seems pretty harmless and eliminates some horizontal funkiness. I mean, generally the projectiles explode on impact, so I don't see any reason to reflect them off of the target. They shouldn't be going so fast as to penetrate too deeply...
And even if they do, I tried offsetting the impact point along the PC's view vector (the "camera") to try to make the ugly sheering go away.
This worked so well, I bit the bullet and tracked down all of the subroutines/calls for boxes, NPCs, MHM geometry, etc. so that fireballs look good exploding off every kind of thing.
I don't know if this is a good fit for every SFX but it seems to me like it should not be too bad. I will address problems as they arise.
EDITED: I was worried about the Moonlight Sword's 3 stage sword magic. And similar effects. I put a limit on the offset, since it's just meant to get the explosion away from the walls, etc. But did not update the download. Since the second splash explosion is at its center. I didn't want it to be too far away. However, the additional explosions, would have been a larger problem, since their locations are not based on the center of the splash. The splash is subject to the offset, although considerably smaller since it's limited. However, it doesn't seem like the hit site is used for this effect, so it seems to be fine. Instead of using the hit site, just the center of the NPC is used (feet level) for the stage 3 explosions.
The initial fireball has a 0.75 radius, and the limit I set was to 0.5, based on the small fireball's radius. So the difference is not enough to warrant a patch. The splash had a 4.5 radius. But it doesn't seem to matter.
EDITED: For the record, I wrote a replacement for the cylinder/sphere clipping procedure from scratch (it's very simple) in order to make fat (more disc shaped) cylinders work. It's hard to imagine why they don't. The subroutines seem overly complex for what they accomplish, and don't seem to be used elsewhere. It suggests that they are part of general purpose "library" code. The fix will be in the next patch/demo/release. I've also made the fireball's clipping radius smaller so that it doesn't explode so easily when grazing things. It's still no smaller than the 3D model I think. It's probably time to start correcting the clip shapes of SOM's built-in components. Before long I'm going to begin extending clipping to MHM like polygons. Speaking of which, there's definitely something wrong with MHM clipping, since the fireball often goes through walls. It may help to simplify the clip models, or may not.
-
Hell yeah!
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
FINALLY FOUND A WORKAROUND for the most obnoxious Windows bug in the world!
This patch is to fix the problem with exiting F11 mode (fullscreen) wherein a few years ago Windows 10 (8 too I think) started making the title bar part of the window disabled, so that it cannot be clicked, and disables the window when clicked!
I've tried and tried to find a fix for this problem, and also to bring it to Microsoft's attention.... unfortunately they have an army of employees that ensure that bugs are never fixed... that's literally their job from what I can tell. (The only time I've had success fixing Windows bugs is when I can find the blogs of the employees who are responsible for the module and contact them directly.)
The brilliant fix I came up with, was to try to make it so the window doesn't look like a fullscreen window, and so to avoid the idiotic bug altogether.
The only fix to get the window to work normally is to minimize it and restore it via the task manager menu. That's been something I've had to deal with for years ever since. There was also a graphical glitch in the top-left corner when this bug was in effect. But that went away about a year or so ago.
I'm convinced the bug is due to bad programmers hacking the window manager to try to give special affordances to fullscreen windows. They think they solved the problem, but something about SOM is broken by the feature.
Good news is that what I did is put a frame around the window, which is not even visible, at least not on Windows 10. I think maybe it's on the outside of the screen, off screen. So it looks no different.
Bad news is, maybe there is a performance loss, but F11 is not for performance, so I could care less.
-
EDITED: I'm putting up another patch because I think I may have left something that might be messed up in it, to do with better handling the mouse takeover behavior when multitasking with outside windows. I think it was made to put the mouse in an Alt/F10 mode, which was not really correct, since it floats the mouse and requires 2 clicks to begin interacting.
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
P.S. I got carried away tonight working on a custom menu for my King's Field II project. Consequently it's part of this patch, though by accidental (http://www.swordofmoonlight.net/bbs2/index.php?topic=286.15)
EDITED: I had a change of heart and moved the description of this image to my KF2 "devlog" thread.
(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=958;image)
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
The up/down arrows I modified yesterday have a problem because of the VR feature that changes the size of the menu area. It doesn't just do this in F2 mode.
Also, yesterday it seems like my hard drive or something related to it has began to occasionally take long pauses. Every now and then it would take a long time to start a game test session, from running it to the window appearing. I thought it was just this hard drive thing, and once SOM_MAP took forever to load the files at the start. But after a while, I began to look into the program to see where it was when it was stuck, and it consistently came up to some code I added to detect XInput controllers...
So it turns out the code can be very unfriendly for real-time applications. Probably it's acting up because of the strange behavior I'm experiencing, but my impression is that it can take a long time even under normal circumstances, and so it's very possible it can be a large part of delay before the window appears. So I've done some work to mitigate this likelihood, by moving the routine to the secondary "thread," that does time keeping, and mouse tracking, pausing, etc. And it doesn't begin until SOM starts polling for input, which should be after the window appears.
The problem is described by this (https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/improving-enumeration-performance) document, and I don't know why this is the recommended way to determine that a DirectInput controller is an XInput controller. I'm going to look into it some more. I've made some of the changes that are recommended, but it still takes more than a quarter second sometimes. And there appears to be a possibility that it can fail to work, or give up after taking too long.
-
EDITED:
I've reuploaded a patch because the game window is getting stuck in a state where it cannot be clicked on! I think it is a bug in Windows, but related to the change I made to try to make the mouse pointer behave better when switching between other windows and the taskbar. I haven't got stuck since.
I've changed it to a different behavior, and am hoping for the best. (My disk or disk-controller seems to be malfunctioning, so it's really hard to tell what isn't a side effect of that. I don't know what I'm going to do. I should probably start looking at a new workstation, instead of trying to replace the drive just to find out that it's the motherboard acting up.)
P.S. I've added Shift support to the Esc and F3 functions. I could say more on the subject, but it's probably not worth anyone's time. EDITED: So it turns out I had a lot more to say (http://www.swordofmoonlight.net/bbs2/index.php?topic=290.0) on the subject, but just didn't realize it.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
I discovered the MP3 pathway I implemented has been converting regular WAV files, redundantly. I know I remember checking this code, but I basically had botched the code that determines if a WAV file is compatible with SOM or not. I probably only checked it for the converse.
(Edited: I think possibly this has been exacerbating the trouble I've been having with my disk/disk-controller/something. If so it chokes up when simultaneously reading/writing to the disk. This procedure seems to be especially prone to choking: https://docs.microsoft.com/en-us/windows/desktop/xinput/xinput-and-directinput)
P.S. I've enabled transparent text, which was actually super simple. I thought the the SetTextColor API would surely discard the "alpha" component, but it doesn't...
I've done this because I'm using it with KF2 to make text appear smoother when using the do_stipple extension. I prefer to use it with dithering, in high color, but I found that it is so noticeable on the text that it was making me to prefer the true color mode (which admittedly looks quite good itself nowadays running at a steady 60fps.) With transparent text the edge is less crisp, and so it looks smoother under do_stipple.
On my previous monitor I cannot see do_stipple, but my latest monitor is slightly larger. And individual pixels are visible. I think probably monitors shouldn't be so large, that you can see pixels, but I didn't now this when I placed the order. It's not generally a problem. (Except funny story, the Samsung monitor kind of malfunctions with dithering turned on, depending on its Gamma Mode. I can't fathom why. I thought it was limited to Mode 2, since there is a place you can stand in Moratheia's demo that causes it to malfunction. You can take a screenshot, and look at the picture normally, and it still malfunctions... that was an interesting day. Well, it turns out Mode 1 malfunctions when sweeping over KF2's water. And so I put it into Mode 2 again... which I actually prefer, since it's a darker gamma setting.)
-
EDITED: I've reuploaded a fix for the Pause+S or Pause+Select screenshot feature, which had stopped working with the addition of D3DSWAPEFFECT_FLIPEX mode. It can be useful feature, but I mainly wanted to not have anything broken.
In the FLIPEX mode you can't get a picture from the window. Last night I tried many Direct3D ways to, and they all failed. I realized the way to do it was to use the desktop, and just clip the window out of the desktop, which is the same thing, no better no worse... just a counterintuitive approach.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
I found a much less stinky way to detect the XInput controllers. Some accounts online suggest the documentation's way can take up to a minute. I don't understand where Microsoft is going with some of its COM based APIs, but this is useless, and certainly cannot be used at start up.
http://lists.libsdl.org/pipermail/commits-libsdl.org/2013-August/007312.html
http://hg.libsdl.org/SDL/file/8cc29a668223/src/joystick/windows/SDL_dxjoystick.c
I think I began to have problems with this because my computer may be dying, which is not good if it up and dies while I'm working on a KF2 project and lose a day or so of work. I actually think I may have indirectly hurt it by accidentally hitting a shutdown button while some files were transferring to an external drive... but it would be really stupid if that job did not keep the system from shutting down. I just don't know if a shortcut to a direct shutdown command goes through the same kinds of checks. Anyway, the problem began the next morning after having shut it down. It could be a cosmic blessing to get this egregious code out of the start up sequence.
I thought maybe my SSD disk is working in a bad section, and so I copied my KF2 project, and deleted the old files. It's only been an evening since I did that, but before I did it SOM_PRM couldn't switch tabs without getting stuck for a minute (which prompted me to try this) and after, so far so good.
P.S. This "build" has a new feature where the Attack/Magic buttons don't fire until they are released. It's actually better than before, because it removes 150ms delay, if you can just press faster than that. It's now easier to press all three buttons to run fast without accidentally lashing out. It opens up using the Shift key as a modifier, without dorky side effects. The Menu button will also work this way at some stage, but doesn't just yet.
-
Patch Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.8.zip
This patch fixes depth buffer issue for items in a menu with a picture background, instead of transparent effect, caused by the new transparent frame feature.
It also uses the linear filter for 2D elements, with the point filter option. I can't think of a single reason to use a point filter for these things. There's no reason wanting the point filter option ought to degrade the menu system.