Sensors Jim Vassilakos (18 Sep 2021 22:42 UTC)
Re: [TML] Sensors Evyn MacDude (18 Sep 2021 22:51 UTC)
Re: [TML] Sensors Kurt Feltenberger (18 Sep 2021 23:03 UTC)
Re: [TML] Sensors Rupert Boleyn (18 Sep 2021 23:07 UTC)
Re: [TML] Sensors Kurt Feltenberger (18 Sep 2021 23:16 UTC)
Crunchy vs Squishy [WAS: Re: [TML] Sensors] Greg Nokes (18 Sep 2021 23:24 UTC)
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors] Mark Urbin (19 Sep 2021 14:10 UTC)
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors] Bruce Johnson (20 Sep 2021 18:55 UTC)
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors] Zane Healy (20 Sep 2021 23:27 UTC)
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors] Mark Urbin (21 Sep 2021 00:45 UTC)
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors] Phil Pugliese (21 Sep 2021 04:32 UTC)
Re: [TML] Sensors Rupert Boleyn (18 Sep 2021 23:54 UTC)
Re: [TML] Sensors Evyn MacDude (19 Sep 2021 00:15 UTC)
Re: [TML] Sensors Thomas Jones-Low (19 Sep 2021 00:08 UTC)
Re: [TML] Sensors Evyn MacDude (19 Sep 2021 00:33 UTC)
Re: [TML] Sensors Phil Pugliese (19 Sep 2021 16:57 UTC)
Re: [TML] Sensors Jim Vassilakos (20 Sep 2021 23:32 UTC)
Re: [TML] Sensors Alex Goodwin (21 Sep 2021 16:33 UTC)
Re: [TML] Sensors Jim Vassilakos (21 Sep 2021 20:17 UTC)
Re: [TML] Sensors Phil Pugliese (21 Sep 2021 21:13 UTC)
Re: [TML] Sensors Kurt Feltenberger (21 Sep 2021 22:40 UTC)
Re: [TML] Sensors Rupert Boleyn (21 Sep 2021 23:47 UTC)
Re: [TML] Sensors Phil Pugliese (21 Sep 2021 23:54 UTC)
Re: [TML] Sensors Alex Goodwin (24 Sep 2021 19:02 UTC)
Re: [TML] Sensors Timothy Collinson (25 Sep 2021 17:28 UTC)
Re: [TML] Sensors Alex Goodwin (25 Sep 2021 19:09 UTC)
Re: [TML] Sensors Nokes.Name (25 Sep 2021 21:15 UTC)
Re: [TML] Sensors Alex Goodwin (26 Sep 2021 09:12 UTC)
Re: [TML] Sensors Nokes.Name (26 Sep 2021 15:43 UTC)
Re: [TML] Sensors Alex Goodwin (26 Sep 2021 16:43 UTC)
Re: [TML] Sensors Nokes.Name (26 Sep 2021 16:45 UTC)
Re: [TML] Sensors Timothy Collinson (27 Sep 2021 07:00 UTC)
Re: [TML] Sensors Bruce Johnson (27 Sep 2021 17:56 UTC)
Re: [TML] Sensors Rupert Boleyn (27 Sep 2021 23:27 UTC)
Re: [TML] Sensors Timothy Collinson (27 Sep 2021 07:00 UTC)
[TML] Dodgie by name, dodgy by nature(?) Alex Goodwin (27 Sep 2021 19:37 UTC)
Re: [TML] Sensors Rupert Boleyn (21 Sep 2021 23:44 UTC)
Re: [TML] Sensors Alex Goodwin (22 Sep 2021 08:13 UTC)
Re: [TML] Sensors Jim Vassilakos (22 Sep 2021 14:51 UTC)
Re: [TML] Sensors David Shaw (22 Sep 2021 15:07 UTC)
Re: [TML] Sensors Jim Vassilakos (22 Sep 2021 16:26 UTC)
Re: [TML] Sensors Thomas Jones-Low (22 Sep 2021 20:35 UTC)
Re: [TML] Sensors Phil Pugliese (22 Sep 2021 19:30 UTC)
Re: [TML] Sensors Rupert Boleyn (22 Sep 2021 20:30 UTC)
Re: [TML] Sensors Phil Pugliese (22 Sep 2021 22:36 UTC)
Re: [TML] Sensors Jim Vassilakos (23 Sep 2021 16:05 UTC)
Cian Rants About dTons (Was Re: [TML] Sensors) Cian Witherspoon (23 Sep 2021 04:27 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Evyn MacDude (23 Sep 2021 04:55 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Cian Witherspoon (23 Sep 2021 06:39 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Rupert Boleyn (23 Sep 2021 06:54 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Cian Witherspoon (23 Sep 2021 07:15 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Rupert Boleyn (23 Sep 2021 06:13 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Cian Witherspoon (23 Sep 2021 06:46 UTC)
Re: Cian Rants About dTons (Was Re: [TML] Sensors) Rupert Boleyn (23 Sep 2021 06:57 UTC)
Re: [TML] Sensors Alex Goodwin (19 Sep 2021 06:16 UTC)
Re: [TML] Sensors Phil Pugliese (19 Sep 2021 16:46 UTC)

Re: [TML] Sensors Alex Goodwin 21 Sep 2021 16:32 UTC

Comments interspersed.

On 21/9/21 9:32 am, Jim Vassilakos - jim.vassilakos at gmail.com (via
tml list) wrote:
> Thomas suggested GURPS:Vehicles. The only useful range table I found
> in GURPS was in GURPS:Traveller:First In in the sidebar of page 124,
> but it’s incomplete, but once you know there’s a -6 range modifier for
> every factor of ten, you can figure that’s -1 for every factor of
> 1.4678, roughly speaking. And while ships in GURPS have size
> modifiers, no doubt affecting their signature, I haven’t found
> anything talking about emitted vs reflected signatures. For example, I
> think that if you’re trying to find some asteroid, for example, it
> should matter how close it is to the nearest star, as well as how much
> light that star is outputting, and also the reflectivity of the
> asteroid should be taken into account. There’s honestly no system that
> does all this, at least not as far as I can tell.

I also went this route, because it allows PCs to at least be able to
attempt sensor feats at least as fancy as what I am capable of in real
life.  A trivial example being sticking my head out the back door and,
with unassisted pair of Mk 1 eyeball, hooked to a Mk 1 brain, detecting
Alpha thru Epsilon Crucis, each at least 69 pc away.

No doubt Jeff Zeitlin will split his sides over _me_ saying this, but
you _might_ be overcooking the detail.

Ceteris fnordibus, two same sized objects, one with albedo 1.000 at
distance 10X will throw as much reflected energy towards your sensors as
one with albedo 0.0100 at distance X - so you could drop the
lower-albedo's effective size mod by -6 (in GURPS terms) per 100x
reduction in albedo, prorated accordingly.

IIRC, GT:FI also mentions that stars should receive a _bonus_ to their
signature (above and beyond their size - eg Sol having +56, Rigel having
+67 and Rho Cassiopeiae having +73) from their intrinsic luminosity. 
Assuming hyperspectral telescopes, I'd expect brown dwarfs to get no
bonus, and active stars would get a bonus depending not on their
_spectral_ class but their _luminosity_ class (M-class hypergiants
getting a bigger luminosity bonus than B-class main sequence stars).

>
> I should probably listen to Phil, who basically says to just wing it.
> Normally, that would probably be what I’d do, but the problem is Table
> 195 in T4’s FF&S makes it clear that when you look at range on a
> logarithmic scale, you end up with a narrow band where the sensor
> operator’s skill comes into play. For a wide set of ranges on either
> side of this band, detection is either assured or impossible. Which
> means that if you are specific in your gaming (or writing) about how
> far away something is, then whether or not it can be seen is probably
> baked into that range estimate, and if you wing it, you’re probably
> going to end up getting it wrong. It’s not a big deal in gaming,
> unless you have an astronomer at the table, but in writing, you don’t
> know who your readers are going to be, and if you flub the science,
> then it’s no longer hard-SF.
You and I obviously have different player expectations - my mobs tend
(and have tended) towards preferring rational knowability (which has
caused a lot of GRRR about MGT2).
>
> Evyn & Kurt suggested I stick with CT or MT. MT has passive EMS on
> pages 70 and 88 of the Referee’s Manual, however, there are obvious
> problems with this. For one thing, given the logarithmic scale of the
> ranges, one should expect a much tighter grouping when it comes to
> difficulty. Secondly, it doesn’t seem to take the size of an object
> into account. Are we looking for an object 50 meters wide or 50
> kilometers wide? I hate being the one to say it, but sometimes size
> matters.
See above re: GT:FI bitz.  I've ripped it off essentially holus-bolus,
converted the mods to G4 (to square up with the sensor deets from
GT:ISW), then wedged the kitten kaboodle into the increasingly-thin MGT2
shell that is Parental Advisory.
>
> Now, I get that having a wide spread when it comes to difficulty makes
> for a more cinematic game. Players generally want the actions of their
> characters to matter. And they like to roll dice. So I get why from a
> gaming experience, CT/MT is superior to T4:FF&S in this regard.
Something I just tumbled to, Jim - are you designing for _cause_ or
_effect_ here?
>
> <Excellent T4 discussion snipped - was getting a bit beyond my ken at
> 0230 local and me not knowing where my socks are>
>
> -----
> The Traveller Mailing List
> Archives at http://archives.simplelists.com/tml
> <http://archives.simplelists.com/tml>
> Report problems to xxxxxx@simplelists.com
> To unsubscribe from this list please go to
> http://www.simplelists.com/confirm.php?u=BOJXpTlhq8JLuOsJzSV1RtNTE9qsN8u5
>
--