#LFO - Lux's Flames and Ornaments
1 messages · Page 4 of 1
Still, it could be a messed up thing in SPARK
I'm gonna call it a night, but I'll work on this some more tomorrow.
From what I can see I think LFO 0.10.0 is OK
There's some madness with one of my plumes, but since the others in that family are all behaving I don't think it's anything to do with LFO
here's the file if you want to test it out tomorrow
Thanks! I'll check that against what I've got to see what the matter may be.
seems like the current GitHub action is not equipped to handle projects with dependency on submodules
MSBuild version 17.7.3+4fca21998 for .NET
Determining projects to restore...
Restored /home/runner/work/LFO/LFO/src/LFO.Editor/LFO.Editor.csproj (in 4.72 sec).
Restored /home/runner/work/LFO/LFO/src/LFO/LFO.csproj (in 4.87 sec).
LFO.Editor -> /home/runner/work/LFO/LFO/build/bin/plugin/LFO.Editor/Debug/netstandard2.1/LFO.Editor.dll
/home/runner/work/LFO/LFO/src/LFO/LFOPlugin.cs(11,21): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/LFOPlugin.cs(5,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/LFOPlugin.cs(6,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(10,21): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(6,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(7,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(8,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Services/AssetManager.cs(3,21): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Services/AssetManager.cs(1,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Services/BepInExLogger.cs(2,11): error CS0234: The type or namespace name 'Shared' does not exist in the namespace 'LFO' (are you missing an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Services/BepInExLogger.cs(6,34): error CS0246: The type or namespace name 'ILogger' could not be found (are you missing a using directive or an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Services/AssetManager.cs(8,33): error CS0246: The type or namespace name 'IAssetManager' could not be found (are you missing a using directive or an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(50,46): error CS0246: The type or namespace name 'LFOConfig' could not be found (are you missing a using directive or an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(118,13): error CS0246: The type or namespace name 'PlumeConfig' could not be found (are you missing a using directive or an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
/home/runner/work/LFO/LFO/src/LFO/Patcher.cs(19,33): error CS0246: The type or namespace name 'IAssetManager' could not be found (are you missing a using directive or an assembly reference?) [/home/runner/work/LFO/LFO/src/LFO/LFO.csproj]
Build FAILED.
if any kind soul could approve my PR
ooor I'll just force merge lol
Looks done?
@grim bridge I forgot this was a thing when trying to delete a release...
I guess for now I'll just edit the old releases, replacing the download with a text file that says that the original had to be taken down, or something
alright, now it should be all done
all the old GitHub releases are deleted, new one up, and for SpaceDock, I replaced the downloads with a zip containing this README.txt:
This version of Lux's Flames and Ornaments (LFO) has been taken down due to some issues. Please see the latest version here: https://spacedock.info/mod/3383
and I added a notice to the changelogs of the old versions, too
so I think this is the best we can do for now
now to fix the shaders...
So much progress today!
i just want to quickly say i'll never take LFO for granted again and will remember the sacrifices you guys have made to get these pretty plumes working whenever i see them, lol
Congrat guys. What a great job !
I can't check it today but as soon as possible. Respect for your work !!!
Amazing job, congrats!
@brittle tendon Thanks for the update! Amazing work at getting this working again!
Console message (unity 2022) :
Assembly 'Assets/LFO/LFO.dll' will not be loaded due to errors:
Unable to resolve reference 'SpaceWarp.Core'. Is the assembly missing or incompatible with the current platform?
Reference validation can be disabled in the Plugin Inspector.
Something is missing ?
That looks like you're using an old version of LFO in Unity
You have to delete the LFO folder in Assets and install the new package from the Git URL https://github.com/KSP2Community/LFO.Editor.git
thanks munix. I will try
Works fine ! Thanks.
I'll rebuild each part and push a mod update.
Really, thank you to everyone who contributed to this LFO upgrade
it didn't look easy
Saving plume json works nice in Assets\plugin_template\assets\plumes
loading plume json config too, except for noise texture (in LFO/Additive shader). In Unity, no noise texture reference, but exists in json
Not blocking me, just for info
@brittle tendon and @grim bridge did all the heavy lifting! I mainly contributed moral support, encouragement, a little bit of testing, some frankly useless kibitzing, and some new meshes for some of the plumes. If it weren't for the amazing work munix and cheese put in we would not have a new LFO for 0.1.5!
I made a mistake on install. Sorry
it's ok
@brittle tendon I dumped my old LFO and synched to 0.10.0, added an Archive folder on my local repo that's now ignored in the .gitignore, added a Meshes folder under src, and put updated blends and fbx files there with the units now in m instead of mm. There's a PR for you.
We're not gonna get into a situation where whe can't rebuild!
thank you
however, a few things - the fbx files still contain the cameras and lights, which they shouldn't, and then, do we need two versions of each fbx to be in the repo?
I think just the blend files would be fine
Oh! So sorry. let me fix thos rn
no need!
They're easy to fix!
since the working exported fbxs are already in the Assets folder of the Unity project
it makes no sense to have them duplicated
Well, I'll fix the blends to remove those so that if we ever need to remake them we don't get those things
I assume it probably does make sense to have things scaled in m since pretty much 100% of modders will be scaling their engines like that.
it's fine to have the lights and cameras in the blend, you just have to select only the mesh when doing an export
but if you want to update them, there's one thing I've noticed now
the mesh is called "bell_j_01.002"
but to be loaded properly in the game when exported, it needs to have just the name without the .002
oh and one more thing, could you please move the folder with these out of src? into something like <root>/blender or similar?
I'd prefer to keep the src folder only for the C# projects
(which inevitably also includes the Unity project in the hierarchy in our case, because the LFO.Editor C# project needs to compile files that are inside the Unity project)
but for asset sources, I'd prefer to have them in a different folder in the root
sorry if I'm asking a lot 😅
I just really want to have some good structure in the project so that it doesn't devolve into a similar state to how it was before
I think I fixed the naming - though I didn't see what you're showing up there. When I look at the blends they all look like this
ahhh yeah that's actually my mistake, sorry
I opened the blend and then imported the fbx into it, to see both at once
I think it's fine to remove the camera and lights, it makes generating the fbx bulletproof and we don't need them. When are we going to render these things in blender? And we could always add the default camera and lights back in quite easily if we did want to.
and of course, since a mesh with the same name already existed, it named the imported one with the .002
so that's totally on me!
yeah, sure, that makes sense
No worries. I renamed the folder blender and moved it to the root. I'll update my repo. Do I need to make another push or will updating my repo get you the update?
<- is a Git git
the pull request is from one of your branches to one of the project's branches, so when you update yours, so will the pull request
I thought it might be like that
I've pushed to my branch so it should be good to go. My tiny little contribution to this effort!
the folder still contains the fbx files with the lights and cameras, and ideally there should be no fbx files in it
That's weird. I re-exported after removing the camera and lights.
If you prefer I'll just delete the fbx's, but I thought you might like to have them in m
if you want them to be updated to use meters, then you could make a PR to where they actually are in the project: https://github.com/KSP2Community/LFO.Editor/tree/main/Assets/Meshes
in the LFO.Editor repo
Hang on, I may know what's happening - I've got a hunch. When you say there is a camera and a light in the fbx are you determining this by importing the fbx into an empty blend?
yeah, and that resulted in two cameras and two lights
but maybe I just imported the wrong old file
let me try again
ah yeah it looks alright now, I probably clicked the wrong file, sorry!
my downloads folder is getting slightly messy lol
Oh good, cause I tried that on my end and it worked. I thought I was going mad
I'll move the fbx's to the LFO.Editor folder where they belong
when I try the new ones, it does result in this in Unity:
where the tiny speck is the old one and the big one is the new one
it automatically gets created at 100x scale for some reason
but when I set the scale to 1, it's fine
so hopefully it will be ok
it seems like the 100 scale comes from the fbx itself
Hmm... Then I've messed up something in my attempt to get it to be scaled in m.
That's no good. I'd like these to be left in a state where anyone can use them and it's easy to update
honestly this whole thing about units and scales is so annoying
It is!
And I'm sure it's my fault for being stubborn and going with mm at the begining.
I set that as my defauilt in blender, and I really should fix that
what worked for me was what I showed you earlier, setting the units to cm and unit scale to 0.01
that resulted in the correct size by default in Unity
but why, I have no clue
since units as meters and scale of 1 should be pretty much the same thing
Well, I can scale everything down by 100x very easily in blender, but I suspect there's something else I'm missing. Though why 100x and not 1000x?
well, probably because 100 cm is 1 m
OIC. You could have used a scale of .0001 and set the units to mm and had the same effect.
You're really just saying 1 = 1
yeah, to be honest I really have no clue how all these scales work and interact
you have blender units, blender unit scale, blender mesh scale, and unity scale
I'm not finding the folder to drop the fbx's into. What I see under LFO.Editor is this for content in the Assets folder
I found it!
it's a separate repository which is linked as a submodule in the main repository
I want to get these right before I move them in though
and yeah it's under Packages
Let's see, the ones that are there are OK now? They work as is, but when you import them into a blend with the new ones then they're scaled wrong, correct?
Well, the new ones are scaled wrong.
yeah, basically
So if I manage to get the blends to where, if I were to import an fbx from the lfo.editor/Assests/Meshes folder, they basically overlay, then I will have gotten my blend to perhaps be scaled correctly.
Or rather, that a new blend importing both fbx's would have them overlaying.
this is such a mess, jesus
If I can get them to that state (and I'm sure I can), then the blends I'm submitting will be OK
this is the scale of the one that currently works
when I set it to 1, it's the same size as the new one
Which also makes it 100x to big, right?
(oh because now I have the units set to meters)
when I had them set to cm, the scale was 1
You mean the scale in Unity, right?
in Blender
when my units are set to cm, and unit scale to 0.01, then the old fbx is imported at 1x scale, and the new one at 100x scale, when I set the units to meters and unit scale to 1, then the old fbx is imported at 0.01 scale and the new one at 1x scale
ahhhh I hate everything about this
Let me work on this and you relax. I'll sort this out so that the new fbx's are the same scale as the old one, and as the stock stuff from the game. I'm sure whatever we do it will be best to be at the same scale as stock.
thank you for dealing with this, this has been making me lose the last bits of sanity I have left after all the updates for UITK and LFO

but at least we know it works in the current form
I think I've got it sorted now. Once again, the problem was at my end. The fix was stupidly easy, and I should have known. All I needed to do was go into it in Object mode and click Apply Rotation and Scale. I think what happened was that in changing the units this gave it an automatically applied scale transformation to keep it the same size, and Blender was relying on me to know that I would then need to go in and also click on Apply Scale and Rotation. Silly Blender! This is schlosrat! Here's a video from a test blend where you can see I've imported the original game objects as well as some brand new fbx's, and they look like they're very close but not quite identical.
Ditto for the bel_p2_1
Which is huge next to the shock diamonds...
Likewise for bel_j_1
awesome! no clue why the bell meshes are so huge compared to the shock ones lol
I'll move the test.blend to Archive so it doesn't get commited, and the new FBX's to where they need to go
but it seems like they work fine that way, so that's all that matters
Oh, the bell is used I think when you're modeling a plume expanding in space maybe?
actually I think those may be placed, as the name suggests, inside the engine bell
But yeah, if they work then they work, and now we've got blends that can generate proper fbx's (I hope!)
Well then, I have no idea why they're such a different scale.
Hmmm... before I just haul off and drop new FBX's into a unity project folder... Can I do that without messing up the .meta files? Should I do that in Unity instead?
yeah, that's probably for the best
I'll do it that way then
just delete the old files and their meta files, and drop in the new ones
so that new meta files are generated for them
and please assign them to the lfo-resources bundle
The project is 2022.3.5f1, right?
yep
that's not a Unity project
it's just a package inside a project
you need to open src/LFO.Editor/Unity
the way packages work is that you create a project that will hold the package, and create a folder for it in the Packages folder
and then you edit it through the project
Yeah, well now I've got a Project called "Unity" in my hub... That'll be easy to remember!
Also this
it's not the greatest name, I could probably rename the folder to something like LFOUnity
Expected?
because it doesn't have KSP2 imported, yeah
OK.
this is really annoying but there's not much we can do about it
you may have to do some shuffling around to get ThunderKit to show up
LFO depends on KSP2_x64, but obviously we can't put that on GitHub, so there are compile errors when you clone and open the project
So, for my local copy, it's safe to install TK, import the game, etc.?
And that won't mess up the repo?
Seems like TK is installed, it popped up the Settings dialog
ah great, that makes things easier
sometimes TK doesn't pop up because of the compile errors, and you have to take the lfo.editor package, move it out of Packages, import KSP2, and then move it back in
So, I'm seeing LFO Editor Tools int he Packages. I thought things in Packages are RO.
RO?
oh
well usually packages are not actually in the Packages folder
this one is
because the project is the source of the package
so nope, it is not read-only
because it's not just a cached remote package, it's a local one
OK, I was able to delete the old ones and drop in the new ones, but they look rotated by 90deg
The ones I found in there were all horizontal.
well what happens when you drop them into the scene?
I'm concerned I might have messed something up, but OTOH I know that in Blender I can import these and the stock .obj's and they're oriented the same
Looks horizontal to me!
Hi, I'm Hugh. Hugh Jass. Pleased to meetcha
well then, you can try to build the bundle and drop it into your game, and see if they work fine
or send the bundle to me to test with SORRY
since I have various vessels and save files ready for quick testing
Presumably I need to install KSP2UT then
no
just build the bundle
from the Assets menu
KSP2UT messes up the project, because it usually prevents ThunderKit from working when KSP2 is not imported
it's only really needed/useful for parts
Hmmm... Need to import the game looks like
Are we OK to do Include Everything again?
no, that still doesn't work
at least not in the main TK repo
Cheese has a hotfix in her fork, but I didn't want to add a dependency to a fork
yep
There are a lot. 999+
huh?
Should be 666 I think...
hide the warnings, seems like there are also 5 errors
There are a lot of these hash conflicts
The errors are the old ones
I'll clear the log and rebuild
yep, thanks!
Now it doesn't build. Like nada. No errors, warnings, or anything.
is there an old built bundle? if so, delete it
it doesn't rebuild if there are no changes
Where will it be?
Delete in Unity or in file explorer?
it doesn't matter
'cause it had no effect deleting in file explorer
There's a 25MB file from 11:14 am in there
ok and if you delete the whole AssetBundles folder?
That got it moving
alright, finally! 😆
Sorta...
oh god
It created the folder and put stuff in it
But there's nothing in the Addressables Report and nothing in the console
alright, that seems like the normal amount
it's just some inefficiencies in the shaders
I didn't want to mess around with them for now, when it works
Like this stuff?
yeah, exactly
There you go then. A test bundle.
I'll be happy to test it as well, but most likely it needs to be tested with SORRY engines.
yeah, those most notably make use of those meshes
it seems like you didn't add the new meshes to the bundle
I prefer to call it "gaining experience" 😆
LOL, if you say so!
<- slow learner
Here in 'merica we say "rides the short bus", but I'm sure that it would be insensitive to imply that I measure up to that standard.
There was a guild in WoW called "Rides the Short Bus"... That was a lot of fun to see under a character name
😆 never heard that one before
Now what about this issue?
I've put the meshes into the proper folder, made them part of the bundle, and still my GitHub doesn't see them in that folder?
ah alright, so seems like .vsconfig needs to be added to the .gitignore
it's a whole different repository, remember
LFO.Editor
not LFO
you should be able to see it by opening the Packages/lfo.editor folder in GH Desktop
Ahhh... I thought we'd already established my bus?
I'll yank them out of the blender folder, then push
wait with that push
I still see one .fbx checked, that's one thing
also we probably don't want to push all the other files below
the project and TK settings
and I have no clue why your packages-lock.json is different
How about this? Just the new blends
yeah, that would be ideal
And maybe the .gitignore needs some fresh love
well, most of the ones that are unchecked are supposed to be in the repo
but there shouldn't be any need to update them
but the .vsconfig folder should definitely be added to .gitignore
ahh I see another issue now that I'm testing with SORRY
QA!
I can change those, the stock one's have bel_j_xxxx
I'm not sure what j is for. I assumed jar
also one of them has a capital J in the bel_J_1 in the mesh name
but a lowercase j in the file name
by the way the originals had "bell", I double checked
Do you want the exxact same names?
I had assumed that since we're different we'd have at least slightly different names.
definitely not, but it makes more sense to keep it a real word 😆
Would you like it to be just bell and bell_p2 then?
I'm really annoying today with all these requests and corrections, aren't I
Nope, not at all!
eh I'd rather not change it now
since it's already hardcoded in C#
Oh that... Picky picky picky
basically I have a dictionary that maps the old names to the new ones
so that plumes made for older LFO can still work
What should I be saving this unity project as?
that's just a scene, not a Unity project
and you don't need to be saving it at all
whenever there are some changes there, I just do this
since we don't need anything to be in the scene in the repo
The only issue with that is that where you have SampleScene* I've got Untitled* and so Discard changes is grayed out for me
In other news...
huh why do you have an untitled scene at all
you should see the SampleScene under Assets/Scenes, right?
Cause I dropped a mesh onto the scene to see if it was horrizontal or vertical
that doesn't really answer the question
since I do that as well, but in the SampleScene
not a new untitled one
Ha! I got around it!
I double clicked on Sample Scene to open it and that let me discard the changes
basically, there always has to be an open scene, so you should just be able to discard it by opening SampleScene
yeah, exactly
If this bundle works then it will mean there are at least two (or three counting Cheese) who can readily build and export the lfo bundle.
There is safety in numbers! And you are worth 2 or 3 at least
Did you ever play the old Baulders Gate game?
nope, I've only played BG 3
There was this big strong character (don't recall the name) who had a pet giant minature space hamster (a real hamster, but that's not what he thought), who would say "there is safety in numbers, and I'm worth 2 or 3 at least". And you know what, he was!
😆
guess what
I also had a bug in LFO
[Error :Lux's Flames and Ornaments] Couldn't find asset vfx_exh_bell_j_01_0
I was missing the _0 in my dictionary
The hamster's name was Boo!
I guess it's time for LFO 0.10.1
oh that's adorable lol
if you haven't played the new Baldur's Gate 3, I strongly recommend it
one of the best games I've ever played
I haven't actually. I should play it. I've heard good things!
Wow... I don't get it. I imported both the new one and the stock one and they were oriented, positioned, and scaled basically the exact same
If it's wrong, it's on me.
But... how?
check your meshes for these settings
(when you click on the mesh in the Meshes folder directly, and scroll down in the inspector
they should look like this, with 0 rotation and 1 scale
There are import settings in unity that will try to automatically fix orientation of meshes. And then theres the options in a blender export that also try to do the same.
yeah, as expected
I think the best practice for unity is to turn off the Y-Up setting in blender(so blender gets to use what ever its orientation is), and let unity try and correct the orientation
Or vice versa
But not both
I could see that fixing the orientation, but why is my scale wonky?
Is the scale in unity wonky? Or the scale in blender?
Unity is wonky
Cause unity also has a convert scale button that will convert real measurements into unity units. This scale depends on the scale set in the blender mesh
When I import both the FBX and the stock game's OBJ files into the same empty blend they are scaled and oriented just fine
I hope you don't mind if I get back to something else for now, since we've already spent 3 hours on this
and the version we had before works fine
Sure. No worries. Eventually I'll get these blends to make FBXs that work straight out of the box
And when you export them, is there an option to set a scale?
Cause and fbx export and obj export will have different settings
Interesting, there is this
yeah, I did have to uncheck that for my fbx files
but also it makes no sense, 1cm is 0.01m
(Also that bake Axis Conversion button the orientation import setting i mentioned earlier)
Try switching that on and off
And what are the export settings for a obj?
Hmm the scales are normal in blender. Which probably means you've got the "convert units" option turned on when importing to unity
This could be different per mesh type
well the obj files we are using for comparison were not exported by us from Blender, they were extracted from the game's assets
so who knows what export settings they used for them
For importing into Unity all I did was darg and drop the fbx's into the folder
Ah, i see. Then OBJs are most likely already in a proper unity scale
The fbx then needs to be converted to the right scale. Either through the import setting or changing the scale of the mesh in blender. (I would reccomend doing this on the unity side)
I think that's just a matter of unchecking the Conver Units box
Give it a shot
This version has both Convert Units and Bake Axis Conversion OFF
it's interesting that the file size keeps changing by a couple of kB
Its probably the extra information from. The convert units, and bake axis conversion settings
This version has Convert Units OFF and Bake Axis Conversion ON
For reference, the previous version I posted had Convert Units ON and Bake Axis Conversion OFF. #1092613573290754108 message
LOL
Lmao
Those look a tad large...
actually I think the size is right
the orientation is wrong
I'll try the second bundle
well that changed nothing
so the axis conversion doesn't seem to have any effect
Hmm, can you make sure that the axis conversion option is actually checked
I'm not sure if the settings travel with the mesh or the meshes .meta file
Huh
I clicked the box and hit apply for each one
I meant @brittle tendon
I'm just dropping the built bundle into the game
Ooh
Nvm then
Huh weird
Looks like each child/sub mesh is being oriented in world space. Maybe adjust the settings from blender? Try "Apply Transforms"?
the files each only contain one mesh, and the plume is composed of multiple of them
Oh, how does the plume work exactly?
I did apply scale and rotation, but not apply transforms. I can do that real quick
Is there anything you recommend I do with the Up setting in the Blender export?
basically it's composed of a hierarchy of objects in Unity, you can add as many meshes as you want, choose the appropriate shader for each, toy with the shader parameters until you're happy, and then a JSON config file is exported for the plume, dropped into the game, and the mod then recreates the plume hierarchy and appends it to the engine's root "plume" object
Um, usually i wouldnt touch it, cause theres all sorts of issues that can come from messing around with the orientation. But maybe try and set them back to there defaulta
They are at default. I've never messed with those settings
I'm going to give it a go with just the Apply Transforms done in Blender and see what they look like in the Unity project
Ah i see. Ok, then the axis conversion should remain off, cause the game will handle the orientation of the little cones
for reference these are the settings from other custom meshes in the project
Yeah try this, if that fails, try removing any rotation from the cone models, so that the rotation should say 0,0,0
however the ones that we have replaced with the new ones were the game objs, so the import settings could have looked different
OK, so I did one, and it came in like this
If I place it in a scene though, it orients like this
yeah, but the game ignores these position/rotation/scale parameters
so it's important that they're at 0, 0 and 1
Why are they not though?
I would like to know that, too
When i export fbx from blender :
- Rotate -90 to X
- Object -> apply rotation
3 rotate 90 to X
Then export fbx
I've gotta head out, hope this gets figured out. Converting of axis and scale units has always been and will always be a pain. Good luck yall
though for example Lux's Flames mesh also has those wrong:
and it shows, because when you're making a plume with it, it's oriented incorrectly and you have to manually rotate it back
I'm gonna try Jim's approach and see what I get, although I'm really puzzled by the whole scale thing
there's actually a lot of weird rotations happening in general with LFO
but we can't really go back and fix it without breaking current plumes (even more)
Success! Maybe...
I'll do the others this way (thanks Jim!) and we'll see soon enough if this sorts the rotation problem.
except it's not supposed to be oriented that way
Sure it is.
(if that is the current one)
You mean in the scene? I think it should be
My engines are all oriented like that with thrust pointed down
I mean it should but the obj wasn't like that originally
which means plumes are not made with this (correct) orientation
The object was originally like this, right?
yeah
oh...
Wacky, huh?
jesus this is such a mess
how come it was so easy for me to fix the ones you originally made
I simply imported the fbx into Blender, changed units to cm and scale to 0.01, exported, and then in Unity I unchecked Convert Units
and that was it
and it works fine
no rotation issues or anything

I call this one El Beuno!
no bueno...
We can try the same GD trick with scale then. How about I convert the model to use cm?
I bet that's what it needs.
you can try
but it should be possible to get this working using whichever units you choose
it should just be possible to apply the new scale in Blender
and have the mesh itself scaled to 1x
Didn't that get solved by me unlicking the Convert Units?
At one point the scale was OK. Let me do that rn and try again.
Though I suspect the more long term solution will involve changing the blends to be in cm.
there we go, finally
Converting a blend to be scaled in cm gives this when I bring in the FBX
to export fbx with correct units for unity
That's with Convert Units checked
This also works (as it appears in the Unity project)
I'm going to do this with the others, then rebuild the bundle
If it puts this problem behind us and establishes a documented path forward, then it was time well spent. Behold! I present to you Tiempo Bien Gastado!
yeah, that works
alright so I recreated the hierarchy of the SORRY Raptor plume
and managed to load the JSON config into it
safe to say that there is no difference in the shader between the game and the editor
the shader is just incorrect/unfinished
or
it' just new and the old plumes were supposed to be remade
(the sizes and positions of the elements don't match because I'd have to do that manually, but the general shape is the same as in the game)
one thing I want to do is enable the loading of the full plume, including its object hierarchy, all the objects' positions, rotations and scales, and all that, from an existing JSON config
Almost looks like an expansion ratio somewhere was set to be negative instead of positive
because currently the way it works is that you have to have the object hierarchy already fully created, and have to set up the position/rotation/scale of every object manually, and add all the components to all the objects
and then you can press "Load Config" and it just loads the material properties from it
I think it shouldn't be too difficult to make it so that it instead creates the full plume for you
it's more like the min-max scale is wrong
I took an already existing SORRY plume
and the linear expansion is set to -1 on the main mesh
but that worked well with LFO 0.2.1 and the older shader
it's possible that the old shader was "broken" and this one is working as intended
but in that case, plumes will have to be remade
Can you send me a unitypackage of that prefab
I want to mess with some stuff
getting a bunch of NREs
with LFO and KSP2?
Yep
btw this one I unchecked "include dependencies"
but it looks to be the same size so idk
what line is that?
wtf
I see FloatParam.cs
Thats the line its actually referencing
idk but double clicking on it brought me to the mastergroup
weird
I see what happened
but yeah that makes sense, since materials are created programmatically and assigned directly to the objects
it didn't apply the materials corrrectly
not actually saved to files
so the object will have references to non-existing materials
So can you send me the config?
you'll still need to create them all manually probably but sure
the config only applies values to existing materials
When attempting to load the config
(I added a material instance ot every child beforehand
the plume is not really complicated to recreate anyway, I just created this object hierarchy, where Engine is just a cube cube, thrustTransform is simply moved below the engine, Plume is an empty object with the master group component, and then Screen and all the Scatter objects are just unpacked Flame prefabs, Mach 1-3 are unpacked shock_1_pt2 prefabs, and Bell is an unpacked bell_p2_1 prefab, and these all need a LFO Throttle Data component, where you click New material instance
ah, well that was easier than I thought it would be lol
do a search+replace for LFOAdditive 2.0, replace it with LFO/Additive
in the config
that's another thing I'm adding to the editor scripts, being able to load the shader from materials and shaders
just like the runtime can
the Editor is severely lacking in features that exist in the runtime
Now I have the issue of the Mach 3 scatter being way too big
Scaling that down helped
like I said, none of the positions/rotations/scales are correct
since that info isn't loaded from the config in the current version
But yeah, that is wrong in the editor
I wouldn't even say it's wrong
it just has linear expansion set to -1
so it makes sense it looks like this
it looks fine with values ~0-1
I think the fix for this is to just remake the plumes that look wrong
for example Kesa plumes look just fine, because I'm guessing they were remade with the newer (0.9) version
and to make remaking existing plumes not as tedious, since going from older LFO to current LFO breaks everything in the editor, I'll just add a button to (hopefully) completely re-create the plume from JSON
and then the few wrong values can just be easily readjusted
Setting the linear expansion to zero in the throttle data while keeping the same curve looks aight
yeah
I still need to plan out the KSP2UnityTools/LFO integration, and also how to ignore files, which is actually quite simple
I want LFO to keep its stuff in its bundle so it doesn't mess with addressable groups itself, so at the runtime it will load either from its bundle or addressables
I don't even know if it wouldn't be better to keep all that functionality in LFO itself
(except for the ignoring stuff)
Well, KSP2 Unity Tools sets up a custom addressables group for everything
And for asset deduplication it makes sense to have the plumes keys be like {mod_id}/plumes/{part}.json
yeah it does
I just wish KSP2UT didn't mess with ThunderKit when KSP2 is not imported
LFO also depends on KSP2 code but it doesn't seem to break it
when you clone a project that has ThunderKit and KSP2UT installed as a dependencies, ThunderKit will not load and you're not able to import KSP2
at least whenever I tried
because of the compile errors presumably
but LFO doesn't do it
even though it also has compile errors
so you can go and import the game and everything works fine
usually
with KSP2UT, you have to uninstall the package, import KSP2, and reinstall it
I hit the issue when I added KSP2UT as a dependency for my LFO project
so I removed it
Alright, I'm going to try myself
it's why I originally told you that Unity templates won't work
because I noticed that you can't import KSP2 when KSP2UT is installed
but then I saw that it's not the case always, since with LFO it was fine
I removed KSP2_x64 as a package from my own KSP2UT testing project
now lets restart it
I can't guarantee it will always happen, since I didn't test it extensively, but it definitely happened the few times I tried
It works fine for me though...
bruh
now I can't replicate it either
but I swear to god it happened to me at least 4-5 times
with various projects
no TK menu, no TK window
oh well
let's just ignore that lmao
I'll let you know if I encounter it again
but for now I guess it's ok
Alright
In that case, can you review my PR for KSP2UnityTools
sure
Wait
btw I think you skipped a version
I did a dumb
I did not
I bumped the version in my editor
but ehh I need to fix something rq
this was the version I just installed from main
that's why I said it
ah yeah, I see
Ohh I named it 0.6.4 in the pr, but 0.6.3 in the package.json
Rider used to correctly inform about stuff that wasn't available in the current Unity version of C#
but now it doesn't seem to anymore
I also had that thing with file scoped namespaces happen multiple times, when they don't work in Unity
idk why it no longer recognizes that
I am going to set rider to force block scoping
yeah, that's what I did, for the specific project
But anyways, that PR should actually be right now
also I'm going to comment out the KSP2 Builder GH action in LFO for now
since it doesn't clone the submodule and thus doesn't work
Hmm, one thing with loading from addressables ... if we put textures and such in addressables, then they won't be loaded properly in the editor when loading a config
hm why not?
the files still have to be in the project somewhere
and the search is done by name
in both editor and runtime
at runtime we just need to load everything from a specific label, and then find the asset with the correct name among the loaded ones
and in the editor, it's just about doing AssetDatabase.FindAssets("name")
(and also checking the type, since there can be technically multiple assets with the same name, but different type)
such as a shader and its material
I don't see a problem though
Darn I was already pushing something to dev
Though all I pushed was having it reference KSP2UT, and then changing the load json button to be a lot more usable
Aight, time to fix what you just pushed
Hy. Everything works fine. Great work guys. Mods updated with unity2022 and LFO 0.10.0
When i edit curves for engine, i can't edit values. I have to move dots manualy. It seems to be general with all curves edition. Is it same for you ?
Yeah they changed the curve editor since Unity 2020, to edit the values of the key you have to: select the dot by drawing a rectangle over it and then press Enter it'll allow you to modify the x,y values
Thanks Safarte
very interesting
seems like this particular bug only occurs when there's more than one active engine
oh and not even that, it looks like it may be specific engines that trigger it?
aaand I got it figured out I guess
it's only SORRY engines that do this
and the SORRY engines also have all the objects, components and materials directly on the prefab, which they shouldn't
alright, not all SORRY engines, the only ones I see this happen with are the sea level Reiptor, sea level Kheap and the Mk2 double-nozzle engine
and I can confirm it's not related to the "Error assigning 3D texture to 2D texture property" errors
soo that isn't the cause either, since all the SORRY engines have this, and only 3 of them break the shaders
this would be much easier to debug if I could see how the SORRY prefabs are set up
I mean I can in Asset Studio
but it's not great
also this makes me think the new shader is working like it's supposed to
since this is for one of the newest SORRY engines iirc
and its plume looks good, unlike the old ones
so the plume was probably created using the new shader
and the older ones were either not tested, or Lux was planning on updating them
SORRY also demonstrates really nicely why having the plumes in addressables is important - if they were, we could just release a separate PM patch for the SORRY plumes
without Lux having to update the core mod
alright, the first half of the addressables support (the editor side) is done
the KSP2UT API makes it dead simple - just needed to call the AddressablesTools.MakeAddressable method
thanks for that @grim bridge!
You are welcome!
one thing I've noticed that happens when I call that method is that in the Addressables Groups window, the label appears as crossed out, if it hasn't been used before, but unchecking and checking it again in the dropdown gets rid of that
is that expected?
Ahh no
I can fix that tho
I was wondering what would happen if I add a label that isnt defined yet
I couldn't even find anything about it online
Because technically the addressables API is undocumented :3
hm
[Error :Lux's Flames and Ornaments] Failed to load assets from lfo_assets: UnityEngine.AddressableAssets.InvalidKeyException: Exception of type 'UnityEngine.AddressableAssets.InvalidKeyException' was thrown. No Location found for Key=lfo_assets
i have my catalog/settings/StandaloneWindows64/AddressablesLink in LFO/addressables, as usual
and all the settings look correct afaik
I used the group created by KSP2UT
do I need to add a custom loading action or something?
I don't really need to pre-process the assets in any way, I just need them accessible through Addressables.LoadAssetsAsync
You shouldn't?
weird, as far as I can tell, the structure, location, the catalog, the settings, everything looks fine (and equivant to those of other mods using addressables)
oh duh
I'm trying to access the addressables in OnPreInitialized but SpaceWarp loads them later

aaand done
addressables support finished
reworking the entire asset workflow in LFO previously made this change extremely easy to implement at runtime
just need to make a test mod with addressable assets and configs to test that part out
How does it deal with deduplication against the builtin bundles?
but I'm pretty happy with the progress, 0.11 so far includes a dropdown for shader params in the FloatParams editor, the option to completely create a plume from a JSON, and addressables support
does it need to?
and if so, how? 😅
2 assets can't have the same key
why would they have the same key?
I did check the builtinshaders bundle and it contains nothing
shaders are all included in the main bundle, with their whole path, like Packages/lfo.editor/Assets/Shaders/...
everything that was in the lfo_resources asset bundle is now in the main addressable bundle
including the noise textures
And what if a mod wants to add noise?
then they add it, just need to use a different name for it than the ones included in LFO
the way I handle the adding of assets to addressables during the saving of the plume is that I go through the whole object hierarchy, gather all the mesh and texture names, then find their paths, and if the path begins with Packages/lfo.editor, it's ignored
otherwise the asset is added into addressables
I could theoretically do something like add a prefix for the asset names in the addressables, like lfo-*
so that they can't conflict with other non-LFO assets
Gotcha
Well shit, we might wanna start working on a PM addon for this now
It can still load json files the old way as well right?
I really need to be 100% sure that the addressables loading actions run after all the PM stuff
which means I might need to do some PM shenanigans
yep
the plumes in the screenshot are loaded from JSON
haven't actually tested loading the JSON from addressables yet
I'll make a plume for the Community Parts Pack engine to test it out, and add a custom mesh and noise for good measure
I'm gonna see what I can do in PM to make its actions the first ones
This is going to involve some reflection, or more accurately publicizing spacewarp
actually now that I'm thinking about it, instead of just directly loading the plumes from the JSON files, I could add a custom resource locator/provider pair and add even the old .json plumes to the addressables system
theoretically that would allow for the patching of even those old plumes
but then that would have to be done before Patch Manager stuff runs lol
That'd have to be done in PreInitialize
well, then that should work I suppose
I can try to do that
after I make the test plume mod
https://github.com/KSP2Community/PatchManager/pull/16
Anyways, this should also be reviewed
Actually wait
lemme fix one thing
This is necessary to ensure patch manager gets run and registers its locators before any other mod does
Alright, now lemme make that release
Hmmm, would it be a stupid idea if we create an LFO/PM addon to have an export as PM patch button?
it'd at least make the process of completely swapping out plumes a lot easier
it'd still have to put everything else in addressables tho
I mean I don't hate the idea, it would make the patching of plumes much easier
you'd just import a plume using the new Create plume from JSON functionality, change stuff, and then press Export as PM patch
and you could patch any existing plumes from any mod that way
Did you do the CPP test?
I had to go take care of some work stuff, but I'll finish dinner and get to it
Aight
No rush, was just curious if it worked
And once that is done mayhaps I'll start on a PM Addon for LFO
I was also kinda thinking
could we do kinda the opposite maybe?
basically allow embedding raw JSON into a patch
You already can
@set-value
that makes it really simple then
Raw json is a valid patch manager literal
That was actually unintentional at first
But it just came naturally from the syntax I was designing
Set-value was intentional though
I should add an @embed, but that would make caching weird
So no
alright time to try this out
[Error : Unity Log] AssetProvider unable to find assets with label 'lfo_configs'. these are so annoying, it's the same thing as the one with the localization label
(this is before adding the new plume)
Not much can be done about that
I mean
we could just not log that specific exception as an error
instead just make it an info message or something
in AddressableAction
we could even just do a check like this before the try block, and it it returns false, just info log it and resolve:
I suppose yeah
I'll test it and PR it to dev then
Did the test work
yep
Pog
You built your flame mesh ?
that's just the default Flame mesh from LFO with some noise on it, but I am adding a custom mesh, the purple part is just a default Unity capsule mesh
just to test out the adding of assets to addressables
Nice
(and of course I've already found a couple of bugs)
🙂 Never stops
Welcome to mr. bugs wild ride, the bughunting never ends
Someone d seen if xenon is integrated in natives resources in ksp2 ?
Xenon is a stock resource, yeah
Cool
alright yeah the prefixing of the assets is a must
this will obviously not work
I just changed the code to save and read the LFO assets with the prefix "lfo/"
Definitely nott
that should hopefully prevent any conflicts
and I will definitely recommend to also prefix the name of any custom assets with the name of the mod, similarly to parts
so that two mods don't add the same "Capsule" mesh for example
I was thinking of having the editor automatically doing the prefixing
{sanitizedmodid}/{asset}
It shouldnt be hard to reverse that at runtime if need be
so upon saving, it would go through all the meshes from Assets that are used in the plume config, and rename them?
ah
I mean, that could also work
it shouldn't theoretically cause issues since mod IDs really shouldn't be changing
actually, thinking about it, that would make things pretty difficult
currently all assets are simply cached in a dictionary with their name as key
and while we probably could just store them with the mod ID prefix, it would also mean that the prefix would have to be part of the name of the asset in the configs themselves
oh nevermind, it doesn't even work like that
I didn't realize that when you load addressables from a label, you don't get to know their addresses at all
you just get the asset name, which has nothing to do with the name in the addressables group settings
so we really will just need people to name their assets with the name of their mod as a prefix or something, because the address setting won't prevent collisions of assets of the same name
within the lfo_assets label
alright, we've officially got addressable plume configs with custom addressable assets
there are some obvious issues with that plume, but it wasn't made to be actually used anywhere, it's just a test of the system
overall I'm very happy with where LFO is right now, so I think it may be time for a 1.0.0 release pretty soon
next step before the release will probably be to write documentation for this
Hmm, then maybes I can use this to fix LFOs plumes using patch manager (if you do the thing where you put json plumes into addressables)
I mean SORRY's plumes
yeah, that was really my main reasoning for that feature
I have some work stuff I need to finish today, and work all day tomorrow, but I'll try to take a look at it either later tonight or tomorrow after work
it shouldn't be too difficult
alright, it seems to be working, though I'm not 100% sure if it's done in time for Patch Manager to patch the plumes
but it probably should be?
the plumes are registered as addressables in an action added through Loading.AddAssetLoadingAction in Awake
and also the one plume that is actually in addressables seems to be loaded twice for some reason
(though it just means that the 2nd time will overwrite the 1st time)
I'll push it to dev anyway, since it seems to not have broken anything so far
You said its being loaded twice?
Where did you build the plume to
Did you put it under plugin_template/assets/plumes?
no
it's only in the addressables
you can see here that it's definitely not coming from the file system, since it doesn't have a full path as its name
Hmm, it is being loaded twice for some reason
yeah, and it's the only thing in the addressables with the lfo_configs label
Can you send your ksp.log?
here's both
It only calls the loading action once ... hmmm
Are you sure you didn't accidentally put it into 2 groups or something
same
And the addressable action just does a load by label with the game ... hmmm
When this in LFO 
Gods I cant imagine the work needed for that, to combine multiple plumes into one
Cheese just look at these mach diamonds Cheese do it for them
I mean it would be relatively easy to make with current LFO if someone made a single SH engine, like in Starship Expansion Project
wouldnt it be very difficult to have it behave realistically though, since the inner 13 engines can all gimbal independantly?
Tundra and SEP for KSP1 both have single engines with 9/33 nozzles
and they all gimbal correctly as they should
Is LFO for v.1.5 out yet?
#1170561870026002433 message
We should release the version with addressables
ah yeah, you're right, I should probably just do that
though I feel like I'd rather do some more testing first
considering that weird asset duplication bug
and the major architecture rewrite
maybe a prerelease?
well fuck me, I just spent like 30 minutes typing up a detailed changelog along with instructions for the 1.0 prerelease
and then I fucking misclicked and left the GH page and it's all lost
lmao
I am so not redoing that tonight
is there a new dev kit for making plumes for the new version?
the Unity package is already at 1.0 on the main branch, since I was going to release the 1.0 mod as well yesterday
so I might as well just do that now
install from Git URL https://github.com/KSP2Community/LFO.Editor.git
also have to delete the old LFO folder
in your project
and existing plume components will almost definitely be broken, but that's why I added an option to fully create the plume object hierarchy from a JSON config, so redoing it shouldn't take long
at most you should have to move/scale/rotate the root plume object since LFO doesn't know anything about your original transform
Thanks
I hate that I lost all the text I was writing yesterday because it explained everything in detail

this is so sad
I was going to write docs and then release 1.0
but I'll just do the opposite lol
since plumes made with the new editor (if using addressables) will only work with LFO 1.0
(old plumes will still work as well though)
i gotta make new plumes since my old ones are distorted
yeah, Lux either updated or rewrote the mesh additive shader for 0.9
so old plumes don't look great, the issue is mostly with the linear and quadratic expansion parameters from what I've seen
well, not sure if I'd call it "issue", I feel like it makes more sense the way it's set up now
but we don't have the source for the old version of the shader so there's no way to compare the code
it is done
1.0 is released
now let's just hope I don't get a flurry of bug reports lmao
i would image it could either be, a set of 3 plumes for different states, like a plume for each ring, and then a combined plume. or if you really wanna get crazy, some light raymarching for each plume
I'm pretty sure raymarching was what Lux was working on
but since I kinda took over this project (at least until Lux is hopefully back), guess I'll have to learn shader programming and all these techniques lmao
that's going to be fun, coming from a place where I have like 0 experience with graphics 
oof, good luck. you know about the youtuber sebastian lague?
yep, love his videos
dope, then you already know about his raymarching vid(s)
yeah
graphics is fun........after you've gone through the hell making it work. It looks pretty!
guess my uni linear algebra course will come in handy now lol
oh yeah it will lmao. 3D math is vital to a lot of game programming, especially graphics. Did your linear algebra course cover matrices, and quaternions, and transforming vectors?
not quaternions, but other than that it was pretty in-depth (and also the course with the lowest passing rate of the whole software engineering program, at like 15%
)
oooof
yeah, for games the only thing you really need to know about quaternions is that they rotate stuff good
anything more would require a math degree
Quaternions are fun
4 dimensional complex numbers
Just do everything with transformation matrices lol
woo hell yeah
I really like this talk to understand where quaternions come from mathematically: https://youtu.be/htYh-Tq7ZBI
..or can you? A deceptively simple question with a complex answer – come join a mathematical journey into madness and wonder, in search of answers that might just give you a new perspective on the mathematical constructs we use in our games
Recorded at Dutch Game Day 2023, October 4th
Timestamps:
00:00 Intro
04:34 Talk Start
05:17 Anatomy of a...
I mean ive watched that video yeah
nice, thanks, I'll definitely watch it
And quaternions do actually describe certain 4x4 matrices
are there configs for the vanilla engines?
nope, it would require some extra work in removing the stock engine plumes, which I haven't gotten around to
any documentation available on controllers (like atmoDepth or throttle) and exporting plumes?
I don't think Lux has written any docs for this, and I haven't gotten to it yet (in addition to not even completely understanding everything 100% yet myself)
but I can try to assist
i will probably need that help when i get back from my trip
i need to make new plumes since my old ones are not working properly in the new LFO
yeah, Lux made some changes in the shader in 0.9 before he took off
but it should only be a matter of changing a "-1" to "0" in one spot
Well, the LFO editor import has now been changed to an actual Unity package installed in the Package Manager, and most of the backend and editor stuff has been rewritten
but
I added a button for "Create plume from JSON"
so even though the old plume objects won't work with the new LFO version, you can just import your JSON plumes back into the editor with one click
and then just fix up the number stuff and correctly rotate/scale the plume (since the exported JSON has no fields for the root transform)
it should be relatively straight-forward, I tried to make the "remaking" process as simple as possible
nicee
and then you just click a button to export the plumes and you'll get the addressables to put into your mod folder
(new plumes are in addressables instead of just in JSON files)
it allows other people to patch your plumes with Patch Manager if they want
where is this button?
When you right click on an object in the scene hierarchy (for example your thrust transform), there should be a for LFO
Under create or something like that probably
I'll take a look at soon as I get to my computer
by the way, you will need to delete any old LFO files you may have imported into your project
I think it was just a folder called LFO
and add the new Unity package
in Package Manager, add from git url: https://github.com/KSP2Community/LFO.Editor.git
@eternal robin here's a video that should hopefully help with the whole updating process
thanks
the only thing I didn't show off at the end is that when you are done with all of that and have the plume file in your addressables group, you can simply delete the old assets/plumes folder, and just rebuild the addressables and replace the old ones with the new version, since the plume will now be in them
though, if you do not have KSP2 Unity Tools set up like this, you'll want to do that first (the window is in Tools -> KSP2 Unity Tools)
you can import your swinfo.json instead of typing it manually
and after setting that up, when you click "Set Up Addressables From Mod Info", you should get a new addressables group labeled with the name of your mod below the Default Local Group
you'll want to move all the assets from the default group into the new one
(not sure if this is something you already have or not)
oh and another tiny thing, at first I accidentally clicked "Save plume" before unchecking "Don't use addressables", that will simply save the JSON file into plugin_template/assets/plume_name.json, and we don't want that
@final plaza
nice