Dynamic Sector Map Idea
- Thread starter DangerousThing
- Start date
What's the tidal formula you are using?
Also, for added complications and fun, you can consider the different relative vectors to the systems star that each system has.
Since each system has its own motion relative to the galactic core, a 0 vector in System A is 0 relative to the star of System A. The vector for System B will be different, yet you retain your 0 vector from System A when you arrive from jump.
So, you may well have a vector of some velocity as soon as you enter, which will need to be compensated for (for example you may well have a nice, fast vector directly away from your destination as soon as you arrive).
I bring it up as a complicating factor since you have the option of correcting that vector before or after jump. That brings up the details of safe operation (is it safe to jump in to a system with some hurtling vector). It probably is. I don't think the relative vectors of the different systems is likely that large, but I don't know.
But if the vector needs compensating before jump, then you'll need consider that in the plot for exit. In a trivial example, you may need to maneuver to the 100D limit, and beyond just so you can turn around heading back the way you came to build the compensating vector. Adding a jump shadow of a local star, just adds more to the fun.
Also, for added complications and fun, you can consider the different relative vectors to the systems star that each system has.
Since each system has its own motion relative to the galactic core, a 0 vector in System A is 0 relative to the star of System A. The vector for System B will be different, yet you retain your 0 vector from System A when you arrive from jump.
So, you may well have a vector of some velocity as soon as you enter, which will need to be compensated for (for example you may well have a nice, fast vector directly away from your destination as soon as you arrive).
I bring it up as a complicating factor since you have the option of correcting that vector before or after jump. That brings up the details of safe operation (is it safe to jump in to a system with some hurtling vector). It probably is. I don't think the relative vectors of the different systems is likely that large, but I don't know.
But if the vector needs compensating before jump, then you'll need consider that in the plot for exit. In a trivial example, you may need to maneuver to the 100D limit, and beyond just so you can turn around heading back the way you came to build the compensating vector. Adding a jump shadow of a local star, just adds more to the fun.
"Very wrong" is subjective. In reality it just means added in system travel distance to jump point.
No different, in effect, than trying to jump to Mercury even when you can see it line of sight.
DangerousThing
SOC-13
No, it means you either need more time, or you have to plan your routes more carefully so that the jumps are clear. It also gives a merchant ship a reason to have a better M-Drive than M-1, to get to the proper point faster.
Jump line occlusion is something from the new editions that IMTU I simply do not use.
Travel takes long enough in game that I often have to gloss over it to keep my players from going ADD, so one more set of calculations that drag out what should be quick and easy travelling during game play is not something I will use.
In fact, the Jump occlusion stuff that has been and is being published above and beyond "You jump in at the planets 100D limit, unless the planet is within the stars or gas giants 100D limit" is usually way to crunchy for most of my players, and usually way to much work to actually bother with its use during game.
My players want to play a game, not play with calculators.
HOWEVER, while I do not intend to use much (if any of this) stuff in my games, I will however use it in my writing.
Soldier on!
~Rich
Travel takes long enough in game that I often have to gloss over it to keep my players from going ADD, so one more set of calculations that drag out what should be quick and easy travelling during game play is not something I will use.
In fact, the Jump occlusion stuff that has been and is being published above and beyond "You jump in at the planets 100D limit, unless the planet is within the stars or gas giants 100D limit" is usually way to crunchy for most of my players, and usually way to much work to actually bother with its use during game.
My players want to play a game, not play with calculators.
HOWEVER, while I do not intend to use much (if any of this) stuff in my games, I will however use it in my writing.
Soldier on!
~Rich
DangerousThing
SOC-13
My players want to play a game, not play with calculators.
HOWEVER, while I do not intend to use much (if any of this) stuff in my games, I will however use it in my writing.
Soldier on!f
~Rich
I don't want the players to have to use calculators, which is why I want to write an app for it. I put in the date. Connect the points and the app pops out any problems.
What Rich is saying is that adding an extra amount of in-system travel time, even using an app, is the kind of "bad for play" modality that his players would reject outright, swearing at the GM for using such a rule. ANd the app is still a calculator.
Mine are much the same. I use Tidal force, but I only use endpoint checking for occlusion - treating jump as a parabola that takes you "over" (in axis J) the intervening space.
I think Marc's made a REALLY bad choice in T5 making the whole course part of the blocking, because it means 1/4 to 1/6 of systems (2d or 3d) are obscured sufficiently to render them non-viable for commerce at any given point. It makes the stock setting quite different than that described in CT's adventures. It breaks GT even - trade routes are unstable. You're adding a week of travel in many cases. In some, more than. Which breaks a merchant's profit margins badly.
For those who want to use it, fine... enjoy... but it's bad for the OTU setting, and severely restricts trade due to the need to "keep going" on a 2 jumps a month schedule to make payments. It's worse for Hans and My lines running 3-4 jumps a month - adding a week of N-space travel to each jump makes them cut their income in half, while cutting expenses by only about 1/3.
Last edited:
In 3d-space, wouldn't that be an octagonal wedge, i.e. 1/8th the space?
And, don't the probabilities add... i.e. in 2-d space, there's a 75% chance that one side, the other side, or both sides will be blocked?
Last edited:
I've never seen a rule on this. Maybe in T5 but I don't have those rules.
No. It' will be a cone of 100° - measue ±50°. You define a square by a pyramid with the edge centers ±45°. A cube is 6 such centerline±45° And octogon is 360/8=45° wide, or centerlines±22.5°, and there is no regular solid defined by octagonal space...
This doesn't have to be a crunchy mechanic.
Rather can be considered a "seasonal" mechanic, since for two particular systems it happens at different times of the local system "year".
So, it could be something similar to a "trade wind" mechanic where the trade winds performed differently (and thus lengthened or shortened particular trade routes) during particular times of year. I don't know if our actual trade winds manifested something like that or not, but it's still a useful analogy.
Because this isn't something that changes daily. Once shadowed, the planet will stay shadowed for some time. Much like the length of day changes seasonally, the length of travel will slowly lengthen day by day until it reaches some peak and then it shortens.
Now, there is a complicating factor that as the two systems orbit at (likely) different speeds, you have the shadows of both systems to deal with. But the overall point is that the travel times can change like the tides, astrogators would be well aware of this, and it would simply be a normal circumstance of trade.
"Oh it's winter there and summer here, so we need to add a week to the shipping time." This adjustment is something that can be handled by referee fiat without having to do any number crunches.
When System A is in Spring, add 2 days. In Summer add 1 day, fall and winter, zero days. Same with System B. If A is in Spring and B is in Spring, add 4 days. It varies by M-Drive, and perhaps my estimate of days is wrong, but that's the gist of it.
Give each planet a note as to which season is in which month, and go with it. System A has Spring from May through July. System B has Spring from October through December. Go to each system and roll a D12 for the "Winter start" month and go from there.
They don't even have to be out of sync with each other (i.e. where one systems year is faster enough than the other that they get out of sync from one (or more) year to the next). Since most habitable worlds have similar orbits, they'll have similar periods to where over the span of 5 years, there will be little overall change in these delays from year to year. So, set it up once, make a note for each system, and then just keep track of the month, and be done with it. You get the flavor, you get the impact, and all of the math is gone, and it takes maybe a 1/2 hour of time to set it up once for your cluster of worlds.
It also gives faster (Higher M-Drives) traders a distinct advantage as the non-jump space time of travel becomes more a factor in the overall shipping time during bad seasonal delays.
Rather can be considered a "seasonal" mechanic, since for two particular systems it happens at different times of the local system "year".
So, it could be something similar to a "trade wind" mechanic where the trade winds performed differently (and thus lengthened or shortened particular trade routes) during particular times of year. I don't know if our actual trade winds manifested something like that or not, but it's still a useful analogy.
Because this isn't something that changes daily. Once shadowed, the planet will stay shadowed for some time. Much like the length of day changes seasonally, the length of travel will slowly lengthen day by day until it reaches some peak and then it shortens.
Now, there is a complicating factor that as the two systems orbit at (likely) different speeds, you have the shadows of both systems to deal with. But the overall point is that the travel times can change like the tides, astrogators would be well aware of this, and it would simply be a normal circumstance of trade.
"Oh it's winter there and summer here, so we need to add a week to the shipping time." This adjustment is something that can be handled by referee fiat without having to do any number crunches.
When System A is in Spring, add 2 days. In Summer add 1 day, fall and winter, zero days. Same with System B. If A is in Spring and B is in Spring, add 4 days. It varies by M-Drive, and perhaps my estimate of days is wrong, but that's the gist of it.
Give each planet a note as to which season is in which month, and go with it. System A has Spring from May through July. System B has Spring from October through December. Go to each system and roll a D12 for the "Winter start" month and go from there.
They don't even have to be out of sync with each other (i.e. where one systems year is faster enough than the other that they get out of sync from one (or more) year to the next). Since most habitable worlds have similar orbits, they'll have similar periods to where over the span of 5 years, there will be little overall change in these delays from year to year. So, set it up once, make a note for each system, and then just keep track of the month, and be done with it. You get the flavor, you get the impact, and all of the math is gone, and it takes maybe a 1/2 hour of time to set it up once for your cluster of worlds.
It also gives faster (Higher M-Drives) traders a distinct advantage as the non-jump space time of travel becomes more a factor in the overall shipping time during bad seasonal delays.
The example illustrations of jump-masking (GT Far Trader p.59 or Mongoose Traveller Core p.141, for example) suggest to me that jumps are in straight lines. That may very IYTU, of course.
Excellent! Thanks for pointing that out.
Bingo! Thanks SpaceBadger
I've never used the jump masking in MTU, as I understand that jump is into an alternative universe where gravity wells don't have to extend, and the fact that ships never exit jump under 100 d of a large body is due to real space stress, not jump space one (and jump shadow too disruptive). But that's IMTU...
Anyway, for jump shadow to have effect we must assume all system orbits are in the same plane as our 2 D map, while they could as well be inclined relative to it, or even perpendicular to the map, in which case there would be no jump shadow derived from departing/arrival stars, while keeping as true the statement on MgT Core Book Spacebadget talked about...
Or they could be mixted, so leaving the jump shadow to the referee whim (or interest), or represented by the slim possibility of a missjump.
Anyway, for jump shadow to have effect we must assume all system orbits are in the same plane as our 2 D map, while they could as well be inclined relative to it, or even perpendicular to the map, in which case there would be no jump shadow derived from departing/arrival stars, while keeping as true the statement on MgT Core Book Spacebadget talked about...
Or they could be mixted, so leaving the jump shadow to the referee whim (or interest), or represented by the slim possibility of a missjump.
Nope. See aramis' calculations earlier in thread.
Actually, no, there's no 2D requirement. If you project a straight line from where the ship is to where the ship wants to go, and there is a gravity bubble "in the way", you have a jump shadow. The gravity bubble doesn't have to be "near" either end. For example, you could be at Jupiter on one side of the Sun and want to do a in-system jump to Saturn, which happens to be on the complete opposite side of the Sun, and the Sun will block you from doing that in a single jump, even though it's mostly "in the middle".
Gravity wells break "line of sight" for Jump. I have not read T5, in the JTAS Jump article, it suggests that if you cross one of these "bubbles" you will be pulled from Jump. This suggests that there is the (extremely) remote chance that rogue planet or dead star happened to be on the jump line, it COULD pull you out of Jump mid stream and plop you in the middle of nowhere. But it's a fine explanation for referee fiat when your recently maintained ship misjumps.
The basic premise is that interstellar space isn't dense enough to where this really becomes enough of a problem to worry about rogue objects, and we simply assume that intervening systems are unlikely to be on the exact route of two other systems, so as to not add even more complexity, even if all of the systems are considered to be on the same plane. Instead, the mechanic tends to manifest at the source and destination systems, because the 100D of the main star has such a commanding presence over the two systems and much more likely to interfere.
I've never run a merchant campaign, nor a planetary assault, both of which could be affected by jump shadow. I suspect that if I ran a merchant campaign I would still ignore the sort of shadowing we've been discussing, even though it sounds valid.
Based on a higher than originally believed number of rogue planets, IMTU there is not a "big sky small bullet" assumption, but rather that is what makes navigation difficult, plotting around the various 100D of the myriad objects potentially in the way, before, during, and after jump. Keeping accurate, four-dimensional maps of these millions of objects and their vectors is one of the crucial jobs of the IISS.
I don't get into the mechanics of what is an essentially iconic system; I don't try to get into the interface between 2D, 3D, and 4D with my players. here are enough variables that I do not know, and enough science I would just have to plain make up, that we would never even get a parsec.
