You could highlight all the pieces you want off board, and go to the move to menu and select off board.

When done you select the same pieces in the off board pieces tab, and can move them back to the board in there old spots.

But if the same logic powering the piece info filter could be applied to the pieces on the map that are visable it would be a much easier way to get a clear look at the board.

If you mouse over a stack you can see whats in there but its not the same as clearing all the clutter off the board to get at the ships.

By Paul Franz (Andromedan) on Wednesday, May 30, 2012 - 11:19 pm: Edit

Ken,
I will see what I can do.

Mike,
That is a little harder. The pieces will need to be hidden on the board.

Josh,
I think that would be the best. That is if I could link the Filter to what you see on the board to be consistent

By Mike Kenyon (Mikek) on Thursday, May 31, 2012 - 12:01 am: Edit

So, I thought about the on-board/off-board thing. Part of the problem is I have off-board fighters for rack loads, so it's a little confusing what's actually off board and what I'm just hidding, but that could work.

By William T Wilson (Sheap) on Thursday, May 31, 2012 - 12:17 am: Edit

I find that in a large battle, I basically play entirely on the game control and almost completely ignore the board.

The first step is getting the right computer setup. You need two (or more) big monitors. One monitor has the board, the other monitor has game control, impulse chart, and SSDs. I actually have a third monitor, which I have for work, but which I consider indispensable to complex battles. In my 3-monitor setup, the center monitor has the board and the IA popup, the left monitor has the SSDs, and the right monitor has game control, impulse chart, and expendables/weapon status. With the board as a floating window, I can have the chat on the "main" window with expendables and whatnot, leaving more space for the board alone on the center monitor. In a tournament style game, the whole board fits on the center monitor with room to spare; in a large map game, you still see a lot more of the map than you would if the map had to share space with other windows.

My center monitor is a 4x3 aspect ratio CRT, which closely approximates the shape of the board. If your center monitor is widescreen, as most are at this point, you would be able to have room for a tall, narrow window to the side of the board, perhaps the weapons chart or even the game control. I, however, prefer a fairly wide game control, but if your center monitor had enough pixels, you could do a slightly shrunken board, game control to the side, and then something below the board. The toolbar has a "tear off" capability so that you can detach it from the main window, and position it right below or above the board, that's probably what I would do. Unfortunately, the "action bar" cannot be detached from either the game control or the main window (although you can turn it off in either location).

If you are using Windows, the default Windows Look & Feel used by Java is fairly compact. If you are on Mac or Linux however, the available L&Fs are wasteful of space. You can hack the Java system to use the Windows L&F anyway, or you can install an add-on L&F. I use the Infonode L&F, which is intended for productivity applications and displays information efficiently (except the impulse chart, unfortunately, which is either much wider than it needs to be, or has the column headers with the speeds cut off).

Next is picking the right information display in game control and adjusting the column widths. The UI doesn't save the column widths so you have to twiddle it every game, but the fact is that unit name needs a lot more space than move status, with target and position somewhere in between. Making that adjustment means you can always see what you need to see. What you don't see in game control is just as important as what you do see - owner and especially unit type aren't all that useful.

Configuring the ancillary chaff in game control can help as well. Turn off the useless mini-map, a space-wasting holdover from the ancient 2.x client. If you must have movement buttons, select small ones. Unfortunately, having any movement buttons at all means a double-wide control area in game control - another 2.x holdover. A fleet battle needs a long game control window and this means the movement buttons stick out to the right when they could flow down - the movement buttons end up consuming probably ten square inches of screen space for a reasonable game control window size. If you can at all stand it, get rid of movement buttons entirely and use the keyboard shortcuts.

There is a LOT of information potentially displayable in game control. The configurability here is probably SFBOL's best feature. Turn on move status display, and sort by that, so you can see which pieces still need to move. I find target name, ECM and loaned ECM, and notes to be essential displays as well. (If only there was a column for natural ECM!)

The game control unit filter is far less capable than it should be. The predefined filters are in no particular order in the menu, making the entries hard to find. The custom filter feature would be fantastic, allowing very useful and precise filters, except that you can only define one filter at a time, and the filter does not actually work. It almost works, but it doesn't, and to really be useful you would need more than one anyway. Wouldn't it be great if you could define a filter that shows, for instance, all the enemy drones targeted on a particular ship, that you could toggle on and off as the waves of drones approach? 80% of this feature is there. Complain to Paul.

