MT 1.3b62 Progress

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MT 1.3b62 Progress

Post by jfrazierjr »

Sorry guys.. I did not mean to imply that the slow down between versions was localized to specific frameworks. Just more of a general "hey, here is one reason why stuff is slow based on what I have experienced".

Two things I can see of the top of my head that will need to be worked on in future releases:

1) switch to javascript should greatly improve the parsing speed of json stuctures as well as get rid of a good bit of kludgy code.

2) remove the token's property change event and have the hook for updates to tokens coded into the end of the macro execution so that only a single update is performed no matter how many changes are done to the token. The big issue with this is figuring out how to deal with macros that update multiple tokens. One possible way is to create a queue with tokenid's as things are changed and then at the end of macro execution, "sync" tokens that are in that queue to the other clients.
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..

User avatar
trevor
Codeum Arcanum (RPTools Founder)
Posts: 11311
Joined: Mon Jan 09, 2006 4:16 pm
Location: Austin, Tx
Contact:

Re: MT 1.3b62 Progress

Post by trevor »

Sorry for the delay, weekends are brutal over here.

For a point of reference, when you drop a token, it has to transfer the entire token(s) back to the server. So the more content on a token, the longer the delay is.

So it won't be rendering code, it'll be in the transfer of the token.

That doesn't explain why it would be different between two versions using the same framework.

Could someone send me a campaign file with the framework that this is seen in, along with steps to reproduce (even if it's just "move token X"). I'll see what is taking up the time.
Dreaming of a 1.3 release

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: MT 1.3b62 Progress

Post by Rumble »

Trevor:

Here's a link to a bug reports thread I started on this - there are two campaign files attached, one saved in b56, and the other the same campaign, but saved in b61. I've put instructions to show what I was doing to compare the macro handling speeds.

viewtopic.php?f=21&t=12185

I hadn't really noticed the drag/drop speed issue until someone else pointed it out; I assumed it was just because the campaigns I was using were big and had lots of images.
I don't have a specific example for the token moving delay, but you may be able to see it between those two campaigns anyway.

Hope these help!

Chrest
Cave Troll
Posts: 46
Joined: Mon Mar 16, 2009 4:56 pm

Re: MT 1.3b62 Progress

Post by Chrest »

Azhrei wrote:I'm guessing is an inefficiency of the drawing routine. For example, you drag the tokens and let go and it goes back and recalculates the A* path over and over, once for each token, when the pathing had already been done so that it could be displayed. Or perhaps it's the process of moving the tokens -- longer drags seem to have a larger lag, so perhaps MapTool is moving each token each step, then moving it again for the next step, and so forth. That might have happened when the code was added to prevent players from dragging tokens into an area of VBL, back around the mid to late 40's. Or perhaps it's related to fow exposures at each step of the path being taken? (Note that MT is necessarily doing that, but the code may not be optimizing it correctly.)


Forgive my ignorance, but why is MapTool using A* search for path calculation? I didn't know that MapTool ever did anything but calculate direct routes between a series of points. Movement rules will change the exact path that tokens take, but I didn't think MapTool ever routed around obstacles; wouldn't a small dedicated path function for each possible movement type be more efficient (in memory usage or CPU usage or both) than A* search?

User avatar
Azhrei
Site Admin
Posts: 12061
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MT 1.3b62 Progress

Post by Azhrei »

Perhaps short-term. But there have been plans for a movement blocking layer for a long time. Why invent a specialized routine when a generic one -- that will be useful in the future -- is well-known?

That, and the fact that A* routines are cool. ;) 8)

User avatar
trevor
Codeum Arcanum (RPTools Founder)
Posts: 11311
Joined: Mon Jan 09, 2006 4:16 pm
Location: Austin, Tx
Contact:

Re: MT 1.3b62 Progress

Post by trevor »

The original intention was to make it possible to have obsticles to work around automatically, like walls and tables and such, it just hasn't gotten high enough priority to implement yet.
Dreaming of a 1.3 release

User avatar
trevor
Codeum Arcanum (RPTools Founder)
Posts: 11311
Joined: Mon Jan 09, 2006 4:16 pm
Location: Austin, Tx
Contact:

Re: MT 1.3b62 Progress

Post by trevor »

Update
I apologize for the delay, I've been out of town on a business trip.

Work is slowly moving forward on b62 as I can get time. Currently I'm working with a few macro developers to figure out the slowness issue. I'm hoping we can nail that and do a build this weekend.
Dreaming of a 1.3 release

Post Reply

Return to “Developer Notes”