MapTool Dev Build (testing, version 0.95) - Jan. 28, 2012

[Lee]

@wolph I take it back, I didn't miss anything but rather, it was how MT does FoW clearing through PC vision: while it clears the cache locally, it forgot to tell all the other clients to do the same. I'm not going to fix that as it is a minor issue and I'd rather work on the permanent fix.

Apparently, the way the launcher invokes the MT app also internally redirects "stuff" (simplifying) which then triggers the console to not show at all. It is not a problem with the launcher but it is how things are when a Java app calls another Java app, which is why I think the original launcher was written in C++, because it passed the java call through the Window's command shell, therefore allowing the console to show. Of course, I could invoke the command line to then invoke the java call but I'll set that aside for now since I'll need to look up the implementations of that for Linux and OSX and I don't have the time.

@Sol Thanks for going through the list. The $ fix was reverted because it caused problems downstream. The conic light footprint shouldn't look like that. Hmm. I tested my upload and it shows just fine. Did you overwrite a previous test build or extracted it anew to another folder? Normally, that ellipse would be the size of the pog/token. What's important is to note that the footprint light should correctly follow the token after the grid is adjusted.

Yes, following the changelog would be nice as we want to know if the fixes work under all types of systems. Testing like wolph's and yours are thorough and specific enough so as not to need anyone else to replicate.

Edit:
I forgot to mention that perhaps, as an alternative solution to the "annoyance" is to automatically set a token as PC when ownership is set to a player and NPC when no one owns it. But I do agree with Sol since most game systems do not employ shared vision unless another effect is called to share another entity's vision. While that is being weighed, a workaround in MT script to toggle PC <-> NPC is easy enough to figure in, don't you think?

Edit #2:
build 0.95 is up with some fixes to what was reported today. Let me know what you think. Thanks.

[Full Bleed]

Still trying to totally get the new fog paradigm... we're talking about getting rid of soft fog for a performance increase and to fix some bug? (I've been using 87 for awhile and haven't noticed any glaring issues with vision/fog, so it's probably a use-case I just don't use.)

For my part, I quite like the soft fog over areas that PC's have been but can no longer see. As for performance, I've never really had cause to complain much about it. But I also don't use auto-reveal (I always use Ctrl-I so that I have much more control over what's revealed... and I don't stress on doing it with every single step unless it's needed.)

So, my vote would be to *not* lose Soft Fog, but to seriously consider putting in Wolph's toggle idea in 1.4 if there is a demand for it and Lee's up for the challenge.


When Soft Fog was introduced we all knew it was a hog, but the effect was worth it. I'm still in that camp.

[Lee]

0.95 has 2 implementations. One for day and one for night. The implementation for night is an optimized version of the usual (i.e. what you see in b87). The day implementation still has soft fog but only clears it where the token lands, which is just as fast as what was in version 0.9. 0.9 tested pure hard fog.

In MapTool b87, we only had one for both day and night and it meant slow execution on complex maps regardless of vision. To illustrate, try out the map wolph shared as testing material a page or 2 back and follow the steps he prescribed. Do it 1st in b87 and then in this test build both in day and night and you will see what the discussion is about.

By doing it this way (in 0.95) we now have a toggle of sorts. If you want fast execution, switch to day vision. If you want realistic FoW, switch to night.

Edit: IDK about 1.4, the devs are still laying the groundwork on that, so the complexities that bog 1.3 version of FoW might be a thing of the past in 1.4. Let's hope so.

[wolph42]

actually its already 4 pages back: here's the link

edit: Ok run a quick test and it looks good!. It still begs the question whether in this case its not better to simply have a toggle for the optimization (e.g. checkbox 'clear hole path on move'). Cause this will allows one to still choose between day and night (with lightsources and such).

I noticed by the way that when using the night version with a client attached that the 'path clearing' is done iterative on the other client. So
On server: move token A from cell 1 to 10
On player client: vision of cell 2 is cleared, vision of cell 3 is cleared, vision of cell 4 is cleared, etc. upto 10 and then the server vision is updated (showing path from 1 to 10). It looks kinda cool, but I imagine that this also means that this requires network traffic... so it might not be optimal.

O and the java console now works!

[jfrazierjr]

Yea, I would rather have Soft FOW also as it was working previously.

For performance, there are a couple of possible changes that could be made that would increase performance except when you tell MT not to. The big one would be to check the Server setting for "Individual View" and "Individual FOW"(which implies that a server is started for player connection and the GM explicitly enabled those features) and update the token's exposed area only if all preceding checks are true(such as "Players can reveal vision", Vision mode set to day or night(not off), "token has vision enabled", etc.) This gets the code "somewhat" back to the original implementation of Individual FOW(though not totally.) and let's the GM decide if he wants the performance hit(which can be quite large!!!)

Another option would be to leave as it currently is in b87 and change to only expose on waypoints and drop location. This could drastically reduce the calculations needed for a 30 "step"(as in 30 grid movement units) move and again, would put the control back in the GM and/or players hands. This will break from the existing model of exposing for each grid moved through, but would coincidentally get to closer in alignment with the only thing possible now with non-gridded tokens(though, non gridded tokens do not automatically expose area as opposed to gridded ones which can optionally exposed automatically.)

Personally, I think both approaches layered on top of each other are a really good compromise while still allowing the ability to expose per grid cell via the use of way points if someone needs that much control and are willing the pay the performance penalty for such.

