darn it's ugly

Talk about whatever topic you'd like, RPG related or not. (But please discuss things related to our software in the Tools section, below.)

Moderators: dorpond, trevor, Azhrei

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

Re: darn it's ugly

Post by bobifle »

I don't own Herolab, so I'm not sure how I could use your software, and unfortunately I already wrote all the tedious, zip/md5 code. (well in python, it's not that tedious, there's always a module for anything :) )

I looked at your code and we ended up writing almost the same stuff. A pity you came here too late :mrgreen:.

My next step would be to fetch spells from dnd5api, so my tokens would have fully described spell list. When I run combat, one thing I need the most is an easy access to the spell list with the description. Something I need to prepare before the session, if the tokens have already the descriptions, no more prep ! 8)

FYI here's my code:

https://github.com/bobifle/tokens

You may want to look at how I generate xml. I used a template engine (jinja2), it's very common on the web, but it's actually very useful to generate any kind of data/code.


Edit / Question:

I see you ran into the same issue than I did, the size of tokens being reference with a GUID. Problem, I don't know if those GUIDs are valid over different version of maptool, or even campaigns...

Also is Jamz's version of maptool fully compatible ? (file format wise). For instance a I tried to use my token with Mote, and it didn't work. Well I may simply try but I wonder I Jamz'version is designed to be 100% compatible with the master branch file format.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: darn it's ugly

Post by JamzTheMan »

It depends on what you mean by compatible. The GUID is just the id of the serialized Token class. My "version" is just a fork from the main repo and I submit changes back but, if the Token class changes, then you may loose backwards compatibility (this is true within my fork and the main repo) so from version to version it "can change" (although we try not to change Token/Campaign classes between minor releases.

Which is also why I suggested using the sendURL macro code to retrieve your data and hand making the token "in maptool" instead. If you build your tokens in MapTool via macro, you have better compatibility. Building outside of MapTool means you are locked in and your tokens could break in other maptool releases and not as portable across frameworks...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

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

Re: darn it's ugly

Post by bobifle »

By compatibility I mean whatever token, campaign, macro saved with Maptool, it can be successfuly loaded with your fork. That's what I meant.

Regarding building tokens with macro, I see your point. However I know very little about maptool macros and I honestly think it would have taken me weeks if not month to achieve what I've done in few hours with python, I'm sort of fluent in python.

Right now I don't have the time and dedication to learn another macro language.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: darn it's ugly

Post by JamzTheMan »

Generally speaking, MapTool can load any token from a previous version (just not always the other way around) and my fork ks basically a 'newer' version so yes, it can load tokens/campaigns saved in other MT versions.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Post Reply

Return to “General Discussion”