Import / #Include. Maybe other preprocessor?

Developer discussion regarding MapTool 1.4

Moderators: dorpond, trevor, Azhrei

Forum rules
Posting now open to all registered forum users.
Post Reply
Kencomer
Kobold
Posts: 1
Joined: Mon Dec 03, 2018 12:33 am

Import / #Include. Maybe other preprocessor?

Post by Kencomer »

For me, the equivalent of #include or import statements is essential for anything but the most trivial task. I write programs so I don't have to do the same thing repeatedly.

I am embarking on a quest to become a pro GM, so I will want to use the same framework for many modules. I will want to change the framework from time to time. I will *not* want to go back and replicate changes across modules (nor will I want to have a Mondo module to contain all modules).

I will want to have different characters in play sessions. Like, if Bill cannot play but Mary can, I want to deactivate Bill's character's token in the TuePM campaign and bring Mary's in just for the adventure. Then I want to put Mary's back into a vault or ThurPM when the adventure is done. This might be soluble without #include, but it is also soluble using #include.

Ideally, it would be possible to have multiple #includes per file and arbitrary nesting depth. Like file a has #include B, B has #include C, etc. To prevent circular inclusion resolution, it would be good to have a mechanism like #ifdef | #ifndef | #else and #define.

Has this been discussed. Is there a reason not to do have an "import" function??

taustinoc
Dragon
Posts: 516
Joined: Mon Aug 03, 2015 6:30 pm

Re: Import / #Include. Maybe other preprocessor?

Post by taustinoc »

I suspect you can do most of what you want to do with macros that can call other macros, lib tokens and user defined functions.

bobifle
Giant
Posts: 219
Joined: Thu Oct 19, 2017 12:36 pm

Re: Import / #Include. Maybe other preprocessor?

Post by bobifle »

I will want to use the same framework for many modules. I will want to change the framework from time to time. I will *not* want to go back and replicate changes across modules
You can't (and I feel your pain.)

Campaign properties, lights, states, can only be edited through gui manipulations, they cannot be loaded from a file nor set through macros. I think this is a no go, you simply cannot move these around. See viewtopic.php?f=26&t=27891 for a small hope for futre MT versions.

For everything else, the MT way of doing is to have drop-in macros. The idea is simple: have a lib token contain all the data you want to move around your modules. At the begining of each session you could just drag the last up to date verion of the lib token. And save it as up to date at the end of the session (if you changed it). But again the data contained in the lib token will only be macros and hidden properties.

As for the #include proposal, it would overlap with the lib tokens purpose. Put you macros in a lib token, define them as UDFs, and you can call these functions from wherever you like.

PS: I'm not from the MT dev team, read my opinion for what it's worth.

Phergus
Deity
Posts: 7132
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Import / #Include. Maybe other preprocessor?

Post by Phergus »

bobifle wrote:
Mon Dec 03, 2018 11:14 am
Campaign properties, lights, states, can only be edited through gui manipulations, they cannot be loaded from a file...
You can import and export Campaign Properties to a .mtprops file which is just XML.

Are you sure you've been using MapTool? :wink:

bobifle
Giant
Posts: 219
Joined: Thu Oct 19, 2017 12:36 pm

Re: Import / #Include. Maybe other preprocessor?

Post by bobifle »

darn ! why nobody told me when I was crying all over the forum !

I'll have to kill a kitten, I'm sorry but this demands retribution !

Phergus
Deity
Posts: 7132
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Import / #Include. Maybe other preprocessor?

Post by Phergus »

On a related note, Tables can also be imported/exported. The saved files (.mttable) are zipped and contain a properties file and a contents file. Tables make handy places to store data as well.

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Import / #Include. Maybe other preprocessor?

Post by Full Bleed »

bobifle wrote:
Mon Dec 03, 2018 11:14 am
I will want to use the same framework for many modules. I will want to change the framework from time to time. I will *not* want to go back and replicate changes across modules
You can't (and I feel your pain.)
I've used the same (growing) framework for multiple campaigns (Golarian, World of Greyhawk, Generic) and dozens of modules over the years. Multiple parties and many characters, too.

You *can* export everything for a framework, but much of it will have to be done separately:

1) All Campaign properties (token properties, sights, lights, states, bars) can be exported into a single *. mtprops file.

