JPLRepo

Modders Notes the Dev team have thrown together for 1.12.0. We upgraded the project to Unity 2019.4.18f1 LTS to position KSP on a long term support version of Unity. This should not have any major impact on mods. API documentation can be found here. Wheels and Landing Legs changes ModuleWheelBase.useNewFrictionModel by default is false. Which means all wheels and landing legs using this module will use the old behaviour/logic by default. Set it to true in the part.cfg file to use the new friction model. ModuleWheelSuspension.useDistributedMass by default is false. Which means all wheels and landing legs using this module will use the old behaviour/logic by default for suspension processing. Set it to true in the part.cfg file to use the new friction model. ModuleWheelSteering.autoSteeringAdjust by default is false. Which means all wheels and landing legs using this module will use the old behaviour/logic by default for steering processing. Set it to true in the part.cfg file to use the new friction model. Refer to the Wheels Devblog for more information about the functional changes that were made to wheels and landing legs. Maneuver Tool The maneuver tool app has been designed in such a way to allow modders to easily add additional maneuver types to the app. To do this you will need to create your own mod c# class that inherits class TransferTypeBase - Base class for the transfer types. The Manuever Tool app on startup finds all classes based on this base class and adds them into it’s maneuver type list. Refer to the API documentation for the abstract methods your class has to implement. Additionally you must implement your own data class for your transfer type. Use this class as the base and assign to currentSelectedTransfer: TransferDataBase - Base class for the TransferData for each transfer type. This class inherits AppUI_Data class that allows you to define UI fields for your transfer that will appear in the center part of the manuever tool UI. See the section below called “Generic UI framework” on how to define your UI fields. You will also want to assign your dataChangedCAllback and calculationStateChangedCallback. Additionally you can use the following base class to define your own data class for the top slide out section of the maneuver tool app: TransferDataTopDataBase - Base class for the TransferDataTop for each transfer type. This class also inherits from AppUI_Data class. Another important class is ManeuverToolUIFrame. This manages the UI for the Manuever Tool App and has a number of useful methods. Refer to the API documentation. AlarmClock App The Alarm Clock follows a similar idea to most moddable things in KSP. The fundamental building blocks are: AlarmClockScenario: The scenario module that runs and manages the alarms AlarmTypeBase: The abstract class that all alarm types inherit from I won’t go into all the specifics here as the API help should cover many of these things, but here’s some key pointers. The scenario maintains the list of alarms and persists them into the save file. AddAlarm, RemoveAlarm, GetNextAlarm, etc help you manage the alarm list.There are GameEvents for changes to the list as well. There is currently no “GetAllAlarms” method - Triggers apologies - this will be fixed You define the input fields you want by attributing fields or properties with AppUI_Control types. These fields/properties can then be used in the AlarmType class to define the time for the alarm and any other behaviour. An example here is AppUI_InputDateTime which will give you a datetime input when creating/editing an alarm. Some key fields/overrides in the alarm type include: id - the persistent identifier for an alarm GetDefaultTitle() - the string that will be the title of a new alarm iconURL - a gamedatabase path to the icon to use in the drop downs and lists - the default ones are 64x64 pngs ut - the time of the alarm in universal time RequiresVessel() - when true the alarm will only be available in the UI to add when a vessel can be selected CanSetAlarm(AlarmUIDisplayMode displayMode) - lets you control when the inputs are valid in add and edit mode to save changes OnInputPanelUpdate(AlarmUIDisplayMode displayMode) - called in the Monobehavior update loop by the app for each alarm when it is displayed in the app OnScenarioUpdate - called in the Monobehavior update loop by the scenario when the alarm is in the list. Here’s an example of a very simple alarm type that will let you set a date public class AlarmTypeTest : AlarmTypeBase { [AppUI_InputDateTime(guiName = "Alarm Date", datetimeMode = AppUIMemberDateTime.DateTimeModes.date)] public double alarmDate; public AlarmTypeTest() { iconURL = "TriggerTech/TestMod/AlarmIcons/DavesTest"; } public override bool CanSetAlarm(AlarmUIDisplayMode displayMode) { return true; } public override string GetDefaultTitle() { return "Daves Test Alarm"; } public override bool RequiresVessel() { return false; } public override void OnUIEndInitialization(AlarmUIDisplayMode displayMode) { if(displayMode == AlarmUIDisplayMode.Add) { alarmDate = Planetarium.GetUniversalTime() + 600; } AppUIMemberDateTime m = (AppUIMemberDateTime)uiPanel.GetControl("alarmDate"); m.DatetimeMode = AppUIMemberDateTime.DateTimeModes.date; } public override void OnInputPanelUpdate(AlarmUIDisplayMode displayMode) { ut = alarmDate; } } Generic UI framework The key driver for this system is the idea of moddable inputs to applications for various moddable functions. The fundamental idea being that in a UI you can place a panel that has a vertical layout group and an AppUIPanel component, call Setup with a data class and it will present the user with an editable section of UI that correlates to the data inputs. It edits the data class and the code can then use the edited object directly. Steps to use it: Create a “panel” in your UI that will hold the input fields. Create a class that holds the inputs (inherits class AppUI_Data). Apply the attributes to the fields that are for input within the class. “Setup” the panel at the right time in code. Classes of interest AppUI_Data - this is your data class which can use attributes on fields to create UI controls. The following UI controls can be used as attributes on your fields in your AppUI_Data class.: AppUIMemberDataTime AppUIMemberDropdown AppUIMemberDropdownMultiLine AppUIMemberHeading AppUIMemberInput AppUIMemberInputFloat AppUIMemberLabel AppUIMemberLabelList AppUIMemberRadioBool AppUIMmeberSliderFloat AppUIMemberSliderFloatMultiLine AppuiMemberToggleBool File Folder Browser Craft files are still stored as text in .craft files. The thumbnail naming convention has changed, but otherwise the thumbnail itself is generated no differently. The search classes don’t have any exposed methods that can be used to actually do anything aside from literally starting and stopping a search using whatever information is in the search input text field. The folder-action confirmation dialog for deleting and creating folders can be created and passed callbacks that are fired when the indicated action is confirmed. The folder browser doesn’t use any config files that could be modified. Public methods and properties include querying if the currently selected folder is a player-craft or stock-craft folder, and querying if the currently displayed folder structure is for the VAB or SPH. Folder highlighting can be overridden using a craft’s file-path, and folder highlight overrides can also be turned off. Also exposed is a method for updating folder file-counts for all folders as well as for a specific folder. Properties are exposed that return the local machine’s file path for the stock craft folder, the expansion directory folders, and the mission craft folders Lights We added the ability to disable and enable the Color Picker of the lights - use the KSPField disableColorPicker in the part.cfg file. Also if one light has more than one transform you can control it with the same Module light. You can do this by defining one or more LIGHT submodes within the ModuleLight node in your part.cfg file. Eg: MODULE { name = ModuleLight …. (normal ModuleLight fields) LIGHT { lightName = light1 lightR = 1.0 lightG = 1.0 lightB = 1.0 flareRendererName = flare1 } LIGHT { lightName = light2 lightR = 1.0 lightG = 1.0 lightB = 1.0 flareRendererName = flare2 } } Docking Port rotations. Docking port parts are now able to do an alignment rotation once they are docked. In order to make a dock being able to rotate, you need to configure them so: canRotate: set to True, when this rotating feature should be available to this part rotationTransformName: Name of the transform of the model that will rotate. maxMotorOutput: this is used for the electric charge resource consumption calculations. set this according to the part’s design guidelines RESOURCE definition: this one should be the same for all docking ports that use this rotating feature. This is used to specify which resource is consumed by doing the rotation These other KSPFields are optionally available to configure as well: rotationAxis: The rotation axis, defaulted to the z axis. This is necessary as some docks might have a different rotation axis. Can be "X", "X-", "Y", "Y-" or "Z", "Z-" traverseVelocity: The traverse speed (in deg/s for rotational motion) hardMinMaxLimits: The angle range that's defined by the physical limits of the part model and/or the part's designer. The default values are -15, 15. A player must not be able to set an angle beyond this range. This is a Vector2 so, could be defined as “-15, 15“, for example. efficiency: Servo efficiency (1 = 100%) baseResourceConsumptionRate: Base resource consumption on motor output when the servo is moving referenceConsumptionVelocity: The transform velocity (angular or positional) at which the resource consumption is 1 x the baseResourceConsumptionRate New Slim Suit ID Maps ksp_slimsuit_uv_map.zip ksp_1-12_suit_idmap.zip Other misc modding changes Failed reflection calls to incompatible or otherwise invalid mods are now handled, so they don't stop the game from loading. Custom suits now show the corresponding icon in all relevant screens. These have to be provided by the mod, the game will not generate them. Added an additional useCustomThreshold field to ModuleOrbitalSurveyor. Setting it to true will allow the module to recalculate the minimum and maximum altitudes beyond the stock values. When multiple versions of the same assembly are present, KSP now makes sure only the most recent one is loaded. It’s still a good idea to encourage people not to do this, to avoid clutter. Tuned the logic to calculate space object resource percentages based on the lowRange and highRange values, preventing space objects from always having > 80% resources regardless of the range values. Added a GameEvent for revert to launch that returns the current FlightState.

