Beta 19 Reloaded: Whispers

May 6, 2012

Ugh…. I know it’s a beta, but I still hate regressions. It tells me that I’m rushing and that I don’t have enough test automation.

In beta 19, as released Friday night, there was a bug in the chat window that affected whispers. Essentially, each player could only whisper to players who’d joined later, and as a result, no one could whisper to the GM, and the last person to join couldn’t whisper to anyone!
It’s fixed now, and you can download the new beta 19 (1.0.19.3) now.

If you’ve already downloaded Friday night’s beta 19 release, you can just install this latest one over top. If you’ve not already downloaded beta 19, just pretend that this never happened. ;)

Beta 19: Persona Fixes

May 4, 2012

Beta 19 is ready. I call this one “Persona Fixes” because many of the changes involve character personas in one way or another.

Below are some of the highlights of this release.  For a full list of the fixes and enhancements in this release, check out the what’s new page

Just give me the beta! If you just want the beta download, without all the discussion of what’s in it, go ahead and jump down to "How do I get the beta?"

Features and Fixes

Give another player control over a character

Prior to beta-19, you could only speak as and only edit characters you introduced. Now, the GM can reassign control of a character. This enables scenarios like:

  • The GM creates a set of pre-generated characters to pass out to players.
  • A player is absent and one of the other players will run his character.
  • A player’s going to run an NPC (because his paladin just charged bravely into the jaws of a purple worm)

Give control to...

Giving another player control over a character

To give another player control of a character, you right-click on the character portrait in the gallery (on the Characters tab) or in the portrait bar (which by default, sits just below the ribbon, on top of the main tabbed area for maps and tabletops), and select “Give control to…”.

You’ll see a list of players, including yourself. The player list is pretty bare bones right now, but it does the job. Select one and hit okay. EpicTable will transfer control of the character to that player. This means that the character will appear in his character gallery and will be added to the list of available characters in the persona selector of the chat window. Likewise, if control is taken from a player, by assigning it back to yourself or by assigning it to another player, the character is removed from his gallery and his chat persona selector.

A few rules about how this all works:

  • Only the GM or game organizer (which are, for now, the same person) may reassign characters.
  • The GM always can speak as any character and control any character, so he won’t notice any change to his gallery or chat persona selector.
  • Characters can currently only be controlled by the GM and one player. This was done, not so much out of a desire to constrain players as to avoid overwhelming them with characters to choose from. There’s an open feature request to allow any player to speak as or control any character. I plan to implement that feature, but only after 1.0 and when I can make it configurable.

Response to Auto-Reported Errors

There were a number of errors reported via the automated reporting tool (thanks) that I’ve fixed. These had to do with:

  • Character portrait handling in the chat window
  • Character portrait handling and in the character editor
  • Allowing the user to remove all the chat windows

What Didn’t Make Beta 19?

Map Issues Under Zoom

I’ve worked with some of you on map issues–especially snap-to-grid and map (mis)behavior when zoomed. Something’s clearly gone wrong with zoomed maps. They’re very sluggish. What’s more, positioning a token while zoomed has issues that are more than just sluggishness (though that certainly doesn’t help). I’m somewhere between embarrassed and reassured to be able to say that I know maps didn’t always behave this way. My group used maps under zoom a fair bit and didn’t see this problem until recently. Regressions are really embarrassing, but the glass half-full perspective is that this worked before and there’s probably some small, stupid, easy to fix thing behind this. Getting maps working properly under zoom again is my top priority. I almost held beta 19 up for it, but the other fixes were all in the final stages of testing before I became aware of the map issue, and it’s worthwhile getting the resource handling fixes, in particular, out to people.

Edit: I found the source of the sluggishness. It has to do with a change to how I draw the background. It was introduced when I added scrolling of texture-backed maps and tabletops. Looking into a fix now. In the meantime, you’ll find that image-backed maps and tabletops perform far better than texture backed maps. That also helps explain why my group missed it at first–we were using maps from a Paizo adventure path a lot, so we normally had image-backed, not texture backed maps.

Map Drawing Weirdnesses

I’ve observed some of the oddest things with a couple of the beta test groups…. There are some map drawing issues that are spectacularly bizarre. I actually have some theories about these. They’re next in line behind the zoom issues.

