Improved method for noting Holonet Relay Construction

A forum for general discussion and announcements.
Mercury
Mercury
Brend
Brend
User avatar
Mercury
Storyteller
 
When processing my turn report I noticed that besides the ones pointed out by Brend, there were additional numbering issues in my previous turn report. Since it was hanging me out of the throat (sic), and to prevent issues regarding numbering in the future, I decided to significantly simplify my Holonet Relay bookkeeping.

First off, I've changed how I note down Holonet Relay stations. Instead of having many individual upgrade stations, I have made a singular entry for a holonet relay station, which lists the total capacity in the sector and which includes an entry "Upgrade Stations" which lists the number of additional upgrade stations (always equal to (Capacity - 500) / 500). I have edited my IO Protocol Bookkeeping Holonet page to follow this scheme, and if someone feels the desire, they can check to make sure I fairly converted this.

Additionally, I have modified the way in which I note down Holonet Upgrades. The old notation is this:

old wrote:Holonet Relay Base Station __ ( (:hex) __ __) construction: + __ (:holonet-relays) -> __COMPLETE (__ / 150 (:holonet-relays) )
Holonet Relay Upgrade Station __ ( (:hex) __ __, attached to __) construction: + __ (:holonet-relays) -> __COMPLETE (__ / 100 (:holonet-relays) )


The new way I use is as follows when building a new station in a sector where you don't have anything yet:

new wrote:New Holonet Relay Base Station __ ( (:hex) __ __) construction: + __ (:holonet-relays) -> __COMPLETE (__ / 150 (:holonet-relays) )
New Holonet Relay Upgrade Station __ ( (:hex) __ __, attached to __) construction: + __ (:holonet-relays) -> __COMPLETE (__ / 100 (:holonet-relays) )
New Holonet Relay Upgrade Station __ ( (:hex) __ __, UNATTACHED) construction: + __ (:holonet-relays) -> __COMPLETE (__ / 100 (:holonet-relays) )


