PDA

View Full Version : What Ruleset was BRP Based On



S Ferguson
March 4th, 2013, 23:29
I've got a bit of a problem building my calendar extension. It seems to spit out errors left, right and center. I was wondering what the original ruleset it was based off of so I could take a look at the untouched code vs. the BRP rules. To me it looks like a toss up between the d20_JPG and the Base Ruleset of old.

Any help would be appreciated.

Moon Wizard
March 5th, 2013, 00:13
It's all iterative. The rulesets have been building on each other and changing over time. You would need a snapshot of the ruleset it was built for, at the time it was built to get a clear picture. If I remember right, the original calendar extension was written for an older version of the 4E ruleset (v2.8.x?), but I don't remember.

Maybe posting the errors will help?

Regards,
JPG

S Ferguson
March 5th, 2013, 02:01
Most of the errors are basically all nil values thrown out by the program. For example:

1) The day and date don't appear in the title bar, so it can't be changed, but will output to the chat window.
2) The days of the week don't appear above the dates.
3) Clicking on a date throws the exception attempt to call field setSelectedDate in calendar.lua is nil.
4)Clicking on create log entry brings up a underline bar but no "page" in which to record things.
5)Clicking on View Log Entry throws the exception addLogEntryToSelected in calendar_main.lua is nil.
6)Adjusting the year throws an exception onYearChanged in calendar_main is nil
Even though the year is accepted and if the calendar is closed and reopened it displays the proper dates.
7) pressing the set current date throws the exception onButtonPressed in calendar_main is nil.
8)Player's can't access the calendar at all (another nil for another time).

On the bright side, the chat window output and the "era" box work as advertised. I was just wondering what features are lacking in the set in order to get the calendar to work properly. Otherwise I can bring it up in BRP, Shadowrun 4e, GURPS 4e (which strangely gets the months right on the calendar, but still dosn't display the days).
The errors seem to be consistant across the board. I'm using a Gregorian Calendar; that's how I know it's getting the dates right.

It seems that there is something "missing" in those rulesets that allows the calendar to be seen properly (as it is in more modern systems like 4e, 3.5/Pathfinder and Rolemaster to name a few with the calendar internal to the ruleset). Have any ideas of what could be wrong? The classes that are nil are calendar specific so the calendar interface I believe isn't communicating with the ruleset properly.

Any Suggestions?

Ikael
March 5th, 2013, 05:34
Feature that big won't ever work as is. You will have to read all the code line by line and define it your tsrget ruleset is missing something. I think you are missing few things: fonts, frames, icons and some templates. Make sure that that all of these resources exist in your target ruleset and if not, add them in or alter them in the calendar to be something that exists.

Also like I States in previous Post set all players as watchers for calendar dstabasenode and add that tool to client version of desktop tools.

There is ne need to check on which ruleset current one edistä because changes are HUGE and it is easier just to make sure that current one has all required resources.

S Ferguson
March 5th, 2013, 05:45
I think it's just a matter of templates that are missing from the code base. The question is which ones? the calendar seems to be quite self consistant and modularized. It's what it's connected to that is the problem. It runs fine as an attachment under "modern" rulesets, so I can't really compare apples and oranges. Going through the ruleset line by line to track down the source of the errors seems to be the only way. And I was enjoying my time off.

S Ferguson
March 5th, 2013, 17:15
It's all iterative. The rulesets have been building on each other and changing over time. You would need a snapshot of the ruleset it was built for, at the time it was built to get a clear picture. If I remember right, the original calendar extension was written for an older version of the 4E ruleset (v2.8.x?), but I don't remember.

Maybe posting the errors will help?

Regards,
JPG

That's about right.So the ruledet would have been based off an earlier version of the Base Ruleset. Hopefully, the modular rules system will take care of this, so updating code could rely on a type of verison control mechanism.

Ikael
March 5th, 2013, 18:41
That's about right.So the ruledet would have been based off an earlier version of the Base Ruleset. Hopefully, the modular rules system will take care of this, so updating code could rely on a type of verison control mechanism.

Not trying to tease or unmotivate, but just speaking out loud from experience. Even with making 4E / 3.5E more modular doesn't prevent the worst work of including features from ruleset to another. There are several possible issues which can raise when including code to existing base. Modularization could help developers to understand the source ruleset/featureset more better, but developers still has responsbility to double-check that there won't be conflicts and that all resources are brought manually to target ruleset.

I hope MoonWizard could prove me wrong.

S Ferguson
March 5th, 2013, 19:07
No teasing allowed:p .

That's what "version control" is. Maintenence of the code in a modular fashion to keep it up to date. Of course there are going to be variations in the rules simply because the "rules" of whatever is being played are going to be different. The base feature set, under the hood, however, would not have to be modified that often and would be done so through updates (infrequent if maintained properly originally).

Most of these rulesets stemmed from the same source and grew apart in dynamic ways (well except for your UniCore system:) ) so if we made *that* source constant, with only the "ruies" would have to be maintained, and the community could benefit as BRP is all about changing the "rules of the game" by adding extentions to the base.

Knowing what basic controls you have available to you across the board simplifies building on to the system of your choice as well as they only have to concentrate on the "top level" of construction. They, if they've modified one set, could potentially modify *any* of the rulesets, by just looking at the "top" rules, i.e. those of the system you're using. I as a, say, BRP developer and as long as my code conforms to the base, could potentially write it for any other system.

It's the "Programming in the Large" rule #1: modularize, and conquer.

Moon Wizard
March 5th, 2013, 23:30
That's one of the things that I'm hoping the community will help refine during the beta process for the layered rulesets feature. Specifically, which features should have hooks in the "core" ruleset to support the specific game system rulesets?

Right now, I'm essentially building a "generic" ruleset as the core to build off of, and then planning on layering 3.5E, 4E, PFRPG and 5E on top. That way, the "core" can potentially be updated to add generic features without the rulesets deriving from them. And the upkeep of all rulesets will be much lower.

Regards,
JPG

S Ferguson
March 5th, 2013, 23:39
That's one of the things that I'm hoping the community will help refine during the beta process for the layered rulesets feature. Specifically, which features should have hooks in the "core" ruleset to support the specific game system rulesets?

Right now, I'm essentially building a "generic" ruleset as the core to build off of, and then planning on layering 3.5E, 4E, PFRPG and 5E on top. That way, the "core" can potentially be updated to add generic features without the rulesets deriving from them. And the upkeep of all rulesets will be much lower.

Regards,
JPG

Thank goodness. A separation between "rule" code and "stuff you reallly don't need to know unless you're changing the ruleset" needed to happen. I only wish I could help more on hte BRP side; be it beta-testing, extension building, or *anything*.