the movement pad

[jfrazierjr]

The trap is the big function I am looking for right now. I will take a look at the thread and see if I can get it into Rumbles FW. I am also going to take a deeper look at the "peek" function so I can understand what it is doing. Thanks.

Doc_Waldo, there are two functions that can help here (docs are a bit scarce ATM, but CIF, Wolph42, and myself could probably help answer any outstanding questions).

The first is movedOverToken() which was added in b74 or b75.. not sure which. Basically, you could have a trap represented as a token(even on the hidden layer!) and if a visible token moves over it, you can detect this using the function while within the onTokenMove() or onMultipleTokensrepresenttedMove() functions and act accordingly(including reverting movement to start(though FOW is still revealed.. not much I can do about that one) or manually macro moving the token to the location of the trap).

The second one is a bit more general, movedOverPoints() which is in b76 I think. The good thing about this is that you could create an arbitrary closed shape (while tokens are always square!!!!) to test if a token entered said area.

[CoveredInFish]

@jrfrazier:
Any chance for the pathInterectsVBL()? You had ideas for that IIRC.. didnt they work out or did you just havent time for them yet?

[wolph42]

@jfrazier/rumble, while on this topic, you asked me to test something you and rumble were working at (i believe a timer) but I haven't heard from you since. Is this still 'on'?
Next to that I believe you also asked me to create a 'trap' function with the area function instead of the token, admittedly I haven't come round to that. But I guess that would be something doc could use.

[jfrazierjr]

@jrfrazier:
Any chance for the pathInterectsVBL()? You had ideas for that IIRC.. didnt they work out or did you just havent time for them yet?

Been busy. Lot's of stuff going on in the dev thread with me fixing a few things, adding a few things and (trying) to help track down some bugs/places for speed improvements. To be honest, I am not 100% sure this will get done. It really depends on my free time over the next few weeks(which looks slim as of right now)

[jfrazierjr]

@jfrazier/rumble, while on this topic, you asked me to test something you and rumble were working at (i believe a timer) but I haven't heard from you since. Is this still 'on'?
Next to that I believe you also asked me to create a 'trap' function with the area function instead of the token, admittedly I haven't come round to that. But I guess that would be something doc could use.

Yep... check you token move speed thread for the first question. It's in source now and while I have no tested(want you to do a comparison test before and after with the same token sets), so if you could update and test, that would be great.

As for the second thing, yep, get to that when you have some time. The wiki could use some example code if your up for it for all of the move functions.

Oh.. also added getMoveCount() which takes movement metric into effect(needs more testing, but appears to work on all grids/gridless)

[lmarkus001]

Instead of "hard coding" your movement states to the 5 foot step, could you instead use just 30 integer statess to give you any number from 0 to 999? You could have ten 0-9, then ten shifted left 0-9, and again. You would need to change 2 states on roll over (so every other step using 5 foot steps) so this would slow the processing down a tad but would greatly increase your flexibility.

And as an aside, I liked the "Hustle" state icon as it was nice to see when you were moving into a second movement phase. But perhaps setting the movement to a single "move" worth of movement, then having a button that adds the full movement again would be a better approach. The player would hit the end of movement (out of move points) and know they reached the end of a single move, then pressing the second move button they would just add to the existing move (thereby preserving the nice footsteps).