In 1.4, the plan is to get away from using the built in Java geometry classes and build something more performant(but that's a HELL of a lot of code work.)

[wolph42]

Yea, I would rather have Soft FOW also as it was working previously.

that is a line that, depending on where you put the emphasis, can interpret in two ways. So just to clarify: you *do* like the current implementation in dev 9.5 (because it significantly faster) and you *do* like to keep it BUT you *also* want the option to have the soft fow working as it was working previously ?

Thats how I look at it, just verifying whether we share that opinion.

[jfrazierjr]

Yea, I would rather have Soft FOW also as it was working previously.

that is a line that, depending on where you put the emphasis, can interpret in two ways. So just to clarify: you *do* like the current implementation in dev 9.5 (because it significantly faster) and you *do* like to keep it BUT you *also* want the option to have the soft fow working as it was working previously ?

Thats how I look at it, just verifying whether we share that opinion.

Need Soft FOW for both Day and Night as it works in b87 and previous back several years prior.

[Lee]

@jfj sorry for the confusion, but soft fow was taken out only in 0.9 as an experiment. It's back in 0.95 but I made it so it only clears on path start and end rather than for each cell path (that's for night). I observed that VBL is the more dominant aspect during the day and if a user doesn't clip the sight range, all the fog (soft or otherwise) get's cleared anyway.

@wolph thanks for testing it out. actually, while it might give that impression, it is actually a more optimal approach since I've avoided using the bulk of the area processes involved in the original approach. The original approach, algorithm-wise, is well done, but was built on the standard Java geometric library. Had it not been for that, things will be zipping by without any need for modification. It also does things iteratively, even more so whereas mine only has 2 loops. The original process was not visible since the final visible area is formed in the background on all clients. The approach in 0.95 was more interactive with the canvas that's why you see soft fog get eaten up, especially on long movement. They do share the same idea of taking each step on the path and using the token's vision to cookie-cut through soft fog.

Again, let's have Azhrei or the others decide where to put the GUI toggle, if ever. I'll be more than happy to write it in when the time comes. Or perhaps even a macro toggle - though I think there might already be one under the hood.

[wolph42]

@jfj @lee: that clears matters up.

Then I can only say: I *really* like the performance improvements you have achieved however I also *really* like the fow options that b87 has however I do not always require BOTH of them so, as I mentioned in my previous post, a "Clear FoW on Waypoints only (performance increase)" checkbox/menu item/function call/whatever would be REALLY appreciated. After all the insane lag that *can* happen is something that should be dealt with. But thats my 0.02$

[Full Bleed]

@jfj sorry for the confusion, but soft fow was taken out only in 0.9 as an experiment. It's back in 0.95 but I made it so it only clears on path start and end rather than for each cell path (that's for night).

This sounds like an implementation I can live with. Though, to be honest, since I only use manual FoW clearing I almost always do it on the end points anyway unless I'm clearing a long stretch of map (where I will do it in small chunks.)

[RPTroll]

Did anyone get it to run under Linux?

[Sol Invictus]

About the conical light footprint (I did unpack the new dev build into a new folder):
It adjusts correctly to grid offset and token movement. Not to changing size of the token though, but IIRC that wasn't implemented.
I found the issue with the odd size of it!: Apparently the size of the footprint is 5 "distance". If the map's "Distance per cell" is set to "5", the footprint is the size of 1 grid field. If the map's "Distance per cell" is set to "1", the footprint is the size of 5 grid fields (in diameter).
(everything true as well for 0.95)

The new MT Launcher works perfectly now, I didn't have trouble understanding it, but I read the discussion here. I guess changing the top button to "Find Maptool .jar" would make its purpose exceedingly obvious.

FOW: 0.95 seems to work as it is supposed to, having tested it with the forest map.

a "Clear FoW on Waypoints only (performance increase)" checkbox/menu item/function call/whatever would be REALLY appreciated

I'm with wolph!

On that matter as well:
Would it help performance if instead of soft fog there would not be any fog to cover up areas once uncovered?
If so, then a toggle for this might be handy.

And then it might be good to have a toggle that has only the token's current view uncovered, all the rest would be covered with 'Hard' Fog. Like 0.90 had it.

I know this has to be decided by the core devs. However, I hope they read this.
I really think MT needs to accomodate users with performance problems. In my own group, performance has been a huge problem in the past. At the same time giving up the vision simulation capabilities of MT for good can't be a possibility, that is understood. So toggles seem to be the perfect compromise.

These toggles could be made available in the "Start Server" dialogue, in a subsection labelled "use to increase performance" or something like that. Running MT without having a server set up the toggles could be set to minimal performance. For map building, performance problems caused by vision are not really a serious issue.


PS: my OS is Windows Vista (32 Bit), so yeah:

Did anyone get it to run under Linux?

[Azhrei]

Again, let's have Azhrei or the others decide where to put the GUI toggle, if ever. I'll be more than happy to write it in when the time comes. Or perhaps even a macro toggle - though I think there might already be one under the hood.

If you want to put a static final ... = false; in the relevant class it can be converted to a GUI checkbox at some point in the future. This allows you to test it both ways with a minimum of effort and also allows for future adaptations.

[Lee]

@RPTroll I got it to run in VMd Ubuntu 64, which was the only distro I had lying around.

@wolph, Sol: The question remains as to where to put the GUI control. Putting it on the server setup would mean that a local MT session wouldn't have it set w/o launching a server. More on this below.

@Sol I see what you mean. You're using a square grid, I take it? I was using a hex grid. Since we're leaning (in the conic light thread) toward not highlighting the personal area automatically, this point may be moot, but what happened was the token size values in those xml files was the culprit, meaning the formula is sound and all that needs to be done is to adjust the values to make it right.

@Azhrei I don't mind writing all that's needed if it will make it into official MT. Let me see what I can come up with and I'll pitch it here

[wolph42]

@lee I would actually prefer it to be no part of the server settings as it allows more freedom during a game. I've had it a few times that the lag kicked in and was forcedc to turn off vision. To have one step in between that would be nice. I would vote to put it with the map options day/ night view.