Sword of Moonlight > Devs
EXIT: Layer feature unearthed, now restored
Holey Moley:
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.
Holey Moley:
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:
Holey Moley:
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.
Holey Moley:
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.)
Holey Moley:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version