Add shared ModuleNameTag part module#23
Merged
Merged
Conversation
Copies kOS's KOSNameTag part module and its KOSNameTagWindow editor UI unchanged from the kOS repository (src/kOS/Module/KOSNameTag.cs and src/kOS/Screen/KOSNameTagWindow.cs) as the starting point for a shared name-tag module. This commit is a faithful byte-for-byte snapshot; it is not yet wired into the build. Subsequent commits adapt it for KSPCommunityPartModules. Provenance: adapted from the kOS mod (https://github.com/KSP-KOS/KOS), which is licensed under the GPLv3. See issue krpc/krpc#829.
Moves both files into the KSPCommunityPartModules.Modules namespace, removes kOS-only dependencies (SafeHouse.Logger becomes Debug.Log with a [MODULENAME] prefix; the camera helper and editor-building career gate are inlined so kOS's Utils/Career/Safe assemblies are no longer needed), and wires the two files into the (non-globbed) project file. The class name KOSNameTag and the persistent nameTag field are unchanged for now; a later commit renames the module.
Renames the part module class KOSNameTag to ModuleNameTag (and its files and the window/activation-manager helper types) to follow the KSPCommunityPartModules Module* naming convention and to drop the kOS-specific name. The persistent nameTag field is deliberately unchanged so it remains the save key; a Harmony shim in a later commit migrates old KOSNameTag save nodes to the new module name. User-facing strings are neutralized (window title and PAW group).
The window locked editor input with EditorLogic.fetch.Lock(false, false, false, ...), whose all-false flags never lock part pick/place, so clicking Accept/Cancel dragged whatever part sat behind the button. Use an InputLockManager EDITOR_LOCK instead, which includes pick/place, and pair a matching RemoveControlLock in Close(). The lock ID was also a fixed string shared by every window, so closing one open name-tag window released the lock for all of them. Make the lock ID per-window (keyed on the instance id).
Removes the isEnabled=false optimization and the NameTagActivationManager KSPAddon that existed only to re-show the field in the part action window after that optimization hid it. The field is guiActive already, so it shows in the PAW directly. The OnAwake duplicate-removal guard (kOS #2764, for parts that get the module added twice) is kept.
Adds a Harmony prefix on Part.LoadModule that rewrites a saved
MODULE { name = KOSNameTag } node to name = ModuleNameTag before KSP binds
it to a prefab module. Both the editor craft path (ShipConstruct.LoadShip)
and the flight path (ProtoPartModuleSnapshot.Load) go through
Part.LoadModule, so this single hook preserves tags from craft and saves
made with the old kOS/kRPC modules. The nameTag value key is unchanged, so
it binds directly once the module name matches.
The rewrite is skipped if a real KOSNameTag PartModule type is still loaded,
so an old kOS/kRPC or the retired standalone NameTag mod is not misrouted.
This was referenced Jul 17, 2026
Collaborator
|
Hey! Thanks for this detailed PR, it all looks pretty good on first glance but I'd like to have another look at it later when I'm at a pc before merging anything. I'll approve the workflows so they can at least so their validation already. |
The 0.0.2-alpha.7 package did not provide the .NET Framework 4.8 reference assemblies, so the Linux CI build failed with MSB3644. Version 0.0.4 supplies them, matching the build workflow which already targets KSPBuildTools 0.0.4.
Contributor
Author
|
Thanks. Looks like CI was failing due to a change on dev branch to the build tools not being on main branch. I bumped KSPBuildTools to 0.0.4 matching the fix already on dev - hopefully it passes now. |
Collaborator
|
Looking at Dunbaratu's activity I feel it's unlikely we'll be able to get the permission we'd need to relicense the files in a timely manner. So to make things easier I've just kept the GPLv3 license for those files. Thanks for the contribution! |
Contributor
Author
|
Excellent, thanks for the very prompt review and merge! |
Collaborator
|
No worries, the release should now be public on GitHub and Spacedock. I expect it will come to CKAN within the hour. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a shared
ModuleNameTagpart module so kOS and kRPC can stop each shipping their own copy.Background
kOS and kRPC each define a part module named
KOSNameTag(kRPC's is an adaptation of kOS's). Two loaded assemblies defining the same simple type name is only safe by load order - KSP resolves a type-by-name lookup againstloadedAssembliesin order, and it currently picks the right one only because kOS happens to sort first. A recent KSPCommunityFixes change (KSPModdingLibs/KSPCommunityFixes#307) showed this breaks as soon as anything perturbs load order. See krpc/krpc#829, where moving the module here was suggested.This PR brings the module into KSPCommunityPartModules as
ModuleNameTag; companion PRs on kOS and kRPC drop their own copies and depend on this mod.What's here
The commits are sequenced so the history separates what was imported from what changed:
KOSNameTagpart module and its editor window verbatim (provenance snapshot - see licensing note below).ModuleNameTag(persistent field kept asnameTag, the save key). User-facing strings neutralised.EditorLogic.fetch.Lock(false, false, false, ...), whose all-falseflags never lock part pick/place, so clicking Accept/Cancel dragged whatever part sat behind the button. Now usesInputLockManager.SetControlLock(ControlTypes.EDITOR_LOCK, ...).isEnabled=falsePAW workaround (the field isguiActive), keep theOnAwakeduplicate-removal guard (kOS #2764).Part.LoadModulerewrites a legacyMODULE { name = KOSNameTag, ... }node toModuleNameTagbefore KSP binds it, so name tags on existing craft and saves are preserved. Both the editor craft path (ShipConstruct.LoadShip) and the flight path (ProtoPartModuleSnapshot.Load) funnel throughPart.LoadModule, so the one hook covers both. It is skipped if a realKOSNameTagtype is still loaded, so an un-migrated kOS/kRPC install is not misrouted.I verified in-game: with this mod installed and craft that still contain old
KOSNameTagnodes, the tags load ontoModuleNameTag.Licensing - needs your call
kOS is GPLv3 and this mod is MIT, so the imported file (commit 1) can't simply be relicensed. Two options: get the kOS name-tag author's agreement to relicense that file under MIT, or carry it here under GPLv3 with an explicit per-file header + a note in
LICENSE.md.Left out for you to decide
I intentionally did not bump the version or edit the README, since those are release/maintainer calls. For dependents (kOS and kRPC) to require the build that contains
ModuleNameTag, theKSPAssemblyversion inAssemblyInfo.cswould need bumping (the kOS/kRPC draft PRs currently declareKSPAssemblyDependency("KSPCommunityPartModules", 0, 5), i.e. they expect a 0.5.0 release).And here is a suggested README entry:
Companion PRs