Free Epic Campaign - The Pirates of Drinax

[Elrick]

I've always ruled that you can enter jump at any speed and exit it at the same speed.

However, although space is big and empty, there is the outside chance you could exit jump space close to a micrometeorite or some other object or debris. Your jump program couldn't know it was there and your sensors wouldn't give you any warning until you were back in normal space (and the feedback from the jump bubble had subsided), so if you were going flat out when you exited jump the first you might know about it was when it smacked a hole in your ship.

For that reason, my players prefer to enter jump at a relatively low speed and do a short range scan as their first task at their arriving system.

There is also the problem that any news you have of conditions in the system you are jumping to is a minimum of a fortnight old (one jump from there for the news and one jump to there for you). I once ran an adventure based around the very start of the fifth frontier war where the players jumped into a system a few hours after a Zhodani battlefleet. Zapping around the target system fast before you know what is occurring (especially in the middle of a battle) may make for an interesting adventure - or possibly a frantic one...

 

[Hans Rancke]

The thing is, there's no such thing a zero velocity, only zero velocity in a specific reference frame. So what the rules as written has the ship doing is accelerating for half the journey from orbit to jump limit and decellarating for the other half, coming a stop relative to the departure world, then do a jump and arrive at the jump limit of the destination world, and then accelerate for half the inbound trip and decelerating for the other half, coming to a stop relative to the destination world.

This would only work if the departure and destination worlds happened to have the exact same vector relative to each other, something that is mind-bogglingly unlikely and guaranteed not to be true twice in a row.

I believe the RAW represent a simplification for game purposes. In "reality", the ship would be laying a course that would give it a zero velocity relative to the destination world when it arrives at the jump limit of the departure world. But since that would complicate calculations for no real gain, the simpler version is used for gaming purposes.


Hans

 

[BP]

IIRC, the RAW is only explicit for interplanetary transit times (and the table is wrong in most printings - see errata). Jumping can happen at any velocity - so ship doesn't need to decelerate to 'relative zero' to jump.

Other than having a 100D limit and rolls for mis-jumps, the rest is basically undefined.

A crude way to handle it is add the 100D limits for departure and destination worlds and then use interplanetary transit times. Ship may thus be still accelerating, or decelerating at the time of jump. Like everything else, it is still only a crude representation that ignores most things (starting velocities from orbit or planetary orbit, directions, the 3rd spatial dimensions, gravity, etc...).

 

[Hans Rancke]

IIRC, the RAW is only explicit for interplanetary transit times (and the table is wrong in most printings - see errata).

All interplanetary travel assumed "constant acceleration to midpoint, turnaround, and constant deceleration to arrive at the destination at rest" [The Traveller Book, p. 54]. The typical travel times to safe jump distance for various sized worlds listed in the tabel on the same page conform to this.

Jumping can happen at any velocity - so ship doesn't need to decelerate to 'relative zero' to jump.

It can happen at any velocity, but usually ships decelerate to "rest" as the typical travel times show. (There's also an explicit mention of typical jumps as opposed to so-called "running jumps" somewhere, but I can't recall where).


Hans

 

[BP]

... [The Traveller Book, p. 54]. The typical travel times to safe jump distance for various sized worlds listed in the tabel on the same page conform to this.

In that version of Traveller. :wink:

RAW for Mongoose Traveller does not say the same thing nor even imply it by listing safe jump distances on its table on page 145 of the Core.

Further the RAW for other versions of Traveller explicitly does mention 'non-zero' jumps in various places and the reverse is not explicit.

 

[Rikki Tikki Traveller]