2) You can also export a map with all the core Library tokens of your framework using Map>Export. And then Import them into separate campaigns the same way.

3) Tables, however, have to imported/exported individually.

How complicated this is will depend entirely on how you develop your framework. So you would need to design a workflow where you're developing on some centralized campaign and then exporting as necessary to keep adjacent campaign files updated. Or you can build the tools necessary for having a single Master Campaign file with multiple campaigns in one file. I did the latter for awhile but it will require some creative custom macroscript tools.

For example, I resorted to hiding all maps (save the core library map which must be visible) and having players do map switching with a custom macro interface. The macro looked at what campaign the particular player (token) was a part of and then only listed the maps available to that campaign. I did that by tagging the names of maps with a prefix to identify which campaign it was a part of and a suffix that set it's visibility in the custom interface. That way when Party X logged into the campaign they only had access to Greyhawk maps and when Party Y logged in, they only had access to Golarian content. And there was some content that both had access to.

That was a quick fix for my situation, but if I was going to be running more than a few campaigns, I'd store and maintain map access information on a special Lib Token that was used for all map access and switching.

Ultimately, I was able to develop and maintain only one master campaign/framework file, with multiple campaign worlds and groups, without ever having to export anything. I found that to be a lot easier than maintaining separate campaign files.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

bobifle
Giant
Posts: 219
Joined: Thu Oct 19, 2017 12:36 pm

Re: Import / #Include. Maybe other preprocessor?

Post by bobifle »

I stand here corrected...

Phergus
Deity
Posts: 7132
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Import / #Include. Maybe other preprocessor?

Post by Phergus »

Full Bleed wrote:
Mon Dec 03, 2018 1:32 pm
For example, I resorted to hiding all maps (save the core library map which must be visible)
All my lib:tokens are on a hidden map and always have been. The tokens themselves must be flagged as Visible but the map doesn't have to be.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Import / #Include. Maybe other preprocessor?

Post by aliasmask »

Phergus wrote:
Mon Dec 03, 2018 2:23 pm
Full Bleed wrote:
Mon Dec 03, 2018 1:32 pm
For example, I resorted to hiding all maps (save the core library map which must be visible)
All my lib:tokens are on a hidden map and always have been. The tokens themselves must be flagged as Visible but the map doesn't have to be.
You should keep lib tokens on the token layer as well, especially ones with onCampaignLoad. Hidden map is okay, hidden layer is not okay.

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Import / #Include. Maybe other preprocessor?

Post by Full Bleed »

Phergus wrote:
Mon Dec 03, 2018 2:23 pm
Full Bleed wrote:
Mon Dec 03, 2018 1:32 pm
For example, I resorted to hiding all maps (save the core library map which must be visible)
All my lib:tokens are on a hidden map and always have been. The tokens themselves must be flagged as Visible but the map doesn't have to be.
Interesting. That's not spelled out in the wiki. The fact that the token needs to be "Visible to Player" is mentioned multiple times though. And while I'm not sure how a token on a map they can't see is "visible" to them I'll happily be making my core library map "not visible to players." Could have sworn I tried this before... :/
aliasmask wrote:
Mon Dec 03, 2018 3:02 pm
You should keep lib tokens on the token layer as well, especially ones with onCampaignLoad. Hidden map is okay, hidden layer is not okay.
I haven't tested this... but the wiki explicitly indicates otherwise:
wiki wrote: The library token must be visible to players (make sure Visible to Players is set in the right-click context menu). The library token need not be on the "Token" layer (you can keep it on the "Hidden" layer to hide it from players, although "Visible to Players" must still be set to true).
Library_Token

Is not using hidden layer lib tokens with onCampaignLoad a limitation? If so, it's not mentioned there either... and there is a section specifically for its "limitations."
Last edited by Full Bleed on Wed Dec 05, 2018 5:14 am, edited 1 time in total.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

Phergus
Deity
Posts: 7132
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Import / #Include. Maybe other preprocessor?

Post by Phergus »

Some simple tests from both a player and GM clients moving a lib:token to the hidden layer gave me no problems. Works fine whether the map is also hidden or not.

I'll look over the wiki page to see about clarifying this.

Post Reply

Return to “MapTool 1.4”