Launch numbering

[Damien_The_Unbeliever]

Okay, I'll admit I've only done a cursory search, so I may have missed an existing mod.

I want to be able to build a ship in the VAB, name it (say) "Spearfish" and launch it. Once it's in orbit, I want to go back to the space centre and launch another copy of the same. And again. And again. And then be able to visit the space centre and see that I have "Spearfish", "Spearfish 2", "Spearfish 3" and "Spearfish 4" in orbit. Bonus points if, having modified the "Spearfish" rocket and launched it a new time, it somehow gets marked as "Bloc II" (whether that involves restarting numbering or not, I'm not sure).

So, does such a mod exist? (I haven't found one). If not, I'd be happy to start working on one (I'm a programmer by trade, but not too experienced in game programming), but not too sure where to start.

[NateDaBeast]

I get what you're wanting, it seems like a cool and simple mod but I don't believe I've found anything before when I was looking for this type of mod.

[troyfawkes]

I'd love to see this too

[Drew Kerman]

Why not just make a quick pass thru the VAB instead of straight to the launch pad from the space center and change the name there? You don't have to actually save the newly-named vessel before launching so it's not like it would clutter up your saved ships folder

that said, if you're really just looking for an excuse to work up a simple mod and learn how to do it, sounds like a good concept. 

Edited January 3, 2016 by Gaiiden

[Damien_The_Unbeliever]

So, I've started coding this up this morning, and I'm making (very) slow progress. The basic concept seems to work, but there are a number of places where things don't seem to work quite right.

If anyone familiar with writing small Add-Ins could offer some feedback here, it would be much appreciated. The code should be visible at https://github.com/Damien-The-Unbeliever/KSPLaunchNumbering.git

So, the first issue is that I'm directly inheriting from Unity's MonoBehaviour. Is there a more appropriate KSP base class for an Add-In that doesn't (currently) deal with any form of UI?

The second is finding an appropriate "time" to do my work against any particular vessel. At the moment, I'm resorting to putting code in a FixedUpdate handler and keeping a local list of vessel IDs that I've already worked on. Initially, this list was a static member (as was the other member) and before I started trying to do persistence, this seemed to work. It just didn't look very clean to me, and it also had the issue that it didn't operate correctly in the face of reverting saves.

So, I've started trying to do persistence, and that's where I'm currently broken. I want to persist most of my data within the game's save file. So, in my Awake, I'm adding handlers to GameEvents.onGameStateSave and GameEvents.onGameStateLoad. (I've also switched the members to be instance members rather than static at this point - it seemed "correct"). But it just doesn't seem to work as I imagine it will. So, for a simple Add-In, are these the most appropriate events to load/save data in the save file? And are local, non-static members the appropriate way to model my local data?

Any assistance with the above issues (or any other stylistic feedback) would be appreciated.

 

[sal_vager]

Moved to addon dev by request

[Beale]

6 hours ago, Damien_The_Unbeliever said:

So, I've started coding this up this morning, and I'm making (very) slow progress. The basic concept seems to work, but there are a number of places where things don't seem to work quite right.

 

Extremely interested in this, I've wanted it for a while.

I wish I could offer more help with the coding problems.
When storing local data, you could avoid modifying the Game Save persistence file entirely (Seems like a minefield), and use a local data file, as simple as comma-separated values if you want (I believe?).

Just a thought, best of luck!

Edited January 3, 2016 by Beale

[wasml]

I'm new to the plugin stuff myself so take what I say with a couple grains of salt.

Quote

So, the first issue is that I'm directly inheriting from Unity's MonoBehaviour. Is there a more appropriate KSP base class for an Add-In that doesn't (currently) deal with any form of UI?

I believe this is what most part less mods use.

Quote

I want to persist most of my data within the game's save file.

I've managed to save data to the SCENARIO section of the save game - appears to be the place to store general mod data using the following code

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using KSP;
using UnityEngine;

namespace Aerostat
{
    [KSPScenario(ScenarioCreationOptions.AddToAllGames, new GameScenes[] { GameScenes.FLIGHT, GameScenes.SPACECENTER })]
    internal class AerostatScenario : ScenarioModule
    {
        private static float liftMultiplier = 1.0f;
        public static float LiftMultiplier
        {
            get { return liftMultiplier; }
            set { if (liftMultiplier != value) liftMultiplier = value; }
        }

        public override void OnLoad(ConfigNode gameNode)
        {
            base.OnLoad(gameNode);

            if (gameNode.HasNode("liftMultiplier")) 
            {
                liftMultiplier = float.Parse(gameNode.GetValue("liftMultiplier"));
            }
        }

        public override void OnSave(ConfigNode gameNode)
        {
            base.OnSave(gameNode);

            gameNode.AddValue("liftMultiplier", liftMultiplier.ToString());
        }
    }
}

 

[Crzyrndm]

20 hours ago, Damien_The_Unbeliever said:

So, the first issue is that I'm directly inheriting from Unity's MonoBehaviour. Is there a more appropriate KSP base class for an Add-In that doesn't (currently) deal with any form of UI?

The second is finding an appropriate "time" to do my work against any particular vessel. At the moment, I'm resorting to putting code in a FixedUpdate handler and keeping a local list of vessel IDs that I've already worked on. Initially, this list was a static member (as was the other member) and before I started trying to do persistence, this seemed to work. It just didn't look very clean to me, and it also had the issue that it didn't operate correctly in the face of reverting saves.

So, I've started trying to do persistence, and that's where I'm currently broken. I want to persist most of my data within the game's save file. So, in my Awake, I'm adding handlers to GameEvents.onGameStateSave and GameEvents.onGameStateLoad. (I've also switched the members to be instance members rather than static at this point - it seemed "correct"). But it just doesn't seem to work as I imagine it will. So, for a simple Add-In, are these the most appropriate events to load/save data in the save file? And are local, non-static members the appropriate way to model my local data?

