Kerbal Profession determined by its own parameter

[razark]

The thing is, documentation on savegame parameters has been fairly sparse, so 95% of the time, there is no list to refer to.

Sure there is. It's even been pointed out that it's an extendable list by... someone. All it needs is one additional integer field for an index.

If you look at GameData\Squad\Experience\Traits.cfg, you'll see that it is actually possible for users/modders to define their own roles (e.g. "Mission Specialist", "Flight Surgeon", "Tourist")...

Even if the community managed to figure out a list through trial and error, the information would become outdated as soon as a new release changes Kerbal careers, or invalidated by conflicting add-ons / variations in add-on installations.

IMHO, it's easy for people who don't use / author add-ons to not care about savegame readability / implementation, but for the significant number of add-on users / authors like myself, it is very important that Kerbal roles be defined using human-readable values like "pilot".

But what if my installation has had pilots completely removed from the list, and replaced with another class, like "Driver"? It would be just as incompatible until I updated things to work properly. Aside from that, it's not the community that has to manage my Kerbals. That's my responsibility. I do not insist that every modder make things work for me. If I want to combine mod A and mod B, I must be willing to A. accept that it might not work cleanly out of the box; and B. fix it myself if it doesn't (although the modder may be willing to assist if asked kindly, it's not his job).

However, if all my Pilots have a "0" as their class index, I can go to the file that defines these (GameData\Squad\Experience\Traits.cfg), change "Pilot" to "Driver" for index 0, and not have to go through the save file and reclassify every single Kerbal by swapping the strings.

I'll say this again: Strings and integers both work. There are advantages and disadvantages to both, but neither is undeniably superior. For some reason, you've taken the position that integers are so unwieldy that they must be consigned to the ash-heap of computing history along with punch cards and vacuum tubes.

[sumghai]

Sure there is. It's even been pointed out that it's an extendable list by... someone. All it needs is one additional integer field for an index.

You've misquoted me.

- Traits.CFG allows existing career roles to be created or new ones added

- Traits.CFG does not assign numerical indexes to each career role, whether explicitly as an integer field, or implied based on the order the roles are defined; therefore, it is not (and should not be) the lookup list Bill Phil and yourself are expecting to find.

Let's consider the following examples:

Case 1 - Default Trait

Pilot
Engineer
Scientist

Case 2 - Modified Traits by a user that wants Scientists to come before Engineers

Pilot
Scientist
Engineer

Case 3 - Modified Traits by a user that installed a space tourism add-on

Pilot
Engineer
Scientist
Tourist

Case 4 - Modified Traits by a user that installed an add-on with extra professions

Pilot
Engineer
Scientist
Flight Surgeon
Mission Specialist

Case 5 - Modified Traits by a user that first installed the extra professions add-on, and then installed the space tourism add-on

Pilot
Engineer
Scientist
Flight Surgeon
Mission Specialist
Tourist

Case 6 - Modified Traits by a user that first installed the space tourism add-on, and then installed extra professions add-on

Pilot
Engineer
Scientist
Tourist
Flight Surgeon
Mission Specialist

Assuming the integer index method is used within the savefiles, the first entry = 0, the second = 1 and so on, regardless of the actual name / order of professions.

A user who creates a savegame under case 5 then shares their savefile with a user under case 6 would encounter an incompatibility because career type 3 would unexpectedly change from Tourist to Flight Surgeon, even though both users have the same add-ons installed (albeit in a different order).

But what if my installation has had pilots completely removed from the list, and replaced with another class, like "Driver"? It would be just as incompatible until I updated things to work properly.

If the integer system is used, then the order in which the traits are defined will influence what new role the ex-pilots become.

If the string system is used, then the order doesn't matter, because all Pilots will automatically be renamed as Drivers.

Aside from that, it's not the community that has to manage my Kerbals. That's my responsibility. I do not insist that every modder make things work for me. If I want to combine mod A and mod B, I must be willing to A. accept that it might not work cleanly out of the box; and B. fix it myself if it doesn't (although the modder may be willing to assist if asked kindly, it's not his job).

Interesting. Good luck with that.

However, if all my Pilots have a "0" as their class index, I can go to the file that defines these (GameData\Squad\Experience\Traits.cfg), change "Pilot" to "Driver" for index 0, and not have to go through the save file and reclassify every single Kerbal by swapping the strings.

Notepad++'s find/replace all is very quick and efficient for string replacements.

I'll say this again: Strings and integers both work. There are advantages and disadvantages to both, but neither is undeniably superior. For some reason, you've taken the position that integers are so unwieldy that they must be consigned to the ash-heap of computing history along with punch cards and vacuum tubes.

Integers would be perfect if KSP was never meant to be modded and the encrypted and obsfuscated savefiles will only ever be read internally by the game. It could even be in machine code or binary if you want.

Strings are best since KSP is moddable and the savefiles are meant to be readable / modifiable by both humans and software. This is why in the savefile for instance, parameters for SOI refer to Kerbin as Kerbin, rather than enigmatic "3", and in-flight vessels have parts referred to as FusTek_Karmony_Node_(timestamp) rather than 346278098362. These parameters you and Bill Phil think should be integers are already referred to by strings.

Edited January 29, 2015 by sumghai

[razark]

You've misquoted me.

And you've failed to read what I posted.

Traits.CFG does not assign numerical indexes to each career role, whether explicitly as an integer field, or implied based on the order the roles are defined; therefore, it is not (and should not be) the lookup list Bill Phil and yourself are expecting to find.

I already stated that the existing Traits.cfg file would need to have an index added:

All it needs is one additional integer field for an index.

Let's consider the following examples

Let's give up, because you're not really following what I've said, and insist on arguing points I've never made.

