Terrene Session Log

[DrAwkward]

(Terrene is the name of the setting)

First session went smoothly. Everyone was quite impressed with MapTool.

Important Discoveries:
* Most of the worries I had about scripting dialog was a non-issue.
I ended up typing interactive conversation more than doing "box text".

* I need a better understanding of how vision and light work.

I suppose that "60' vision" would simulate darkvision,
but how do you simulate "can only see via light sources"?
how do you accomodate Low Light Vision?
can you place "light sources" on the map w/o a token?

Why aren't light radius effects blocked by the Topology?

Can a new PC token default to having a vision of "no"?

* InitTool is my friend.
I can tell it has a lot to offer, especially in the area of seting up encounters beforehand. This is where I was least prepared, and it showed.

* Stacked tokens are a headache

was using rats that I gave "Swarmfighting" (can fight from the same space without penalties) and it was hard to keep track of. was using token states to mark status effects, but those states did not show up on the "double click to pick a token from a stack", and the names kinda smushed together there too.

* Fog of war is awesome

In setting these up, would be nice if the topology was attached to an object or background rather than attached to the coordinates.

I can envision a "door" token with a topology running through it being copied and pasted throughout a dungeon, and when I "rotate" the door out of the way - tada, you can see.

* What am I missing by using 1.2.b32?
I expect a lot of what I'm running into may already be addressed. I grabbed the "stable" version, and its very usable. I was just wondering what I'm missing and how hard it is to switch back and forth.

Now that I've seen it in action, I feel relieved that I picked MapTool. I toyed around with some of the others, and this has by-far the lowest learning curve (most intuitive interface) of what I've seen.

Thanks for making it available for public use.

[Phergus]

I suppose that "60' vision" would simulate darkvision, but how do you simulate "can only see via light sources"?

At the moment they are one and the same. A token with 60' of Vision enabled is either a token with some kind of night-vision that allows sight to 60' or they have a light source that extends to 60'.

how do you accomodate Low Light Vision?

Short answer is you don't. Maybe Dorpond has figured out a way.

can you place "light sources" on the map w/o a token?

Yes but it would be with an object instead.

Why aren't light radius effects blocked by the Topology?

Because the Light feature predates FoW/Topology and doesn't interact with them. It's use is deprecated.

Can a new PC token default to having a vision of "no"?

All tokens default to no vision. If you mean not being able to see the areas revealed by other PC tokens with Vision, then no. That is waiting upon individual views for tokens.

In setting these up, would be nice if the topology was attached to an object or background rather than attached to the coordinates.

Very common request that has been waiting on the other features that would be needed to support it like the recent Token format addition.

* What am I missing by using 1.2.b32?
I expect a lot of what I'm running into may already be addressed. I grabbed the "stable" version, and its very usable. I was just wondering what I'm missing and how hard it is to switch back and forth.

Nothing to stop you from downloading the dev releases and trying them out. You can keep the 1.2 release around and still experiment with the 1.3 dev releases.

[DrAwkward]

A token with 60' of Vision enabled is either a token with some kind of night-vision that allows sight to 60' or they have a light source that extends to 60'.

Ah, I see. So if a token has no light, and normal vision in a pitch black room, I set him to a vision of 0 feet? It seems that a token with no vision set at all gets to see everything, by default.
The only feature that "light" has that vision doesn't surpass (that i can tell) is the "Lit" vs "Dim" range. I guess if we figure out low-light, the lit-dim thing might be there too.

It would be neat if the vision had settings indicating light vs low-light vs darkvision (vs tremorsense vs scent vs blindsight...oy. I am asking for way too much unless we can find a theme that these fall within). Thinking it would be badass if Darkvision showed up in black & white.

[Phergus]

A token with 60' of Vision enabled is either a token with some kind of night-vision that allows sight to 60' or they have a light source that extends to 60'.

Ah, I see. So if a token has no light, and normal vision in a pitch black room, I set him to a vision of 0 feet?

That would do it. Or you can disable an existing Vision on the token to achieve the same effect. Currently it is kind of handy to put a small 3' radius Vision on a token so that the token itself is always visible.

It seems that a token with no vision set at all gets to see everything, by default.

The Vision/Topology system isn't enabled until one token has Vision enabled. Until that point, any revealed areas will be fully visible to all tokens.