[strike]I would also like a setting that lets me choose what layer to place the footsteps on. I prefer the object layer (I use the steps as a multi-tasking thing, as GM I can process other things/role-play while a player manages their movement and I don't have to be staring at their token the whole while).[/strike]

[lmarkus001]

Ok, tried to use this (1.8.3 on MT1.3b81) last night and ran into these issues.

Showstopper:

When I was a player, I was unable to get my token into the Movement Pad. When I attempted to get it in I would get this error:

Code: Select all

Macro-defined error: No (owned) tokens selected!

I was able to to whatever needed when I was connected as a GM.

Quirks & Observations:

Oddness based on map grid density settings.
We have a large city map that has these grid settings: Distance per cell (50), Pixels per cell (13).
If I deselected "use map defaults for movement cost" and "fix ONE_TWO_ONE bug" then I could move (as a GM only) my token around and it spent movement per my Movement cost settings in MovePad. If instead I turned on the settings checkboxes, then I got some fun weirdness. When I moved rectangularly (is that the opposite of diagonally? aka up down left right) the movement costs were spent 5 per step. When I moved diagonally the movement costs were spent 50 ! per step.

Footstep placements:
I mentioned in a previous post that I would like a setting saying what layer the footsteps appear on. You can ignore that. I learned that they appear on the layer that the masters live on. So by placing the masters on the Object layer I was happy.

Peeking:
This is buggy and needs work. When I press the Peek action, after I step in a direction to peek, I get a bit of spam to the chat

Code: Select all

g,r

A duplicate icon is left in place, and when I turn off the Peek, the duplicate is not removed, then actual token does not lose the Peek state, and the following is spammed to the chat channel:

Code: Select all

Argument number 1 '' to function setTokenFacing must be a number.

So there are some bugs to work out yet.

[CoveredInFish]

Showstopping bugs shouldnt happen, thanks for the report. I'll check that out.

Lately I havent used this myself anymore so I more or less stopped working on it. But if there are people out there using this I'm happy to see what I can fix. With the introduction of the onTokenMove-Event many things I accomplished with the movePad can be done in an easier to use way. I havent a complete replacement package yet (and probably this cannot be done completely) though...

I'll jump in it again and see what I can do. I will provide some infos to your previously posted issues as well (the state stuff for example is all handled in a single macro, so should be easy to change by yourself)

[lmarkus001]

This tool helps get around one of the significant bugs with MapTools http://forums.rptools.net/viewtopic.php ... 96#p137596... specifically the player name getting stuck on the fog of war. I have some maps my players can hardly move around in because their name gets stuck on the fog of war (this primarily happens on maps with tiny grid settings, like 7 pixels per cell), especially for the players that put in their full name for their login so it is quite long.

Plus I like the little feet

[Velocinox]

Ok, tried to use this (1.8.3 on MT1.3b81) last night and ran into these issues.

Showstopper:

When I was a player, I was unable to get my token into the Movement Pad. When I attempted to get it in I would get this error:

Code: Select all

Macro-defined error: No (owned) tokens selected!

I was able to to whatever needed when I was connected as a GM.

I was having the same problem. Here is the solution:

• Select the Lib:cifMovPad token.
• In the Selection Window, find the Select Macro in the Mechanics Group.
• Find the following code line:

  Code: Select all

  [h, if(isGM() || owns=="true"): selectedTokens = listAppend(selectedTokens, id)]
  

• Change "true" (including quotes) to the number one (1).

Hope this works for you as well.
V

[CoveredInFish]

Ah yes ... this was fixed in some recent maptool build- Before that Wiki: isOwned() worked .. lets say quirky. Thanks for finding that.

[Full Bleed]

I'm still back on 1.3b76 but was looking to move up to a newer version and properly integrate the movepad. It sounds like I should wait for another version of the Movepad to come out before I do. If you're willing to start working on this again, CiF, I know I'm still interested in using it!

I'm a little confused about how the new move functions might improve things... Any chance any of that is going to be integrated anytime soon?

[CoveredInFish]

I'm still back on 1.3b76 but was looking to move up to a newer version and properly integrate the movepad. It sounds like I should wait for another version of the Movepad to come out before I do. If you're willing to start working on this again, CiF, I know I'm still interested in using it!

I'll fix some bugs, no new features to expect. I'm a little short on time right now so this might take a while.

I'm a little confused about how the new move functions might improve things... Any chance any of that is going to be integrated anytime soon?

Its probably more a replacement than an improvement. For example its simple (as in 10-20 lines of code) to do movement point tracking with the onTokenMove event right now .. for mouse-based movement. That is, more or less, the most important feature of the pad for my game.

[CoveredInFish]

Dont think this is forgotten. I just dont make any progress

Finding bugs in almost 3000 lines of spaghetti code (ah .. nay .. the euphemism used here is dynamically grown, isnt it?) is tedious and I cant stay very long focused on that.

So please be patient with me...

[Full Bleed]

So please be patient with me...

*Taps foot*

*Looks at watch*

*Sighs loudly*

That's ok... take alllll the time you need.