The only change here is that I added "New", and I made a separate "UNATTACHED" entry in case of Holonet Relay Upgrade Stations being built with no base station (in which case they won't work)

To upgrade to a duplex station, the following notation is used:

new wrote:Holonet Relay Base Station __ ( (:hex) __ __) to become Duplex Station: + __ (:tax), + __ (:ict-technology) -> __COMPLETE (__ / 100 (:tax), __ / 200 (:ict-technology) )
Holonet Relay Upgrade Station __ ( (:hex) __ __) to become Duplex Station: + __ (:tax), + __ (:ict-technology), + __ (:holonet-relays) -> __COMPLETE (__ / 100 (:tax), __ / 200 (:ict-technology), __ / 50 (:holonet-relays) )


I removed the 'attached' entry (since it isn't relevant to the upgrade) and made it a "to become" entry. In case of an upgrade from Base to Duplex which immediately follows, attachment is noted as a separate entry (see below)

To upgrade an existing Base, Upgrade or Duplex Station with additional capacity:

new wrote:Holonet Relay __ Station __ ( (:hex) __ __) upgrade; + __ (:holonet-relays) -> __COMPLETE (__ / 100 (:holonet-relays) )


Note that here too, I removed the 'attached' entry as it is irrelevant. I added a __ to note the current type of the station, and I marked it as "upgrade" instead of "construction", to further help distinguish it from a new station

Finally, to attach or unattach, I use the following notation:

new wrote:Holonet Relay __ Station __ ( (:hex) __ __) to attach to __
Holonet Relay Duplex Station __ ( (:hex) __ __) to become self-supporting


Where of course the first can never be a Holonet Base Station (but Upgrade and Duplex are fine) while the second one must be a Holonet Duplex Station, since a Holonet Base Station is -always- self-supporting while a Holonet Upgrade Station cannot be self-supporting.

This notation has several advantages:

  • Separating the attachment information except where necessary makes the entry cleaner.
  • Splitting different actions makes the turn report easier to assess.
  • Splitting new stations and upgrades to existing stations makes checking more natural and eliminates confusion as to whether a new station is built or an existing one is upgraded
  • Since upgrades have no names, for all practical applications, holonet stations can be identified in turn reports by their coordinates only, eliminating number-string name classes

I propose making this new notation the norm.

For your convenience, here is a comparison between the two notations for my turn report this turn:

OLD STYLE wrote:Holonet Relay Upgrade Station 0-01010-1-00110-000111 ( (:hex) 10 -6, attached to ic:veolian_commonwealth_bookkeeping#base_station_10_-6 ) construction: + 100 (:holonet-relays) -> COMPLETE (100 / 100 (:holonet-relays))

Holonet Relay Upgrade Station 0-01100-1-00101-001010 ( (:hex) 12 -5, attached to 0-01100-1-00101 ) construction: + 100 (:holonet-relays) -> COMPLETE (100 / 100 (:holonet-relays))

Holonet Relay Upgrade Station 0-01101-1-00100-100101 ( (:hex) 13 -4, attached to 0-01101-1-00100 ) construction: + 45 (:holonet-relays) -> COMPLETE (100 / 100 (:holonet-relays))
Holonet Relay Upgrade Station 0-01101-1-00100-100110 ( (:hex) 13 -4, attached to 0-01101-1-00100 ) construction: + 55 (:holonet-relays) -> INCOMPLETE (55 / 100 (:holonet-relays))


NEW STYLE wrote:Holonet Relay Duplex Station 0-01010-1-00110 ( (:hex) 10 -6 ) upgrade: + 100 (:holonet-relays) -> COMPLETE (100 / 100 (:holonet-relays))

Holonet Relay Duplex Station 0-01100-1-00101 ( (:hex) 12 -5 ) upgrade: + 100 (:holonet-relays) -> COMPLETE (100 / 100 (:holonet-relays))

Holonet Relay Duplex Station 0-01101-1-00100 ( (:hex) 13 -4 ) upgrade: + 45 (:holonet-relays) -> COMPLETE (100 / 100 (:holonet-relays))
Holonet Relay Duplex Station 0-01101-1-00100 ( (:hex) 13 -4 ) upgrade: + 55 (:holonet-relays) -> INCOMPLETE (55 / 100 (:holonet-relays))
Post Brend » Thu Sep 17, 2015 11:10 pm
User avatar
Brend
 
Mercury wrote:First off, I've changed how I note down Holonet Relay stations. <snip>


I'm not against having a new way of noting down data, but I do not see why you did not opt to do it like all other players do? There's a perfectly fine model which comes from Proposal: Change in Holonet Relay Station modelling (and was further defined by Rules change: Holonet Relays) where you have one Base Station/Duplex Station entry and one entry for the 'swarm' of upgrade stations related to it.

Now, instead of adopting the convention, you switch to a representation that obfuscates the actual situation: you do have upgrade stations, you're just not noting them down, not really a problem for people but tools won't pick them up. Now we have two different formats for noting down stations (XKCD 927 :P)

It doesn't matter much right now, yet for the use of technologies and such upgrade stations, base stations and duplex stations are are different, so keep that in mind. (Also... Now I'm really curious why you don't just use the convention, because you probably have a good reason for not doing so. Maybe we can all switch to your model, and have an easier time allround? ^_^)

Mercury wrote:Additionally, I have modified the way in which I note down Holonet Upgrades. The old notation is this:

<snipped awesome new notation>


I strongly support this, and will update the tax tooler to autogenerate these templates instead of the old one. I shall do this soon™.

There's two things that I'd suggest though: in the trade fleet upgrade we mention the current capacity and the upgraded capacity, which helps match turn report entries when you have multiple upgrades (it really does ^_^), and makes looking back in the history easier.

So, in short, I suggest:
Holonet Relay __ Station __ ( (:hex) __ __) upgrade (+500 (:holo-trade) to __ (:holo-trade)): + __ (:holonet-relays) -> __COMPLETE (__ / 100 (:holonet-relays) )


((Moderator voice: I have moved this topic from "Game Design & Rules Discussion" to "General Discussion" since no game design or rules discussion is contained in this topic))
Post Mercury » Fri Sep 18, 2015 2:25 pm
User avatar
Mercury
Storyteller
 
First off, and as an aside, I in the strongest possible way support your suggestion to note the capacity in the upgrade entry!

that having been said, I see that I failed to specify some things - probably because I went through my post to eliminate superfluous material with a bit too much zeal. This also explains why my post appeared to be in the wrong place, but I'll get to that later. For now, let me describe the three issues I have with the current system:

  • It is clumsy and confusing

The listed system spreads entries out over multiple data blocks. This means each sector has several data entries, rather than a singular entry covering the entire sector.

Moreover, having multiple entries gets confusing: as they must be added up to count the actual capacity. This becomes apparent, for example, in the Veolian Commonwealth Bookkeeping page. I look to the lower left corner of the screen an see "Upgrade Cluster 12 -7". I note that Sector 12 -7 has a capacity of 1500. But this is incorrect. "Hidden" on the previous line, there's a duplex station in the same sector which has another 500 capacity, so the total is actually 2000. Your mileage my vary due to screen resolution, but you catch my drift, I think.

This became especially problematic in my [url=http://www.fwurg.net/dokuwiki/ic:io_protocol_bookkeeping_holonet?rev=1442475377]old holonet bookkeeping page. Sector 13 -4 had a whopping 38 entries. Note that I did not blob them together as with the Veolian Commonwealth, which brings me to the next point:

  • It is inaccurate and incomplete

By the rules, each holonet upgrade station is a separate station operating independently. This is quite clear from the [url=http://www.fwurg.net/dokuwiki/rules:holonet_relay_stations]rules for Holonet Relay Station[/rules]. In other words, it is not the case that a second upgrade station is an expansion to the first one which gives it additional capacity (nor is it noted down as such).

As such, noting it down as an "upgrade cluster" with a capacity of more than 500 is inaccurate. But it also leaves the notation incomplete: since they are separate upgrade clusters, each cluster can be attached to a different base station. For example, both the Veolian Commonwealth and the Astrian Colonial Authority have base stations in Sector 10 -6. If I brokered a deal with the Veolians that I can attach, at most, 10 upgrade stations, I could then broker the same deal with the ACA to connect a total of 20 upgrade stations, half to each base station - a "blob" notation does not allow this.

I want to note that no such double deals currently exist (though there is a singular deal between the IO Protocol and the Divine Fiefdom of Highmons), but it is technically allowed to do this.

The way the Veolian Commonwealth bookkeeping is noted makes it impossible to do this, unless you press space to split-jump, but there's no known notation for this in turn reports. Moreover, it'd make it harder to verify if a turn report was correctly processed if multiple blobs start splitting and recombining - it'd be a headacke.

Now, I might solve this by never forming the blob in the first place (as my old notation) - that way I can simply attach individual holonet upgrade stations. But if I replace the base station in busy sectors, it would become a very long turn report, listing dozens of almost identical entries which'd switch.

And that brings me to the third issue:

  • It isn't uniform

Most players want to not have 38 entries, so they make a blob. This to me makes sense. However, others want the freedom attach separately without having to do blob splits that aren't in the turn report, but that do alter the bookkeeping pages, so they make individual entries for each station in accordance with how holonet relay stations are defined in the rules. And that leads to different notations between players.



Now, this all having been said, I left out another part, hoping to first get a positive responses to my new notation. I also want to make a minor change the game rules regarding how Holonet Relay Stations work to better align with how people use and think of them, which will also fit exceptionally well with the new notation, as well as the way we actually use Holonet Relays. This is why I put it in Game Design & Rule Discussion, which was no longer accurate after I left this part out to save on wall-of-text. As a side note that this change is not dependent upon any scale changes to the map and should in fact make such changes easier in the future.

I propose that any player can only ever have a singular holonet relay station in a given sector. That station will be either a base station, an upgrade station or a duplex station, with the exact same abilities as before. instead of having additional upgrade stations, that station can have a number of upgrades equal to 0 or more - similar to upgrades on a zone or trade fleet. This is effectively exactly the same thing as having additional upgrade stations in the sector in the current rules connected to one of the stations (be it upgrade, base or duplex), and covers 100% of all existing cases, except now it can be noted as a singular entry.

So far this seems mostly identical to the current rules (and it is), but it removes two options which nobody uses anyway, and which lead to the clumsy old system:

First, a single player can no longer have multiple base stations / duplex stations in a single sector. Nobody did this, because its plain stupid, but technically this was allowed. Whether you'd blob them together or make separate entries, I don't even want to think about. Regardless, I don't feel this is a great loss.

Secondly, you can no longer connect to multiple different base stations with different capacity. This was possible before (see above) was a cause for different notations. But in practice, nobody was using the option anyway. I will note that the case for the Divine Fiefdom of Highmons / IO Protocol deal is unaffected since there is no second station there: capacity limitations over a certain path are still possible. Moreover, in home sectors such as with the Divine Fiefdom of Highmons, we can't even have multiple players with base stations if the sector owner doesn't agree, making competition for shared capacity mostly a mute point. As a result, I don't feel this is a great loss either, while the benefits are numerous.

Brend correctly notes that listing the number of upgrades in the new system is a bit weird - it is required before the rule change (so the new style "blob" can be split up again), but can be eliminated once the above rule change takes effect.


Together, the new notation and the rule change will significantly simplify how Holonet Relay Stations work. It will unify and standardize notation between players, make things easier on tools (no adding of numbers, there will be a unique entry for each player in each sector), allowing for easier tables as well, and it will ensure that the rules represent the way in which most players are already, de-facto, using the system.

What do others think of this?
Post Brend » Fri Sep 18, 2015 3:00 pm
User avatar
Brend
 
Might I suggest that next time instead of first changing everything up, you start with the clean and simple rules proposal from which all other things neatly flow into place :P


As expected, there's a good reason behind the sudden change. Convinced by your arguments, I can get behind a rules change that works on the basis of the constraint of one holonet relay station per faction per sector!

As an aside: I do feel that your proposal reduces the complexity of the system at the expense of the "deal making power" of factions. Since you are the player most benefiting from the Holonet, I feel compelled to explain this. The scenario: a restriction that a foreign faction F not attach more than X upgrades to your station in sector S might be a deal-breaker in the new system, while in the old system F could agree and immediately open negotiations with a third faction that maintained an attachable station in sector S as well. I'm not saying that this is a real problem, but it does change negotiation positions in a non-trivial manner, especially on the Bozzy Spine where several factions maintain base stations.


I look forward to seeing the actual rules change proposal -- I have the nagging feeling that there's some hidden complexity in there somehow that I can't quite put my finger on at the moment -- so I can check it against the current rules for debuggin :)

PS. Make a new thread for the rules proposal? That way we have a nice and clear rules proposal, instead of one three long posts into another thread.

Return to General Discussion

cron