Wolph42's 'Drop-in' Bag of MT Tricks v.49

[wolph42]

The only difference between the two files are added doors in the file with the bot.

thats quite some vital info: problem solved!! (I delete the doors and it worked fine)!
Note I did that in the 'BoT' version. Valid question remains: why! I'll post this with the devs.

[krevett]

thats quite some vital info: problem solved!! (I delete the doors and it worked fine)!
Note I did that in the 'BoT' version. Valid question remains: why! I'll post this with the devs.

Well I was going to do that...not fast enough ^^
Ok thanks for the return it's a bit sad I had just installed BoT for the toggle door macro...i'll try to use your integrated vbl (i was using object vbl rather than bot built-in vbl).

[wolph42]

thats quite some vital info: problem solved!! (I delete the doors and it worked fine)!
Note I did that in the 'BoT' version. Valid question remains: why! I'll post this with the devs.

Well I was going to do that...not fast enough ^^
Ok thanks for the return it's a bit sad I had just installed BoT for the toggle door macro...i'll try to use your integrated vbl (i was using object vbl rather than bot built-in vbl).

I can imagine, note that that should not happen, unless the door tokens are massive in size and slorping up all memory, did you check?

edit: checked, its a 74kb png file...so no. It really smells like an MT bug.

[krevett]

A bit more details: if there's no pc on the map door animations are perfect. As soon as a pc is on the map even with a single door, door animation is sloppy as hell and token movement slows down the more of them you add to the map.

With 1.4.1.8 door animations are slower too when there's some pc tokens on the map but nowhere near 1.5++ versions.
Also with 1.4.1.8 token movement remains fluid even with all the doors set.

Edit: setting vbl sensitivity to 0 instead of 1 when generating vbl on the door object seems to be smoother as far as token movement is concerned. The downside is that my door are no longer always visible over fow when a token gets near.

Edit2: sorry for polluting your thread. I see you log to github perhaps you can open an issue there for me (i've got a git account too but it's very old and I'm abit lazy to reset my password... ) thanks for your time wolf

[wolph42]

im lazy too, Im discussing this in the dev section on discord. apparently (most likely) its a VBL issue combined with vision range.

ok as it turns out: youve been using 'token vbl' (the yellow kind) and thats the actual reason!! removing the yellow vbl and applying the blue (while setting up the door, in other words USING BoT macros to do that) will solve the problem!!

In the mean time, the dev team looks into the general issue of the yellow vbl lag, but don't hold your horses on that one!

[krevett]

Well i'm not on discord (not anymore in fact) but i've already tried to reduce the map's vision range down to 20 (it's really not much... ) but the time to calculate vbl was as long as with 1000. As if the parameter don't change anything.

Edit i will try the blue vbl

[wolph42]

note that you will need to use different doors!! in order for it to work with the bot. The bot works with doors that run from the middle of the token to the west:

Code: Select all

 _______
|       |
|   ====|
|_______|

set size to "large" and then the door will cover the edge of one cell (same as your current setup)

[krevett]

Ok i need a bit of your help to setup a door with the blue vbl. When setup it says that you must have the hinge on the middle of the door but i really don't know how to do that as whatever the size of my token, the hinge is always on the left not in the middle. I tried to play with 'layout' of the token in the options but to no avail...

Edit: just read you message ^^ so it must be in the base png

[wolph42]

lemme know if you need something else.

[krevett]

Indeed still need a bit of help ^^
When I open the door the vbl on the wall is removed creating a hole as you can see in the screenshots below
Door set to a standard size (large) no vbl drawn on the door, setup the door, then draw my vbl on the wall

Closed.png (126.56 KiB) Viewed 2610 times

Open.png (139.57 KiB) Viewed 2610 times

Edit: nevermind, I just need to draw vbl on the wall BEFORE I setup the door in BoT

Edit 2: Indeed token movement is much smoother now, thanks for the help wolf!

[wolph42]

good to hear you got it working!

[RicoTheBold]

Hey Wolph42, I'm happy to see you're actively maintaining this again. Like the other posters, I've found it to be a valuable resource, even though I only use a small fraction of the capabilities. I'd hacked the version check on v43g to allow Maptool 1.5x to pass the check, which largely let the things I needed work just fine.