Any plugin will inherit either directly or indirectly from Monobehaviour. PartModules, VesselModules, and ScenarioModules (as well as the KSPAddon type you're using) are just classes extending from Monobehaviour with some extra KSP interfacing.

You really don't want to be working in fixed update at all for this. Fixed Update should be limited to anything physics related that needs to be updated every physics frame. Renaming a vessel is a one time event so you either want it running from Start() or in an event callback. Additionally, because you're going to need save file access (which a KSPAddon doesn't have), you'll want to shift to a ScenarioModule which gives you OnLoad and OnSave.

[KSPScenario(ScenarioCreationOptions.AddToAllGames, new GameScenes[] { GameScenes.SPACECENTER, GameScenes.EDITOR })] // places you can launch from
class VesselRenamer : ScenarioModule
{
	public override void OnSave(ConfigNode node)
    {
     	// save stuff 
    }
	public override void OnLoad(ConfigNode node)
    {
     	// load stuff 
    }

	public void Start()
    {
      GameEvents.OnVesselRollout.Add(RenameVessel);
    }
    public void OnDestroy()
    {
      GameEvents.OnVesselRollout.Remove(RenameVessel);
    }
    public void RenameVessel(ShipConstruct sc)
    {
      // rename vessel if name is part of series
    }
}

^^ Event based framework. I'm assuming OnRollout is called for each new vessel from the launching scene (not once flight starts. Mainly because it uses ShipConstruct, not vessel), just change the scene if its wrong

Edited January 4, 2016 by Crzyrndm

[Damien_The_Unbeliever]

Thanks for the replies. I'll try adjusting things tonight and see how it holds up.

[Damien_The_Unbeliever]

I've now got the basics hanging together - every launch gets numbered, if it doesn't already end with a number.

I'll try working out how Kerbal Stuff works and then will share an early version with people.

[NateDaBeast]

7 hours ago, Damien_The_Unbeliever said:

I've now got the basics hanging together - every launch gets numbered, if it doesn't already end with a number.

I'll try working out how Kerbal Stuff works and then will share an early version with people.

Great to hear !

[Damien_The_Unbeliever]

So, here's a preliminary build, it's MIT licensed and the source is here.

The Zip contains a LaunchNumbering directory, that should be inserted into the GameData folder.

So far, it's very preliminary. It'll work best for new saves where you haven't already launched vessels with the same name (since I don't attempt to find existing vessels and de-conflict the names)

The first launch will be recorded as "Initial launch" (via the notices at the top of the page) and will not be renamed. Every subsequent launch of vessels with the same name will have a number appended (and a separate notice will tell you what it's been named).

Any feedback gratefully received. Initially, any changes to behaviour will only be possible by editing the save file, since (given the expected 1.1 changes), I don't think it's worthwhile to learn UI at the moment. Currently, the save file will have sections that look like this:

    SCENARIO
    {
        name = LaunchNumberer
        scene = 5, 6, 7
        SERIES
        {
            name = Scishot
            BLOC
            {
                vessel-hash = 1
                vessel-count = 2
                bloc-number = 1
                bloc-roman = False
                vessel-roman = False
                bloc-shown = False
            }
        }
    }

Presently, you can ignore most of these settings (I.e. they have no effects). If you set vessel-roman to True, then I'll start generating the numbers as roman numeral rather than digits. This was originally planned to be used to mark "Blocs" (I.e. variations in the vessel), but this isn't working yet.

For an existing save, you can populate a SERIES section with an appropriate name and an appropriate vessel-number, and I'll start numbering vessels with that name and the next number.

Edited January 18, 2016 by Damien_The_Unbeliever
typo