It would be neat if the vision had settings indicating light vs low-light vs darkvision (vs tremorsense vs scent vs blindsight...

You can put different Vision Overlays on different tokens. So something with infravision vs something with low-light vision would be apparent on the display.

[trevor]

Somehow I missed your original post. Sorry about that.

Looks like Phergus has you hooked up

* What am I missing by using 1.2.b32?

1.3 is almost an entirely new beast. Tokens and Chat have received the most TLC. You can do things like add portraits to your tokens, or let you tokens stretch outside their cell.

It's still a bit unstable, so I wouldn't depend on it for anything that has a lot of setup. Several people are using it in game (thanks to all you guys for the testing!) though. YMMV

[Hawke]

I'm using it to game but I mostly use bounded maps. As a result I can just drop the map in, setup the vision-blocking and be done pretty quickly. If it crashes or for some reason were to mess up a savegame (hasn't happened to me yet, but don't want to take chances) I could just spend 5 minutes and redo it.

We haven't run into any crashes either, actually... mostly just odd behavior.

[DrAwkward]

This go around, MapTool reported that it couldn't find itself on the 'net. Nothing (to my knowledge) had changed, and the port forwarding was still set up correctly.

After about 45 minutes of blind panic, we ended up having one of the players host the game instead. That went well, except for as a remote GM I couldn't "Force players to current map".

The session itself, once it was rolling, went well.
I think my map-making skills are improving, and the players are getting used to the toolset.

One of the players was having a strange lag issue -- His token stopped moving for the rest of us, and his chat wasn't showing up, but he could see our stuff bounce around just fine. Took us a good 10 minutes to notice it. This only happened once, though he did drop out completely a few times, so something was up with his connection.

We've been using TeamSpeak to get voice during game, though we generally only use it during setup -- they seem to prefer that I type the important stuff so they can save the logs.

[trevor]

Good notes. What most likely happened is your friend's outbound connect was dropped but not the inbound.

When you say "reported that it couldn't find itself on the 'net." do you mean the Test Connect, or was it failing when connecting with direct or RPTools Alias ?

[DrAwkward]

..do you mean the Test Connect, or was it failing when connecting with direct or RPTools Alias ?

Test connect was saying it couldn't find me.

My group and I haven't been able to get the RPTools Alias to work -- though we've never tried very hard since direct connect is so reliable.

I'll probably troubleshoot my connection tonight, to see if I can get it working for my game Saturday.

[DrAwkward]

This go around, my connection was working fine (for no apparant reason) until my damnable ISP changed my dynamic IP right in the middle of my session. This seemed to make it take a really long time (5 minutes-ish) for my players to connect (just connect, not load), even after I rebooted.

The "dissapearing GUI" bug that I thought was fixed by this latest Java version is back.

Found out not to give players a long vision range in the middle of a forest.
Long vision + lots of vision blocking elements = lose.

Found lots of other things about vision that annoy me. Prolly time to head over to the Wall and see about getting them talked about. Gonna try them on the latest dev build first, though.

[torstan]

Trevor is implementing a speed increase for vision that apparently will make unlimited visions possible, so the vision speed issues sound like they are almost resolved. What were the other vision issues?

[DrAwkward]

What were the other vision issues?

** Going from outside a dungeon to inside a dungeon means changing each PC's vision from the longer range to a shorter range. This is a laborious process, and bogs the game down because only the GM can do it.

I'm not against letting the players select thier own vision, but I can see why some GMs might not want to allow that. I think Dorpond has made some suggestions regarding handling vision/light that would make this go smoother.

** My players keep accidentally selecting "Player visible only" to reveal vision, and then crying over the lost map. I think, for me at least, this is an advanced enough feature that it might be a good canditate for "GM only".

I suppose they'll eventually figure out to not do it anymore, but its sure a pain to fix it for them.

** "Expose last path" in the Dev build fixes the last gripe. Neato.

[trevor]

very, very soon now (b19, b20) you'll have a single vision type per token, and then configure the light sources in the outside and dungeon.

[DrAwkward]

Had the same connection issues as last time, though we paid better attention to how long things were really taking.

It seems my lovely ISP is scheduling me a dynamic IP change right in the middle of my sessions (thats twice in a row now, anyway). MapTool doesn't seem to handle it very well.

Everyone gets booted, and we timed it -- it took 50 minutes (almost an hour!) to get everyone connected again. Each player typed in my new IP addy, and then sat around looking at the "connecting" screen.

Is it possible for MapTool to watch for an IP change, and then let everyone know before the session is lost?

Why an hour to connect?

Next session we plan to let the player with the faster connection host.

[Phergus]

Everyone gets booted, and we timed it -- it took 50 minutes (almost an hour!) to get everyone connected again. Each player typed in my new IP addy, and then sat around looking at the "connecting" screen.

I doubt MT can do anything about that. That delay is probably all thanks to your ISP.

Are you shutting down MT and restarting it when that happens or just trying to carry on?

Is it possible for MapTool to watch for an IP change, and then let everyone know before the session is lost?

Once you know about the IP change the session is already lost.

Next session we plan to let the player with the faster connection host.

As the customer paying for the service I would think you letting your ISP know just how unacceptable this resetting of your IP address is to you would also be a good step to take.