RPTools.net

This is likely the last update for MT 1.3.

There are no new features in this build but there are fixes for bugs that don't have known workarounds. As always, you can find a specific list by clicking on the ChangeLog link from the Main Page of the wiki.

Change in this version are primarily centered around some tweaks to the way Individual Fog works (and a couple of bug fixes), and some fixes to the way hex grids validate token movement. Lots of minor bug fixes as well.

I'm building the OSX image right now and everything should be uploaded shortly. I'll give it a day or two and then move this from the "Development" column to the "Release" column on the Launch page of the main site.

Cross your fingers!!

Is this per map, or per campaign?

edit:

Cool.

When a campaign is loaded you'll notice the "Optimizing map: ..." note in the window status bar. That's when this optimization is occurring. That means it is per-map but it is done when the campaign is loaded.


I've tested the former with the campaigns Phergus provided (as well as a few of my own) and they look good. I should define the validation better:

Movement from cell A to cell B figures out which face of cell A is being crossed. The triangle formed by that face and the centerpoint of the cell is check to see if it has any hard fog in it. Movement is blocked if there is. The same thing is checked for cell B. In addition, the centerpoint of cell B is also checked to see if it's in hard fog and movement is blocked if it is.

The above restrictions don't apply to tokens that are not SnapToGrid. For those tokens, only the destination point is checked.


The latter appeared to have been the intent in the original code but a bug kept it from working! While I was in there mucking with the movement validation is when I found it. Seemed like a neat feature and technically it was a bug fix, so...

Awesome. Gratz.

Although it feels like the ending of an era...

If this is to be the end, then I would have it be such an end as to be worthy of remembrance!

In seriousness, though, I hope it is the end. This apple has been well and truly polished, and I'd rather have the power hitters start swinging at the new goalposts, to horribly mangle several metaphors.

I am getting some serious performance issues with b85 over b84. The New Map or Edit Map dialog takes over 15 seconds to display on a new campaign in b85 as opposed to maybe a little over a second in b84. Also picking up and moving tokens is unusably laggy in b85 instead of slightly laggy in b84. Both are getting launched from the website using the same settings. Anybody else getting this problem or or is it an ID10T error between keyboard and chair?

Hm, I think I agree.

When I tested it previously using a very complicated map it worked fine. But the build I just did isn't doing so well at all. I don't know what could have changed as part of the build process though???

The lag doesn't seem to be in the GUI layer. That really only leaves the input layer as the other major pieces wouldn't cause the GUI to lag. Even selecting a token takes about a quarter of a second, which is way too long.

I just ran the current version inside Eclipse (the IDE) and it's still lagging. So at least it's reproducible in the IDE. That's a good start. I'll post again when I know more.

well... I guess this is one of the few occasions where you both congratulate and offer condolences at the same time .
So... congratulations with the new release and my condolences that its still not the final one.

That's odd - I don't see any performance issues at all with b85 launched from a download or from the web - no token selection lag, no new map lag, etc. What settings and OS is this?

I'm not disputing it exists - Azhrei is seeing it too - I just wonder where it comes from.

maybe its Spoiler related.

@Az, does it happen with a clean campaign file already or does it happen with certain .cmpgn files? If its the latter, then maybe you can share one so we can test as well.
If its the former, than I can't reproduce as well, tried both a clean map and my rather heavy framework, both were snappy also in creating a new map.
Im running windows XP, I believe Rumble is also behind a windows unit. I know you (Az) are an apple aficionado, question remains whether MageMirin is too.

Maybe its wise to share the campaign file anyway you tested this on.

Yeah, that's why I wondered at the OS - I'm using Windows 7 Home Premium* 64-bit






* How many more adjectives can I throw in there? "Windows 7 home premium most excellent improved discounted double-secret-Gitmo CAPSLOCK x64"

is that the OEM or retail version?
edit: oh and which SP?

Okay, so it only happens on very busy maps. Which is understandable. By "very busy" I mean maps with lots of VBL and a few dozen tokens.


It does seem to be rather snappy on my "typical" maps. And I just used a new feature of b85 to reset all fog when importing a new map and it seems to be running much faster. I then went through and cleared away fog throughout the castle for 4-5 PC tokens and the performance stayed fine. So I believe the lag to be a combination of complicated VBL and "left over" fog from a previous version.


The map itself is too large to attach here, but I've uploaded it to my web site. You can find it at http://www.eeconsulting.net/maptool/test/ -- the name is Castle Korvosa.rpmap. This is the original export that still has all of the fog in it (exported in b84). You can try loading it both with and without clearing the fog.

Running the profiler on it did indicate a "hot spot" but the execution time of that code was only about 10% of the total (real) run time of the application and I was heavily testing mouseover and token selection (since those seemed to be the slowest).

My best guess is that the exposed area was so complicated that the calculations that merge exposed fog areas was taking a noticeable amount of time. That can be helped using a cache, but I'll let others take a look at my export map before we discuss that further.

Son-of-a... Now it isn't doing it. I installed CamStudio to do a capture of the sluggishness on my win7x64 ultimate (pyr8 edition) system and now it is super snappy... wtf?

were you testing it first on an electronic fruit calculator?? (Apple)