I'm also totally digging the ideas with the updated Switch Map function, which I'd completely neglected to use in the past. It's a good answer for a performance issue I've got with cutting a bunch of player tokens at once in mid-game (it's *probably* vision-related or network-related or something, but I only ever run seem to run into it during an actual game and I haven't spent time troubleshooting.)

Also, thanks for the heads-up in this thread that on-token VBL is laggier than other VBL. I don't seen any open issues about that on github, so I would never have known that was specifically an thing to be aware of.

I do have a few questions that don't seem to be covered in the manual:

1) Why exactly does the "Diagnose Maps" Macro complain about maps with names that start with numbers (but contain other characters)? What does it break? I stumbled on this macro while trying to figure out the next one.

2) It looks like there's a bug in the "VBL move check" option with tokens with duplicate names. What happens is that you try to move one token, and instead it moves a different one (that you don't have selected) by the same name. Because MapTool's random numbering option option appears to have a bug in it allowing for duplicates for tokens created on different sessions, there's a fairly meaningful chance that you'll unwittingly have two tokens named "Creature 304" or something, which is how I ran into it. I'm curious if there's a reason the macro uses the token name instead of its ID? Obviously there's a pretty straightforward workaround in checking for duplicate names (using your helpful macro) before running a map. I'm more just trying to understand, because it seems like using the tokenID would be preferable as it, presumably is always unique. But I'm not super well-versed in how MapTool does things under the hood, so...feel free to enlighten me. Link to my bug report for randomly-generated duplicate token names

It also look like the switchMap macro also uses token names for the selected tokens, which can result in similar problems, especially if a randomly-named token gets moved between maps and then has a duplicate name on the new map.

3) There are a couple issues with the switchMap macro as written in Lib:OnTokenMove version 44d.
- First, it doesn't correctly move tokens/map view to "centreOnMePad" tokens, but does find "centreOnMePad " tokens.
On line 82:

Code: Select all

[h:comPad = "centreOnMePad " + newLoc]

That space in the "centreOnMePad " means that the macro can't find the coordinates of a centreOnMePad token without anything after the name. If you put a space at the end of the token's name, it works fine, and if you name it something like "centreOnMePad 22" it works fine, but "centreOnMePad" doesn't work properly. It can't find the token and defaults to coordinates 0,0. When the argument gets passed to the gotoMap macro, a similar thing happens.
I fixed this by changing it so the space was included in the additional part of the name that only gets added when it exists. So I changed line 82 on the switchMap macro to:

Code: Select all

[h:comPad = "centreOnMePad" + newLoc]

This also required a corresponding change to the CoMScan macro to put the space in the back half of the location name.
Line 12 goes from:

Code: Select all

		[newResult = json.append(newResult, json.set("{}", "map", map, "spot", spot))]

to:

Code: Select all

		[newResult = json.append(newResult, json.set("{}", "map", map, "spot", " " + spot))]

I tried for simple changes that work fine with the current design. The gotoMap macro doesn't need to be changed, because the spot argument it gets passed is an empty string, so appending it doesn't affect anything.

- Second, it totally ignores the "Move selected token(s)?" checkbox in the prompt, and always moves selected tokens even if you uncheck it.
- Third, it doesn't move tokens to other spots on the same map, which would be kind of neat if you want to move stuff between places manually instead of with automatic pads, or if you wanted to move everyone back to the entrance of some kind of maze or something. I thought it was supposed to work, and was bummed it didn't. Maybe I won't use it much, if ever, but the option would be nice.

I fixed both of these at the same time.
Old lines 96 and 97:

Code: Select all

[h,FOREACH(tok, selected),if(oldMap != newMap): moveTokenFromMap(tok, oldMap, X+roll.count, Y)]
[h:setCurrentMap(oldMap)]

New lines 96-101:

Code: Select all

[h, if(selCount == 1), CODE: {
	[h,FOREACH(tok, selected),if(oldMap != newMap): moveTokenFromMap(tok, oldMap, X+roll.count, Y)]
	[h,FOREACH(tok, selected),if(oldMap == newMap): moveToken(X+roll.count, Y, 0, tok)]
	[h:setCurrentMap(oldMap)]
};{
}]