Because units selected in game control are highlighted on the map, a working custom filter would essentially solve this entire problem (at least you would see the hexes the units are in, if not their facing). I have asked for automatically bringing selected units to the top of their stack, or even a manual bring-to-top feature, before. You have to make do with the "rotate stack" button, or just getting used to seeing unit facings in the game control window.

It would still be better if there was a "smart turn markers" feature. For instance, an option to display the POT/POS markers only for selected units. Still, I basically ignore the POT/POS markers because some of that information is available in game control.

Game control has a "Moves" column which (almost) works as a turn mode counter. It does, for ships (except that it displays one less than the actual accumulated turn mode). The best part is that it is not confused by tractor beam induced movements like the POT/POS counters are. Unfortunately there is no sideslip status option (the best situation would be a separate Turn & Slip column that combined both pieces of information and wasn't off by one). As it is, it is still possible to mark POT markers as hidden and maybe POS markers too, depending on how willing you are to scroll back in the chat to look up slip mode status. Additionally, the client simply does not track the turn mode status of shuttles (the "Moves" column increments instead of being reset when they turn). This only occasionally matters in tournament, but it matters in fleet battles all the time. Shuttles probably should never have POS/POT counters because of the clutter problem that would result, but it's too bad the turn status is simply not tracked at all, because a display in game control (and a report in the chat window when the shuttle turns, just like ships have) would be very useful.

SFBOL does not really present information in a hierarchical order of importance. For instance, in the fire summary, it does not organize fire by target and range, but instead by firing ship, which means you still have to tally up all the fire manually when more than one firing unit is involved. Similar problems affect weapons targeting - instead of picking a target and then deciding what weapons to fire at it, which is the user's thought process, you have to pick weapons to fire and then designate targets for all of them individually (and the column where the targets are designated is too small to see the name of the unit you are trying to target). This also means you don't see the range to the target until after you've picked it, and gatling phasers can't be targeted on multiple targets. When there are many targets involved it gets very hard. This would help not only large battles, but even the tournament battles that are the majority of SFBOL games.

I would probably pitch a fit if my opponent was moving pieces on and off the board.

By William T Wilson (Sheap) on Thursday, May 31, 2012 - 12:54 am: Edit

My previous post was very long, so, in the interest of brevity, here would by my list of display and movement related features that would improve complex battles:

1) Make the custom unit filter work. Right now it updates the game control window once, when you edit the filter. Selecting the filter does not apply it, and it does not update when conditions change. It only updates when you edit it. Also, saving multiple filters (kind of like saving drone loadouts) would be necessary for this to be really useful. Finally, while the logical operators that are there now would be a big improvement over what is currently usable, not and parentheses would be needed to really make the most of it. (ability to incorporate other custom filters would also be on the wishlist, and in fact this would be equivalent to parentheses operators - right now you can already incorporate the predefined filters, so hopefully it's not that far off).

2) For me, a turn & slip mode column that could be displayed in game control, that also had information about shuttles. For others, perhaps, linking on-board counter display to the game control filter would be more valuable. I am not sure I would use that if it existed and would probably want to be able to turn it off if it did exist, because I would want control over the hiding certain counters (I always hide pods, modules, pallets, skids and such, as well as turn & slip counters in large battles, but never hide terrain and would probably never want to hide ships). In some cases I might hide some POT/POS but not others, for instance, in a convoy battle I might hide all the freighter's POT/POS but not those of the escorts or attackers. Hard to get this right in a filter. Meanwhile, the fact that a filter is used in game control doesn't always mean I would want to hide the filtered counters on the map. Maybe I selected only my seeking weapons in the filter so I can move my drones, but doing that made all the enemy ships disappear - not good.

3) Weapons targeting that matches the actual player's thought process (select target, choose weapons) vs. the current workflow (select weapons, designate targets). I would happily write this code.

Fighter ready racks and loadouts are still kind of a problem area, but beyond the scope of the discussion...

By Paul Scott (The_Rock) on Thursday, May 31, 2012 - 12:48 pm: Edit

The FCOL client handles fire declaration perfectly. Essentially it acta as you say. The pulldown is for the target, not the weapon. Once the target is selected, you ise the SSD and click on the weapons you want to fire.

You should check it out to see what I mean, but imo SFBOL should adopt that code.

By Francois Lemay (Princeton) on Thursday, May 31, 2012 - 01:56 pm: Edit

Re the POT and POS counters, is it possible to have them always at the bottom of a stack ?

It seems they are always at the top of a stack.

Cheers
Frank

By Mike Kenyon (Mikek) on Wednesday, June 06, 2012 - 09:58 pm: Edit