API docs links updated for 1.12.0 see link in OP

Sorry, yeah real life. Work, deaths in the family, etc. It's been hectic. With 1.12.0 about to release I think I'll hold off putting out a full release until then. It's less than 2 weeks. I took a look at your log. there's lots of errors and not just this mod. But I have no idea how you've managed to kill this mod. I can see it's broken. But for me to investigate I would have to spend hours installing all the mods you have installed to try and reproduce.

First, they aren’t integrated mods. They are written features. They have numerous additions to the mods you talk about. That said, they are features within the core code and not mods. Hence are completely interwoven with all the games systems such as patched conics. so the short answer is yes. They should work with modded solar systems. and like all KSP systems, are moddable themselves.

It works like all other deployable parts. It can be deployed. where it screws itself into the ground, and it can be undeployed where it unscrews itself from the ground and be picked up.

To clarify: Rotating Docking ports are not robotic parts.

No they are not.

I already have a fix for this. Just haven't published it yet.

Sorry folks. Real life stuff keeps getting in the way of me getting this update out. Trying to find some time. Hopefully not too much longer.

yeah sorry. Real life stuff too much lately... I'll see if I can get the patch done ASAP

Sorry due to KSP 1.11.2 being released... i haven't been able to get the update out for this mod yet. Hopefully this week - (Fingers crossed).

