#V-SwiFT
1 messages · Page 2 of 1
The patch:
@use "VSwift:*";
:parts #KLSS_storage_0v_radial {
@include part-switch() {
+TankType {
VariantSetLocalizationKey: "KLSS/Variants/TankType";
+Food {
VariantLocalizationKey: "Resource/DisplayName/Food";
+TransformActivator {
Transforms: [food];
}
}
+Water {
VariantLocalizationKey: "Resource/DisplayName/Water";
+TransformActivator {
Transforms: [water];
}
+ResourceContainerAdded {
Containers: [
{
Name: "Water";
CapacityUnits: 45.0;
InitialUnits: 45.0;
},
{
Name: "WasteWater";
CapacityUnits: 45.0;
InitialUnits: 0.0;
}
];
}
+ResourceContainerRemover {
Containers: [Food, Waste];
}
}
+Oxygen {
VariantLocalizationKey: "Resource/DisplayName/Oxygen";
+TransformActivator {
Transforms: [oxygen];
}
+ResourceContainerAdded {
Containers: [
{
Name: "Oxygen";
CapacityUnits: 0.015;
InitialUnits: 0.015;
},
{
Name: "CarbonDioxide";
CapacityUnits: 0.015;
InitialUnits: 0.0;
}
];
}
+ResourceContainerRemover {
Containers: [Food, Waste];
}
}
}
}
}
Check the logs as per usual, I havent gotten syntax errors into the log
But the issue is obvious to me
The semicolons after the name/capunits/initunits things
Those need to be commas as they are in a value, they are not statements
Oh thx I'll change that rq
(I got no errors in the logs and PM reports 0 errors)
PM syntax errors are a bit hard to see
I need to make them more transparent
But they are somewhat near the top of the log
ah yes indeed found them
nice! I still need to fix some stuff with wrong orientations, the water tank is weirdly dirty and also add the reentry meshes but progress!
Progress is good!
On the note of the weirdly dirty part
That may be a spacewarp bug on top of the disabled mesh
I dont think spacewarps color patches looks into disabled renderers thinking about it
Oh, so in the meantime should I enable all transforms in Unity and disable them in the variants to go around this issue?
I dont have a transform disabler set up yet
Ill fix the issue later todsy
So for now the shaders may be odd, but they will be fixed after I get to class
Roger that, I wasn't planning on releasing a KLSS update today anyway
I want to look into hibernation instead of death for Kerbals out of supplies for this update (as an option)
So how would the hibernation work ?
I assume it's not a part that with high EC comsubtion that can store kerbals without needing food ?
that would be nice/cool thought
How would we revive thoses kerbals?
Out of supplies => hibernation
Has supplies again => wakes up
It's just a softer penalty than death
And when in hibernation they can't control vessels or perform experiments
so supplies would have to be brought by docked vessel ?
no vessel control
depending on if you have a probe core or not
Let's move to https://discord.com/channels/1078696971088433153/1145349899777478759 however for the discussion
Thoughts?
(note this is a configurable option in the variant setif you want this popout)
What does "Unlockable" mean in this context?
Also the stats header backgrounds might look better with a blue-ish grey
Also might want to make missing techs red / orange to make it clearer they are missing
- I was going to change it to
Unlocked - Fair point
- Fair point
Hmm I have a feeling the "Requirement not met" / "Unlocked" indicators are a bit redundant with the list of required tech
The latter alone with a green / red font depending on if the tefch is unlocked might be enough imo (and would make the window more compact)
Also true, yeah
I'll implement stuff like that after lunch
and what do I need to do to prevent scrolling in the part switch menu from scrolling in the OAB
https://github.com/Kerbalight/WayfarersWings/blob/main/src/WayfarersWings/Extensions/UIToolkitExtensions.cs add this class extension iirc
gotcha
Here's what it looks like for displaying something with multiple engine modes
For another reference
Im thinking on this
I dont want color to be the only thing able to quickly differentiate, because R/G colorblindless is a thing people can have, so I feel having a text label at the top helps there
Ah true, didn't think of that, yeah the text would be better to have then 👍
Also, completely unrelated but here's a Gimp file to make 3-variants parts icons if anyone wants it
Yeah, one of my partners is colorblind in that way so it's something I think about normally when designing stuff
It was mostly meant in the context of something like a funds mod, where you need funds to unlock a part after unlocking the technology
With support for mods like Kapitalism in mind
@little sundial thoughts now?
My immediate thought is just to not show unlocked and the techs when it is unlocked
Looking nice!
Some other small thoughts:
- Maybe make the red text for the locked techs darker to differentiate them from the "Requirements not met" indicator
- For the stats body, this looks like the bold font, maybe the regular font would be better
- The "Currently Selected" button looks a bit weird? Kinda "raw"? Some margins and nice colors would go a long way imo
That could be nice, but then a player could not know how they unlocked a variant (unless the variants are displayed as icons in the tech tree)
I'm planning on looking into that specifically next
Plus theres still another way of seeing that
The parts stats window
Ohhh right, yeah those that are researched can go away from this screen then
I'm trying to think of how I will handle multitech things in the OAB window, but maybe that will be some form of 1/n display next to the + and when hovering over it will show the other tech names
Research window
aaaa
Here is the currently selected with a basically invisible border instead
Too dark
Yeah, also another idea: only show the tech requirements when the variant is selected in this window. When unselected maybe add a small red icon with like a crossed over erlenmeyer flask / science icon?
That's an idea I'll have to think about, if I continue I'm gonna get stunlocked with UI design for the moment
Something I'm not particularly great about
Yeah, I will switch away from the bold font first
Alright, I must go to class but I am going to work on engine switching stuff, then node switching, then scalar switching, then world domination
btw @little sundial if you find any breaking bugs in your testing, please tell me
In flight, non-default variant parts' colliders don't work
Here's the log file in case there's anything useful in there
Ill look at it later, for now can you use a common collider?
Yeah, will do for my internal testing
I think my only solution here is to work earlier
Right as the prefab is loaded
Luckily I know exactly what method that is
The internals of this mod are quite interesting I shall say lol
I still haven't dared looking at the code, a lot of IL wizardry I presume?
Yep
Plus a preload patch to add another field to the serialized part stuff
And I suppose im going to have to add one more
I don't see why
I really don't understand
Hmm, I could try one thing
can you describe the behaviour though?
@little sundial could you actually record what you are referencing
As there is zero reason they shouldnt' work
Yes will do, I'll also go over my Unity prefab setup one more time just in case
So ... the colliders are working but also not ... hmmm
Because if they weren't working then it'd fall through the ground
But like also the part hover code goes through all those colliders, no?
I suppose? This is definitely weird
I legitimately see no reason why in the code it wouldn't work
but I'll look into it more
How do you have your colliders set up in unity
foreach (PartComponent part in vesselComponent.SimulationObject.PartOwner.Parts)
{
if (!part.IsValidInSim || !spaceSimulation.TryGetViewObjectComponent<PartBehavior>(part.SimulationObject, out var viewObjectComponent) || viewObjectComponent.Colliders == null || (viewObjectComponent.transform.position - _mouseOverRayCastCamera.transform.position).magnitude > mouseOverRaycastDistance)
{
continue;
}
Collider[] colliders = viewObjectComponent.Colliders;
foreach (Collider collider in colliders)
{
if (collider != null && !collider.isTrigger && collider.Raycast(ray, out var hitInfo, mouseOverRaycastDistance))
{
_partsUnderMouseRay.Add(new KeyValuePair<PartBehavior, float>(viewObjectComponent, hitInfo.distance));
if (hitInfo.distance < num)
{
_partUnderMouse = viewObjectComponent;
num = hitInfo.distance;
}
break;
}
}
}
This is the code where it does that logic
the colliders are set including inactive ones
what's Collider.isTrigger?
Oh yeah just saw it's a editor set thingy
This is how the Colliders are set as well
wait
@little sundial your issue is the naming of your transforms
You have multiple model transforms
so its looking for the first one
and stuff is breaking due to that
Hmmm I'll try putting all three variant transforms under a single model transform?
You technically don't need a model transform
Because if it doesn't have a model transform, it'll just use the top level transform
though
using a single model transform is required for stuff like wheells
This system feels a bit "rigid" lol
I kinda don't like it
I don't like magically named game objects
oh god
This should be what fixes it though
but aaaa
the pitfalls
This should definitely be documented on the wiki
this works
then that should be the standard
Glad to have figured this out
this is some arcane stuff
someone knows what class is used for PAM ?
In what sense?
i'd like to refresh windows
i found how to do that for engineer stats windows (height, width, mass, ...) with Game.OAB.Current.ActivePartTracker.stats.engineerReport
but not found for PAM windows
Ok, found it : Game.OAB.Current.Game.PartsManager
Okay finally, an actual use for goto
SerializedModuleData FilterData(SerializedModuleData moduleData)
{
if (moduleData.DataObject is not Data_Engine dataEngine) return moduleData;
List<Data_Engine.EngineMode> engineModes = [];
foreach (var engineMode in dataEngine.engineModes)
{
foreach (var engineModeTwo in modes)
{
if (engineMode.engineID != engineModeTwo.engineID) continue;
engineModes.Add(engineModeTwo);
goto found;
}
engineModes.Add(engineMode);
found: ;
}
dataEngine.engineModes = engineModes.ToArray();
return moduleData;
}
public static T JsonClone<T>(this T obj) => IOProvider.FromJson<T>(IOProvider.ToJson(obj));
If you ever need an extension method to clone just about anything
Also aaaaa
I am definitely going to provide a very complex patch manager library for this once I'm done
alright, testing engine mode swiching
Gods
I kind of want to make a command to add an argument for KSP2 to load into a save on launch
y'know?
doesn't Falki's mod allow you to do that?
huh
hmm
I'd prefer passing the name of the save
as a command line argument
or the save file location
I seem to have caught a case of dumbass-itis
aaaaaaaaaaaaa
I broke something
I forgot to harmony patch stuff again
after switching between project types
and btw, you can definitely change the thrust transform between engine modes, the main issue there will be having to duplicate the old engine mode
hmmmm
somethings wrong here
Now im actually confused
I dont ever replace the part data in flight
Except at the point of deserialization
So why is ISP not changing
aaaaaaaaaaaaaaaaaaaa
there's another method that gets data
and this will be a bit more complex of a place to add stuff
but I think I have an idea
It's going to involve using the part provider for more than I bargained for
I'm going to have to add each used variant to the part provider
With IDs like
KLSS_Triple+VariantID1+VariantID2
This may actually be a better idea
but it involves ... yet another patch
Means that I can "cache" used variant data
This will either be legendary or completely broken
no in between
well
apparently there was an inbetween
of just nothing
I really need to prep for dnd
aaaaaaaaaa
but I'm so close
iuohpgftsrpuoighfewgijo;lhpgbsvfedalhkp;jfewqaklhoj;ufgqwaerkljbbnjk;ghrfeqop[irjgheyq3w
I fucking did it
I got the ISP doubled variant to load
holy shit
holy fucking shit
Real Fuels incoming 👀
This will be a great mod to release an update on tomorrow for the 1 year anniversery of ksp2 and this server
ah pog
attach nodes might be quite easy
The game has a concept of Dynamic Attach Nodes already
So I can likely just hook into that
Yay! That's fantastic! I suppose it makes sense that it would given engine plates and such things.
This also makes me wonder if there's a way to make fairings with interstage nodes! Not my next project - but with all that's happening in CommNext it could be really useful.
That said, it's probably time for me to go back to TNO and see what I need to do to V-SwiFT it. I'd like to get that ready and join the team for modders actively using V-SwiFT.
Well that's a new bug
Wrongfully created part icons for variants?
yep, it's a side effect I hadn't considered of each variant getting its own instanced part data in the parts provider when loaded into flight
I need to do some patching of the part provider rq
Is this all I need to do to make my parts V-SwiFT ready? They're already split into separate prefabs for the base and top, where the _open configuration omits the _top prefab
I'm thinking maybe these need to be addressables though.
I'd like to take a shot at making a dev build for TNO that (for now) has both nodes but makes having or not having the top framework a part selectable option in the VAB.
Yeah, what you need to do on the part that you want the variant on, is to keep the _top prefab, but disable it
Meaning disable it by default in Unity so that V-SwiFT can re-enable it, right?
yep
How does one disable a prefab in part. I've not done that before
Is it Toggle Active State?
Ah ha!
OK, so toggle the active state to off (un check it) and then save and make the bundle, then add a V-SwiFT patch?
yep
This may be kinda easy then!
Very much so
And if you are willing, can you send me a version of your mod with the top attach node removed and the original json for that top attach node
(Along with the variant patch)
I believe I can do that. I'm a bit rusty on making my own parts pack, so I'm working through the buildthedamnthing step right now.
I've got jsons for it with the nodes, those should already be available, so then the next step would be take that node off, build a version without the top node and send that to you.
yep
There's one. Do you need more than one or just a sample?
Screw it, take your pick!
Damnn the dart is exactly 1 ton
I've always thought it was a bit heavy for the performance. Needs to go on a diet.
As I said, some small changes
But most of that is from adding the UI stuff
Version 0.3.0 has been released!
@little sundial i forgot to test if klss still worked with this update btw
let's hope it does
I really need to make a forum post now
Now that multiple mods are going to be depending on this
I'd love these too!
There is a way to make parts with these, not really the purview of v-swift I think tho
Sure
I was giving this some more thought. I agree, this may not be a V-SwiFT thing. My possibly even simpler idea is to build what amounts to an inner fairing decoupler part. Grab your ordinary everyday procedural fairing. Start stacking as many interstage decoupler parts as you need. Attach your parts to the interstage decoupbler's nodes. Close your fairing.
I would say the latter would probably be more useful
I'm trying to think what I can actually change
Cost is likely easy enough
but only matters for like #1189139111206993950
I can actually change a lot of scalars, but I can't guarentee the changes will show up in the OAB
only in flight
That might be what I do
like sure I can change CoM
but it would be very complex to do in the OAB
and have the indicators be correct
temperature isn't even shown in the OAB
Anyways, now just need to set up the stuff for popouts with scalar transformers
For scalars that can change mass is obvious, but what about ISP? Or thrust?
Heat will one day be a part of it.
Resource capacity? How about an option that adds a battery and so you need to store EC?
ISP, thrust already doable with the engine mode swapper
resource capacity doable with the resource tank stuff
OK, some other crazy adds for scalar changes: Crew Capacity, Crash Tolerance, Heat Conductivity, Max Temp, Maximum Drag, Minimum Drag, Angular Drag, Breaking Force, Breaking Torque?
I have the stuff for each of those except crew cap
Oh, and of course Buoyancy!
I can't really change crew cap in the oab
I finally made that pesky thing called a forum post
https://forum.kerbalspaceprogram.com/topic/223839-v-swift-v030/
V-SwiFT Variant Switching & Feature Tweaking, a part switch mod for KSP2 Spacedock: https://spacedock.info/mod/3562/V-SwiFT Github: https://github.com/KSP2Community/V-SwiFT Author: KSP2 Community Description V-SwiFT is a part switch mod for Kerbal Space Program 2, it allows modders to make va...
Oh and another idea, though this one is probably slightly more complicated?
It would be really cool if you could specify in the patch whether the switcher should also be available in flight
Thats basically impossible
For example for the use case of the RCS/engine switcher
In flight is a very complex and different environment than in the oab
Could it be possible maybe at least for the module enabling/disabling switcher? I feel like that one could work by just having both versions on the part and one being enabled and the other disabled, no?
Of course, this would be a pretty niche edge case, I imagine, but I do know that it was a thing in KSP1 to some extent
Like, some mods allowed switching of engine/RCS propellant type in flight, or the switching of plumes
Alright
I'll think on this
Dont know if I can guarentee anything
Of course, just some food for thought 😆
hmm, how should I test the module property changing
Like what module has a property that can be easily visible when changed?
how about RCS thrust?
though, I'm kinda thinking RCS might deserve the same treatment as engines
with the window
Fair enough
That window is fully customizable and not necessarily for engines
there are other things that show when that window is set to show
like mass modification for example
it will show +/- x tons
Anyways, now time to finally test using RCS thrust
:parts #rcs_0v_block_monoprop {
@include part-switch() {
+EngineType {
VariantSetLocalizationKey: "VSwiftTest/EngineType";
+Default {
VariantLocalizationKey: "VSwiftTest/Default";
}
+Better {
VariantLocalizationKey: "VSwiftTest/Better";
+ModuleDefinitionTransformer {
BehaviourType: Module_RCS;
DataType: Data_RCS;
Key: maxThrust;
Value: 10000.0;
}
}
}
}
}
This can only go well
Hmmmm
It did not go well?
No
well
it worked there
but there are still some bugs
I think that's the expected result from that patch
I know what causes these bugs now
Its the stock module pattern
Or wait
Maybe
But the bug im referring to is in the oab
Where the advanced controls toggle for rcs stops working
This is the bug I'm having
I'm thinking I know why
spoiler: she did not know whyyy
but the way the issue manifests, makes me think this is a game buggg
also I need to do symmetry stuff
so hmmm
Also test
Or that I'm not resetting the PAM completely
can this be accesed by group manager ?
and also the part manager is accesible even when no com , this would basically allow you to do anything even when no comm
that bug should be fixed
OAB = VAB ?
no it doesnt
Okay, but the bug I'm speaking about
oh
is that the advanced controls are always visible after switching the variant
i thought you talked about this
Also this doesn't allow you to do anything
It allows you to do some things
But you aren't landing a probe with just the parts manager alon
Fixed it!
Now the thing I really want to do is sync variants in a symmetry group
oh this cant pitch yaw and roll on it's own ?
so not like control surfaces parts
@sonic lily would it be possible to "re-open" the part in PAM after switching variant? Having it unfocus the part makes it a bit annoying cycling through variants
Maybe, the problem is the PAM isn't built again till the following frame
You could try to open it from a coroutine after WaitForUpdate
How does the MaterialSwapper know which MeshRenderer it should apply to?
It applies to all mesh renderers on the part with that material
Ah it's a map
I see thank you
so something like that:
+MaterialSwapper {
Swaps: {
KeepOnTruckin_truck_tank_methalox_mat: "addressables://KeepOnTruckin_truck_tank_monopropellant_mat"
};
}
And I need to add that mat to the addressable bundle right?
yeah that should be it
I think something might be wrong with the material switching, it' using the colors defined in Unity for the paint instead of the ones defined in VAB. Some stuff from the Colors patch might need to be applied on, mat switching
hmmm, let me see if there is a reason
but I just copy properties from/to
I think I know what I should do
it'll be fixed by the next release
No, for your purposes you want to generate all attach modes dynamically
because
you need all the nodes to be dynamic for this to work
though I do have some ideas
to make this easier
So add them all in the variants with adders?
Insofar as being able to predefine nodes in the module part switch and have constructs to move them
yes
the issue is that you currently won't be able to switch with stuff attached without having to unnattach and reattach
Hence why I do want this capability as well
That capability should now at least be in dev
I'll explain how when I make this next release (likely tomorrow)
@little sundial can you send me a build of this such that I can do testing with both the module color stuff and attach node moving for this use case
A build of KeepOnTruckin?
Yeah, if you don't want to publicly share it just yet, just dm it to me
Yup give me 2s fixing some stuff
Take your time, gonna be busy for a bit
Note btw with this system, you wont be able to rotate nodes that are predefined (or hide them)
@little sundial
@use "VSwift:*";
:parts #KeepOnTruckin_truck_tank {
@include part-switch() {
PredefinedDynamicNodes: [
{
nodeID: front,
Size: 1,
VisualSize: 1,
Position: {
X: 0.0,
Y: 1.395,
Z: 0.0
},
Orientation: {
X: 0.0,
Y: 1.0,
Z: 0.0
},
},
{
nodeID: back,
Size: 1,
VisualSize: 1,
Position: {
X: 0.0,
Y: -1.395,
Z: 0.0
},
Orientation: {
X: 0.0,
Y: -1.0,
Z: 0.0
}
}
];
+TankType {
VariantSetLocalizationKey: "KeepOnTruckin/Variants/TankType";
+Methalox {
VariantLocalizationKey: "Resource/DisplayName/Methalox";
}
+MonoPropellant {
VariantLocalizationKey: "Resource/DisplayName/MonoPropellant";
+MaterialSwapper {
Swaps: {
KeepOnTruckin_truck_tank_methalox_mat: "addressables://KeepOnTruckin_truck_tank_monopropellant_mat"
};
}
+ResourceContainerAdder {
Containers: [
{
Name: "MonoPropellant",
CapacityUnits: 2.0,
InitialUnits: 2.0
}
];
}
+ResourceContainerRemover {
Containers: [Methane, Oxidizer];
}
}
+Hydrogen {
VariantLocalizationKey: "Resource/DisplayName/Hydrogen";
+MaterialSwapper {
Swaps: {
KeepOnTruckin_truck_tank_methalox_mat: "addressables://KeepOnTruckin_truck_tank_hydrogen_mat"
};
}
+ResourceContainerAdder {
Containers: [
{
Name: "Hydrogen",
CapacityUnits: 1.2,
InitialUnits: 1.2
}
];
}
+ResourceContainerRemover {
Containers: [Methane, Oxidizer];
}
}
}
+ForeTube {
VariantSetLocalizationKey: "KeepOnTruckin/Variants/ForeTube";
+Long {
VariantLocalizationKey: "KeepOnTruckin/Variants/Long";
+TransformActivator {
Transforms: [
"col_tube_fore",
"Fore Long Tube"
];
}
}
+Short {
VariantLocalizationKey: "KeepOnTruckin/Variants/Short";
+TransformActivator {
Transforms: [
"Fore Short Tube"
];
}
+AttachNodeMover {
MovedNodes: {
front: {
x: 0.0,
y: 1.23,
z: 0.0
}
};
}
}
}
+AftTube {
VariantSetLocalizationKey: "KeepOnTruckin/Variants/AftTube";
+Long {
VariantLocalizationKey: "KeepOnTruckin/Variants/Long";
+TransformActivator {
Transforms: [
"col_tube_aft",
"Aft Long Tube"
];
}
}
+Short {
VariantLocalizationKey: "KeepOnTruckin/Variants/Short";
+TransformActivator {
Transforms: [
"Aft Short Tube"
];
}
+AttachNodeMover {
MovedNodes: {
back: {
x: 0.0,
y: -1.23,
z: 0.0
}
};
}
}
}
}
}
(This is the patch I used on my dev version, I think I'm about ready to release it)
Nice!
Silly little creature
I can't wait to see it in KKY colors! (KKY are the initials of the character I use for pretty much everything)
@sonic lily when alt-click duplicating parts they do not have the correctly moved attach node
Hmm, I'll look into it
You can for now just toggle it
ah also the base/accent colors seem to switch sometimes
Now thats quite odd
All I do is call the refresh colors method on the module color
Not in flight tho
I should
@little sundial so the first issue is just me being an idiot and messing up the order of 2 lines of code, the other issue, can you tell me how to repro?
Uuuh I'm not on my computer anymore but you can try switching the tubes while in monopropellant mode and launching the vessel and teleporting with cheat menu
I have a fix for the attach nodes
and a tentative fix for the colors
I can't reliably repro but I did have some bugs with colors I fixed
Gonna put this into a 0.4.1 and wait for munix to approve
So now I only have conditional switchers and adding/removing modules on my todo list
One of those sounds easier than the others...
hy. You spoke about dynamic node. What are dynamic nodes ?