25 items
File information
Created by
SammiLucia UnderwaterHomie Awaydays and LazorrUploaded by
sammiluciaVirus scan
Some manually verified files
754 comments
-
1
-
2
-
3
- ...
-
30
-
JumpJoin The Ultra Place Discord For the fastest support and releases. See you there!! 😊
My mods will always be free. However if you'd like to support me, please plant a tree, say "thanks" in Posts, or support me on patreon.com/sammilucia 😊
Make sure you read the "How to use" on the Description page!
(For those that downloaded 3.5.1 before this, we've only renamed the file to 5.0 in order to not bring confusion with the older 4.x.x versions. No actual changes for the mod itself)
This mod is fantastic, great experience with it
i will keep this in mind when i come back to JS 😊
did you ever manage to get the map to work properly?
Things I've tried to get the holomaps working again:
* run the clear-shader-caches script in the Solutions folder
* set all settings to LOW and applied the changes > re-opened the menu, reset settings back to EPIC and applied
* used DFU to uninstall the current game ready Nvidia drivers (I'm running a 4090 with 13900k), then tested with both the game ready and studio drivers
* reset the config files using reset-config-files_jedi-survivor.bat in the Solutions folder of the mod
* cleared my system's directx cache
* verified game files
* reinstalled the game
Unfortunately the only way I can get the holomaps working is by removing the mod =(
I've undone all of the below changes except the r.AlsoUseSphereForFrustumCull=1 change, and the maps work properly! I've updated the link to my PAK file below. Anyone can feel free to grab the file and let me know if it fixes the holomap for them. So far I've heard from a few people that it works for them, too!
EDIT 2:
I've been using this fix for several days now and have not noticed any performance penalty after making this change. Now, I'm playing on a high-end system (4090/13900k), so there COULD still be a performance hit related to this change for players with lower-spec systems, but I just figured I'd drop this update to let folks know that - at least for me - this change did literally nothing for me other than fix the holomap, which was my goal!
EDIT 3:
Whether you download my PAK or not, I just wanted to say thank you - again - to sammilucia for their work with this mod in general. Outside of the change I made to disable the "use sphere for Frustum culling" functionality, everything else they did in this mod remains intact, and it has made the game an order of magnitude more playable and enjoyable for me, personally. Sammi, if you see this, please let me know if there's some way I can give back to you (perhaps a way I can make a small donation or something along those lines?)
Either way, thank you again, and HAPPY NEW YEAR, all =)
----------------------------------------------------------------
@sammilucia - I can't believe it, but I managed to fix the issue with the holomap not working properly.
It turns out that
some of yourone of your changes to the engine's occlusion settings were causing all but the nearest map objects to be culled immediately after they load.Below are the values I modified before using your create_Ultra+.bat file to create a new PAK (format is oldValue --> newValue):
This was the offending change in the mod that caused the holomap to stop working properly. It appears that using a sphere - which is invisible and extends outward in all directions from the player's current location for a set distance (though I don't know what that distance is) - to determine which elements should get culled was making it so that only the elements within the sphere were being rendered while everything else was getting culled. I don't know why this only affected the holomap, but here we are ¯\_(ツ)_/¯
r.NumBufferedOcclusionQueries--> r.NumBufferedOcclusionQueries=1r.GFramesNotOcclusionTestedToExpandBBoxes --> r.GFramesNotOcclusionTestedToExpandBBoxes=2r.RespawnDecal.NewCulling --> r.RespawnDecal.NewCulling=1I modified this thinking sections were made visible within the holomap as the user visited them using Respawn's own decal system, and I figured using their new culling system (whatever that is) was necessaryr.RespawnDecal.MaxLayers=2 --> r.RespawnDecal.MaxLayers=4r.RespawnDecal.DebuggableShaders --> COMMENTED OUTI commented this thinking that if the default value for this is 0 (as your own comment on the line seems to imply) then I'd comment the line altogether and see if the default SM6 shaders worked instead. I couldn't tell you if this line had any effect, and since things are working (and performance still seems good) I'm not super motivated to weed out which lines worked, and which didn't, but if I happen to come across any other issues I'll let you know.r.Emitter.FastPoolEnable=0 --> r.Emitter.FastPoolEnable=1I enabled this because it sure seems like this should already be enabled by default given your "why aren't emitters pooled, bro?" comment (lmfao), though in truth I'll likely undo this change as I don't think it had any part in the fix.r.PostProcessing.PropagateAlpha=0 --> r.PostProcessing.PropagateAlpha=1I made this change because after seeing some of the previously viewed sections of the map disappear almost immediately after opening the holomap, I was wondering if perhaps the alpha channel (transparency) of the unlocked map decals in areas where the player character wasn't currently standing may have been getting their opacity modified to 0 (without alpha channel propagation occurring). In truth, I could be understanding this completely incorrectly and am not sure if it had any impact whatsoever.For anyone who'd like to use my personal PAK file (which, for me at least, fixed the holomap issues, though it's currently untested re: whether or not it may cause other performance/visual issues), here's a link to my personal PAK file (based off of Sammi's original work):
https://www.dropbox.com/scl/fi/9di9dfodeedv4snsmu2i2/zzz_UltraPlus-NonStreaming_vTest_MisterHyd3-v2.pak?rlkey=elznkiae61t2bl5823h3oae1j&dl=0
Keep in mind that this is based on the NON-STREAMING version of this mod, so I make no guarantees this will fix anything for anyone using the streaming version of the mod.
The game stutters for me no matter what and I do not understand why this is happening.
*They are like frame time spikes, not constant stutters.
I usually only get stutters on Koboh (and I do get explicit stutters at times, but they manifest more like frametime spikes than stutters, because they don't last long at all, maybe 100-150ms). The worst thing is that with this mod (the non-streaming version), eventually my 4090's VRAM will fill until roughly 22gb is being used, and at that point the stutters start to get worse and I know a crash is coming. It takes a WHILE to get to that point (usually like 2 hours of gametime) so it hasn't happened too many times (as I don't usually play that long in a single sitting), but it has been pretty consistent in my longer play sessions.
That said, I actually tried playing without this mod just to see if its improvements were placebo and I can tell you with 100% certainty that the game is substantially more playable with this mod installed. Is it perfect? Definitely not. Is it a far better experience? In my opinion, absolutely, even with the remaining frametime issues.
BTW as far as I could tell I didn't run into any glaring performance issues that differed from Sammi's release. I did run into some strange texture flickering issues on Coruscant that I had never experienced before but I doubt it's due to this particular mod. Other than that holomap worked like a charm and gameplay smoothened out
I'm personally done with the game now, so I don't really plan to do much (if anything) as far as tweaking this mod any further in future. I never actually even got permission from Sammi to do what I did, truth be told (so hopefully they're not mad at me for the sort of rogue modification of their hard work!)
That said, if anything comes up that feels really critical and you need a hand, DM me here and I'll see what I can do!
I don't believe that's actually a graphical bug to do with this mod.
I could honestly be wrong about that, but that's my understanding.
Apologies for not being more helpful on this!
First, I apologize for taking so long to reply!
Second: When you said "ears" I thought you meant the little "bumps" on the sides of Toa's head. What you referred to as "ears" I thought were her horns. lmao :facepalm:
Idk, I thought her species just had horns growing out of her forehead that they sort of brushed back so they'd hang over the back of their head during their daily lives. I'm clearly a moron, lmfao. Forgive my confusion!
While I have no doubt that removing this mod actually did make it so that Toa's ears drooped as they did before you installed the mod, I'm
surprised that's the case. If my memory serves me (and it's been a few months since I've touched the game or this mod, so I could be misremembering things), this mod didn't actually touch the game's physics (and thus shouldn't have affected the "droop" of Toa's ears at all).
In fact, the only things I remember this mod doing were things like:
* determining which built-in UE engine render tool should be used to render specific elements in a scene
* the number of draw calls to a given tool that could be made within a specific timeframe (or the amount of memory that could be allocated as a
buffer to that tool)
* increasing (or decreasing, I can't remember which) the threshold (in terms of filesize) before the garbage collection routines were called (as they were either being called way too often than they should've been, or not being called often enough - either way, there's a performance cost)
* whether or not specific parameters should be activated or deactivated when determining how the rendering engine should draw elements in the current scene (i.e. the "use sphere for frustum culling" parameter - which Sammi had originally enabled in this mod - which was the thing responsible for the in-game map breaking when you opened it)
I don't actually remember anything in this mod that touched the game's physics in any way whatsoever though.
I'm no expert at any of this, but I'm very surprised to hear that your game's physics were affected by this mod. Clearly I have more to learn!
i've rebuilt this mod from the ground up (v3.0) using what i learnt from Fallen Order. hopefully it performs a lot better, but as usual i will need a lot of feedback to get it right.
i've added you to the Contributors MisterHyd 😊
also i'm a girl people 😊 not that i care, just tryin'a get runs on the board for our team 🤭
Also appreciate being added to the contributors. Thanks so much!
Hope you're well, homie. Much love to you and yours!
A bit late to the party here, but regarding the "ear" problem mentioned by @Axexend in this thread, I think I found the line in WindowsEngine.ini that causes the ears/tentacles on Toa's head to stand out instead of hanging down:
p.RigidBodyNode.EnableSimulation 0
Setting that to 1, or removing the line entirely from WindowsEngine.ini causes the physics to behave correctly and the ears/tentacles to hang down. I'm curious as to why this is disabled in the first place, is it for performance reasons?
Edit: looks like it's not in the latest version
My specs:
I9 14900K
64 GB DDR5 5600 Mhz
RTX 4080S
Game is on gen. 4 NVME
-
1
-
2
-
3
- ...
-
30
-
Jump