Just an update here. I've worked through and made fixes for all the following issues. I just need to complete testing before I can release the update, shouldn't be too much longer (day or two). *Fix issue where CBs were becomming visible when they shouldn't be. *Fix issue where CB visibility was not being reset when loading different save games in the same game session. *Fix issue where errors would occur and game stuck when entering the SOI of a CB that hadn't been discovered before. *Fix issue where Asteroids entering CBs were making them discovered. *Fix issue with bumpmaps on CBs.

a) Sorry. b) Not currently. c) Litres.

Sorry. No this hasn't made it. This was fixed in 1.11.1 by way of adding new static public method to do this.

V1.13 published. V1.13 * Added KSP 1.11 stock inventories. * Fixed issues with Kerbalism: * FusionPellets don't appear on crewed parts. * Ranger VTOL engine guzzles ElectricCharge (due to install with incompatible WBI Classic Stock). * Moved storage cuboid to Cargo category. Many thanks to @JadeOfMaar for this update.

I've been through the changes. Will look to get out an update sometime in the next week.

yes it should. and if used together it will trigger a discovery of that celestial body if not already found before. They will also appear foggy initially, and gradually become clearer as you research them more in the research bodies mod.

Thanks everyone for raising known issues of late. I'll see if I can assign some time to give this mod some love and try to address the CB visibility issues and bring it up to date in the next week or two. Thanks again.

it may or may not. if it doesn't let me know and I'll release a new version.

Vessel.GroupOverride is the index of (Vessel.OverrideActionControl) the currently set action group. Vessel.OverrideActionControl is an array of the action groups for the vessel. Vessel.SetGroupOverride(int newGroup) - sets the action group.

Changing the vesselId would create other issues, hence there is no public method for doing that. You can remove and add a vessel/vesselId but that also will create unwanted issues for you as that fires events and other processing.. as removing it - means it's being removed. You could try that. but I can't say that you won't have other side effects. Feels to me you should be tracking your data based on the command pod/root part persistentId and then sharing the data between them if they are part of the same vessel.

Correct. Unity only uses Vector3. Vector3d is a construct used in KSP - but is outside of Unity. Raycasts are a functionality of Unity, and as such only work with Vector3.

I can recreate the error in various KSP versions. Don't believe it's new to KSP 1.11.

That's because when I replied there were no links. The original post was edited to add links to some of the issues that were in the post after my post and the subsequent follow on comments in the thread.

It never ceases to amaze me what you, the amazing KSP Community, can come up with. Not in 1,000,000 years would I have thought of using the flag parts in this way when we dreamt them up as a thing in the game. Well done.