Kerbal Profession determined by its own parameter

[sumghai]

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.

I'm not convinced that integer-only representation of Kerbal career roles is "easy to use".

While it's true software internally converts variables into its own set of values for it to read, the fact of the matter is, KSP savefiles are intended to be readable by humans for debugging and modding purposes. That's why KSP parts aren't reduced to integer identifiers, nor are agency mentalities ("strict", "easygoing", "pioneer" and "startup" are much easier to understand and work with than "163", "413", "889" and "632").

Let's say you see in the persistence file a career field with a value of 42, and it needs to be changed to a value corresponding to "Security Officer". Without referring to any other documentation and with no knowledge of what integer represents "Security Officer", how do you intend to make the change?

And as you have pointed out, the method you're championing is geared towards unmoddable games, where savefiles can be obfuscated, encrypted and compressed as much as possible. KSP is meant to be modder-friendly, so more verbose values are useful for debugging and maintainability.

If your goal is to save memory at all costs, then I should once again emphasize that making career role variables into strings, even when applied to a large number of Kerbals, wouldn't impact memory usage adversely. It's part texture and sound file sizes that you need to be more concerned with.

[razark]

I don't care how it's done, as long as it is done. Allowing access to the classes so that we can create extensions would be nice, even if it's just combinations of the existing ones.

I'm not convinced that integer-only representation of Kerbal career roles is "easy to use".

If a user can't handle that level of "difficulty", they won't be bothering with it in the first place.

Edited January 26, 2015 by razark

[sumghai]

I don't care how it's done, as long as it is done. Allowing access to the classes so that we can create extensions would be nice, even if it's just combinations of the existing ones.

Career roles are not defined as classes, but in a CFG file:

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.

I, for one, do care about how this is implemented; this is similar to concerns about updates to the stock aerodynamics might be coded in a way that prevents add-ons like FAR from easily modifying it, but I digress.

I'm not convinced that integer-only representation of Kerbal career roles is "easy to use".

If a user can't handle that level of "difficulty", they won't be bothering with it in the first place.

Here's the thing - if converting many CFG and savegame file variables from text strings to abstract integers A) offers as much memory savings as Bill Phil claims and is a litmus test for a user's computer ability (as your statement apparently suggests), then why hasn't SQUAD done so for:

- Part categories?

- Current SOI?

- Contract agency mentalities?

- Tech Node internal names?

Shouldn't the fact that SQUAD has moved towards more verbose parameter values in more recent releases to improve maintainability / moddability extend to Kerbal career roles?

[razark]

Career roles are not defined as classes, but in a CFG file:

http://en.wikipedia.org/wiki/Character_class

Here's the thing - if converting many CFG and savegame file variables from text strings to abstract integers...

As I said, I don't care how it is implemented. Integer or string works for me.

I merely said that if a user is lacking the basic competency to read a number from one text file and type it into another, they aren't the sort of user that would be mucking about in the files.

[micha]

Going back to the OP's point, yes, I also think Kerbal Kareers should be stored as a separate value instead of being derived from their names. The exact mechanics of storing that is mostly irrelevant; in the save-file it should be human-readable, and in an optimised game-engine it should be a (set of) numbers.

I also really like the idea of a Kerbal being able to learn multiple roles; especially in the early game before having access to the bigger command pods it'd be nice to have Kerbals with secondary traits. Or later if you want to send a light-weight mission requiring a mission specialist with at least a Pilot-Level-1 skill to keep control of the ship would be essential.

[cicatrix]

If a profession is chosen basing on the name, does anyone know how EXACTLY it is done? They don't have a names database with assigned professions, do they?

[Superfluous J]

If a profession is chosen basing on the name, does anyone know how EXACTLY it is done? They don't have a names database with assigned professions, do they?

I do not know EXACTLY how it's done but it's some sort of hash on the name, and it's not simple. It is NOT a lookup as you can type "asdfhsadlfjhdsaflj" for the name and get a profession.