Good evening.

[sumghai]

I already stated that the existing Traits.cfg file would need to have an index added

And I'm stating that instead a integer index, the existing string-based values from the Traits.CFG file (e.g. name = pilot) would not only suffice, but is greatly preferable in the context of KSP savegames (human-readable self-documentation ability, robust against reordering of / changes to career role definitions by SQUAD / add-ons).

[sumghai]

While conversing with some other users in IRC, it was conjectured that the reason SQUAD made Kerbal professions based on the hash of the Kerbal's name was because they wanted the name/career combo to persist across savegames - e.g. Billy-Bob Kerman might always be a stupid scientist.

In the Ship Manifest add-on thread, there was a discussion involving attempted hacks and workarounds for the profession limitation, where futrtrubl made the following suggestion:

What Squad should do is, upon creation of a Kerbal, base its profession on its name hash and save that as a separate variable. This will allow same named Kerbals across saves to have the same profession unless changed by an addon, and allow graceful name and profession changes.

This is the best-of-both-world approach, and hopefully SQUAD could look into this post-1.0.

[sumghai]

To further elaborate on futrtrubl's idea, let us examine some use cases:

- By default, Bob Kerman is a scientist, determined by the hash for the name

- The specialization "scientist" is stored as a string in a separate specialization field for the Kerbal (as a counter-argument to Bill Phil and razark's persistent opinion that these variables should be reduced to integers, I'll point out that 1.0's Kerbal gender uses text strings of male and female rather than 0 and 1)

- If a user (say, myself) wants to change Bob into a pilot, said user would simply change the value of the specialization field and reload the savegame, which overrides the hash-based system

- If an add-on provides a brand new specialization other than the default pilot/scientist/engineer/tourist options, then again, the add-on can change the value of the specialization field to, say, "Flight Surgeon"

- If the aforementioned add-on is removed, KSP will detect that "Flight Surgeon" is no longer a valid specialization, and so will once again invoke the hash-based generation to rewrite the default specialization for that Kerbal.

In psuedocode, this would be:

When a Kerbal is first created
    Use the hash of the Kerbal's name to generate the default profession
    Write the text string value of the profession to the specialization field for that Kerbal
End

When accessing a Kerbal (in the Astronaut Complex, loading a savegame, loading a vessel etc.)
    Check the profession of the Kerbal
    If the Kerbal's profession is invalid (i.e. not pilot/scientist/engineer/tourist or other any other custom profession provided by add-ons)
        Use the hash of the Kerbal's name to generate the default profession
        Write the text string value of the profession to the specialization field for that Kerbal
    End
End

[I](There is no else statement, since the game doesn't need to do anything if a valid profession name, stock or mod, is found )[/I]

[Armchair Rocket Scientist]

the current profession system feels pretty damn hollow and could do with a complete do-over/expansion.

id prefer it if you could change a kerbals job by training them in a new field.

EG:

Jeb starts with pilot skill 6, engineering 2, and science 1 so he gets the "pilot" title after is name.

Then you train him in engineering ether by practice or instruction from a qualified kerbal. Instruction trains faster than practice.

Now Jeb has pilot 6, engi 6, and science 1 so he gets "flight engineer" title after his name.

pilot 2, engi 0, sci 0 = trainee pilot.

pilot 0, engi 1, sci 0 = handy man.

pilot 0, engi 5, sci 5 = senior aerospace technician.

pilot 10, engi 10, sci 10 = space cowboy.

pilot 0, engi 0, sci 0 = spud.

as each level is gained it becomes slower by 10% to gain the next. (it would be very very difficult to get a 10,10,10 kerbal)

*the numbers im using are for explanation only. it could be 1 - 5 or 1 - 100 what ever.

this would add allot more depth and give reason for multiple crew so you can train up new kerbals in the field. training missions could be useful too.

This would be incredibly useful, AND realistic. For example, through the end of the Apollo program astronauts were almost always originally trained as pilots, but were also given some science and repair training. It's ridiculous that right now a Kerbal can't simultaneously know how to drive and change a tire.

[razark]

(as a counter-argument to Bill Phil and razark's persistent opinion that these variables should be reduced to integers, I'll point out that 1.0's Kerbal gender uses text strings of male and female rather than 0 and 1)

Wow. Declaring victory in an argument everyone else walked away from three months ago?

That's really kind of sad. Go get you some ice cream and a hug...

[sumghai]

Wow. Declaring victory in an argument everyone else walked away from three months ago?

I'm merely pointing that since SQUAD chose to use text strings for genders, they could just as easily use text strings for professions - there is no winning or losing involved.

[Superfluous J]

I don't care how they do it. They could add

Flapdoodle=Joozimiwhiz

to mean that someone is a scientist. I just want to be able to modify it.

[sumghai]

I don't care how they do it. They could add

Flapdoodle=Joozimiwhiz

to mean that someone is a scientist. I just want to be able to modify it.

The method of implementation is important because code/savefile variables should, ideally, be self-documenting to permit ease of development / debugging.

[Bill Phil]

Well..

using names would mean that someone who doesn't have a list of them could have problems guessing.

[sumghai]

Well..

using names would mean that someone who doesn't have a list of them could have problems guessing.

If explicit text values are used, a dedicated lookup table isn't needed.

- The candidate roster will always have Kerbals of all four stock professions explicitly listed in the savegame file

- If specifying a custom profession defined by an add-on, the add-on will provide the profession definition in a CFG file

- By not relying on integer representation, the professions can be reordered (i.e. custom profession add-ons installed/uninstalled in different order/combinations) without worrying about breaking anything

- Invalid professions from missing add-ons would cause the Kerbals to just revert to one of the stock ones