Travel Times and Communication Speeds
Open in chat • 12 posts (analysis)
• Page 1 of 1
-

Mercury - Storyteller
I wanted to provide a reminder and some background regarding the speed at which things go, as established in the early days of Fwurg.
Hyperspace travel by ship takes 10 days per hex on the map, or about 10 lightyears per hour. This is an upper bound, not a lower limit - some ships may be slower. It is possible to go a bit faster, but not a lot.
The only exception to that is using hyperspace lanes. These significantly speed up travel times. The bozzy spine makes speeds go x10, so travel through hexes on the map along the bozzy spine takes one day per hex. Local hyperspace lanes, as provided by the Union, doubles speed, so travel through those hexes takes 5 days.
In general, within a single hex, you may fairly presume real-time communications. It does not matter if it is between planets or systems or from one edge to the other. Communication between hexes is generally too slow to maintain a live stream. Instead, a message is sent out, and a message is received, as if by letter.
The exception is using existing Holonet Relays. These speed up communications and allow live conversations over extended distances, provided both sides are connected.
While it is not explicitly defined, you may presume your homeworld is hooked up to the Holonet of NPC Union members over the Bozzy Spine so you can communicate live with the Union government (or your own if you are present on Unity).
Any significant amounts of information cannot be transmitted but must instead be carried over by data-crystals.
Again, the exception is using Holonet Relays. These have focussed point-to-point links which have far higher bandwidths and can transport data on an industrial scale.
Travel Speed
Star Wars is a fictional setting, which means travel often goes at the "speed of plot", people arriving the time that the plot calls for. In general we follow this, but there are some guidelines regarding distance as well:Hyperspace travel by ship takes 10 days per hex on the map, or about 10 lightyears per hour. This is an upper bound, not a lower limit - some ships may be slower. It is possible to go a bit faster, but not a lot.
The only exception to that is using hyperspace lanes. These significantly speed up travel times. The bozzy spine makes speeds go x10, so travel through hexes on the map along the bozzy spine takes one day per hex. Local hyperspace lanes, as provided by the Union, doubles speed, so travel through those hexes takes 5 days.
Communication Speed
Communication is faster than using hyperspace to travel, but it is still limited.In general, within a single hex, you may fairly presume real-time communications. It does not matter if it is between planets or systems or from one edge to the other. Communication between hexes is generally too slow to maintain a live stream. Instead, a message is sent out, and a message is received, as if by letter.
The exception is using existing Holonet Relays. These speed up communications and allow live conversations over extended distances, provided both sides are connected.
While it is not explicitly defined, you may presume your homeworld is hooked up to the Holonet of NPC Union members over the Bozzy Spine so you can communicate live with the Union government (or your own if you are present on Unity).
Communication Bandwidth
Holonet communication is limited to basic data such as text, speech and a simple hologram and subject to minor errors. Most sentients can deal with a mispronounced A or a glitchy picture, but computers don't like that. Surely you can send MP3s or a short video, but not large files or scientific data or secret plans, for example.Any significant amounts of information cannot be transmitted but must instead be carried over by data-crystals.
Again, the exception is using Holonet Relays. These have focussed point-to-point links which have far higher bandwidths and can transport data on an industrial scale.
I think we should put stuff like this on the wiki -- maybe we need a few 'setting' pages in the rules namespace?
I agree, maybe we can save this for the next write-a-ton?
Anyone know where we could place this info on the wiki?
I'm doubting between the rules: and ic: namespaces. It would do well as rules:setting.
I'm doubting between the rules: and ic: namespaces. It would do well as rules:setting.
rules:setting with subsections sounds good to me.
I don't have a good reasoning for not placing it in ic:travel like ic:hyperspace, but it seems like it would fit in the rules.
I don't have a good reasoning for not placing it in ic:travel like ic:hyperspace, but it seems like it would fit in the rules.
The only reason I have, admittedly rather shaky, is that this is not really an in-character piece of text. It seems to more of a guideline on RPing.
The text might not be IC, but it is relevant IC.
I think setting also is better then rules, so maybe re-writing it will help.
I think setting also is better then rules, so maybe re-writing it will help.
Stuiter wrote:The text might not be IC, but it is relevant IC.
Agreed, but as is, this text simply outlines some of the aspects of the setting. These things are common knowledge IC; especially the data thing.
I feel that they are best placed together with some other setting comments like: "No teleportation, No time travel, No midichlorians." in a rules:setting page...
You know... I just found this exact text on the wiki: rules:travel.
Maybe we should move it a little :P
Maybe we should move it a little :P
or make it more findable ;)
And combine it with some notes on 'No midichlorians', 'No vader' :P
I have moved the notes to the Setting page.
Can somebody filter through hyperspace as well, and see what needs to be moved to the rules namespace? I found it difficult to do so immediately, but some things are just rules: the no-imulse thing for example.
Can somebody filter through hyperspace as well, and see what needs to be moved to the rules namespace? I found it difficult to do so immediately, but some things are just rules: the no-imulse thing for example.
12 posts (analysis)
• Page 1 of 1

