Commandline to assemble the spaceship

[deontologician]

The command line will be the initial interface to the simulator. Some examples of how it might work:

> attach ammo-cable-002 to gun-port-001
[port.info]: ammo-cable-002 attached to gun-port-001
> list cables
 - ammo-cable-002
 - ammo-cable-001
 - power-cable-001
> purchase power-cable
Cost is 300c, purchase? [Y/n]
Purchased "power-cable-002"

These are examples. I'd like to flesh this idea out more. and possibly break it into sub-issues to add commands one at a time.

[xXxH3LIOSxXx]

I'm working on something similar to interfaces in networking for browsing the 'slots' or components of the ship. When I have a pretty comprehensive example I'll post here, just wanted you to know I was working on this element more so than anything else so we can begin prototyping asap.

[xXxH3LIOSxXx]

Prepare for intense examples:

Core Levels of the CLI:

Upper-most / Supervisory layer

Lists all ships, bays, and modules owned can narrow context down to a ship for faster sorting/processing

configuration terminal

The direct interface to the modules of a specific bay Lists all of the modules of a specific bay Lists all of the configurations of a specific module Has a lower level configuration mode Has context for each module Each context has configuration for specific parts of that module

Supervisory layer examples
---------------------------------

[prompt characters signify state]
[ '>' symbolizes supervisory state]

> ?
 show
 context
 exit
 save

[ Contextual help displayed ]

> some-comm?
 some-communication
 some-command

[ Completion level contextual help displayed ]

Example commands

> show ships

ship    Breaker_1   1/5/10 
ship    Horcrux     2/5/10

Where 1/5/10 = ship id# / Max bays / max modules

> show Breaker_1
or
> show ship 1/0/0

bay weapon-systems  1/0/0
bay shield-system   1/1/0
bay propulsion-systems  1/2/0
bay etc         1/3/0
bay etc         1/4/0

> show bay 1/0/0

bay weapon-systems 1/0/0

bay weapon-systems 1/0/1
 name Hyper-Beam_Mk.II
 damage-type laser

> show bay 1/1/1

bay shield-systems 1/1/1
 name Dorinfal_Generator
 force-resistance 10u

> show shield-system 1/1/1

bay shield-systems 1/1/1
 name Dorinfal_Generator
 force-resistance 10u
 depletion-factor 20
 max-capacity 100000

More broad show commands show summary or 'important' data, specific ones show lower level detail. Entry point to configuration, seeing more detail, or limiting CLI scope to a ship, enter ship context

> context Breaker_1
Breaker_1+>

where 'name+>' is the ship level context, this makes diagnostics faster, for example:

+> show ship

bay weapon-systems  0/0
bay shield-system   1/0
bay propulsion-systems  2/0
bay etc         3/0
bay etc         4/0

instead of having to enter a specific ship, note ship id no longer necessary as we're in context

+> show weapon-systems

bay weapon-systems 0/0

bay weapon-systems 0/1
 name Hyper-Beam_Mk.II
 damage-type laser

etc

To configure bays, modules, interfaces etc, enter configuration terminal:

+> configure terminal

#

Where '#' is configuration mode.

select which bay to work with

# bay 1
(bay_1)#

Change the bay type:

(bay_1)# type weapon-systems
(bay_1)# exit
# exit
+> show ship

bay weapon-systems  0/0
bay weapon-systems      1/0
bay propulsion-systems  2/0
bay etc         3/0
bay etc         4/0

Want to configure modules within a bay?

+> configure terminal
# weapon-systems 0/0
(ws_0/0)# equip ?
 Hyper-Beam_Mk.II
 Triton_Lance
 BFG_9000
(ws_0/0)# equip Hyper-Be?
 Hyper-Beam_Mk.II
(ws_0/0)# equip Hyper-Beam_Mk.II
(ws_0/0)# weapon-systems 0/1
(ws_0/1)# equip Hyper-Beam_Mk.II
(ws_0/1)# weapon-systems 0/2
(ws_0/2)# equip BFG_9000
(ws_0/2)# exit
# exit
+> show weapon-systems

bay weapon-systems 0/0
 name Hyper-Beam_Mk.II
 damage-type laser

bay weapon-systems 0/1
 name Hyper-Beam_Mk.II
 damage-type laser

bay weapon-systems 0/2
 name BFG_9000
 damage-type awesome

Want to customize that module??

+> configure terminal
# weapon-systems 0/0
(ws_0/0)# ?
 polarity
 intensity
 color
 max-draw
 overdrive
 ...
(ws_0/0) intensity ?
 low
 mid
 high
(ws_0/0)# intensity low
(ws_0/0)# exit
# exit
+> show weapon-systems

bay weapon-systems 0/0
 name Hyper-Beam_Mk.II
 damage-type laser

bay weapon-systems 0/1
 name Hyper-Beam_Mk.II
 damage-type laser

bay weapon-systems 0/2
 name BFG_9000
 damage-type awesome

+> show weapon-systems 0/0
bay weapon-systems 0/0
 name Hyper-Beam_Mk.II
 damage-type laser
 intensity low

Error output as follows:

(ws_0/0)# intensity low
Error at ^ where '^ low'!
Low Intensity setting requires:
 bay control-modules Power-Regulator_Class.IV