How do I get the beta?

Download the full EpicTable installer and run it. (No need to uninstall first.)

To those of you who have already installed the beta:  My apologies–the auto-updater won’t work for this release.  My goal is to distribute updates automatically, so you don’t have to visit this site to know that there are updates.  Sadly, the approach I’d been using for that has turned out to be less reliable and less flexible than I’d hoped.   I plan to replace it before the 1.0 release.  In the meantime, I’ll continue to distribute updates in installer form.

Thanks for your participation in the beta!

– John

Beta 18: Error Reporting, Stability, Image Updates

April 11, 2012

After the long pull on beta 17, there were some important things that I wanted to get out quickly.  As a result, beta 18 is here already!

Below are some of the highlights of this release.  For a full list of the fixes and enhancements in this release, check out the what’s new pageJust give me the beta! If you just want the beta download, without all the discussion of what’s in it, go ahead and jump down to "How do I get the beta?"

Reveal Yourself:  Improved Error Reporting

ErrorReportEpicTable has always had an automated error reporting mechanism, but one of my frustrations has been that the error reports were a little too anonymous. 

Anonymity is fine, but prior to this release, you could not supply contact info or any details about what was happening when you encountered an error.   A lot of times, that was okay—there’d be a smoking gun in the error report and I’d find and fix the issue without needing any additional information.  Every now and then, though, I’d get reports where the error was down deep in the .NET Framework code, and it would have been really helpful to follow up with some questions.  Plus, if someone’s having a problem, I like to make contact and see what I can do to help.  I’ll jump on a Skype session with you and join your EpicTable game, or whatever helps—but if I don’t know who you are, I can’t do that. 

Now, with Beta 18, you have the option to provide a name and email address, as well as some descriptive text.  As always, you’re free to report issues anonymously, if you’d prefer.


Beware Guests Bearing Images:  Stability Fixes for Image Retrieval by the Host

I resolved an unusual image access error.  You may have seen it and then written it off, because it would normally occur only once for a given image and only if that image was added by a guest participant (i.e., not the host) and had to be fetched by the host.

Another unusual one also involved images fetched by the host.  This one could actually cause EpicTable to become unresponsive.

 

Background and Object Image Updates

MenuChangeImageOne of the most versatile features of EpicTable is the ability to put an image on the tabletop—any image—it doesn’t have to be a character token or a map or anything—just whatever you want.  I use it all the time for dungeon dressing or as an alternative to a handout.  

When you hit the image button, you’re prompted for an image to use:

RibbonImageObject

It’s only when you want to change it that a couple bugs came into play. 

  1. If you changed the image of an object, that change wasn’t broadcast, so no one else saw it…which kind of takes the zing out of your changing that image of the peasant’s hearth into one of the throne room of Asmodeus. 
  2. If you edited an image used as a background or for an object on the tabletop, EpicTable would still show the original version of the file, even if you re-selected the image.

Happily, both those scenarios are taken care of in this release.

 

Let Go of My Token!

Changed select-on-duplicate to only do so when the duplication of an object was initiated by the local user.  It had been the case that duplicated objects were automatically selected for all participants.  However, this led to scenarios where different participants would “steal the selection” when they duplicated objects or added entirely objects to a tabletop.  This made it difficult for multiple participants to work effectively together on setup—you’d be moving something and suddenly drop it because the selection was stolen and given to another object.

Cleaning up Sticky Italics

There was an odd little bug that caused text objects on the map or tabletop to stay forever italicized once you changed their styleThis made everything put on the tabletop seem curiously enthusiastic and upbeat.  As of beta 18, you may now resume being dark and foreboding.


How do I get the beta?

Download the full EpicTable installer and run it. (No need to uninstall first.)

To those of you who have already installed the beta:  My apologies–the auto-updater won’t work for this release.  My goal is to distribute updates automatically, so you don’t have to visit this site to know that there are updates.  Sadly, the approach I’d been using for that has turned out to be less reliable and less flexible than I’d hoped.   I plan to replace it before the 1.0 release.  In the meantime, I’ll continue to distribute updates in installer form.

