Kerbal Profession determined by its own parameter

[Wabbit]

Currently, kerbal proffesion is chosen by name, and I think dosen't make much sense. It does mess with some stuff; as an example, Brotoro's Long Term Laythe, as well as it does my savegame and some of my friends' too.

Were this implemented, it would also make it easier on mods like KXP. It would overall improve Kerbal mod-ability (if that's a word ), and make the roster cfg make more sense. Being determined by name really limits how you can change the jobs of your poor Kerbs without changing their name.

Please post below if you like this idea, or you want to discuss.

[sumghai]

I definitely concur with this notion.

[Bill Phil]

It does seem to overcomplicate things. Specific values have to be set out beforehand, whereas if it was its own perimeter, it would only require three values. 0, 1, 2.

[Bioman222]

I like the idea.

[Norpo]

Yes, as an amateur programmer, this just seems like quick programming. It's possible there was a huge issue and they needed a fast, easy, workaround, but in the long run wouldn't it be best just to determine it using the name only ORIGINALLY, and then store that result elsewhere, so it's not needed again? That even seems easier. Of course, I could be completely wrong and it's a weird inbuilt system of the Node functionality that (i think) they made, but I can't think of any other reason it'd HAVE to be this way.

*Norpo hides all the assert functions he used to end threads in Python*

[Capt Snuggler]

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.

[klgraham1013]

Yes please.

[Commander Jebidiah]

I'm sure it would be better if when you hired them you trained them to either be pilot, engineer or scientist with a small fee for training and if you decide that you don't want Bob to be scientist an you want him to be an engineer then oh retrain him with a higher fee

[sumghai]

It does seem to overcomplicate things. Specific values have to be set out beforehand, whereas if it was its own perimeter, it would only require three values. 0, 1, 2.

Rather than integer values, I would prefer the parameter to be defined with explicit string values like "Pilot", "Scientist" and "Engineer".

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"), so integers might not be helpful.

[Bill Phil]

Rather than integer values, I would prefer the parameter to be defined with explicit string values like "Pilot", "Scientist" and "Engineer".

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"), so integers might not be helpful.

Integers are made of very few characters, especially compared to "Pilot", which his 5, whereas "0" is 1 character.

[klgraham1013]

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"), so integers might not be helpful.

Really? Hmm...so many ideas...

[sumghai]

Rather than integer values, I would prefer the parameter to be defined with explicit string values like "Pilot", "Scientist" and "Engineer".

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"), so integers might not be helpful.

Integers are made of very few characters, especially compared to "Pilot", which his 5, whereas "0" is 1 character.

While brevity would be nice, I'm forseeing potential problems if, for some reason, the Traits definitions were re-ordered or modified.

If 0 was originally mapped to Pilot as you said, and Pilot later got moved below Engineer, then all of your pilots would suddenly become engineers with no advance warning.

(ASIDE: In early versions of KSP, part CFGs used to define part categories using integers i.e. 0 = Command Pods. But as more and more categories were added, it became difficult for SQUAD/add-on authors/users to remember which number corresponded with categories, and so in more recent versions of the game, SQUAD revised it such that part categories were explicitly defined using the more-readable text strings).

[Bill Phil]

Why would they move the scale?

Anyways, even the best programmers can't remember all the commands, they use sources that are on hand.

[GreeningGalaxy]

I originally thought that profession would be based on courage/stupiditiy values. For instance:

[TABLE=width: 500]

[TR]

[TD]Courage[/TD]

[TD]Stupidity[/TD]

[TD]Resulting Occupation[/TD]

[/TR]

[TR]

[TD]Low[/TD]

[TD]Low[/TD]

[TD]Scientist[/TD]

[/TR]

[TR]

[TD]High[/TD]

[TD]High[/TD]

[TD]Pilot[/TD]

[/TR]

[TR]

[TD]High[/TD]

[TD]Low[/TD]

[TD]Engineer[/TD]

[/TR]

[TR]

[TD]Low[/TD]

[TD]High[/TD]

[TD]Unassigned/Trainee[/TD]

[/TR]

[/TABLE]

It would at least be pretty kerbal, if a little cynical.

Of course, it makes much more sense to have it randomly assigned independently of courage/stupidity ratings (ideally as a persistence file option!), mainly because I know a lot of very brave scientists, a few very smart pilots, and it would be silly to assume that all engineers are courageous. But hey, kerbals are already pretty stereotyped, aren't they?

[Wabbit]

I originally thought that profession would be based on courage/stupiditiy values. For instance:

[TABLE=width: 500]

[TR]

[TD]Courage[/TD]

[TD]Stupidity[/TD]

[TD]Resulting Occupation[/TD]

[/TR]

[TR]

[TD]Low[/TD]

[TD]Low[/TD]

[TD]Scientist[/TD]

[/TR]

[TR]

[TD]High[/TD]

[TD]High[/TD]

[TD]Pilot[/TD]

[/TR]

[TR]

[TD]High[/TD]

[TD]Low[/TD]

[TD]Engineer[/TD]

[/TR]

[TR]

[TD]Low[/TD]

[TD]High[/TD]

[TD]Unassigned/Trainee[/TD]

[/TR]

[/TABLE]

It would at least be pretty kerbal, if a little cynical.

Of course, it makes much more sense to have it randomly assigned independently of courage/stupidity ratings (ideally as a persistence file option!), mainly because I know a lot of very brave scientists, a few very smart pilots, and it would be silly to assume that all engineers are courageous. But hey, kerbals are already pretty stereotyped, aren't they?

Hmm. This looks good. It would give you actual reason to look at the "Courage" and "Stupidity" values.

[sumghai]

Why would they move the scale?

I'm merely presenting the possibility that the values / orders may be altered.

Also, your proposal for integer-only representation is mod-unfriendly:

- Assume Pilot, Engineer and Scientist remain as 0, 1 and 2 respectively.

- A hypothetical Kerbal career role add-on adds two new professions, Flight Surgeon and Mission Specialist

- Another hypothetical Kerbal career role add-on adds another profession, Tourist

- If a person who installs both add-ons, what numbers would be assigned to which custom roles?

- What if a person installs one career role add-on, removes it because it didn't fit their needs, then installs a different career role add-on? If the custom profession number ids remain constant, would this cause the Kerbal to suddenly change roles?

My proposal for text-string representation of profession would handle mods better:

- For instance, a user installs an add-on that adds Flight Surgeon and Mission Specialist as new Kerbal professions, along with the associated traits

- The user has second thoughts and uninstalls the add-on

- The user then installs a different add-on that adds Tourist as a new profession

- Kerbals with the now-defunct roles of Flight Surgeon and Mission Specialist keep their profession titles, but (obviously) not the associated traits from the absent first add-on

- The above is a much more graceful exception handling than "Error! invalid profession ID number"

Anyways, even the best programmers can't remember all the commands, they use sources that are on hand.

While more verbose, explicit strings for professions permits self-documenting and more readable code. It's a good practice not to get too reliant on referring to the source code all the time.

I originally thought that profession would be based on courage/stupiditiy values. For instance:

Courage and stupidity values were mainly used to control the facial expressions of Kerbals reacting to in-game events. I would prefer that they do not automatically determine what profession a Kerbal is ultimately assigned to.

[Bill Phil]

Easy. The modder doesn't specify which values are for each role, that would be applied by the program itself. Therefore, if 0 through 2 is the current three, any add-ons would have values assigned starting after the last assigned value.

And I wasn't referring to the professional programmers referring to source code, I was referring to a book or pdf file that has all the commands/terms in it.

[sumghai]

Easy. The modder doesn't specify which values are for each role, that would be applied by the program itself. Therefore, if 0 through 2 is the current three, any add-ons would have values assigned starting after the last assigned value.

And this is the exact problem you've failed to avoid.

- In what order do the add-on professions get their numerical identifiers? First come first serve? A hash?

- What happens if people install/uninstall such add-ons in different orders? What about conflicts?

- What if someone wants to manually edit their savegame to change roles?

[Bill Phil]

And this is the exact problem you've failed to avoid.

- In what order do the add-on professions get their numerical identifiers? First come first serve? A hash?

- What happens if people install/uninstall such add-ons in different orders? What about conflicts?

- What if someone wants to manually edit their savegame to change roles?

First come first serve, of course.

If it's uninstalled then the values are moved down.

If they want to manually change the roles in their savegame they could look at the numbers. It's not hard, people.

Why does it matter? My original point was that integer values take up less space than words, and this game needs as much space as possible.

[sumghai]

First come first serve, of course.

If it's uninstalled then the values are moved down.

How?

If they want to manually change the roles in their savegame they could look at the numbers. It's not hard, people.

It may be easy for you and I, as we are both reasonably experienced users. However, it would be more difficult for newbies.

Why does it matter? My original point was that integer values take up less space than words, and this game needs as much space as possible.

Brevity in Kerbal career role identifiers offers practically no discernible or relevant memory/HDD space savings, and furthermore, results in code/parameters/variable unreadable by humans.

As an example, do you know what the parameter lct represents in KSP savegame persistence files? Why did SQUAD move from integers for part categories to explicit text shorthands?

Edited January 26, 2015 by sumghai

[Bill Phil]

How? I'm no programmer, don't ask me.

Most newbies don't even LOOK in persistence files...

Let me ask you this: Somewhere around 100 bits, or 8 bits. Which would you prefer?

And why would I know what "lct" means? I'm not the programmer, nor am I actually trying to know.

[sumghai]

How? I'm no programmer, don't ask me.

Most newbies don't even LOOK in persistence files...

Let me ask you this: Somewhere around 100 bits, or 8 bits. Which would you prefer?

One of the strengths of KSP is its ease of moddability by end users with a wide range of computer expertise.

Some add-ons directly modify the persistence file to store data (e.g. Kethane, SCANSat), and from a software development perspective, it is better to have human-readable and maintainable code/variables/savefiles that takes up a little more space in memory than a very compact file that is practically ununderstandable by someone trying to debug potentially faulty code.

So if 100 bits would give coders/modders/users more readable/maintainable code, it is the better and preferable option compared to 8 bits.

You may not be a programmer, but the burden of proof was on you to justify your position, since your statements run counter to accepted software engineering practices.

And why would I know what "lct" means? I'm not the programmer, nor am I actually trying to know.

lct is the unix timestamp representing the in-game time a certain vessel was launched from the pad / runway, a variable useful for those who want to adjust the launch date / mission duration of vessels in their savegame. However, it took a number of people weeks of trial and error to determine the purpose of this variable, which could have been averted if it was instead called "launchTimestamp".

[Bill Phil]

You forget, it's 100 bits times the number of kerbals. A dozen, 1200 bits, or essentially a kilobit.

To to be honest I don't care how it's implemented. Each system has it's merits, dependent on the requirements at hand.

[sumghai]

You forget, it's 100 bits times the number of kerbals. A dozen, 1200 bits, or essentially a kilobit.

Where did you get that 100-bit figure from?

Also, in terms of KSP's memory usage woes, verbose text-based data and model files are very cheap - it's textures and sound files that are memory hogs.

To to be honest I don't care how it's implemented. Each system has it's merits, dependent on the requirements at hand.

Your system's only merit is brevity, while having numerous disadvantages.

My proposal requires an unnoticeable memory overhead in return for ease of use / debugging / maintainability as well as the ability to degrade gracefully in the event of corrupted savefiles due to misconfigured add-ons.

[Bill Phil]

100 bits is just an example, chances are the real value will be much larger. 8 bits per character.

My system has many merits, little memory use, relative ease of implementation, as well as the relative ease of use. Believe it or not, a number is easy to use. Just get yourself a conversion table, and you're good. Besides, the value will be converted to something the computer can read anyways.

My system has been in use for a long time, using simple numbers to determine values. It's been used in procedural generation games such as Elite and other examples. They weren't designed to be modded, and in that case it's better than your system.

Heck, it's not even MY system.