In getting shot at today, I noticed something. First of all, the fire is summarized and then printed in expanded form.

When printed in condensed form, it's sorted by firing ship and what all it's firing. GREAT!

When printed in condensed form, it's sorted by firing ship and then by the weapon it's firng.

IMHO, it would be more useful to have it sorted the SECOND time, but who you're firing at, then source, then weapon. That way, when you have 23 phasers going about at 8 targets, you and go "all fire at X", okay "fire from this ship". Just an idea.

By Josh Driscol (Gfb) on Friday, June 15, 2012 - 11:33 pm: Edit

I had an idea for a new player mode, you could call it gamemaster mode.

The goal would be for a more experienced player to be able to look at both EA and expendables for both sides and give guidance.

Another feature this game mode would benifit from is a chat to each player only, so a player could ask the GM privatly a question but the observers and opponent wouldnt see it.

Teaching new players SFB on SFBOL can be a real challange when you cant see what they see, anybody else have ideas on how this could be made easier?

By Jon Berry (Laz_Longsmith) on Saturday, June 16, 2012 - 12:16 am: Edit

You should be able to reveal your EAF to everyone already, and that would help.

By Josh Driscol (Gfb) on Saturday, June 16, 2012 - 12:28 am: Edit

True but its revealed to everyone, this would allow the newer players to not reveal there EA's but to have a much easeir time learning the the interface and rules.

You could look over each players EA and speed plot before they submit and say yeah looks good, or fix this and its ready.

By Carl Herzog (Carlzog) on Saturday, June 16, 2012 - 09:54 am: Edit

Josh, this is a great idea... Can't imagine what made you think of it! ;)

Seriously, I know I would have loved to have that feedback last night, and I'm sure Vix would have too. Would have saved us both some time and confusion as we negotiated the client and the rules.

I've also thought about this from an observer's mode standpoint too. I watch matches to learn from more experienced players, and I would love to be able to see their EAFs to understand their tactical thinking as I watch it unfold during a turn.

However, I suppose you would want to make sure that your EAF could still remain secure from your opponent though, right?

By Paul Franz (Andromedan) on Saturday, June 16, 2012 - 09:55 am: Edit

Sounds like the old "Judge/Teacher" mode that I have wanted to do. I will need to see what that would require because the EA and Expendables would just need to be read only.

By Josh Driscol (Gfb) on Saturday, June 16, 2012 - 01:49 pm: Edit

Yes, but it would be nice if you had some way to draw there attention to a button or other SFBOL widget that they vitally need to learn to use.

It would be great if you could open there speed plot but not make changes, to confirm that its a legal plot.

To Carl, definatly you wouldnt even want observers being able to see your EA. And the client lets you reveal EA's at the end of a game, this Judge/Teacher mode would allow an impartial player to audit your EA in real time hopefully preventing any mistakes before there locked in when you submit EAF.

The 2 way chats would allow each player to ask tactics and rules questions without having to broadcast there intentions to the opponent. You can do this now but its not built into a special mode, so it may be best to do this with the private message capabiilty the client already has.

Perhaps it would be nice to be able to reveal EA to a particular player, a new player wanting to learn by watching would really befifit from being able to look at my EA form.

Maybe a reveal EA to observer x button where x is the callsign of a player in the room but not your opponent. The regular reveal EA form button could still work for end of game revealing EA's to observers and your opponent.

By Carl Herzog (Carlzog) on Saturday, June 16, 2012 - 03:30 pm: Edit

I don't know anything about the programming required for this, but I do like the functionality you're proposing.

To prevent coaching from turning into cheating, it would probably be necessary to make sure both players agree to having one's EA available to a third party.

By Josh Driscol (Gfb) on Saturday, June 16, 2012 - 04:06 pm: Edit

Yes it would be a pop up saying allow this player to switch to Judge/Teaching mode, similar to how you already request player mode.

So both players would have to hit yes before the Judge/Teacher would see your EA's and Expendables.

Or at least thats how I would like it to work.

By Carl Herzog (Carlzog) on Saturday, June 16, 2012 - 06:02 pm: Edit

Makes sense.

On a nominally related note, is there a reference manual for the SFBOL client? I've seen the tutorial videos, but no comprehensive reference manual to the client's functions and menus.

By William T Wilson (Sheap) on Saturday, June 16, 2012 - 11:10 pm: Edit

I think GFB is the reference manual for the client.

By Kenneth Jones (Kludge) on Sunday, June 17, 2012 - 06:22 am: Edit