Which you don't have!  Equip a Power-Regulator_Class.IV in a control-modules bay

checking inventory, is as easy as:

> show parts
 Item 1
 Item 2
 Item 3
> show parts | include weapons
 Weapon 1
 Weapon 2
> show parts | exclude equipped

etc Standard pipe-line filtering / grep plugin

> show Power-Regulator_Class.IV
 Name
 Property 1
 Property 2
 Property 3
 Requirement 1
 Requirement 2
 Requirement 3
 ...

Shopping could be easily achieved in this shell - examples:

> show merchants 
 Player2
 NPC1

> merchant Player2

!-- MOTD: Welcome to Buzby's magical cantina, ya-wana-meaty-cha-bota?? --!
$> show inventory
 Some Item 1
 Some Item 2
$> purchase Item 1
$> exit
!-- Thanks for stopin' by! --!

For combat, I'd have to know more about what our language is, or if we were really going to do a completely raw shell of our own for this... ideally, each important 'stat' of the ship a player likes, would be compiled by them into a 'view' or 'dashboard', like their own HUD, and as ships engage, players input commands to each module, the dashboard they made giving them (hopefully) the feedback they want. The better hackers, and analysts the better the fighter since they'll see more data in the dashboard, and can respond outside the context of a macros in combat for on the fly manuvers. Multiplayer for this is simple because the 'config' of the ship becomes shared across multiple players who might want to specialize in say 'weapons-systems' and designing weapons programs (macros), while someone else manage propulsion, and someone else manages everything and is a dashboard watcher and relays to the other guys. Programmatically, we can do this as follows:

> show active ship
You're not in a ship!
> board ship Breaker_1
> show active ship
Breaker_1

> show party
You're not in a party!
> invite h3lios
Waiting for response, press Ctrl+C to cancel invitation

-----

Player1 is inviting you to join their party! Do you accept? [y/n]: y

-----

h3lios has joined your party!
> show party
Player 1
h3lios

At this point, options for sharing views opens up:

> share ships h3lios
Now when h3lios does:

> show ships

He'll see his ships and player 1's ships, he can request to enter those ships:

> enter ship Player1s_ship

----

h3lios would like to board Player1s_ship!  Do you accept? [y/n]: y

and from then on when an engagement happened, the following OOO would take place:

Is this player partied?
 If yes
  Are they in the same ship?
   If yes
    Ship object is shared, their commands both impact the same ship, effictively dual control
Is this player partied?
 If no
  Are they in A ship?
   If yes
    Their individual ship is used in the combat for single control

We can talk more later on implementation.

[deontologician]

I think we should be able to fire and simulate from the command line. Later we can add the game portion

[deontologician]

This functions as a good "master issue" for how we want the commandline to end up eventually.

This is good stuff, keep it coming. I'm handing #31 to Cara to get the ball rolling.

[deontologician]

I have digested a lot of this, and I like it.

The idea I'd been kicking around previously was that when building a ship you need to connect the Terminal's Bus to the component you were working on. If you didn't connect, you wouldn't get any diagnostic messages (things might still succeed or fail, but you wouldn't hear about it)

In terms of "write a commandline from scratch" you can see the cmd usage Cara did in the commandline.py module. Essentially these sub-shells you're talking about would just be different instantiations of a commandline initialized with different values. So the ship commandline would accept a ship as a constructor arg, then start its loop. When that loop was finished, you'd exit back into the outer loop seamlessly.

I love the merchant concept and the hangar concept. I'd say we could hold off on implementing them, but I don't think they'll be significantly more complicated than just a default Hanger and a default Shop. If you go through the trouble of implementing one, you can implement multiples.

[deontologician]

BTW, in case you hadn't seen it, the commandline module has been merged into master, so you could try fleshing out some of these ideas if you want

[xXxH3LIOSxXx]

Cool glad you're liking it, it's nothing original, this format works for this type of thing or else Cisco wouldn't be the top CLI in the industry, and agreed that once you've made the first form of the shell all the sub-iterations are just copy/paste/slight edits as they all work in the same way.

I agree for now, doing all of this is crazy, the point behind the extensive example is to get the feel for the overall picture and syntax, if we all like it and just design incrementally with it in the background I think we'll have a smooth sail. I haven't had time to check the other issues or the .py itself, but I should within the next day or two. There are already some open source emulators for the cisco IOS CLI's out there, and eventually I may crack them open and see if I can just replace their interface labeling and adapt it to our needs. .. why re-invent the wheel right?

[deontologician]

Well there's two costs here:

1. we would need to integrate a C library into python. not impossible but a bit of work
2. We'd need to determine what we didn't need from it and pull it out

In this case, since our needs will evolve as we flesh out the game, I'd probably recommend building the CLI from scratch. I say from scratch, but the cmd library python comes built with is pretty decent. It's not a lot of coding to build what we want, and I think it'd take a lot longer to understand the Citrix code, and then extract the relevant parts.

That being said, if you were planning on familiarizing yourself with their code anyway, it could be a good source of inspiration. Maybe get some more good ideas from it

[xXxH3LIOSxXx]

Yeah definitely, I should have time over the weekend to get caught up on the core .py files and start reading on the library, I will eventually get around to demoing my examples up there, I already know how I would lay it out from a code perspective, it's the syntax now I need to dredge up.