Dracwrym wrote:I have not been able to get Wolf42's Bag of Tricks v.42 to work with the latest Nerps version of MapTools. Even when I had it working just fine in the regular version of MT, then open the campaign file in the Nerps version, it still won't work. Is there a way to get relevant information to post here? Are you having the same issues?
Yeah, some of the BoT macros in the "Util - VBL" group on the ontokenmove library still rely on the getTokenFacing() function which doesn't work. If you just go through those macros and replace every instance of that function with bot_getTokenFacing() it fixes it.
I extracted BoT and opened the content.xml file. If I replace getTokenFacing() with bot_getTokenFacing() carefully, save, and rezip it, will it work properly then or is there some kind of checksum that is done to see if a file is valid?
Dracwrym wrote:I have not been able to get Wolf42's Bag of Tricks v.42 to work with the latest Nerps version of MapTools. Even when I had it working just fine in the regular version of MT, then open the campaign file in the Nerps version, it still won't work. Is there a way to get relevant information to post here? Are you having the same issues?
Yeah, some of the BoT macros in the "Util - VBL" group on the ontokenmove library still rely on the getTokenFacing() function which doesn't work. If you just go through those macros and replace every instance of that function with bot_getTokenFacing() it fixes it.
I extracted BoT and opened the content.xml file. If I replace getTokenFacing() with bot_getTokenFacing() carefully, save, and rezip it, will it work properly then or is there some kind of checksum that is done to see if a file is valid?
Thanks.
Not sure. That sounds like it would work. There are only like 4 or 5 macros that need to be fixed; I did it directly in maptool (it is particularly easy b/c in 1.4.3.19 you can ctrl-f search macros and have more than one open at once).
I would be careful with that. The macro bot_getTokenFacing() makes use of getTokenFacing() so if you're doing a blind search and replace you will create an infinite recursive loop. Ill have a look when I've got time.
wolph42 wrote:I would be careful with that. The macro bot_getTokenFacing() makes use of getTokenFacing() so if you're doing a blind search and replace you will create an infinite recursive loop. Ill have a look when I've got time.
Hmm, that's interesting. I wonder why bot_getTokenFacing() works when getTokenFacing() doesn't. I stumbled on the solution of replacing the one with the other in those specific macros kind of blindly, and it seems to work. The entirety of the necessary replacements can be done manually in less than 2 minutes.
Unrelated (or barely related) question -- I see people refer to version 42 of the BoT. How can I get that? I have 40j.
paulstrait wrote:Unrelated (or barely related) question -- I see people refer to version 42 of the BoT. How can I get that? I have 40j.
Thinking about it, I might have put 42 because of Wolf42. I don't know if the version I have is 40 or 42 now.
Ah, got it. Well, I've attached the modified version of Lib:OnTokenMove that I use. I just called it 40j.alt to avoid confusion. getTokenFacing() works on other versions of maptool, so this is really just relevant for people running (the amazing) 1.4.3.x, until Jamz fixes whatever the issue is.
paulstrait wrote:Unrelated (or barely related) question -- I see people refer to version 42 of the BoT. How can I get that? I have 40j.
Thinking about it, I might have put 42 because of Wolf42. I don't know if the version I have is 40 or 42 now.
Ah, got it. Well, I've attached the modified version of Lib:OnTokenMove that I use. I just called it 40j.alt to avoid confusion. getTokenFacing() works on other versions of maptool, so this is really just relevant for people running (the amazing) 1.4.3.x, until Jamz fixes whatever the issue is.
I just want to say thank you, I’m still exploring the features of this fork but just for the code editor you deserve a fraking statue in a fraking temple!
Noticed something odd yesterday -- when I have a server on, and I move an NPC token with vision set, it reveals fog of war. It doesn't do this when there is no server up. The NPC tokens in question are not owned by any players, so it is really unclear to me why this is happening. If it happened in earlier versions of maptool I never noticed it before.
Trying anything without a server running is strange. There's no concept of whether you're the GM or a player, so what should the code do? Whichever way it does it it's going to be wrong for somebody.
Azhrei wrote:Trying anything without a server running is strange. There's no concept of whether you're the GM or a player, so what should the code do? Whichever way it does it it's going to be wrong for somebody.
If you aren't running a server, why wouldn't it always make sense to treat you like a GM? Why would a non-GM be setting up maps before sessions? If maptool doesn't treat you like a GM when there's no server running, the difference has to be pretty subtle because I haven't noticed it before in the last 8 or so years of using maptool.
In any event, with respect to the issue I'm having, it seems to be working correctly when a server is not running, but incorrectly when a server is running.
Because there's no Individual Views or Individual FOW. Those things are based on token ownership and there's no ownership without a server running. And yes, the code assumes the GM is doing everything when there's no server. I don't know off-hand what the rationale might be for exposing an NOCs vision when moved by the GM, but I would think it would depend on whether the NPC is player-owned. Was it?
Azhrei wrote:Because there's no Individual Views or Individual FOW. Those things are based on token ownership and there's no ownership without a server running. And yes, the code assumes the GM is doing everything when there's no server. I don't know off-hand what the rationale might be for exposing an NOCs vision when moved by the GM, but I would think it would depend on whether the NPC is player-owned. Was it?
Nope. That would be logical though. In the past, even player owned NPCs moved by players wouldn't reveal vision (which was mildly annoying). Next session I'll test that out to see if that's still the case. But with these NPCs they were not player-owned.
Yes, FYI, I moved to a more "Ownership" based FoW reveal. It's immaterial if it's an NPC or PC token now. As a GM, I want to play by the same rules as my Players, so FoW needs to be revealed for bad guys so you can see proper lighting and it's easier to see.
Also, I give NPC control to PC's and now they can see what that token can see so they can move it. I didn't see a performance hit (75% of vision performance is in lighting).