Carl there was an old User Ref I wrote but its pretty out of date. It WAS available same place you would download the client not sure if it still is or not.

By Carl Herzog (Carlzog) on Sunday, June 17, 2012 - 06:51 am: Edit

Found it Ken. Thanks!

By Mike Kenyon (Mikek) on Friday, June 22, 2012 - 12:19 pm: Edit

So, the recent announcements of this week from MS have had me wondering whether something had been thought of.

I don't know the Mac vs. PC demographics of SFBOL players, but with the next release of the Win operating system there's a distinction made based off of your underlying hardware. There are traditional computers with Intel-based processors and then ARM processors (what you get in phones and most tablets).

The next version of the client operating system is a completely contained environment, very much like coding for the iPhone. You're limited in what you can do and use, but more facilitites are opened up for you. For the sake of compatibility, you can go into a shell and run on something that reasonably looks and feels like the current OS ... but only if you're on an Intel box (ARM processor versions don't seem to have that shell).

So, Java isn't going to work in the non-shell area nor are you allowed a plug-in, so you can't run in some form of browser shell.

Has there been any plans for the 2-4 year timeline when a fair number of the new PCs coming out won't be able to run the SFBOL client?

By William T Wilson (Sheap) on Friday, June 22, 2012 - 03:29 pm: Edit

There are not going to be any ARM-based PCs. MS's new "Surface" platform is about tablets. MS is basically changing their tablet strategy from the traditional Microsoft OS-vendor, hardware-neutral approach, to something more like Apple, with end to end control. But it doesn't affect PCs, which will continue to run Intel hardware. Nothing would stop you from putting an ARM-based CPU into a PC-like form factor, except for the fact that no one would buy it because it would only run tablet software.

It's all moot because nobody is going to want Microsoft's tablets, either.

By Mike Kenyon (Mikek) on Friday, June 22, 2012 - 06:27 pm: Edit

William,

That's a little head-in-the-sand, don't you think?

I concur that technically, if it's an ARM processor, it's pretty much a tablet.

What's a tablet? It's a computer half the price of a laptop, with the exact same operating system as the laptop, with exactly the same capabilities with a keyboard, running Office and everything else that your desktop runs ... except the SFBOL client.

I do not mean to forecast sales of the OS and as much as people complained about major OS changes in the past, the adoption has taken hold. There's a lot of consumer reasons to suggest that they'll be as successful with this release as any other, if not more so.

By William T Wilson (Sheap) on Saturday, June 23, 2012 - 09:05 am: Edit

PCs run PC software, tablets run tablet software. I expect a very wide gap between the available software, just as there is now between Windows Phone and real Windows.

I think you are just taking way too big a leap. You're assuming that MS's tablet offerings will be successful at all, that if successful they will morph into PCs running ARM, that if that happens they will displace Intel-based PCs for non-niche applications, and finally that if all of that's true you won't be able to run SFBOL on them. I actually don't believe any of those things are likely.

MS is cranky that some big PC vendors like Dell and HP are doing nothing with tablets, and others like Asus are building Android tablets, and no one is showing any interest in Microsoft's tablet OS. As a result, Microsoft will do it themselves, like they did with XBox. There is no plan at Microsoft to do away with the PC platform, which would be like Ford deciding to kill pickup trucks, or Amazon deciding to stop selling paper books.

Why would I buy a Microsoft tablet instead of an Apple or Android tablet? Apple is always going to have better design and Android will always have more choices. Microsoft's only advantage is Office, and I'm not sure anyone will really care. Tablets are lousy platforms for document oriented work, and even if you did want to use a tablet for your document, you'd want a cloud-based approach where MS doesn't really have much compared to Google. The web browser is much more important, and Microsoft always has the worst browser by a wide margin.

Also, I don't agree that an ARM-based PC would cost half what an Intel PC would cost. Sure, there are some very small and cheap tablets that you can get for under $200, but they are very limited, with small screens, tiny amounts of storage, slow CPUs, and limited RAM. When you add on all the stuff to a tablet that PC users take for granted, it costs what a PC costs. Look at the Asus Transformer Prime - it costs $500+, and the specs are still less than a laptop PC in that price range. I have one and I love it, but I couldn't replace my PC with it, even if it had software parity. Tablets just work differently, even if they have keyboards attached.

By Matthew Potter (Neonpico) on Saturday, June 23, 2012 - 12:09 pm: Edit

Apple has been letting their OS slide for the last several years. In many ways, their OS design has been following (i.e. been borrowing heavily from) their mobile designs (iPad/iPod). I could see MS doing the same thing.