Thanks for your participation in the beta!

– John

Beta 17: “Leviathan”

March 24, 2012

Beta 17 is available.  Why “Leviathan”?  This is a BIG release that has taken me a long time to get ready. It’s the result of many bug reports and lots of play testing.

Below are some of the highlights of this release.  For a full list of the fixes and enhancements in this release, check out the what’s new page. Just give me the beta! If you just want the beta download, without all the discussion of what’s in it, go ahead and jump down to "How do I get the beta?"

Image Swap Fix

I think I’ve finally tracked down the source of the “Red X” (or the source of most of them).  You’d sometimes see this in the chat window, sometimes when dealing with handouts, occasionally when changing backgrounds.  The essence of the problem I found was in EpicTable’s “Image Swap”.  EpicTable doesn’t make you wait for everything to be downloaded.  It uses placeholder images (like the hourglass or the horned helm guy) while it downloads the missing images.  When it downloads an image, it swaps it with the placeholder image.  There was a race condition there, which made it possible that the placeholder would be disposed of before the new image was in place, and if the screen happened to get painted at that moment—BAM!  Red X. 

I can’t promise that the Red X is gone forever—it’s a generic response to memory issues.  So, if you just plain ran out of memory, you’d get it too, and there’s not much I can do about that, aside from making sure EpicTable isn’t taking more memory than it has to.  You should, however, see the red X become very rare.

Handout Sharing Fixes

Handouts had a couple problems:  First off, they often failed to display correctly when first downloaded.  The placeholder image was displayed, but then it wasn’t correctly replaced when the real image was downloaded.  Second, handouts were sent to the players immediately when you added them to the handout gallery—before you’d even shared them.  That made it impossible to load handouts before you wanted to show them to your players.  That’s all fixed now.  Handouts aren’t shared until you share them (which you can do by right clicking on them in the gallery and selecting “Share”).

Sharing a Handout

 

Summing a Single Dice Pool

An issue with the dice builder is fixed.  It had been the case that adding a sum to a single dice pool had no effect.  It works fine now.

Dice-Sum-in-Pool-Fix

Map / Tabletop Token “Sync” Issues

Several people have reported issues with map/tabletop tokens becoming out of sync between players.  I’ve resolved several issues that I believe account for many of the problems.

Resizing an object from the top or left

Resizing an object from the top or left was an because doing so actually moves the token (changes the position its upper-left corner). This side-effect of movement on a resize wasn’t accounted for previously, so after an object was resized in this way, its position was incorrect from the perspective of the other players.

Updating an object’s position via Format tab

Updating an object’s position from the Format tab wasn’t broadcast. That resulted in the updating participant having a different view of the object’s position than all the other participants.

Snap-to-Grid was improperly applied to incoming object moves

Snap-to-Grid was improperly applied to incoming object moves. Say I had snap-to-grid on and you had snap-to-grid off. Now, you move an object such that it doesn’t fall within a grid square. When that move broadcast to me, my EpicTable snaps it to grid, and now we’re out of sync with respect to this object.

Move by offset prevented self-correcting

Broadcasting object moves as offsets from their current positions kept them out of sync if anything bad happened. This wasn’t really a bug itself, but it kept the map/tabletop from being self-correcting.

Remaining issue with DPI settings

Just a word of warning:  There’s still an issue with people in the same game using different DPI settings.  If you change your default DPI settings in Windows, textures and objects render in the wrong positions.  For instance, if you bump your DPI from 96 to 120, the rendering of all textures and objects will be about 20% off to the top and left.

 

Lock Objects

You can now “lock” objects on the tabletop or map.  This prevents their being accidentally moved or resized or even selected.  This is great for when you have something that’s essentially part of the scenery or if you have image objects text objects that you’re using as a make-shift character sheet.

lock-object

 

New UI Themes

By now, you’re probably familiar with EpicTable’s default theme, “Adventure”.   While this is great for fantasy and pulp games, it’s not always as visually appropriate for horror or sci-fi.  You Shadowrun folks, in particular, made me feel the need to add new themes—not that any of you complained, but I just couldn’t quite bear to see you playing Shadowrun with the standard theme.  “Dark Future” is for you.