What I mean by "simple" is it's not like Kerbal "abc" will be the same profession as Kerbal "cba", and if kerbal "abc" and kerbal "abcabc" happen to both be engineers, changing their names to "bbc" and "bbcabc" will not (necessarily) make them both the same, new profession. They could end up with any new career and won't necessarily be the same as each other.

[Wabbit]

I assume if Jeb, Bill, and Bob are to be made permanently their same roles, then there will be a defaultjob.cfg somewhere or something like that, where you can set a job to always go to a certain character. For example, something like this:

"Fredlan Kerman=engineer"

[cicatrix]

What I mean, if I knew the algorithm I could rename my Kerbals to assign them the job I want.

[Wabbit]

What I mean, if I knew the algorithm I could rename my Kerbals to assign them the job I want.

Yeah, but... That's real hard to do. I either think you should wait for something from Squad or mess around with adding periods in names and stuff.

[KerbMav]

What I mean by "simple" is it's not like Kerbal "abc" will be the same profession as Kerbal "cba", and if kerbal "abc" and kerbal "abcabc" happen to both be engineers, changing their names to "bbc" and "bbcabc" will not (necessarily) make them both the same, new profession. They could end up with any new career and won't necessarily be the same as each other.

I assume if Jeb, Bill, and Bob are to be made permanently their same roles, then there will be a defaultjob.cfg somewhere or something like that, where you can set a job to always go to a certain character. For example, something like this:

"Fredlan Kerman=engineer"

Oh Squad, you did it again ...

Can anyone (not at work or regardless) look up the stats of his kerbals in a save file? Is there any parameter that looks like "make me a pilot/scientist/engineer","hash my name for profession"?

[Spheniscine]

Oh Squad, you did it again ...

Can anyone (not at work or regardless) look up the stats of his kerbals in a save file? Is there any parameter that looks like "make me a pilot/scientist/engineer","hash my name for profession"?

Nope. There is no line indicating which profession a kerbal is. Currently it is determined solely by the hash function.

[klgraham1013]

I wonder why they choose a hashing system over randomly assigning classes. It just seems like over-complicating the issue.

edit: Maybe they wanted everyone who got Bilfrod to have Bilfrod the scientist? If that's the case, I can see them doing the same with gender. Everyone who gets Bilfrod, gets Blifrod the male scientist.

[Wabbit]

That needs to be a show

Now, for the scheduled episode of "Bilfrod the Male Scientist"

[KerbMav]

OK, has anyone managed to rename (by mod?) Jeb, Bill, Bob and name some other guys to Jeb, Bill, Bob to see which class is assigned?

[klgraham1013]

I always preferred "Bilfrod: The Mail Scientist"

How does licking an envelope make it sticky, anyway!?

[Pthigrivi]

Man Id much rather they just change it to be a skill-tree so rolls are determined as you go.

http://forum.kerbalspaceprogram.com/threads/107243-Skill-Tree-for-Kerbals

[sumghai]

http://en.wikipedia.org/wiki/Character_class

I see.

I assumed by "class" you meant http://en.wikipedia.org/wiki/Class_%28computer_programming%29 . This why I've taken to calling these professions career roles to prevent confusion.

As I said, I don't care how it is implemented. Integer or string works for me.

I merely said that if a user is lacking the basic competency to read a number from one text file and type it into another, they aren't the sort of user that would be mucking about in the files.

It's not so much the inability to read & type into text files, but having to memorize which arbitrary integers correspond to which career role.

Tell me, what does career role 394 mean to you?

Nope. There is no line indicating which profession a kerbal is. Currently it is determined solely by the hash function.

I wonder why they choose a hashing system over randomly assigning classes. It just seems like over-complicating the issue.

edit: Maybe they wanted everyone who got Bilfrod to have Bilfrod the scientist? If that's the case, I can see them doing the same with gender. Everyone who gets Bilfrod, gets Blifrod the male scientist.

I think current system is hash-based because SQUAD wanted a quick and easy implementation to get the game to scope-complete for now, and assumed they would refine it later for ease of maintainability / moddability.

