#LFO - Lux's Flames and Ornaments
1 messages · Page 2 of 1
AND WE'VE GOT PLUMES
finally
now I only need to test this with a new engine
just any engine that has the new components
I'll try to get one such working in SPARK, since I have the source for that project
for fuck's sake
is there literally not a single engine mod with public source that has LFO plumes on the prefabs
the only mod whose source I can get my hands on is SPARK
and the version on GitHub doesn't have any components on the Plume objects


You havent already?
I do have people asleep in the house
I think they wouldn't appreciate it
but istg if I were alone, I definitely would have
ok I actually now have a plume in Unity but no clue what all I need to add/do or how to export it
I added the master group component but that doesn't want anything to do with the volume component
it only interacts with the throttle group one
and that one wants a mesh
but I don't want mesh rendering, I want volumetric
how does this all work
😭
and why is there 0 documentation
ahhHHHhhh
excuse me what the actual fuck
WHY DOES IT NEED TO COMPILE THE SCRIPTS IN RUNTIME MODE FOR ADDRESSABLES TO BUILD?????!!!!!
this can't be real right
will I seriously have to change all these conditional compilation blocks to use reflection??
aaand not even that anymore, now the shader is completely fucked without me ever touching it
I am so done with this
been trying to simply test if plumes work now, for an hour and a half
it's 5am and I am dying
and right now I never want to see Unity, LFO or SPARK ever again in my life
well, 4 and a half hours of sleep and it's time to get back on the grind
(my dog woke me up and won't let me sleep anymore 😴 )
damned ... make it coding 🙂
That's normal and to be expected. The guidance I've folloed from Lux is to make a bare Plume object and LFO will create the things needed below that. The only place you would find the details are in a PRefab Varient where the plume is modeled.
huh, thanks for letting me know
My understanding is that LFO needs (needed?) the bare Plume object.
then I have absolutely no clue where that is supposed to happen in the code
because in the game it kept trying to add a LFOThrottleData component when such a class didn't exist anymore (moved to LFO.Shared.Components.LFOThrottleData)
and I have been through every file in the codebase like 50 times yesterday
and have no clue how that would happen
oh wait maybe I should read first
you did say that there's a plume prefab
so I'm assuming that also has to be exported with the addressables?
No, I'm sorry I wasn't clear. Here's what you do.
Or what is/was normal previously
Take a prefab of your engine and make a prefab variant. It's important to not do this to the prefab you're going to export.
The prefab should have a bare Plume object under thrustTransform
So the variant will have one too
On the variant, add a TDMG to the Plume
Wait then why the fuck did the namespace change break things
mte
I'd open my Spark Project and give you some screen shots, but it's still restoring. about 2:30 left
The object under the Plume is where there is a Cube (for volumetric (Profiled)) or a Flames or whatever
You need to also add a LFO Throttle Data and an LFO Volume component to that object.
You tweak the settings in the LFO Volume to get the plume as you like
And in the LFO Throttle Data I beleive that's where the Float Params go
yeah I got all those settings the way I wanted them before, but on the actual prefab, not a variant
When you have it looking good, you go back to TDMG, make sure you've done a Collect Children, and then export the config
I'm assuming I just drop one of the LFO prefabs in there for that and unpack that?
I really don't know why it's done this way (obviously), I only know that Lux as very clear it needed to be done this way (for LFO to work as it was previously engineered)
Not if you're doing Volumetric (Prefab), since that's just a cube
But yes if you're doing Flames or something like that
yeah gotcha, I was trying to use the regular Volumetric
I don't think any of my engines do that. Maybe @eternal robin can help with that?
I would really like to know how to set those up as it will be needed for the next workshop and the CPP engine
oh it's fine, as long as I can get anything to show up in the game, I'll be happy
I was pretty happy with the previous result
I just needed to know about the variant thing
When I heard 13 hours ... I thought munix was exaggerating...
I think if we're talking about having two ways to do this, or even talking about a break at the 1.0.0 level where we fully do it a better way, then it's fine if we depart from the old way.
Nope.

I was far to hasty last night and bought myself a massive load of trouble
That's one way to learn!
If I'd have slowed down just a tiny bit and thought about it first I could have gotten it done soooo much easier and faster
Almost like me writing a build script that accidentally permanently deleted my saves in a game I was modding...
Yeah, something like that - except that here it's not permanently gone and most of it conveniently ran over night.
ah yes this fun bug again, with blinking red, blue and purple
I'm pretty sure that's not how a plume looks
I kept getting that yesterday, too, it would work for a few minutes, then you'd look away and suddenly this would be there
and wouldn't go away
The thing is Florida has the second most flaky electrical grid in the world (there must be someplace worse... Ukraine?) My power went out twice last evening. What would have happend if it had gone out in the middle of a massive restore?
Use a laptop :3
I think I'll just go with the Additive shader for now, that one doesn't have those issues
That makes sense. Get one working and then move forward.
The additive one is the mesh-based one, right?
I think so yeah
Looks kinda sorta Ok from the side, but dreadful from the back?
and invisible from the top/bottom
Dreadful
Yep! I use that one on several engines
Lux was taling about making a volumetric version that would work better, but he hasn't gotten to it yet
Fixing the volumetric one is going to be fun
oh definitely
If we can reverse engineer enough of this we may be able to do it.
I mean that's what I was using before
#1092613573290754108 message
but as you can see..
it likes to break
I was thinking that one was more for chemical engines.
Maybe if we reverse engineer them, we should document them a lot more
yeah, which one did you mean?
What I was hoping for is a volumetric one suitable for ion
oh
Lux was using this Additive shader for his methalox engines
so the volumetric one is basically a replacement for that
So, like Voumetirc(profiled) but different.
I'm wondering if I couldn't use volumetric(profiled) with just a (very) different profile for the MPDs and VASIMR?
alright, so now that I have the prefab variant with the plume on it, what do I do with it? nothing? just export the JSON?
Yes.
The Prefab variant is just a place to model the plume so you can create the JSON
The JSON
there is nothing about that in the JSON
but that says nothing about the type of the component
so where does it get the class name "LFOVolume"
for example
Maybe all the info is there, but the tool assumes what to add then populates based on the JSON info
yeah but my whole issue is
that doesn't tell me the name of the class?
like
how does it know to add LFOVolume but not LFO.Shared.Components.LFOVolume
that is my whole issue
😭
OK, how about this. If there is a JSON then you add LFOVolume, and if it's not there and you've got an addressable instead then you add LFO.Shared.Components.LFOVolume?
Let me look at the source cose
As a component on the child of Plume?
Ahh, I see. They are both forms of "where to add it", but very different Qs and As
since the information about the components obviously isn't exported
because it's on the variant
not on the prefab
Its even using the assetmanager api in a yucky way
This is due to the fresnel, only way to fix it is to limit the fresnel to only happen side to side and not affect it when looking from the top or bottom
it's alright, we have the volumetric shaders, too
for now the biggest issue is actually getting stuff into the game
I swear I just wanna rewrite parts of this
exactly
but for starters I didn't want to make any big changes because then I wouldn't know if it doesn't work because of those, or something else
and I'm glad I didn't rewrite it yet
because there already are issues
even with just adding namespaces
this shouldn't break on a namespace changeee
right???
it isn't hardcoded anywhere
let me just try again with the current codebase, I'll just disable the Deprecated assembly loading for now
holy shit
we've got a plume
I repeat
we've got a plume
Without the Deprecated assembly?
yep
🎉
I seem to have those on SORRY engines though
Do the SORRY plumes work
except for the shaders being broken, everything works
now let me get rid of the LFO.Deprecated monstrosity
since it's obviously not needed
this is without it loaded
This is great news! Wonderful!
the gimbal on modded engines goes absolutely insane though

the oscillations are out of whack
it isn't nearly that bad on the stock engines
That's curious. I've moddled my gimbals on the config params used in stock engines.
yeah, that's why it's strange to me
ok one more test with the LFO.Deprecated project completely removed
Could be gimbal response speed
I tried to lower it by half on the Community Parts Pack engine, but that gave me oscillations with SAS on, AND it was extremely slow responding to input
or rather, it felt like it was responding to inputs like a couple of seconds late
Could it be like where the thrust transform is?
I was also thinking that
That might be it
maybe if it's inside the throat, right below where the gimbal is, it will be better than if it's below the nozzle
Would that even do much though
I'll admit I'm winging it on some details. My assumption is that thrustTransform needed to be located where you want the plume to be, but of course you can offset the plume graphics form that.
honestly, no idea
So, perhaps I've placed it wong on the CPP engine
I mainly thought it needs to be a child of gimbal and needs to point in the right direction for it to work properly
alright, another test successful
It should also be dead center on axis as with gimbal
so I'd say the next thing that needs to be done with priority is fixing the shaders
and then we can start rewriting/adding features
but first we should get it working, I think
By fixing the shaders, what is included there?
Does that include fixing the colors?
yeah
mainly
but the issue is not just the colors
the shaders generally don't do what they should
Have you tested the new version with any SPARK engines?
I will try right now
but I do know the colors are still broken
since the SORRY plume looks completely wrong and red
(#1092613573290754108 message)
idkwym, that looks perfectly fine!
those clean lines are definitely not supposed to be there
everything is fine, just fine
The clean lines look like the expansion stuff is messed up
It looks like its max compressed and is going into itself
and Lux tried for a couple of hours to fix the colors not getting set properly in the shader, and couldn't figure it out
so it's going to be really fun trying to fix that with my non-existent shader knowledge, when even he couldn't
lmao
Red is the default color of anything so i imagine its because somethings wrong with saving or reading the color information
OTOH, you've got a fresh pair of eyes and may see things differently than he did
this is disgusting
Could there be other defaults that we're getting that might account for the max compression?
you'll find even more "disgusting" in the current version
Maybe
I had to rewrite that with reflection
to appease Unity
Hopefully there are all related and it's just one thign that's different between 0.1.4 and 0.1.4.1
Technically, you could just import spacewarp into unity
it's another one of those things I'd just like to refactor completely out of the in-Unity code
in the current state, everything depends on everything and it's nasty, there's absolutely no reason why the same class used in the editor needs to call a SpaceWarp method
it can be easily solved with some DI
@brittle tendon can you give me a plume config for a volumetric (profiled) plume
Found one
lemme redownload it (I had replaced it with my own version of it which doesn't work)
I think I know one of the issues
jesus it's already 1pm, I gotta go walk my dog
Right here
_NoiseTex should point to a 3D texture, how do those work
But that is only a 2D texture being loaded
[Error : Unity Log] Error assigning 3D texture to 2D texture property '_MainTex': Dimensions must match
[Error : Unity Log] Error assigning 3D texture to 2D texture property '_NoiseTex': Dimensions must match
a lot of these
Exactly
and of course it couldn't be more verbose
like saying which texture it can't assign
Just add some debug logging here
btw where is that code from?
since it's not the current version
Log($"Assigning texture {textureName} to property {kvp.key}");
Unity package for creating LFO plumes. Contribute to KSP2Community/LFO.Editor development by creating an account on GitHub.
https://github.com/KSP2Community/LFO.Editor/blob/main/Shared/Settings/ShaderConfig.cs (main branch version, which is the same)
Thats exactly it
it isn't
Yes it is?
yeah, I was just wondering why you didn't have the version with reflection
Just the reflection
np
Somehow the submodule put me into a weird commit
ah yeah because I only pushed a few minutes ago with the updated submodule commit
Still, just change this to the following
Debug.LogError(e.Message);
To
Debug.LogError($"Error assigning texture {textureName} to property {kvp.Key} of {material.name}: {e.Message}");
that did nothing
It didn't fix the logging?
apparently not
Okay
I mean we can just print it before trying to set it
Just put
Debug.LogInfo($"Assigning texture {textureName} to property {kvp.Key} of {material.name}");
Before the material.setvalue or whatever
what the fuck?
and that's the only place where SetTexture is called
Does unity .... lazily set the textures?????
🤷♂️
Can you show the logs from where it is setting the textures though?
I uhhh, what?
???
Are you sure the correct DLL is in there?
Like did you deployandrun and it not update the DLL?
bruh
yeah
you're right
ahhhhh I hate that this happens
WHY
the same thing happens with PM sometimes
I always just delete the old folder before DeployAndRunning
the new files just don't get copied into dist for some reason
needed to completely delete both build and dist, nuget restore, and rebuild
Wtf
and
surprise surprise
plumes don't show up again
so it was the fucking Deprecated dll
🥲
Error assigning texture 3DNoise to property _NoiseTex of LFO/Additive: Couldn't find texture with name 3DNoise.
at least I got this now lol
that should be the easiest part to fix
but I just don't understand why the fucking namespace breaks it
Alright
and honestly we can just do something where we try to get it from addressables if we can't find it in the asset manager (which is yucky yeah)
...
yeah that would do it
where the hell is it even used
oh, in my testing engine lmao
but why
it isn't assigned anywhere
oh duh
Check the config?
Can you dump the logs where spacewarp lists everything in the bundle?
[Info :lfo/lfo-resources/packages/lfo.editor/assets/noise/3dnoise.png] registering path "lfo/lfo-resources/packages/lfo.editor/assets/noise/3dnoise.png"
here's the whole thing
so why is this throwing an error
lfo/lfo-resources/packages/lfo.editor/assets/noise/3DNoise.png
Yeah thats what that would expand to
is it because I messed up the reflection code?
Like try get asset does lowercase the path as well?
shouldn't it be case insensitive?
it is
huh
anyway I really need to go or my dog will eat me in my sleep for making him wait for 2 hours longer for his walk
There are 2 different methods named TryGetAsset
What logs are near this
BindingFlags.Public | BindingFlags.NonPublic
Also this doesn't work
Just do binding flags.public
I'll get back to you in ~15-20 minutes
Yeah
BindingFlags are a combination, and I'm pretty sure they are treated as an all flags much match kinda situation
I don't think that's true
idk
BTW, if it's expanding to foo.png, then it's looking for a 2D thing (you guys know that of course). The 3D things are not png, but are .asset
I've always had issues with using Public | NonPublic
The issue is that in the editor window for the Additive shader, you cannot select a 3D texture, only a 2D texture
Which (for some stupid reason) 3DNoise is
3DNoise.png is the file
Then the issue is probably an ambiguous match
But its imported as a 3D texture likely
I have no 3DNoise, only "3D Noise"
Nope, those are "3D Noise" not "3DNoise"
Those are two separate files
Both are in the bundle
As you can see from my screenshots above
I don't have a "3DNoise" in the old LFO installed into Sparky
Well, it is in this one
Where did it come from?
From the zip from Lux
I simply added all the assets to the bundle and built it
It's possible that it's not supposed to be used, that it was just for some testing or something
However the file is definitely there
So it makes no sense that the asset manager can't find it
What are its import settings?
Ah that's a good question
and what are the logs surrounding that error?
I'll need to look when I get home
Because I have a guess on where it messed up in the reflection
See if you have that error
Also lux keeps using exception.message
when he should be using exception.tostring!
aaaaaaaaaaaaaaa
Lux does a lot of things 
But the most important part right now is to get the namespaced components to work
I just want to do
sed /\.Message/\.ToString\(\)
Like it's completely beyond me why they don't
Cuz Exception.Message won't contain the exception name either...
now there aren't any _NoiseTex errors but instead there's this...
aaand you're right
Ambiguous match
but I still don't understand why?
how can it find multiple methods of that name in SpaceWarp.API.Assets.AssetManager?
oh, generics... right?
Yep
alright, that should be easy to fix
however these errors were popping up long before I made it generic
No
its the generic method inside of Space Warp
there are 2 space warp methods named TryGetAsset
one is generic, the other isn't
That wasn't the same error
yeah
As I said, not the same as the ambiguous match
By passing the types into the findmethod function
I already made the method generic
You have to pass the argument types into the GetMethod here
wtf is a binder
why the fuck does Rider not show that one at all
oh, it's only in .NET 7
not in .NET Standard 2.1
Wtf
ok apparently I just pass null to the binder
to use the default one
I swear to fucking god
I just can't use the correct overload
There is another more complex method
you can get all methods with the name, and then select the one that isn't generic
Or get all methods
So like
FindType("SpaceWarp.API.Assets","AssetManager").GetMethods(BindingFlags.Static | BindingFlags.Public).Select(method => !method.ContainsGenericParameters && method.Name == "TryGetAsset").FirstOrdefault();
And you might as well just cache that
yeah
I got a bit confused why it said it's returning an ienumerable of bools
it's Where, not Select
but thanks
I really hope this finally works
like
some stupid reflection to call one method should not be this complicated to write

We really need to just make an interface and implement it only at runtime
DI?
dependency injection
Ahh yeah, for sure
everything is so tightly coupled here it's a miracle it doesn't collapse into a black hole
class LFO {
LFORuntimeInterface inter;
LFO(LFORuntimeInterface i) {
inter = i;
}
T TryGetAsset<T>(...) {
return i.TryGetAsset(...);
}
}
yeah, exactly
but lemme just try to make this work first like this
since I already have it
And since we never instantiate the LFO class when building the asset bundles, we don't even need to provide an implementation of the interface in the editor, only the interface itself
oh my god
finally the fucking plume is back
I've never been this happy to see a shitty flame
Post em
[System] Loading localizations for plugin Lux's Flames and Ornaments completed in 0,0011s.
[System] Lux's Flames and Ornaments: loading soundbanks completed in 0,0001s.
Error assigning 3D texture to 2D texture property '_MainTex': Dimensions must match
UnityEngine.StackTraceUtility:ExtractStackTrace ()
UnityEngine.AssetBundle:LoadAsset (string,System.Type)
UnityEngine.AssetBundle:LoadAsset (string)
SpaceWarp.Patching.LoadingActions.FunctionalLoadingActions:AssetBundleLoadingAction (string,string)
SpaceWarp.API.Loading.Loading:LoadSingleAsset (System.Func`3<string, string, System.Collections.Generic.List`1<System.ValueTuple`2<string, UnityEngine.Object>>>,string,string,SpaceWarp.API.Mods.SpaceWarpPluginDescriptor)
SpaceWarp.API.Loading.Loading/<>c__DisplayClass9_0:<CreateAssetLoadingActionWithExtensionsDescriptor>b__0 (SpaceWarp.API.Mods.SpaceWarpPluginDescriptor)
SpaceWarp.Patching.LoadingActions.DescriptorLoadingAction:DoAction (System.Action,System.Action`1<string>)
KSP.Game.Flow.FlowAction:Do (System.Action`1<KSP.Game.Flow.FlowAction>,System.Action`2<KSP.Game.Flow.FlowAction, string>)
(wrapper dynamic-method) KSP.Game.Flow.SequentialFlow:DMD<KSP.Game.Flow.SequentialFlow::NextFlowAction> (KSP.Game.Flow.SequentialFlow)
KSP.Game.Flow.SequentialFlow:Update ()

Meaning one of the assets doesn't have its import setting built right
as in, 16 columns and rows?
Yes
👍
Ahh, nevermind
Might be worth building a custom version of spacewarp that logs exactly which asset it is loading
yeah, hm
[LFO] Assigning texture 3DNoise to property _NoiseTex of LFO/Additive
that does seem to work with no errors
the _MainTex is the issue now
But that comes from the import
the import?
Can you add that to FunctionalLoadingActions.cs in SpaceWarp and use that modified version of space warp?
Honestly I might just push this on dev
yep
Also might be worth adding a try/catch there as well
Screw it I will
You can also just use the dev branch
In a second
There, the dev branch has some more logging
Yep
Can you show that asset
3d noise 3.mat
it might have something set incorrectly
Ahhh
Alright, so its a material named 3d noise ... that uses the standard shader????
yeah, that's weird
lmao
it's weird that they work well in Unity but not in the game
and even weirder that they broke in 0.1.4(.1), not in 0.1.5
It could be some shader parameters not being set correctly
How do we know it was 0.1.4.1 that broke it?
Do we know that
@split geyser seemed pretty sure
and I can't go back to 0.1.4 since it's not in the Steam betas list
I can test 0.1.3.2
but I think we can safely say that the bug was at least partially present in 0.1.4.1 for sure, since SPARK plumes turned red
Alright
My guess is a property isn't bein set correctly
we should dump all the properties being set
actually, where are they even being set
In the class where Material.SetValue is used
that is not used anywhere
Yes it is
oh these
called by https://github.com/KSP2Community/LFO.Editor/blob/main/Shared/Settings/LFOConfig.cs line 105
I only did a project-wide search for SetValue and didn't find anything, that's why I said it isn't called lmao
well alright then
time for some debug logs
but first I need to grab some lunch, it's 3:30pm and I'm dying of hunger
alright time to get back to this
so, those are still the same "errors" I was getting before
except the plumes actually show up now

but the material values look good
where the fuck is it taking the old class names from
when the components are not in the JSON and not on the prefab
this makes literally 0 sense
and this time I'm sure there are no old DLLs
either I'm going crazy, or the SORRY engines just have the components on the prefabs
let me check the SORRY addressables in Asset Studio
https://github.com/nesrak1/AssetsTools.NET
Use this to dump the prefabs
Read and write unity assets/bundle files, based on https://github.com/SeriousCache/UABE - GitHub - nesrak1/AssetsTools.NET: Read and write unity assets/bundle files, based on https://github.com/Ser...
they were built in 2020 so it will open it
istg lux
The fuck

I know Lux was testing custom planets and stars
but why in SORRY

that doesn't look like "an empty object named Plume" to me
....
let me test again with the CPP engine that I added a plume to
since that shouldn't have those errors
Could those be the "stock" plumes
I don't actually think there are any, I think I made that up lol
yeah ok, that is just a thing in SORRY
not in LFO
bruh
[LFO] Setting _Opacity to 0 on LFO/Additive
[LFO] Setting _Brightness to 2,32 on LFO/Additive
[LFO] Setting _StartTint to {
"r": 0.8944215,
"g": 0.5896226,
"b": 1.0,
"a": 1.0
} on LFO/Additive
[LFO] Setting _EndTint to {
"r": 0.672184467,
"g": 0.0,
"b": 1.0,
"a": 1.0
} on LFO/Additive
[LFO] Setting _NoiseTex to 3DNoise on LFO/Additive
[LFO] Method invoked successfully, asset: 3DNoise
[LFO] Assigning texture 3DNoise to property _NoiseTex of LFO/Additive
[LFO] Setting _QuadraticExpansion to -0,1 on LFO/Additive
[LFO] Method invoked successfully, asset: Flames
this is for the CPP engine
:/
so it has to be in the shaders
But what changed with em
I have no idea
especially since it was before the Unity upgrade
let me just try to grab some older versions of LFO to test
nope, still only getting red on 0.2.1 and 0.2, and 0.1 worked completely differently
Rip
so something must have changed in the game somewhere between 0.1.3.2 and 0.1.4.1
most likely between 0.1.4.0 and 0.1.4.1, since that where schlosrat first noticed the red plume on his engines
Does anyone still have a 0.1.4.0 decomp?
I do have a second install, maybe thats still 0.1.4.0
Perfection
I guess I should grab a 0.1.4.1 install
to do a diff
hopefully the downgrade won't take long
Code diffs weren't that helpful...
Nothing significant between 0.1.4 and 0.1.4.1
And there's a lot between 0.1.3.1 and 0.1.4, I did look in some places that have to do with VFX, rendering, and such, but again, nothing that seemed significant
But then there's also the fact that the shaders are all broken in the same way
Even though we checked that the code that is setting the colors on the material is setting the right values
It would be kinda weird if all the shaders had the same bug
So, I do have an old 0.1.4.0 install
Nice!
I just need the mods to test with
a version of LFO and a version of SPARK where the plumes go red
Definitely the latest release of LFO on CKAN/SpaceDock
and SPARK
And the latest version of SORRY should work too
SPARK was the one with the red plumes
And latest version of SPARK
That's literally all modded engines
None of them get anything else than the white-red spectrum
This is what the SORRY plumes should look like
The 3rd one is the one I was testing
#1092613573290754108 message
And this is it in the game now
I think that should illustrate the shader problems pretty well
Reiptor-12
This looks like not the correct plume at all?
Yeah... That looks like the same shader issue
So we can rule out 0141
I'm thinking this is a bug in LFO
tbqh
I don't think anything changed in the game
I think LFO is setting stuff up incorrectly
Could you try version 0.2.1 and 0.2.0 in your version of the game?
0.2.0 definitely had to work
But it doesn't work at all in KSP 0.1.5
or possibly it doesn't work with the latest SORRY
Launching with 0.2.1 now
Thank you
0.2.1
that's... different, but also wrong??
it looks like the mesh is correct, but still wrong colors
But also idk if the latest version of SORRY is correct for that
SPARK just wont load with a lower version of LFO
imma use SORRY 0.4.0
yeah, SPARK uses the volumetric plumes
which Lux only added in 0.9
and schlosrat had working blue plumes at some point
so it can't be because of LFO updates
it has to be a game version thing...
Or it could be lux doing undefined behaviour that didn't mesh well with the game
that's definitely possible
but if I'm right, then it would work in 0.1.3.2
I'll download it
Wronger somehow
that's 0.2?
Thats 0.2.1, with sorry 0.4.0
@split geyser is it possible your plumes only worked (non-red) in 0.1.3.2, and never in 0.1.4 or 0.1.4.1?
because we can't get them to work properly in either of those
well, I suppose we'll know either way in 10 minutes
That’s easy to test. I can download 0.1.3.2. I’m pretty sure though they were fine in 0.1.4. I’ll go back and look at when I released versions of SPARK vs the game version and the fact that red was not there on 10/7 and was there by 10/15
no need! I'm already downloading it
Also, check out the SPARK releases. I generally note what version they’ve been tested with
Nope. My SPARK release notes are useless
version 0.1.1 is the last that says KSP2 0.1.4.0
so that one should be safe to test?
Though I do know that SPARK 0.1.4.1 came out tested with game 0.1.4.1. It was a funny coincidence
gonna go with 0.1.3 then
and I'll run to quickly grab some food before my download finishes
try 0.1.1, that was definitely tested with 0.1.4
0.1.3 was released on 10/7
since it came out before the hotfix release
I was referring to my GH release notes but yeah, spacedock too
alright
Driving home now
Did anything change with the fx manager between 3 and 4?
I think that was one of the obvious few places where I looked, and no substatial changes
I wish someone named lux would document this stuff
In all honesty, how much will this testing help us
I... don't know
I wanted to at least pinpoint exactly where the change from "working" to "not working" happened
to give us some sort of a clue
On my SPARK GH Repo it looks like the README.md was last updated 2 months ago and says
Tested with Kerbal Space Program 2 v0.1.4 & SpaceWarp 1.4.3
Requires SpaceWarp 1.4.0+
Requires LFO 0.9.0+
Optional, but highly recommended: Kesa Solar 1.0.3+
Optional, but highly recommended: Lux's OAB Extensions 1.0.0+
Specifically that was updated on 9/29 actually.
With version 0.1.2
And I know for sure that SPARK v 0.1.4.1 came out shortly after KSP2 0.1.4.1 on 10/16
And I know that I was using LFO 0.9.0 from at least 0.1.2 onwards
according to SpaceDock, you already released 0.1.2 for 0.1.4.1 though
Do all plumes appear red or only previously blue ones?
all of them are only red-white
and that's not the only issue
OK, it's possible that "Tested with Kerbal Space Program 2 v0.1.4" actually meant 0.1.4.1...
yeah, the 0.1.4.1 hotfix released on September 29th
so 0.1.2 was the first version for it
since it came out a day later
and no version of SPARK was released for 0.1.3.2
so it had to work on 0.1.4 and LFO 0.9 (since you were always using the volumetric plumes, and those came only in 0.9)
Yep
so it's even weirder that Cheese couldn't get LFO working properly on 0.1.4
this just gets weirder and weirder
it worked before, and now with the exact same setup, it doesn't
could it be something in SpaceWarp??
Was schlosrat testing with the release version of lfo
How would it be???
I mean, how could debug mode affect the flow actions...
I feel like we're dealing with something metaphysical when it comes to KSP2 modding
lol
I'm gonna start setting up a shrine I suppose
he may not have been, but the plumes worked for players (including me)
and I never had a pre-release
Maybe commune with some other eldritch deities
that might be our best bet to solve this tbh
I had a prerelease of 0.9.0 to develop with, but I also tested with the released version of 0.9.0
Alright
Im gonna install spacewarp 1.4.3 when I get home
istg if that fixes the issues
I will delete spacewarp if it does
Please don't!
SW 1.5 was released on 10/10
I've been trying to get this all running on 0.1.3.2 but it just doesn't seem to want to work
like none of it
SpaceWarp, LFO, or SPARK
Wtf
tried SW 1.4.2, got stuck on loading localization addressables
1.4.3
1.4.2 was the fix
Cuz spacedock didnt have 0.1.4.0 at the time
makes sense
well
time to nuke the BepInEx folder
and try again
this time one by one
not all at once
nope... SpaceWarp 1.4.3, UitkForKsp2 1.4, stuck on localizations
yeah
no Mods...
and I have only SW and UitkForKsp2 1.4.2, which was released before SW 1.4.1, and was the last version before 2.0
Sw 1.4.2 on ksp .132?
SW 1.4.1
Dafuq
Config manager?
internal screaming
I told you none of this makes sense

there's a computer poltergeist fucking with me istg
This has got to be the most bizarre thing I've seen yet. We're unable to roll back to a prior working version? I mean, how that possible?
Try .1.4.1 with sw 1.4.3?
and not just to a working version of LFO or SPARK
I can't even get SpaceWarp working on 0.1.3.2
any version of it
lmao
Yeah, that's what I mean
I can try...
I'd think: Install old version of KSP, Use CKAN to install old version of SW/BIE, etc.
I'll make a backup of 0.1.3.2 just in case we need it again
but it's kinda useless if SW doesn't work
lol
Dont use CKAN for 1.4.1?
Istg
could it be that somehow some remnant files of 0.1.5 are fucking this up?
since I did a downgrade from it
oh duh, this one was obvious
I didn't install UITK with the GH release
lol
because I deleted the full BepInEx folder
They definitely would
fucking finally
I have no clue why the CKAN install didn't work
dear god finally
by the way SPARK is only marked as compatible with 0.1.4-* so I had to manually change that number
but it's the latest release
and obviously it works in 0.1.3.2
FINALLY
ok, so confirmed working on KSP2 0.1.3.2, LFO 0.9, SPARK 0.1.4.1, and SpaceWarp 1.4.1
So 2 variables
and since schlosrat was releasing the mod for 0.1.4, it should work there as well
Game version and sw version
so it's really looking more and more like SpaceWarp to me...
I dont know what would have changed between the versions to cause this??
I can try with a few different SW versions in 0.1.4.1
I was testing with a prototype version of 1.5
we should know soon, this update is only 500 MB
and the only difference should be updating SW to 1.4.3
What the actual fuck
Well we narrowed down the issue
Kinda?
I am now at a loss for what could be causing the issue
I will say, I'm honestly a bit relieved
I was hoping it wasn't something in the shaders themselves
Alright
So ... we debug lfo in 0.1.5 with spacewarp 1.5 hoping to find something for a hotfix?
probably
You wanna start with that while im still out?
oh and let me just quickly test SORRY, to see if all the shader issues happen after SW 1.5
not just the colors
most likely yes
but I'd rather know for sure
Hmm ... should we start with disabling the colors patch as a test
those both look wrong...
except the left one has correct colors
let me test with LFO 0.2.1 now
these were SW 1.4.3 vs 1.5.1
yeah that looks right
so there are two issues
Wtf did we do
the color is caused by SpaceWarp
and the shape of the plumes is caused by LFO
well this is fun
Do we have shader source for the plume in 0.2.1?
now we have two separate bugs for the price of 1
I'm not sure...
the unitypackage schlosrat has is called 0.2.1, but it already has the volumetric shaders
so it's more like a wip version of 0.9
and Lux didn't commit any of his Unity project stuff
so most likely we don't have the 0.2.1 shaders...
istg if this just means the working version is lost forever
because of no VCS
I will commit murder
as for the SpaceWarp part of the problem, I suppose we could just port 1.4.3 to work on 0.1.5
and then start bisecting the commits that led to 1.5
We kinda just have to grok the changes
just to get the full set of permutations
SW 1.5.1 + LFO 0.2.1
basically what you had
correct shape, wrong color
these two issues are definitely completely separate
yeah, it was driving me crazy that we couldn't reproduce it
@brittle tendon the shader shape is correct in unity, right?
I haven't played around with it that much but it looks like it?
For the mesh based
honestly I don't really know how to recreate these more complex plumes
but there were no hard edges or anything
so I think it looked fine
oh but it also did in-game...
so that proves nothing
I couldn't resist
Honestly, LFOs shaders not having any documentation confuses me into how anyone could use it
with a lot of help from Lux
lmao
well, except for JiMKesa
let's face it, he's just a genius
he gets everything working without anyone's help while we're struggling
lmao
it will also be a bit difficult to test in Unity whether the plume shape looks good or not
because we don't know how it's supposed to look for which values
🙃
oh but actually no
We could decompile the asset bundle for SORRY?
we could replicate the values from existing JSON configs
for SORRY for example
and I think that there's even a "load config" button in LFO
never tried it before
Ah wait
Sorry uses mesh based plumes
Unless I have an old version of sorry that I just grabbed
noted, thanks
Actually, why the fuck is the save json button calling load json?
Wait, nevermind
Ahh I need to put the thing as a child of an object
why does ThunderKit just work in 99% of cases now
I'm not even using your fork
no need to reimport or "Fix Unity" after restarts most of the time
Unity is so inconsistent istg
@brittle tendon so your stuff completely broke the LoadConfig stuff
how fun
As the LoadedShaders is never updated for the LFO class
why the fuck does the editor code depend on the runtime stuff

and vice versa
like, LoadedShaders was always written only from the flow action, no??
Yep...
so I didn't break it, it never could have worked
And I am trying to fix this stuff in the editor
I feel like at this point we would be better off really just first completely rewriting it
and then fixing the shaders
Yeahh
I really just want to test something
Honestly, screw it, lets rewrite this
I am not dealing with this as is
I cannot
and consider this: at least now it's a single solution where you can build and test the runtime part with a single click, and for the editor part you don't need to do anything, just push it
it used to be that you go to a .NET project, build the DLLs, copy them to the Unity project, export a unitypackage of all of it, and make a release with that

I'll attempt to remake some
we still have the JSONs for SORRY
I can just manually write down values from it
We obviously have the JSONs for SPARK, and presumably there must be JSONs for Questaria
indeed
but I thought the SORRY ones were an obvious choice, since they are pretty complex, so they should show well if everything behaves the same, and they were made by Lux, so supposedly they should be written how he intended
I'm kinda amazied right now. You guys have done soooo much
That you've isolated this down to two bugs in two different things is really amazing
Are you sure that re-writing is the best path to that?
it will definitely make us not want to tear all our hair out while working with the current codebase...
or at least make it less so
lol
I mean I get it, SW went through a refactor, so finding that one could be pretty hard