Adventure Horror
Adventure Horror
Sci-Fi Dark Future
SciFi DarkFuture

 

How do I get the beta?

Download the full EpicTable installer and run it. (No need to uninstall first.)

To those of you who have already installed the beta:  My apologies–the auto-updater won’t work for this release.  My goal is to distribute updates automatically, so you don’t have to visit this site to know that there are updates.  Sadly, the approach I’d been using for that has turned out to be less reliable and less flexible than I’d hoped.   I plan to replace it before the 1.0 release.  In the meantime, I’ll continue to distribute updates in installer form.

Thanks for your participation in the beta!

– John

EpicTable Beta 17 Ready To Go

March 23, 2012

EpicTable Beta 17 is all set, and there’s a lot in it.  I’ll post all the details tonight, but I wanted to get the word out for anyone playing tonight before I’m able to post the details.

http://www.epictable.com/downloads/EpicTable-1_0-Beta-17.exe

Beta 16: Horned Men and Philosophy of Movement

February 5, 2012

Beta 16 is ready. Anyone who wants to take EpicTable for a spin is welcome. Check out Beta 16: Horned Men and Philosophy of Movement over at the support site.

EpicTable Legacy of Fire, Episode 4: First Session

February 5, 2012

GenieLampWithSmoke-150Enough prep!  This post covers our first gaming session.  In this post, I’ll discuss:

  • Checking your EpicTable version
  • Dealing with hidden opponents
  • Tracking initiative without an initiative tracker

Awards

Before we go any farther, I have an award to pass out.  My friend and EpicTable booth cohort, Jeremy, wins the award for “Most Out-of-Date EpicTable Installation”!  While the rest of us were on beta 14, Jeremy was on beta 1.  To put that in perspective, we were showing something between beta 10 and beta 11 at Gen Con.  So this was way out of date.  It had me reeling to see problems of a sort I hadn’t seen in months. 

Now, this wasn’t entirely Jeremy’s fault.  Beyond the fact that the bugs in beta 1 were, after all, my bugs, Jeremy actually had installed beta 14.  

Here’s what had happened.  Back around beta 4 or beta 6, the installer technology I was using wasn’t letting me do what I wanted to do, so I switched.  I also made EpicTable 64-bit compatible.  This was a change that the auto-updater couldn’t accommodate (the first in a series of such changes, which eventually led me to turn off auto-updates until I can replace the third party component I’d been using).  As a result, everyone was instructed to uninstall and then install the latest EpicTable.  I believe that was the only upgrade which required an uninstall.  Since then, my instructions always tell you to just run the new installer. 

Jeremy had missed a couple upgrades, so he also missed the bit about uninstalling his beta-1.   This lead to his having both beta 1 and beta 14, and the shortcut he was using to launch EpicTable was launching beta 1.  After my near heart failure at “beta 14” behaving like beta 1, we moved past that. 

The moral of this story is:  make sure you have just one version of EpicTable installed, and that it’s the one you think it is. 

By default, EpicTable is installed in C:\Program Files\EpicTable.  This is the case for both 32-bit and 64-bit machines.   Early betas were installed under C:\Program Files (x86)\EpicTable on 64-bit machines.  If you have this directory, just get rid of it.  

I know some people who have installed EpicTable outside of C:\Program Files\EpicTable.   That’s fine—just don’t get yourself confused as to which version you’re running if you end up with multiple versions on your machine.

Checking Your EpicTable Version

EpicTable-FindVersionInside EpicTable, you can check the version through the About EpicTable… item on the application menu.  (That’s the little round button at the upper-left.) 

 


EpicTable-filedetailsFrom Explorer, you can select EpicTable.exe in C:\Program Files\EpicTable, (watch out—Windows, by default, hides file extensions, so you won’t see “EpicTable.exe”, just “EpicTable”), right-clicking and selecting “Properties” and then the “Details” tab. 

Dealing with Hidden Opponents

