Official MGT2e Bug Report Thread

[Sarkoptesmilbe]

I'll add these to my list for this week and give it a look. Thanks for letting us know!

I've played around a bit with the optional rules and found that hit locations ARE rolled, but only when player characters are targeted, never for NPCs (no matter what type, humanoid or animal or otherwise). I'm not sure if this is working as intended; I'd certainly like an implementation for NPCs as well. But this may not be a bug after all.

The spacecraft criticals are also a strange case. The rules always revert from "optional_val_yes" to "Off" when the menu is closed, but it seems that ship criticals are rolled correctly. The criticals themselves are not resolved and applied, so it seems that's left as manual work. The rule is turned off and remembered when set to "optional_val_no", and it simply seems that "off" means the same as "optional_val_yes", so that's more of a UI bug/oversight.

[Moon Wizard]

More than likely, hit locations were only implemented for PCs by the original Traveller ruleset developer. We just took over the ruleset into maintenance mode, because the original developer moved on; so we're focusing on making sure it continues to work with the core features and fixing up anything previously implemented.

Regards,
JPG

[Stargrove]

I have found a data conflict between what is in the Ruleset under the System Bases entry and the data that is on Travelelrmap. I think some of the entries in the ruleset have the races, whereas the entries on TravellerMap no longer use that information, as who owns the base is usually implied by other data for any given system. Anyways...here is the BASE_TABLE from the TravellerMap source code:

      C: 'Corsair Base',
      D: 'Naval Depot',
      E: 'Embassy',
      H: 'Hiver Supply Base', // For TNE
      I: 'Interface', // For TNE
      K: 'Naval Base',
      L: 'Naval Base', // Obsolete
      M: 'Military Base',
      N: 'Naval Base',
      O: 'Naval Outpost', // Obsolete
      R: 'Clan Base',
      S: 'Scout Base',
      //    T: 'Terminus',   // For TNE - name Collision
      T: 'Tlauku Base',
      V: 'Exploration Base',
      W: 'Way Station',
      X: 'Relay Station', // Obsolete
      Z: 'Naval/Military Base' // Obsolete

We, as users of the ruleset, have no insight into what is in there when it comes to these codes, but if they could be updated, that would be nice.

[Moon Wizard]

I'm assuming that the codes come from the source books where they were originally defined. Wouldn't changing the way codes are interpreted interfere with data entered from books using the original method?

Regards,
JPG

[Stargrove]

I guess I hadn't considered that...

Take Theeve, which I came across while testing my UWP import tool tonight. The Bases entry comes back as a 'K' in the JSON, which crosses to Naval Base in their table. In the ruleset, 'K' is currently 'K'kree Naval Base' That world is definitely not a K'kree world and is not anywhere near any K'kree territory. So, the spirit of any past content would still be there with the more agnostic 'Naval Base' in the TM data.

I just put all the letters of the alphabet into the Bases field on a system and now know what all of them mean (assuming there are no two-letter entries):



I am not sure it would make much difference to essentially leave what is in the ruleset there and maybe just remove the race names in front of the entries that have them. There a lot more bases in the ruleset than there are in the TM data. This would allow the names to better line up between the two data sets and not interfere very much with already created FG content.

You all are obviously the arbiters of what's right and wrong for the ruleset and if you think it would be detrimental to make an update like this that's cool. I just wanted to point out the discrepancy is all.


This all has me wondering about the Trade Codes field and how that matches up...

[Moon Wizard]

The thing is that we mimic whatever is in the actual printed book; and try not to deviate from that. I'm not sure what is printed in the books over various time periods (original printings, revised printings, adventure and source book printings, etc.) nor why the web site you are pulling from would use different codes than the books.

Basically, we wouldn't want to change the way the codes work without someone doing an exhaustive review of all the world records across all the books to ensure that all the stuff already in the store is fully compatible. At this point, the ruleset code is in maintenance mode until another developer steps in, as we don't have the resources to do that level of review and development across all the rulesets we support.

Regards,
JPG

[Stargrove]

That's fair, and I understand the whole "it's in maintenance" thing.

It was a lot of work to understand the creation of a couple of extensions and to get my head wrapped around LUA. A whole ruleset that was put together by someone else would be daunting. Diving into someone else's (or many someone's) code is never fun.


I was joking a bit before about the Trade Codes, but would it be possible to get a list of the Trade Codes from the ruleset? I really am curious what's in there. Having that information might help me refine my UWP tool a bit.

[Tarkonian]

That's fair, and I understand the whole "it's in maintenance" thing.

It was a lot of work to understand the creation of a couple of extensions and to get my head wrapped around LUA. A whole ruleset that was put together by someone else would be daunting. Diving into someone else's (or many someone's) code is never fun.


I was joking a bit before about the Trade Codes, but would it be possible to get a list of the Trade Codes from the ruleset? I really am curious what's in there. Having that information might help me refine my UWP tool a bit.

I will have to swing back to this at the end of this week. Unfortunately there's not a standard table for me to just look at and pass that on to you. Instead they take the values, pass them into a Hex format, and then parse the values from there. Let me finish up some work on other projects before my xmas break starts, and then I'll try to figure out what the parsing is and get you a table of codes.

Diving into someone else's (or many someone's) code is never fun.

This is exactly why we try to encourage standard practices when writing scripts and functions, and have been offering registration methods for people to use when they create their ruleset. Then we can standardize most of the "boring" parts, and people can register just their unique code for their ruleset. It makes it a lot easier to work through it later on, as well as maintain it. But Fantasy Grounds has a lot of rulesets and some of them are pretty old. So it'll be an ongoing process for awhile. It'll be worth it when we get there though!

[shindaseishin]

I found an issue with the homeworld system. I searched this thread and didn't see anything about this so I hope it's not a duplicate.

I created a homeworld and added a skill to this. I then start a new character. I drag the homeworld onto the character's homeworld field and the log says that the skill has been added to the character at level 0. I go to the character's skills tab and I see the skill added but the "Unskilled Skill" is not there.

In testing this I seem to have found the work-around to make it behave as expected. When I create the new character, before dropping the homeworld onto the field, if I go to the skills tab first, I see the "Unskilled Skill" and then I go back to the main tab. I then drop the homeworld onto the field. After doing that procedure I can go to the skills tab and see that the "Unsilled Skill" is still there and the new skill is added.

This behaviour suggests to me, not knowing the code behind this, that there is a LUA script run when the skills tab is shown that checks if the skills list is empty. If it is then the script adds the Unskilled Skill to the skill list. But if you add a homeworld before opening the skills list then the script sees that the skill list is not empty and thus does not add the Unskilled Skill. But that is just an assumption.

[LinWood2020]

I've noticed at least one system entry (somewhere in Glisten or Pax Rulin, I think) where the trade codes do not match the UWP for the system. I just corrected the system entry in my campaign, and now try to look ahead to double-check any systems the PCs are traveling towards.

There's also the whole Ganulph kerfuffle, but that seems to be a disconnect between the various flavors of Traveller canon and not necessarily a fault in the ruleset.