Basically, I just had it check for the checkbox variable, then if it was checked execute an appropriate token move option. All I had to do was look up the same-map moveToken function.

Full macros for lazy copy/paste:

switchmap

Code: Select all

[h:'<!------------------------------------- switchMap ([mapName[, players]]) ------------------------------------------------>']
<!-- The argument players must be either a list of player names or 1 to select ALL players -->

<!-- <html> Forces ALL clients to chosen map AND centres view on the token <i>centreOnMePad</i> <br><br>If you select tokens before you use this macro, then the option will be added to move<br>the selected tokens to the new map as well. These tokens will be placed near the <i>centreOnMePad</i><br><br>If there is no <i>centreOnMePad</i> then the coords (X,Y) 0,0 will be used instead.
-->
[h:assert(isGM(),"This macro can only be run by the GM",0)]

[h:mapList		= listSort(getAllMapNames(),"N+")]

[h:comLocations = getLibProperty("centreOnMePads", "lib:EventMacros")]	<!-- centre on me pad locations -->
[h:locationList = ""]
[h,foreach(location, comLocations,"<br>"), CODE:{
	[map = json.get(location, "map")]
	[spot = json.get(location, "spot")]
	[locationList = listAppend(locationList, if(spot != "", map + " - " + spot,map))]
}]

[h:oldMap		= getCurrentMapName()]
[h:allPlayers	= getAllPlayerNames()]

[h,if(argCount() > 0): newMap	= arg(0) ; newMap	= oldMap]
[h:assert(listFind(mapList, newMap) != -1, "The map "+arg(0)+" does not exist",0)]

[h,if(argCount() > 1), CODE:{
	<!-- in case both arguments have been given, the input can be omitted and the players can be switched to the map -->
	[userList		= arg(1)]
	[if(userList == 1): userList = getAllPlayerNames()]

	<!-- move players -->
	[playerList = ""]

	[FOREACH(player, userList), if(listContains(allPlayers, player)): playerList = listAppend(playerList, player) ; broadcast("The player: "+player+" does not exist!")]
	[selCount		= 0]
''
};{
	<!-- in case one or no arguments have been given, show the input and ask for map and players to switch map for -->
	<!-- make sure that at least the current map is part of the comLocation, if not rescan -->
	[if(listFind(locationList, oldMap) == -1), CODE:{
		[bot_CoMScan()]
		[comLocations = getLibProperty("centreOnMePads", "lib:EventMacros")]	<!-- centre on me pad locations -->
		[locationList = ""]
		[foreach(location, comLocations,"<br>"), CODE:{
			[map = json.get(location, "map")]
			[spot = json.get(location, "spot")]
			[locationList = listAppend(locationList, if(spot != "", map + " - " + spot,map))]
		''
		}]
	''
	};{}]
	
	[newMap		= listFind(locationList, newMap)]
	[userList	= allPlayers]
	[selected	= getSelectedNames()]
	[selCount	= listCount(selected)]

	<!-- input string -->
	[							inputStr = "junk|<html><b>Force Selected Players to Map<br></html>|-|LABEL|SPAN=TRUE"]
	[							inputStr = listAppend(inputStr, "newMap|"+locationList+"|Select map|RADIO| SELECT="+newMap,"@")]
	[if(selCount):				inputStr = listAppend(inputStr, "selCount|1|<html><b>Move selected token(s)?</b></html>|CHECK","@")]
	[if(selCount):				inputStr = listAppend(inputStr, "junk|<html>("+selected+")<br>&nbsp;</html>|-|LABEL|SPAN=TRUE","@")]
	[							inputStr = listAppend(inputStr, "junk|<html><b>Select Players<br></html>|-|LABEL|SPAN=TRUE","@")]
	[FOREACH(player, userList):	inputStr = listAppend(inputStr, "player"+roll.count+"|1|"+player+"|CHECK","@")]
	[							inputStr = listAppend(inputStr, "junk|<html><b>Res-scan all maps for new locations<br></html>|<html>When checked this macro will scan ALL maps looking for<br>tokens that are called <i>centrOnMePad Some Location Name</i><br>and adds <i>Some Location Name</i> to the above list of locations<br>when you choose that location the map will be centred around<br><i>that</i> pad. Obviously <i>Some Location Name</i> can be any<br>alphanumerical string you like!<br></html>|LABEL|SPAN=TRUE","@")]
	[							inputStr = listAppend(inputStr, "rescan|0|Re-scan|CHECK","@")]

	<!-- ask for input-->
	[abort(eval(listFormat(inputStr, "input( %list )", " ' %item ' ", ",", "@")))]
	
	<!-- move players -->
	[playerList = ""]
	[FOREACH(player, userList), CODE:{
		[if(eval("player"+roll.count)): playerList = listAppend(playerList, player)]
	''
	}]
''
}]

