-
Notifications
You must be signed in to change notification settings - Fork 25
Reduce part count (rebased, example, WIP) #47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Part files renamed to `Container{Small,,Large}.cfg`, resource-specific
parts moved to separate directory (`Legacy`).
NOTE: "Waste" containers that previously contained CO2+WasteWater+Waste
have been rebranded "Refuse" to avoid confusion. This happened on the
fuel switch level, the actual Waste.cfg parts are still present (in the
`Legacy` dir.)
TODO: put all resources in tags.
TODO: reorder resources so food-water-oxygen and waste-wastewater-co2 (or reverse).
… list and tech tree. This only works for new games ATM. Researched and unlocked parts still show in VAB/SPH and/or tech tree.
This shreds or bypasses some important packaging functionality, mostly versioning. Needs work by someone more knowledgeable. There is no .pdb (debug symbols) on Linux, so don't try to copy those. An .mdb is properly generated by MonoDevelop when launching like this: KSP='\home\keyspace\ksp\KSP_Data\Managed\' KSP_TEST='\tmp\ksp' monodevelop Source/TacLifeSupport.sln & `KSP` is a working copy location with all the packages. `KSP_TEST` is the root dir of the destination copy. Obviously, they don't have to be the same deployment - helps a lot if you screw up and need to delete the testing one. 0-error debug build on Linux, with files copied if KSP_TEST given. P.S. Using MonoDevelop 5.10.1.6.
So everything was in ThunderAerospace, not ThunderAerospace/TacLifeSupport. :D
Should install to proper dir on Linux now.
Parts already researched _and_ purchased will still be visible in the tech tree. Squashed: Revert fudged up hint paths in csproj.
|
There are way too many changes in this PR. |
|
Post-factum thought: it would have been simpler to move all existing parts to Also took a look at Therefore OK to close IMO. |
|
Yes old parts should be legacy/still available or old saves get broken. |
|
I have someone currently re-texturing the parts. |
General discussion: #12
Most changes via shell scripts. Therefore monotonic, don't be alarmed by changed file count.
Major:
Parts/*, DLL inPlugins(see tree).Minor:
TBD:
WasteContainers to Legacy, too, and addRefuseContainers?..