George: ShipTables and ItemTables, adding (to) stations

[alterecco]

I was talking to DigDug earlier today on IRC, and we came to discuss the problem of adding ships or items to stations in the vanilla game. Say, if you want to have your meaner meth enforcer be docked at black markets... How do you do that currently. Well, you can override the station and change it's <Ships> section, or you can add an <OnGlobalSystemCreated> event that looks for black markets and adds the ships via script. The same goes for adding items to stations. Both ways are slightly cumbersome, and present their own problems.

So, we talked about a solution. Extend the syntax of <ShipTable> and <ItemTable>. We propose something like the following as a solution (up for discussion of course)

Code: Select all

<ShipTable UNID="&myBMShips;"
  criteria="+blackMarket; +populated"
  levelFrequency="-vruc cur--"
  chance="25"
  >
  <Ship count="1d3" class="&myBMEnforcer;" orders="guard" />
  ....
</ShipTable>

The above piece of xml will have a 25% chance of adding 1-3 ships to populated black market stations in lvl 2-8 systems (some systems more often than others). Whenever a station is generated, it would have to look through all the ShipTables, check if criteria match, and then roll the dice to generate.

It is a simple and unobtrusive way of adding content to the vanilla game, something that is often asked about, on IRC and here on the forums. The syntax for ItemTables would be much the same. Inside the table we can have the same type of syntax we have in Ships and Items, that is, Groups, Tables, Lookups etc....

It is possible that some of the attributes are not required, or that some more are needed. Maybe it is a bad idea to piggyback off the `ShipTable` and `ItemTable` types, but it seemed the obvious place to start.

I hope we can have a good talk about how this could work, and that we can end up seeing it in game. It would be a great tool in the arsenal of modders, and would solve the old question of "how do i get item X and ship Y to appear at station Z".

I would also like to add another question to the list, something that is a bit related. "How do i get station X to appear in systems of type Y (or, in system Y) at locations of type Z (or, at location Z). It is another one of those questions that get asked a lot, and to which there are no solid answers. I imagine it can be solved with some of the topology syntax being applied to a similar construct as the one defined above. It would be very cool! Perhaps we can also devote some time to brainstorm on that.

I hope you don't mind all the rather large engine questions that have come up in the last couple of days George... I guess it is vacation time :)

[george moromisato]

I like that suggestion. I offer a few enhancements:

1. Maybe we call it ShipTableOverride.
2. There is a flag on it that specifies whether the new table replaces the stations Ships section or adds to it.
3. I think levelFrequency and chance could be moved to the <Ship> element.

Obviously we could do the same thing for ItemTableOverride.

[alterecco]

I am glad you like it. I would love to see something like this available to modders.

A thought occured to me however. If we are making a new element to hold these adjustments, why not collapse them into one element? The syntax for adding items and ships are practically the same, so they could easily be added in one go. How about the following:

Code: Select all

<StationAdjustment
    UNID=           "&myBMAdjustment;"
    criteria=       "+blackMarket; +populated"
    type=           "add"
    levelFrequency= "----c"
    >
    <Items>
        [standard <Items> element stuff]
    </Items>
    <Ships>
        [standard <Ships> element stuff]
    <Ships>
</StationAdjustment>

If the above were the case, then we could also end up being able to adjust several other elements of stations, such as <Reinforcements> and <Trade>. We would however need to keep the levelFrequency attribute on the main element.

I don't know if it is overkill to implement it like that. It seems to keep more of the original syntax and allows for expansion down the line.

I definitely agree with your point nr. 2. There needs to be a flag that specifies whether to replace or to add. In the above example i named it type, but `operation` might be a better term (among others i suppose).

[digdug]

since we already have <shiptables> and <itemtables> that supports levelFrequency, I thought that if <StationAdjustment> would simply accept a UNID, this would be enough.

Code: Select all

<StationAdjustment
    UNID=           "&myBMAdjustment;"
    StationUNID= "&stBlackMarketStation;"
    type=           "add"
    >
    <Items>
        [standard <Items> element stuff or itemtables]
    </Items>
    <Ships>
        [standard <Ships> element stuff or shiptables]
    </Ships>
    <Reinforcements>
        [standard <Ships> element stuff or shiptables]
    </Reinforcements>
</StationAdjustment>

[alterecco]

It seems that the <Ships> and <Items> elements have no arguments (in vanilla at least). Also, if we use the current object criteria syntax, we can target a specific unid by doing: criteria="+unid:&stBlackMarket;".