Starshell.py

[robject]

Cool! I love building very finite frameworks and adding ideas as I can. Working on a merchant-y thing now, a bit at a time.

Any intent on putting this up in github? Or have you and I just missed it?

Yeah, I figure it's almost time to add it to the Traveller Python repo.

 

[robject]

Zipfile in OP updated with latest. I'm about ready to add it to the git repo. Just one more iteration...

ROUND TRIPPING

So it saves to a file, but the file isn't quite importable yet. I wanted to make it so the file is essentially a script that the CLI can run. I may yet do that, but I have to tweak the format a bit.

Unfortunately, I LIKE the format being a very basic sort of YAML on the top level. It means a YAML parser can be useful, but at the same time it's not required. I REALLY like that.

The downside is that cmd2 doesn't process the dash as a command. So if I wanted to very intuitively round-trip my data, it would have to be in a different format (probably use the letter 'a' to itemize, and use that as the "add" operator).

SOLUTION

I guess it's OK: I can have a "yaml" command that saves the design to YAML, and a "regular save" that saves it to the round-trippable format. Yeah, that's a good idea. Whew!

IDs

A really hard question is: should I persist the unique IDs, or toss them out when the design is saved? They're not part of the design; rather, they're part of the utility of the CLI. So they shouldn't be persisted.

Or should they?

 

[Leitz]

A unique id would be useful if folks started building off your ship classes. For example, you make a "Laoshi" class ship with ship_id "1234abcd" and stick it in a file somewhere. I can then pull it out, start with the base Laoshi class, name my ship "Karava Manoi", and modify for my own use.

Note that I haven't gotten into your code yet, it's on my agenda. Just started an on-line C class though so I'm a little swamped.

On the YAML bit, I'd prefer a straight yaml output file. That way I can slurp it into any other program, like the Star Merchant stuff I'm working on, and not have to be in Python. :coffeegulp:

At the moment I'm using JSON, but that's just for mental simplicity for me. Writing a slurper isn't that hard once I know your file arrangement.

 

[robject]

Well the UID is component-based, only expected to be unique for the design... it's half-a-hack to allow edits. Therefore it is short: 24 bits long. It's annoying enough having to type four base64 characters in to select a component. Yeah yeah, I could just print a numbered list, but that has drawbacks too.

And I started having trouble with the hull and drives, which I pre-populate. I'm starting to regret that. There may be some reworking to do.

Last night I had an inkling of an idea, that the "UID" could really be a two-way hash. Then all you'd need is a list of hashes to get the components and their configurations. But I'm not going there today. Besides it starts to look like a USP for components. I don't want to write yet another parser-emitter.

On the YAML bit, I'd prefer a straight yaml output file.

It is, but it's not a full 'structural' dump. I may get there, but not for awhile.

But on that line, you should check out my T5 Desktop Shipyard. It round-trips YAML, JSON, and XML. Once this CLI gets firmed up, I'll update the Desktop Shipyard's ACS emitter and add a reader, and then we'll have portability with utility.

 

[robject]

Okay, I'm working on a PROBLEM. Here it is.

The ACS dump of a ship is a component list, like this:

Components:
 a    Hull  H 0   1  9 000000 0  200 14.0 Streamlined, 200 tons
 a    Driv  J 1   1  9 000000 0   10   10 Jump Drive
 a    Driv  M 1   1  9 000000 0    2    4 Maneuver Drive
 a    Ssen  C 1   1  9 000000 1    0  0.0 Communicator
 a    Wwpn  K 1   1  9 000000 0    1  0.3 T1 Pulse Laser

The 'a' is an item operator of sorts. And in fact it's the import format into the program: enter one of those lines into the shell and that component gets added.

The PROBLEM is that in the cases of drives and hull, I don't want to 'add' them; I want to update them if they exist already.

One way to solve that is to use a different command, say "u", that indicates "update":

Components:
 u    Hull  H 0   1  9 000000 0  200 14.0 Streamlined, 200 tons
 u    Driv  J 1   1  9 000000 0   10   10 Jump Drive
 u    Driv  M 1   1  9 000000 0    2    4 Maneuver Drive
 a    Ssen  C 1   1  9 000000 1    0  0.0 Communicator
 a    Wwpn  K 1   1  9 000000 0    1  0.3 T1 Pulse Laser

Well yeah, but since "adding" a hull or drive is only appropriate the first time, perhaps the add-behavior of the Hull and Drive objects should be DIFFERENT than the add-behavior of any other component.

But it's not just an instance method on Hull and the parent of Drives. Rather, it's how the SYSTEM adds components to the ship. Adding a Hull. Adding a Drive. Not Polymorphism. Perhaps just method signature. Or... well perhaps just the way the Factory works (that's probably the practical solution). Or... or I need a Builder.

That's how I do it in the Desktop Shipyard: I have builder methods (alas not a Builder object) that search for things in the ship list.

 

[Leitz]

Doesn't Python have a memoization thing?

A couple options; set everything to a default value so it's always an "update".

Set hull to a string and weapons to a list.

def update_item(item, add):
  if type(item) is list:
    item.append(add)
  else:
    item = add 
  return item

my_list = ["Esmeralda"]
my_string = 'Fred'
my_list = update_item(my_list, "Guido")
my_string = update_item(my_string, "Sam")

print my_list
print my_string

I'll ignore the lack of strong typing for the function parameters. :rofl: