GURPS 4E Core Ruleset

[Exalted]

Can we have "effects" that auto apply modifiers to rolls? I currently use "modifiers" for Lightning conditions for example, but it would be handy to have a "Moonlight: -3" effect to have that applied to every roll someone with said effect makes.

Edit: Another question: connected as a player, the combat tracker groups PCs on top with Enemies on the bottom regardless of Basic Speed (as GM I see them ordered in their actual turn order) Is this by design?

[ronnke]

Can we have "effects" that auto apply modifiers to rolls? I currently use "modifiers" for Lightning conditions for example, but it would be handy to have a "Moonlight: -3" effect to have that applied to every roll someone with said effect makes.

Edit: Another question: connected as a player, the combat tracker groups PCs on top with Enemies on the bottom regardless of Basic Speed (as GM I see them ordered in their actual turn order) Is this by design?

Short answer to your effects question, is yes, but when this could become available is another matter. It will feature eventually.

Re, the combat tracker...Yes, that is by design. In the options you can toggle just how much tracker information is available to players, so if you want your players to know NPC turn order then you can configure it.

[Exalted]

Short answer to your effects question, is yes, but when this could become available is another matter. It will feature eventually.

Re, the combat tracker...Yes, that is by design. In the options you can toggle just how much tracker information is available to players, so if you want your players to know NPC turn order then you can configure it.

Right, then. Thanks, Ronnke!

[knucklehead]

My wishlist:

Freeze CoreRPG requirement to avoid the "Rolling Release Blues/Everything Broke...Again" issue? Conceptually, I guess, it'd be keeping your own CoreRPG "branch" with the ruleset and then being able to merge to the new CoreRPG foundation when compatibility has been confirmed?

You know, for those of us that, em, always upgrade to the new shiny before considering dependency issues.

[Andraax]

My wishlist:

Freeze CoreRPG requirement to avoid the "Rolling Release Blues/Everything Broke...Again" issue? Conceptually, I guess, it'd be keeping your own CoreRPG "branch" with the ruleset and then being able to merge to the new CoreRPG foundation when compatibility has been confirmed?

You know, for those of us that, em, always upgrade to the new shiny before considering dependency issues.

You can already do that. The client uses an unpacked ruleset by preference over a packed one. So, unpack the version that you know works and leave it out there. Even if you get an update, it will continue to use the unpacked one until you unpack a new version.

[knucklehead]

You can already do that. The client uses an unpacked ruleset by preference over a packed one. So, unpack the version that you know works and leave it out there. Even if you get an update, it will continue to use the unpacked one until you unpack a new version.

Sorry, I'll add the necessary qualifier: "In a commercial/official release." Working, stable rulesets that take a few days to come up to speed on possibly major changes (even in minor patch designations) are preferred.

Reasons: Official rulesets that aren't maintained as actively as others and possibly multiple updates behind Core. Or community rulesets that might not ever get another contributor, but would/could have contributed greatly to the FG ecosystem had the floor not shifted out from under them as volunteers drifted away.

[Andraax]

I don't see what the difference is? You can unpack both community and commercial rulesets. And the client treats both the same (using an unpacked one by preference). So, you can, on your computer, force the use of whichever combination of versions of rulesets you would like. I do it all the time when I'm testing changes for the C&C ruleset. I'm just a little fancier about it - I use subversion with version tags, so I can just go into a ruleset folder, and tell subversion "use version XXX of this ruleset" and it updates all the files accordingly.

[knucklehead]

I don't see what the difference is? You can unpack both community and commercial rulesets.

The difference, in my opinion, is that commercial/official release would be a paid product with a minimum support/reliability expectation. Dipping into the filesystem, unarchiving, and renaming extensions, then keeping abreast of forum updates to know when to update the underlying Core code is pretty inconvenient/cumbersome for someone who possibly just dropped 150 + extension/ruleset costs, installs from say, steam, links their account and syncs their purchases, then clicks the highlighted "Update" button only to find out update x.x.x just broke something.

Alternately, an active maintainer of the paid product would know when to make the move to updated CoreRPG, and could be "pushed" to all the typical end users with minimum fuss.

All that file system work, much less recalling ruleset precedence for is cumbersome to someone who simply wants to run the game they just paid for.

Even if you have everything in your ruleset of choice working just fine, layering on top of CoreRPG is the problem, since every ruleset should be inheriting from it. Or you have an unarchived version of CoreRPG available to prevent that from happening, but then get an update to 5E incorporating some new CoreRPG features/fixes, and your old, unpacked CoreRPG gets used, and breaks the new 5E update. Super obnoxious.

For those of us that want to get under the hood it's perfectly fine. We're a small subset of potential users, though. Stability of all the rulesets, and certainly the paid ones, seems a smart move. Seriously, it's 2017, so download-copy-navigate filesystem-unarchive-recall extension/mod precedence-am-I-inheriting-old-rules-and-what-the-hell-is-inheritance-anyway? as a possible "first time installation" scenario is just garbage, and is not doing any favors for adoption of the platform.

THAT opinion being expressed...this is a GURPS thread, where physicists write rulebooks and linux kernel maintainers theorycraft in sj forums using every mechanic from the "Core 50 books" via memory, or whatever, so I think they can handle some of the complex, anachronistic bits of the UI/UX.

[Andraax]

So, you want to push the responsibility of not updating CoreRPG (a supported ruleset) until GURPS (an unsupported ruleset) gets updated onto SmiteWorks? That's not going to happen. If you use something unsupported, it's on *you* to make sure they work together. SmiteWorks makes sure that all *supported* rulesets gets updates so they work simultaneously - that's all they should be required to do. SmiteWorks already announces, and makes available, the updates well before they push them, so developers have plenty of time to test / update before the push happens. If developers do not take advantage of that, it's not SmiteWorks fault...

If you are using an unsupported ruleset that relies on CoreRPG, your choices are to maintain older versions of CoreRPG that work with the ruleset yourself, or not update until GURPS works with the latest CoreRPG.

Of course, if GURPS *becomes* a supported ruleset, this argument goes away for GURPS.

[Hector Trelane]

Of course, if GURPS *becomes* a supported ruleset, this argument goes away for GURPS.

To help achieve this very thing, you can post on this thread to demonstrate the breadth of user interest in GURPS and support ronnke's conversations with SJG's to agree to allow their product to become officially supported. All we have to do is stand up and say, "aye"!