One of the first combat encounters we had was in the cactus forest mentioned in the last post.  In this encounter, we have an opponent that no one is very likely to see.  There are all sorts of feature requests out there for handling scenarios like this—all variants of hiding and revealing tokens and other objects.  I don’t have anything against these features.  I plan to implement hide/reveal, but I haven’t yet, so what’s a GM to do?  Well, it’s actually pretty effective to just create a private character, and then later drag them from the character gallery to the map.  I know, it’s low tech, but it worked well for us.  Of course, you have to deal with the fact that different characters see different things and now all the players see the new opponent, but I’ve never really had groups with much trouble separating player knowledge from character knowledge. 

private-character

Tracking Initiative without an Initiative Tracker

This one was actually an innovation of one of the beta testers.  I really want to add an initiative tracker (though that’s probably not making it into the 1.0 release).  However, this works so well that it’s changed my thinking a bit—not about whether I want an initiative tracker, but about what I think an initiative tracker should be like.  Because the tabletops and maps let you do essentially anything you’d do on a physical tabletop, one of the beta testers started dragging down additional tokens to the map—somewhere visible but away from the action—and using a coin or map pin to track whose turn it was.  It’s ingenious in its simplicity.  Here’s a screenshot of the “initiative tracker” we were using.

SimpleInitiativeTracker

True, there’s a lot more that an initiative tracker can and should do, but I thought this was pretty clever.  It certainly does the job.  It’s kind of like Paizo’s Combat Pad, which lets you move wet-erase widgets around on a magnetized pad.

In addition to the map pin to tracking who’s turn it is, we’ve also used things like red stones to track wounds, and talked about other objects to track various conditions.  It’s something my group intends to use until there’s an initiative tracker built in to EpicTable.

One thing this has taught me is that it’s really nice to have an initiative tracker that’s much more low-profile than what I’d been envisioning.   I’d always assumed I’d leverage the portrait bar, but since using this, I want something much smaller and something I can move around freely and reorient with respect to horizontal vs. vertical.

 


 


This is one of a series of posts about the Legacy of Fire campaign I’m running for my old gaming group on EpicTable. For the background on this series, check out the original EpicTable Legacy of Fire post, or you can access the entire EpicTable Legacy of Fire series, where I’ll be discussing our game, how I prep, how I run the game, and all the interesting things we run into using EpicTable.

Beta 15 – Fixes, Hexes, Keys!

January 20, 2012

Beta 15 is ready. Anyone who wants to take EpicTable for a spin is welcome. Check out Beta 15 – Fixes, Hexes, Keys! over at the support site.

EpicTable Legacy of Fire, Episode 3: Cactus Forest Map

January 13, 2012

GenieLampWithSmoke-150One of the early encounters takes place around a cactus forest. There are plenty of cactus, rocks, and a ravine providing an opportunity for falls. I could have drawn this ad-hoc, during the session, and that’s probably what I would have done with my physical battlemat. However, I’ve many times wanted to be able to prep a battlemat ahead of time–it’s just that the ink tends to smear when I roll it up. Since digital battlemats don’t tend to smear, I decided to prep the encounter map ahead of time.

I started by creating a private map (private because I didn’t want it shown to players immediately). I backed it with a texture–sort of a death valley looking wasteland texture. It’s one of the ones that ships with EpicTable. For the ravine, I used the drawing tools. I made myself a nice, thick black pen and painted in a ravine. I could have just drawn some squiggles and circles and said, “these are cactus, those are rocks”, but as long as I was prepping…. I went out to the Dundjinni “user creations” forum to search for cactus and rocks. This is an excellent place to find images for maps, as well as advice on making maps. My chief complaint is that every time I go out there, I get distracted and wind up looking at images way too long. (Dundjinni’s also my preferred map making tool, but this was just a quick-and-dirty battlemat, so I just wanted to plunk some images down on the EpicTable map.) And that’s exactly what I did. I downloaded a bunch of rocks and cactus and put them all under “maps” in my campaign folder. I then went to my map and inserted an image object for each cactus image I downloaded. Then I just duplicated each of these objects a few times and changed their size and rotation. In no time I had a cactus forest! I did the same thing with rocks to give the area a little interest (and to create some hiding spots!).

Cactus Forest Drawn with EpicTable

Cactus Forest Drawn with EpicTable