[Bill Phil]

Hmm...

394?

Let me get my handy dandy reference to check that!

It's Developer....

This is my point. A reference where you look it up can be easy to use. And who's to say I'm going to know what every career is even if it's in word form? I'll still have to look up the whole list.

[razark]

I assumed by "class" you meant http://en.wikipedia.org/wiki/Class_%28computer_programming%29 . This why I've taken to calling these professions career roles to prevent confusion.

Being an RPG player, it looks like a class and level system to me, so I just naturally call it that. I don't remember seeing an official name for it anywhere.

It's not so much the inability to read & type into text files, but having to memorize which arbitrary integers correspond to which career role.

Tell me, what does career role 394 mean to you?

It means nothing to me now, however if I had the file that defines it, I can look it up easily enough.

It's about as involved as finding "Test Pilot" or "Mission Specialist" or "Ensign Seventh Class" on a list to see what they are. Perhaps even easier, if it's in numerical order and there's on the order of 400 of them.

[BudgetHedgehog]

Hmm...

394?

Let me get my handy dandy reference to check that!

It's Developer....

This is my point. A reference where you look it up can be easy to use. And who's to say I'm going to know what every career is even if it's in word form? I'll still have to look up the whole list.

Playing Devils Advocate here: would it not be quicker and easier to have Developer written in front of you instead of a number that you then need third-party documentation to translate via? Your second point is moot as you'd have to look up the whole list of careers even if it was either plain text or integers - "shall I go for profession 496 or 273? I have no damn clue, let me consult the table to find out what they are". This is assuming the table A, exists and B, is up to date and C, is correct.

[klgraham1013]

I think current system is hash-based because SQUAD wanted a quick and easy implementation to get the game to scope-complete for now, and assumed they would refine it later for ease of maintainability / moddability.

How is that easier than random? I haven't really programmed since the 90s, but asking for a random number was pretty easy back then.

[Bill Phil]

Playing Devils Advocate here: would it not be quicker and easier to have Developer written in front of you instead of a number that you then need third-party documentation to translate via? Your second point is moot as you'd have to look up the whole list of careers even if it was either plain text or integers - "shall I go for profession 496 or 273? I have no damn clue, let me consult the table to find out what they are". This is assuming the table A, exists and B, is up to date and C, is correct.

Sure. I could look at it and see "Developer" but if I'm changing it anyways I'm going to look at the list. Probably the first thing I would do is get the list open.

And this does have assumptions, but so does the other method. The other method assumes that the list exists and is up-to-date as well.

So, really, I don't see your point.

[sumghai]

How is that easier than random? I haven't really programmed since the 90s, but asking for a random number was pretty easy back then.

With a hash, one gets consistent results across savegames. Perhaps this was what SQUAD currently intends.

It means nothing to me now, however if I had the file that defines it, I can look it up easily enough.

It's about as involved as finding "Test Pilot" or "Mission Specialist" or "Ensign Seventh Class" on a list to see what they are. Perhaps even easier, if it's in numerical order and there's on the order of 400 of them.

Playing Devils Advocate here: would it not be quicker and easier to have Developer written in front of you instead of a number that you then need third-party documentation to translate via? Your second point is moot as you'd have to look up the whole list of careers even if it was either plain text or integers - "shall I go for profession 496 or 273? I have no damn clue, let me consult the table to find out what they are". This is assuming the table A, exists and B, is up to date and C, is correct.

Sure. I could look at it and see "Developer" but if I'm changing it anyways I'm going to look at the list. Probably the first thing I would do is get the list open.

And this does have assumptions, but so does the other method. The other method assumes that the list exists and is up-to-date as well.

So, really, I don't see your point.

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

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".

Besides, there is virtually no memory savings or optimizations to be gained by using abstract integers, even for hundreds of Kerbals.

[Bill Phil]

Who's to say there's going to be more than six types in the stock game?

Any sane addon-creater would make a list as to which his is...

Perhaps each mod can have its own separate meter.