MapTool 1.3 Development Build 40
Moderators: dorpond, trevor, Azhrei, Craig
- lmarkus001
- Great Wyrm
- Posts: 1867
- Joined: Sat Mar 29, 2008 12:30 am
- Location: Layfayette Hill, PA
I've poked around the naming handling/maiming code extensively. It is in serious need of refactoring IMHO. It's on my "to do" list, but RL has seriously kicked me in the butt lately and looks to continue the beating for the next couple of months. So I won't be able to take a shot at even refactoring the naming stuff till later in the fall.applekor wrote:I would still argue that a refactoring of the code for the next minor revision (i.e. 1.4) should include a revamping of key elements in the system to use explicit identification instead of the current name resolution scheme. Obviously we can't entirely get rid of name resolution since it still has value in the /im command, but disambiguation wherever else possible would be a great help.
I very much agree with applekor on the explicit ID. It will take a major revision change, and should be part of the initial 1.4 change since it will break so much that is out there. But it is fairly critical to open up the next level of opportunities for MT (i.e., targeting).
When using strict token ownership you can not select tokens that you do not own, so using selected tokens as targets wont wotkjfrazierjr wrote:Yep, I forgot this earlier, but the macro code usually checks for ownership to make sure that you can't run a token on something you don't own. This is one of the "problems" surrounding how to get a "targeting" system to work and why it is not as easy as saying "everything selected is my target, just run the macro". Though it would be a good feature to have,torstan wrote:Okay. I did a test and yes, right-click uses /im.
So there are a few things to come out of this.
- /im is not case-sensitive
- /im only uses the player name of a token
- I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix
This also answers my question about players running tokens on monsters. As long as 'Restricted Player Impersonation' is ticked, this should stop players modifying monsters by changing their token name.
- Copying and pasting tokens without changing their names will break macros that use/modify properties
So it's at least as much of a feature as a bug and winds up with me asking for /im to be clever enough to look at the GM name as well when it is used implicitly in the right-click menu, macro panels and so on.
I would be just as happy to have a "roll this expression x times" with a prompt and me still have to manually update any non owned token properties in some way (macro). Perhaps a good side benefit is selection based targeting WITHOUT selection modification. For example, if using Kniza's proposal(as implemented by Mr. Pokeylope) for multiple rolls:
[C:targets."target.Name takes damage: " + (1d8 + str + dex + end) + "<br>"]
where SELECTION starts a loop on selected elements and prints out something like:
Goblin 1 takes damage: 9
Goblin 7 takes damage: 3
Goblin 12 takes damage: 12
The loop is already there in the design of this feature, the question comes to can it be pulled from the count of selected elements or not and then can the current one's name be pulled out and printed to chat.
Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage. For me as a player of ranged people, the one with the highest damage output would always hit the closes melee enemy. Lucky me, eh????
- jfrazierjr
- Deity
- Posts: 5176
- Joined: Tue Sep 11, 2007 7:31 pm
Yea, I know.. I am just doing a what if scenario... especially since someone said they were working on some type of targeting scenario already.Craig wrote:When using strict token ownership you can not select tokens that you do not own, so using selected tokens as targets wont wotkjfrazierjr wrote:Yep, I forgot this earlier, but the macro code usually checks for ownership to make sure that you can't run a token on something you don't own. This is one of the "problems" surrounding how to get a "targeting" system to work and why it is not as easy as saying "everything selected is my target, just run the macro". Though it would be a good feature to have,torstan wrote:Okay. I did a test and yes, right-click uses /im.
So there are a few things to come out of this.
- /im is not case-sensitive
- /im only uses the player name of a token
- I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix
This also answers my question about players running tokens on monsters. As long as 'Restricted Player Impersonation' is ticked, this should stop players modifying monsters by changing their token name.
- Copying and pasting tokens without changing their names will break macros that use/modify properties
So it's at least as much of a feature as a bug and winds up with me asking for /im to be clever enough to look at the GM name as well when it is used implicitly in the right-click menu, macro panels and so on.
I would be just as happy to have a "roll this expression x times" with a prompt and me still have to manually update any non owned token properties in some way (macro). Perhaps a good side benefit is selection based targeting WITHOUT selection modification. For example, if using Kniza's proposal(as implemented by Mr. Pokeylope) for multiple rolls:
[C:targets."target.Name takes damage: " + (1d8 + str + dex + end) + "<br>"]
where SELECTION starts a loop on selected elements and prints out something like:
Goblin 1 takes damage: 9
Goblin 7 takes damage: 3
Goblin 12 takes damage: 12
The loop is already there in the design of this feature, the question comes to can it be pulled from the count of selected elements or not and then can the current one's name be pulled out and printed to chat.
Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage. For me as a player of ranged people, the one with the highest damage output would always hit the closes melee enemy. Lucky me, eh????
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.
Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..
Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..
- lmarkus001
- Great Wyrm
- Posts: 1867
- Joined: Sat Mar 29, 2008 12:30 am
- Location: Layfayette Hill, PA
Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!
b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.
b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.
- jfrazierjr
- Deity
- Posts: 5176
- Joined: Tue Sep 11, 2007 7:31 pm
That's odd.... though I have not looked, I have no idea why moving would have anything to do with initiative, and I highly doubt it does. I wonder if there are any other possible causes, possibly light? Are you playing D&D and/or using the shadowy light options on set on the D&D lights default? If so, that's your culprit and will be most likely for another build or a few before Trevor can get it fixed. Changing the lights back to not have shadowy areas will help dramatically.lmarkus001 wrote:Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!
b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.
Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..
Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..
- lmarkus001
- Great Wyrm
- Posts: 1867
- Joined: Sat Mar 29, 2008 12:30 am
- Location: Layfayette Hill, PA
Was creating a new party last night, doing a lot of macro editing through selection tab and having people log on, edit new stuff, etc... and ran into massive problems with macros reverting, resetting, being lost entirely. At one point someone went from the state they were in to where they were in several minutes prior, losing several new macros, regaining a couple that had been deleted, etc.
I took a look and couldn't find anything. The init panel is not getting called while the tokens are moving. It does get called after the tokens stop moving, but there isn't anything I can do about that.lmarkus001 wrote:Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!
b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
So, any plans for a new build soon? I don't want b40 to eat my main campaign like it seems to have for several others but I'd love to start working on some new stuff.trevor wrote:OK, looks like the initiative panel may may have been broken backward compatibility.
Also, giliath has updated the string comparisons to be more flexible (ignore leading/trailing spaces, ignore case).
If I get the fix from jay for the init panel stuff, I'll do a new build tonight to fix it.
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
I think I know what the problem is.jay wrote:I took a look and couldn't find anything. The init panel is not getting called while the tokens are moving. It does get called after the tokens stop moving, but there isn't anything I can do about that.lmarkus001 wrote:Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!
b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.
Right now when you move a token (has to be a rptok file) it doesn't really move until you move your mouse off the token after "dropping" it. Unless you recognize that new behaviour it feels like there is some kind of performance issue and some moves can seem to take a looooong time.
Now, even though this appears to be a bug (or a change in behaviour), after playing around with it I think it could open the door to a future implementation of a "quick-waypoint mode" where you wouldn't have to use any additional buttons to move and drop waypoints (i.e. space bar or 3rd mouse button.)
Imagine being about to drop a waypoint by doing the following:
1) Click'n Hold.
2) Move
3) Unclick
3a) At this point, you could just "complete" the move by moving the mouse off the token as you have to do right now. Or, if you wanted to drop a waypoint and continue moving you could:
4) Click'n Hold again (dropping a quick-waypoint)
5) Move
6) Unclick
6a) Then move cursor off token to "complete"
I think it would be pretty slick actually.
- lmarkus001
- Great Wyrm
- Posts: 1867
- Joined: Sat Mar 29, 2008 12:30 am
- Location: Layfayette Hill, PA
The state images are visible even if the token is not visible to the players. This is only an issue for exposed area of the map, but I had a case where a gnoll ran around behind a staircase, and the PCs could track his movement by watching his state images.
Oh and I just about went blind (as the GM) because the opacity setting for the GM Fog really needs to be adjustable! Note this image which is a GM view...
Oh and I just about went blind (as the GM) because the opacity setting for the GM Fog really needs to be adjustable! Note this image which is a GM view...
Last edited by lmarkus001 on Mon Aug 25, 2008 6:53 pm, edited 1 time in total.