I was pretty pleased with how easy it was to do this. Two negative things struck me though. One is simple—the current implementation of texture backed maps (and tabletops) in EpicTable doesn’t scroll. I know—it’s a crazy oversight. In my head, at the time I implemented that, a texture was like a gas—expanding to fill the available space…which was the window size. Ironically, I named the class responsible for texture backgrounds, “InfiniteTextureBackground”. One part of my brain clearly “got it”, but the other was just not listening. I’ll fix this before release (the texture backgrounds, not my brain).

The other negative thing was that, with all those cactus objects, it was pretty tough to grab the character that I wanted to have positioned in the cactus forest. The real solution to this is (as some of you on the forum have suggested) to have a separate layer for background objects. I never wanted to interact with the cactuses, I just wanted them there in the background, and dropping in image objects was a convenient way to do it. While I’m not trying to make EpicTable a full-blown map-drawing tool, I’m pretty convinced adding layers like this to EpicTable’s map feature set is valuable. Since I don’t have that functionality right now, I took a screenshot of my creation (I used SnagIt, but you could just Alt-PrintSceen and paste it into any image editor. I replaced my texture+objects map with a new one: an empty map backed with the image of a ravine and cactus forest that I’d just created. Essentially, that’s equivalent to what I want to be able to do with layers. If you do this, make sure you turn off the grid display before you take your snapshot, so the grid isn’t part of your background.


This is one of a series of posts about the Legacy of Fire campaign I’m running for my old gaming group on EpicTable. For the background on this series, check out the original EpicTable Legacy of Fire post, or you can access the entire EpicTable Legacy of Fire series, where I’ll be discussing our game, how I prep, how I run the game, and all the interesting things we run into using EpicTable.

EpicTable Legacy of Fire, Episode 2: Raiding the Adventure PDF

January 11, 2012

GenieLampWithSmoke-150As part of my prep for our first session, I wanted to get some important NPCs and upcoming monsters setup as NPCs. Game mechanics are mostly managed outside EpicTable (though see post on character sheets in EpicTable). I didn’t want character sheets for any of the NPCs or even any of the monsters. I just wanted character portraits so everyone would know what the NPCs and monsters looked like.

I considered fishing around for top-down tokens. EpicTable lets you specify a separate image for a map token…but I don’t always like using top-down tokens. Unless you’re very familiar with the thing(s) your fighting, it’s tough (for me at least) to get a sense for who’s who from the top-down token. I actually kind of prefer the pog-style tokens, and EpicTable will make a pog-style token automatically from the character portrait.

Abandoning my thoughts of top-down tokens, I went through the first part of the PDF, looking for character portraits. It would be incredibly helpful if Paizo provided these as PNG images, but they don’t. So, I started with a screenshot…only the portraits aren’t exactly isolated. They have the page background, and some of them have text wrapped around them. I can maybe—maybe—ignore the background, but I can’t ignore text in my character portraits. So, I started cleaning them up in an editor. It struck me that there must be a better way. There is. There are various tools out there that let you extract images from PDFs. They’re not all created equal, and the result isn’t what you’d think. They don’t all just tumble out as ready-to-use PNGs. Extracting images from a PDF is a topic unto itself, so for now, lets leave it as: I pulled images for several characters from the PDF. If you’re interested in how I did that, let me know.

While I was at it, I pulled, not just character portraits, but a full-length character image for one of the characters that seemed especially imposing or worthy of attention, an image of the caravan in the midst of the adventure’s first encounter, and some maps for the ruined monastery that I figured we may or may not get to this first session.

I made shared characters for the important NPCs, filling in nothing but their names and portraits, and made private characters for the first couple adversaries I’d spring on the group. The difference is, the shared characters were in the portrait bar, immediately visible to the players. As with the shared NPCs, I only bothered with names and portraits for the monsters and adversary NPCs.

I added handouts for the full-length character shot and for the picture of the initial encounter and left these unshared, so I could pop them up on the players’ screens at the appropriate moment.


This is one of a series of posts about the Legacy of Fire campaign I’m running for my old gaming group on EpicTable. For the background on this series, check out the original EpicTable Legacy of Fire post, or you can access the entire EpicTable Legacy of Fire series, where I’ll be discussing our game, how I prep, how I run the game, and all the interesting things we run into using EpicTable.

Next Page »