Classic Traveller

[RobP]

I'm currently humming and arring between FG and Klooge.

One question I'd like to ask is....

Is FG2 a D20 system only, or is it known as this simply because of the default ruleset?

Would it be possible to model Classic Traveller with the system? Or would the internal architecture prevent this.

I'm quite a dab hand at programming and know XML and many other languages (see https://AncientArmies.co.uk for my latest project), so I think I have the technical skills to pull it off.

Thanks
RobP

[Sorontar]

https://oberoten.dyndns.org/fgwiki/i...ssic_Traveller

That should help you a little it's discussed in a thread hereabouts by it's developer Foen

[Foen]

Hi Rob and welcome to the FG forums - hopefully we can help and you'll find us friendly

As Sorontar mentions, you can download a Classic Traveller ruleset from the FG Wiki (see his link, above), and I'd say it was pretty useable but represents a first attempt. In particular:

• The ruleset includes standard FG elements (character sheet, images/maps, NPCs, notes, items, encounters, combat tracker, stories) but doesn't provide specific lists for other Traveller elements (vehicles, worlds, systems, subsectors). Starships are included in the items list, and the other eleemnts can be added to the stories list or (in the case of deck plans) included as image files.
• It can store characters (like pen and paper) but doesn't have a character generator. Likewise there are no subsector generators, starship build automation etc. It is a place to store and retreive campaign data, not a mechanism for generating that stuff. It could be added, however, but I haven't done so thus far.
• There are no rulebooks included with the ruleset. This is a major limitation of non-commercial rulesets, because you need the permission of the copyright holder to redistribute that sort of material (it falls outside of the scope of the FFE fair use policy).
• I don't currently have a playtest group, so this has been built but not tested and should be considered a beta version at best. My assumption is that pretty much everything should work how you want it, but please report any bugs to me on these forums or by PM. The most likely area to cause bugs to appear is when you share the combat tracker: the multi-user access to data on the tracker (which is also accessed by character sheets and minisheets) is the hardest part of FG to code robustly.

Some screenshots are posted in the Gallery:

https://www.fantasygrounds.com/forum...ad.php?t=11400

Once you've had a look, if you want to help extend the ruleset for the other features then I'd be delighted for the help!

All the best

Foen

[Spyke]

We should arrange a playtest soon. If I get some time I'll set something up as GM (got to get my head back into those CT mechanics!), but I'm happy to join as a player.

Spyke

[ddavison]

Foen is a very accomplished ruleset developer who has done both commercial and free community rulesets. I highly recommend his work.

[Oberoten]

Not to mention a wonderfully helpful person. As you have allready seen.

- Obe

[RobP]

Wow! Thanks for all the feedback.

It looks like it can indeed support a classic traveller campaign - which is very good news.

I'm now at the point of having to make a decision.

From the testing I've done FG is much more stable on my system and doesn't suffer from some issues like invisible writing in handouts compared to Klooge.

However, from what I have seen FG seems to lack, Hex grids for maps (would be nice for subsector maps) and a direct linkage between a token and the character it represents.

I was suprised at discovering the former as hexes are pretty much run-of the mill for outdoor/space rpg maps. I'm guessing a way of mitigating this is to import the maps with hex grids already on them.

The latter one is a bit harder to explain It seems to me that although a token can be associated with a character - the token itself has no knowledge of the character from whence it came. This means that on a map with a few characters it could be confusing to remember who is who, unless the tokens are imported with names?

The other downside to this lack of linkage is that one cannot get direct shortcuts to the character from the token.

Despite these two niggeling issues, FG does seem to do everything I need. I'm not after massive automation - after all part of the fun is looking stuff up in tables! and FG's representation of a tabletop seems to work very well.

Speaking of tables and maps - I can resize the maps but they seem to be limited to a max frame size? Is there a way to get around this? I have a pretty big monitor and it would be advantageous to take advantage of the space.

Is choosing a VTT always this hard? I have been researching this for a week and I'm still on the fence between Klooge and FG! Hopefully I will make my mind up soon and get buying so that I can get started!

Thanks Everyone
RobP

[Oberoten]

Hexgrids is part of FG since 2.6.0. It is just not always immediately evident.

And yes, the tokens gets a popup on them with the name of the character if they are dragged to the map from character-sheet, portrait or combat tracker. (Depending on ruleset of course. )

- Obe

[Foen]

On the subject of hex grids, the CT ruleset has an option (look under 'Prefs' on the desktop) to show an image toolbar, set this to 'Yes' and you will see a toolbar at the top left of your maps. The toolbar gives you an easy way to select hex or square grids for each map.

You will want some of the grids to be square, for indoor tactcal purposes.

If I recall correctly, the ruleset doesn't yet support the ability to change the scale (which defaults to one grid area = 1.5 metres), so measuring distances on hex subsector maps isn't exactly helpful.

As Obe says, first put characters/NPCs on the combat tracker, then drag the combat tracker token to the map. That way the token on the map will be linked to the character/NPC.

Foen

[Spyke]

FG does have a maximum frame size for images (this can be changed in the ruleset itself), but remember that although you may have a large monitor it's possible that your players don't. What may look great on your screen may not work on your players'. Keeping the image size smaller helps with this, and also with file transfer times.

I'm not saying it's wrong to increase the size, it can be very helpful, but that it's worth considering whether it's really needed.

Spyke