<!-- get new map and location -->
[h:newLocation = json.get(comLocations, newMap)]
[h:newMap = json.get(newLocation, "map")]
[h:newLoc = json.get(newLocation, "spot")]
[h:comPad = "centreOnMePad" + newLoc]

<!-- move tokens (if any) -->
[h:setCurrentMap(newMap)]
[h,if(findToken(comPad)!=""), CODE:{
	[X = getTokenX(0, comPad)]
	[Y = getTokenY(0, comPad)]
};{
	[X = 0]
	[Y = 0]
}]

[h,if(rescan): bot_CoMScan()]	

[h, if(selCount == 1), CODE: {
	[h,FOREACH(tok, selected),if(oldMap != newMap): moveTokenFromMap(tok, oldMap, X+roll.count, Y)]
	[h,FOREACH(tok, selected),if(oldMap == newMap): moveToken(X+roll.count, Y, 0, tok)]
	[h:setCurrentMap(oldMap)]
};{
}]
[h:bot_execAllPlayers("gotoMap@lib:OnTokenMove",json.append("[]",newMap,newLoc), playerList)]

coMScan

Code: Select all

<!-- scan all maps looking for centreOnMePads -->
[h:result = replace(json.indent(bot_seekToken(1,"centreOnMePad",'["TOKEN", "HIDDEN", "OBJECT", "BACKGROUND"]', getAllMapNames(),0,1),2),"centreOnMePad", "")]

<!-- initiate end result json array -->
[h:newResult = "[]"]

<!-- build json array with each map and map-location build up -->
[h,foreach(map, result), CODE:{
	[locations = json.get(result, map)]
	[newResult = json.append(newResult, json.set("{}", "map", map, "spot", ""))]
	[foreach(spot, locations),if(spot != ""), CODE:{
		[newResult = json.append(newResult, json.set("{}", "map", map, "spot", " " + spot))]
	}]

}]
<!-- store end result in lib:eventmacros -->
[h:setLibProperty("centreOnMepads", json.sort(newResult,"spot", "map"), "lib:EventMacros")]

[Phergus]

Also, thanks for the heads-up in this thread that on-token VBL is laggier than other VBL. I don't seen any open issues about that on github, so I would never have known that was specifically an thing to be aware of.

VBL on tokens isn't laggier than the regular VBL. Auto-generated VBL on tokens can be because it ends up with a huge number of points defining the polygon.

Example: Auto-generated versus Drawn and then transferred to the token.

Screenshot 2019-11-30 08.59.58.png (133.05 KiB) Viewed 2529 times

[RicoTheBold]

VBL on tokens isn't laggier than the regular VBL. Auto-generated VBL on tokens can be because it ends up with a huge number of points defining the polygon.

Oh, cool. That makes sense; thanks for the clarification. Most of my token VBL is hand-drawn anyway. I mostly have been drawing VBL onto maps from a Pathfinder Adventure Path and then transferring it to the background tokens in case I screw up and accidentally move them, so it's good to know that's not any worse than leaving it on the map by itself. It does sound like I should revisit my door tokens like the other poster, but that's easy enough.

[wolph42]

actually a while back I started to use the token vbl for self generating maps and they too were very laggy UNTIL I moved (the same vbl structure) to the map VBL. This might have been fixed in the mean time, but that has been a thing.

I'll get into the rest later, its quite a lengthy post you made

edit: see next page