Given that most referees don't have detailed relative velocity tables for each world to every other world within jump distance AND that those tables would be continually changing as the world's orbit their star, the stars move within the galaxy, the galaxy moves in the Local Group and the Universe expands... (and about a dozen other movements that I haven't mentioned)

Using the Zero Relative Velocity assumption is a GAME SIMPLIFICATION that makes sense.

Want to make it more complicated and more realistic? Go for it. But in a GAME, using the ZRV assumption is fine for me.

 

[BP]

Yep - and it works fine for world to world - whether in-system or between systems

Jump with zero to zero (departure to jump limit in space) followed by zero to zero (jump limit to destination) is more complicated than zero to zero. Add the 100D limits and consult the table (or formula) once to get time - or consult the table (or formula) twice, once for each separately, and then add those results accounting for 24 hours in a day, 60 minutes in an hour - more steps and more math.

Thus, Jump without an additional 'zero relative velocity' step is a greater GAME SIMPLIFICATION that makes sense. Especially as in-game it reduces travel times and avoids ships coming to an arbitrary 'stop' in space.

 

[Hans Rancke]

... [The Traveller Book, p. 54]. The typical travel times to safe jump distance for various sized worlds listed in the tabel on the same page conform to this.

In that version of Traveller. :wink:

Mongoose's version of Traveller is based on previous versions. They are entitled to retcon anything they like, of course, but until and unless they do so, previous versions are perfectly valid evidence as far as I'm concerned. The most important aspect of a shared universe is consensus; that those who share it are on the same page. Everyone is entitled to say "That's not how I do it", but then they're no longer on the same page as the rest.

If Mongoose has explicitly said "We're doing things differently now; ships make running jumps, not at-rest jumps (and, retroactively, they never did make at-rest jumps)", then that's the page to be on if you want to share with the rest. But if they merely didn't mention it at all, for whatever reason (word count, simplification, author didn't think about it), then as far as I'm concerned the old rules still apply.

Mind you, if everybody else reaches a consensus that differs from my take, I'll go along with the majority.

RAW for Mongoose Traveller does not say the same thing nor even imply it by listing safe jump distances on its table on page 145 of the Core.

So what does MGT has to say about calculating time to jump point? If it's nothing whatsoever, I submit that the old rules still apply (and shame of Mongoose for omitting such an important rule; I can't imagine what my players would say if I told them that I had no idea how long it would take them to get from orbit to jump limit).

Further the RAW for other versions of Traveller explicitly does mention 'non-zero' jumps in various places and the reverse is not explicit.

I'm going to go out on a limb here and say that you're wrong about that. As I said, I can't remember where I read about running jumps in the old versions, but I'm pretty confident that whenever running jumps are mentioned, they're contrasted with at-rest jumps (and that the at-rest jumps are the normal way to do it).

I'm sorry I can't provide a reference. I suppose I could be misremembering, but I don't think I am.


Hans

 

[Denalor]

Chuckle… the kinds of discussion one sets off when merely commenting on a couple of numbers.
I’m sorry for causing this hiccup.
Indeed I happened to check on Scoundrel and obviously the chapter on piracy was from there... including the wrong numbers

Hmm, I’m far from being even remotely learned in astronomy, but I certainly would have assumed that plotting a jump does of course include the vector aspect of velocity.
Simplified: when travelling out to the 100D mark you do align your ship so that your velocity vector does point towards the destination planet.

[Shrug]
Even so, I think the best approach is indeed to do the simple zero to zero for each planet. Apply a misjump with something like (negative) Effect *10% (or whatever) and do it all again.

Coming to thinking on it, I always find that the 2-weeks power supply of the free trader is too short.

BTW, what has me puzzled repeatedly is the Jump to Gas Giant to refuel. I mean, even if we take the relative small Neptune, it’s still about 49.500km diameter and that would be some 39h for the free trader single way (zero to zero). I mean, 39h ??? Pirate food, no ?

 

[BP]

Mongoose's version of Traveller is based on previous versions.

My Mongoose books make no mention of requiring previous edition rules.

In this particular case - it doesn't even seem explicitly defined in the past and Mongoose hasn't redefined anything. Mongoose gives jump limit as 100D and defines M-Drive Gs. That is all in relation to time to Jump. Mongoose RAW, as far as I know it.

Its certainly your choice whether you perceive a majority you want to go with. However, a 'shared universe' exists regardless in the form of the published game, anything more is really your personal definition and will differ due to that which is not defined.

I'm going to go out on a limb here and say that you're wrong about that.

Not much of a limb :lol:

Its your words and a mention (upthread, or another ?), re: a Challenge article that are the basis of the statement you are questioning.

You've stated you aren't familiar with what MGT has to say about calculating time to jump point - the Mongoose RAW - and you've given nothing explicit from past editions that states how traveling to Jump has to occur, even if that were relevant. Feel free to apply your old rules - I neither said it was incorrect nor a bad idea. My suggestion is simpler overall - steps and math - and doesn't require an explanation that is also not written in Mongoose RAW as far as I know - re: 'stopping' before jumping.

Anyway, I personally use a totally different approach.

I use a program and account for initial velocity and destination world orbital position, orbital velocity, and incoming velocity. Hand-waving away with in-game 'rationalizations' that intersystem differences are negligible given local stellar region (IMTU); and, using gravitics that allows ignoring local gravity or taking advantage of it (destination world only - ignoring n-body and other gravitational assists at this time). I don't just suggest my own mechanics, as they would not be nicely 'playable' without programs - heck, my whole TU mapping is 3D and has been for decades.

Whatever works IYTU. Mongoose RAW is open enough in this regards that it works in a 'shared universe' as well - i.e. no way is really 'wrong' or counter to that as long as 100D and 10 m/s2 is used.

 

[BP]

Chuckle… the kinds of discussion one sets off when merely commenting on a couple of numbers.
I’m sorry for causing this hiccup. ...

No problem that I see ... this topic and many like it cause discussion because the rules are not explicit, nor cover everything - some of which, at least, was surely intentional.

I respect Hans and haven't seen any disrespect from him - we are both accustomed to such discussions, I believe. If everyone only posted what others were interested in discussing, and no-one had differing opinions or made mistakes, then there wouldn't be much on forums. :wink:

...
Coming to thinking on it, I always find that the 2-weeks power supply of the free trader is too short.

BTW, what has me puzzled repeatedly is the Jump to Gas Giant to refuel. I mean, even if we take the relative small Neptune, it’s still about 49.500km diameter and that would be some 39h for the free trader single way (zero to zero). I mean, 39h ??? Pirate food, no ?

:lol: Way to avoid the contentious areas!!!

Power and fuel usage has always been an issue given what is calculated about fusion power and neglecting actual M-Drive usage.

The 100D limit is even more of a hot topic - especially regards the 100D limit for stars. In my CT games I long ago solved this with a formula (without knowing it as a bigger OTU issue) - my Jump safe limit is 100D only for standard density worlds and works out quite a bit less for GGs and significantly less for large stars.

 

[Hans Rancke]

Mongoose's version of Traveller is based on previous versions.

My Mongoose books make no mention of requiring previous edition rules.

I fail to see what relevance that has.

In this particular case - it doesn't even seem explicitly defined in the past and Mongoose hasn't redefined anything.

Wrong. See below.

Mongoose gives jump limit as 100D and defines M-Drive Gs. That is all in relation to time to Jump. Mongoose RAW, as far as I know it.

If I was running an MGT campaign and my players asked how long it would take to get from orbit to jump point, I would first look up the rules in my MGT Core rulebook. Noting that the rules doesn't mention anything about how to figure that out, I'd fall back on the rules in The Traveller Book. I think that makes a lot of sense to assume that if the MGT rules don't explicitly mention that things have changed then things haven't changed.

Its certainly your choice whether you perceive a majority you want to go with. However, a 'shared universe' exists regardless in the form of the published game, anything more is really your personal definition and will differ due to that which is not defined.

The problem with your argument is that it cuts both ways. It doesn't say that at-rest jumps are used, but it doesn't say that running jumps are used either. If you go with running jumps and I go with at rest jumps, you can't use any nifty ideas I and the half of the others who do it my way may come up with and I can't use any nifty ideas that you and the half of the others who do it your way come up with. A clear loss all round. If, OTOH, we reach a consensus, everybody can use what everybody else comes up with. That is, IMO, a much better way to go about things.

One simple example is Joe Newbie who fails to find the rule he needs to figure out things for himself in the MGT Core rulebook and asks for help on these boards. Being the helpful people we both are, I provide him with one figure and you provide him with another, much to his confusion.

I'm going to go out on a limb here and say that you're wrong about that.

Not much of a limb :lol:

I dislike making statements that I can't provide references for. So when I do, I tend to point that out. (When I do it deliberately, I mean; I sometimes make such statements inadvertently, much to my chagrin when someone challenges me on it).

Its your words and a mention (upthread, or another ?), re: a Challenge article that are the basis of the statement you are questioning.

What do you mean? I don't recall talking about any Challenge article.

You've stated you aren't familiar with what MGT has to say about calculating time to jump point - the Mongoose RAW - and you've given nothing explicit from past editions that states how traveling to Jump has to occur, even if that were relevant.

That's not true. I quoted the explicit rule just a few posts back.

"All interplanetary travel assumed "constant acceleration to midpoint, turnaround, and constant deceleration to arrive at the destination at rest" [The Traveller Book, p. 54]."

Nothing is mentioned about an exception for travel to and from jump points. And to show that there is no such exception:

"...The typical travel times to safe jump distance for various sized worlds listed in the tabel on the same page conform to this."

Whatever works IYTU.

Oh, I have no trouble whatsoever doing things my way in MTU. It's just completely irrelevant to how things work in the (note the singular) "real" OTU.

Mongoose RAW is open enough in this regards that it works in a 'shared universe' as well - i.e. no way is really 'wrong' or counter to that as long as 100D and 10 m/s2 is used.

Rules that are open enough to cause doubt and confusion is the very antithesis of something that works well in a shared universe. If there's no way to say how things "really" work but the various ways are mutually exclusive, it's impossible to apply them all to the same universe.


Hans

 

[Hans Rancke]

Coming to thinking on it, I always find that the 2-weeks power supply of the free trader is too short.

I've always felt that the unbelievably inefficient fusion power plants were wrong, wrong, wrong. The fix I use IMTU is to ignore power plant fuel tankage completely (There is some, of course, but it falls below the scale of the shipbuilding rules).

BTW, what has me puzzled repeatedly is the Jump to Gas Giant to refuel. I mean, even if we take the relative small Neptune, it’s still about 49.500km diameter and that would be some 39h for the free trader single way (zero to zero). I mean, 39h ??? Pirate food, no ?

Gas giant refuelling is usually a horribly false economy. It will usually cost more in lost revenue than you save on fuel bills. But for that very reason pirates would be less of a risk, as no pirate would lurk in a place where no prey is likely to come by.


Hans

 

[Denalor]

I use a program and account for initial velocity and destination world orbital position, orbital velocity, and incoming velocity. Hand-waving away with in-game 'rationalizations' that intersystem differences are negligible given local stellar region (IMTU); and, using gravitics that allows ignoring local gravity or taking advantage of it (destination world only - ignoring n-body and other gravitational assists at this time). I don't just suggest my own mechanics, as they would not be nicely 'playable' without programs - heck, my whole TU mapping is 3D and has been for decades.

:shock: I wonder if you're kiddying.
No offence mate.
I guess, once the maths are clear (or copy-pasted from NASA... :lol: ), it's just a program and that's about it, kindo like I do with Visual Basic as add-on to the Excel-sheets I usually employ, e.g. for trade simulations.
However, introducing 3D in whatever you mean by "whole TU" seems daunting indeed, especially if one contemplates the presentation of said map.
And well, as concerns decades... unless you had access to quite sophisticated mapping tool I don't really expect that map to be hand-drawn :wink:
I wonder though, putting that kind of man hours into this... do you actualyl benefit from it ? These sort of project are usually only for the GM's own benefit, i.e. stretching one's world/universe building muscles.
How often, do you actually employ these tools.
Guess what I'm saying is I truly envy the free time you had at your hands to do that thing.
If I could squeeze out some 2h per week I'd be happy.

Oh, and that idea about 100D reduction due to density is a nice one. Need to juggle that around in my head some of these days.

Well, anyway, thanks for the elaborations everyone...

Now we wait for the continuation of the campaign

 

[BP]

...
:shock: I wonder if you're kiddying.

Not at all. It's not rocket science or anything!

• Hehe - I've never worked for NASA, but my dad was working for them when I first began writing Traveller programs! I've worked with research folks who work with ESA and NASA today (but sadly never on anything spacebound) and my dad's last two major projects were instruments now outbound to Pluto and Jupiter. I even got to touch (er, with cloth gloves) an instrument that right now is on its way to Jupiter! http://missionjuno.swri.edu/

I started writing programs for Traveller before I even personally owned any books (third game IIRC) back in the early '80s - as a teen. Definitely with lots of free time available - and, er, invested! Travel and orbital equations are actually pretty simple. [Ignoring n-body gravity, eccentricy, relativity, solar wind, integral position calculations for inter-orbit travels, and such. ] Its the raw number crunching that can become a real challenge, even back then when I could mentally, accurately, do 9 digit division with remainder in under a minute - something my dad's expensive calculator couldn't accurately do (nowadays, lucky to add two numbers together and get the same result, much less the correct one ).

Fortunately, when it came to the travel equations, I had already learned assembly language and knew how to make my own number handling routines to handle large numbers (as the numeric precision standard on 8-bit computers of the day was very limited). Today's software can handle these fairly well without any fancy programming.

As to time invested vs usefulness - I had only a few CT LLBs. All sector mapping and NPCs and my entire TU was basically my own creation. Having programs that allow generating a list of NPCs, trade goods, animal encounters, subsectors, systems, and encounters on the fly, not to mention design programs for pre-game starship design (never created an auto-gen for that) really makes maximum use of play session time. Even had some personal and starship combat aids - though ended up going more RP with this over the years. Really, its hard for me to imagine Ref-ing without those aids for pre-game and real time support.

As to the 3D TU - I started with Mylar sheets layered to visualize and handle overlapping 3D in play for a subsector at a time (had to photocopy from custom coded dot matrix printouts as this was before the days of print drivers and laser printers or even the HP Paintjet and I didn't have access to a plotter for years). The coordinates were still only in 'parsec' precision. Within systems, though, I used 3D routines with pixel/line graphics in the '80s - custom made PC PHIGS emulator (pre-cursor to OpenGL) in the late 90s so I could do 20-sided worlds with image mapping (hardware level coding, so might have issues running on today's hardware). Around 2000 I implemented the OTU 35 sectors in 3D using OpenGL with coordinates that are not integral parsecs. Systems do not overlap and jump distances are not calculated on 3D distance - everything still simplifies perfectly down to regular 2D rules. Spent more time searching the internet and cleaning up sector data than anything else. :roll:

Between license restrictions and the fact that all my programs are written for my specific hardware and way of doing things (especially where rules are vague, conflicting or missing) - I've never had an inclination to publicly release things. That takes a lot more time and effort. (Kudos to folks like Inexorabletash on COTI of http://www.travellermap.com fame!)

Today - one can do all of these things using Javascript or Excel (even 3D graphics).

...
Oh, and that idea about 100D reduction due to density is a nice one. Need to juggle that around in my head some of these days.

Well, it has worked for me for quite some time - don't juggle too hard unless you like numbers. I'm actually planning on writing that one up for sharing - it should work with tables just fine so folks don't have to deal with the calcs and numbers (which between size 0 worlds and Ia stars is an exceptional range ).

 

[Hans Rancke]

Oh, and that idea about 100D reduction due to density is a nice one. Need to juggle that around in my head some of these days.

It's an old idea that IMO would be perfect for Traveller. Unfortunately, Marc Miller has expressly disallowed it. He was asked about it back when they were writing GT:Far Trader and made it absolutely clear to the person who asked him that jump limit was based on diameter, not tidal force (which would perform as BP described).


Hans

 

[BP]

Marc Miller has full say in what is published under his license. GT:Far Trader and whatever decision was made is totally his call to make, change, etc. What anyone does in their own games is an entirely different matter - something he has stated himself and that several of the books go over as well.

If you think something is perfect for Traveller - it is your choice to use it if you want. Even share it if you like - as long as you are not violating copyright nor FFE's policy related to such.

Choosing to do so may invalidate your creations with published material - you take that 'risk'.

Mongoose Traveller RAW states 'A ship can only safely jump when it is more than one hundred diameters distant from any object.' It also states gravity can cause a ship to 'fall out' if within 100D during the jump (though poorly edited and not explicitly worded). This is actually more explicit than The Classic Books, FFE 001, which only make reference to worlds and no reference to gravity having an impact (that I am aware of).

There are plenty of ways to customize the 100D limit - mine isn't anything special that hasn't been thought of numerous times, I am sure. Changing it for me has no negative impact - heck, in nearly 30 years I actually haven't really made much use of the idea, as almost all jumps have happened with standard planets and pretty much ignored the 100D for stars anyway.

It has, however, been a fair sized deal to some OTU folks - given the randomly generated stars and routes (which probably followed other rules - thus the 100D becoming a 'breaking' point). It also lacks a good in-game explanation.

 

[Hans Rancke]

Marc Miller has full say in what is published under his license. GT:Far Trader and whatever decision was made is totally his call to make, change, etc. What anyone does in their own games is an entirely different matter - something he has stated himself and that several of the books go over as well.

No argument there. It's still unfortunate, because it affects official game material. A system where the mainworld is a week's insystem travel inside the 100 diameter solar jump limit is a completely different system from one where the mainworld is well outside the tidal force solar jump limit. Which means that if I tell my players that solar jump limits are based on the second, I have real problems using a system writeup that is based on the first.

(The fact that Traveller writers have ignored solar jump limits for 35 years helps quite a lot, I admit. :wink: )

It's totally my call to use any and all of the official material and any and all fan material. But it's a great help to me to be able to use as much of the material others produce as possible, because it saves me time and allow me to spend my limited setting-creating time on other things.


Hans

 

[tneva82]

Marc Miller has full say in what is published under his license. GT:Far Trader and whatever decision was made is totally his call to make, change, etc. What anyone does in their own games is an entirely different matter - something he has stated himself and that several of the books go over as well.

No argument there. It's still unfortunate, because it affects official game material. A system where the mainworld is a week's insystem travel inside the 100 diameter solar jump limit is a completely different system from one where the mainworld is well outside the tidal force solar jump limit. Which means that if I tell my players that solar jump limits are based on the second, I have real problems using a system writeup that is based on the first.

Well. Conversely if things got changed then the guys who are using things as now would have problems using the new stuff for opposite reason...

 

[Captain Jonah]

Marc Miller has full say in what is published under his license. GT:Far Trader and whatever decision was made is totally his call to make, change, etc. What anyone does in their own games is an entirely different matter - something he has stated himself and that several of the books go over as well.

(The fact that Traveller writers have ignored solar jump limits for 35 years helps quite a lot, I admit. :wink: )

Hans

The economy would colapse, star travel would become an imense undertaking, many of the ship designs would not work etc etc. A week to reach the jump limit, a week in jump space and a week heading back. Say how much fuel do we have. Plenty, a whole two weeks wor................ Erm ref :shock: