Dropdown menus could also easily be used for weapon banks.

By Paul Franz (Andromedan) on Sunday, September 02, 2012 - 10:23 pm: Edit

Please explain to me how they would be used. The only time that I see a use to see what each is, is when you are doing EA at which point does it matter what weapon is charged except possibly in the case of a rapid repair.

By Gregg Dieckhaus (Gdieck) on Sunday, September 02, 2012 - 11:00 pm: Edit

[matter already resolved]

By John Smith (Johnsmith) on Sunday, September 02, 2012 - 11:41 pm: Edit

Hasty repairs for phasers is the primary issue for me, along with which heavy weapon is destroyed.

By Paul Scott (The_Rock) on Monday, September 03, 2012 - 01:13 am: Edit

pulldowns I think are a clever way to deal with the guard and H&R issue. Also a cleaver way to deal with the drones/heavy weapon/hasty repairs. It seems to me the best option to maintain most of the the function of the current interface but also make it impossible to use these in place of paper SSDs for table top.

Actually, really, if every number box expanded out with a pull-down, then you can keep 100% of the individual box tracking. The boxes are just hidden, except for one grouping at a time, and their total replaced by a number.

To me, this is a no brainier and totally brilliant idea I wish I had originated. It satisfies 100% of everyone's concerns because the boxes, everyone of them, are still all there, but in a way that makes them completely useless to anyone trying to use SFBOL as a piracy source. you could continue to use the red/yellow/white as designation for damage and repair because the boxes would all be there if you clicked on one unit of boxes (e.g. LW).

I am about to leave the country, but when I get back I'll do a mock-up of what I envision if it is not clear from the text of this comment.

By Chuck Strong (Raider) on Monday, September 03, 2012 - 01:25 am: Edit

I've been busy with the laborious task of moving into my new home the last several weeks and thought I catchup with the BBS...

I missed the memo of what is going on here with the burning of bandwidth -- can someone tell what are you guys doing and why?

By Terry O'Carroll (Terryoc) on Monday, September 03, 2012 - 03:00 am: Edit

Chuck, the discussion is regarding the "third generation" of SFB On-Line SSDs/Ship Cards. The idea is to come up with SSDs which show data in a way that is useful for on-line play but useless for off-line play, with the intention of making piracy of SSDs from SFBOL impossible. SVC posted an example, somewhere up thread. It basically reduces boxes of a particular type into a single box with a numeral in it showing the # of such still there. E.g. 15-box right warp is changed from fifteen individual check boxes into one box with a "15" in it. Other boxes, such as weapons of the same type with the same firing arcs, are given the same treatment (four photons firing FA is a box with a "4" in it.) As boxes are destroyed the number in the box changes.

There is some discussion about how this will interact with various rules, in particular Hit-And-Run Raids, partial/hasty repairs, and so on. The idea of ADB seems to be (if I understand correctly) that such things will be handled not on the SSD itself but somewhere else in the client. SFBOL users seem to want to have it summarised on the SSD in some way (again, IIUC).

By Steve Cole (Stevecole) on Monday, September 03, 2012 - 02:15 pm: Edit

I don't think it needs to be subsumed into the SSD, and think that pulldowns are cool and sexy and more work than Paul will do.

I'd say go to third-gen with separate notations ASAP and implement pulldown menus later.

Gregg D: Please quit whining as that matter has already been resolved. Tournament SSDs will be the last ones change if they're changed at all. It will be discussed AT THAT POINT. You're just wasting your time and my bandwidth and annoying the bears.

By Paul Franz (Andromedan) on Monday, September 03, 2012 - 08:37 pm: Edit

When it comes to the drop down list I think this is something that could be done later. Because currently the partial repairs are announced and that is it. Because people have been using the yellow box type to denote a repair. They were originally designed to mark a partial repair.

Also, the whole repairing Impulse as an APR is currently being handle by hand and currently that would not change.

By John Smith (Johnsmith) on Monday, September 03, 2012 - 09:04 pm: Edit

deleted

By Steve Cole (Stevecole) on Tuesday, September 04, 2012 - 02:02 am: Edit

I think the idea of drop-downs being used to handle guards is wrong. You need to see at a glance what's guarded and that's easily done on a separate things-guarded-chart.

By Clint Woodall (Vix_Sundown) on Tuesday, September 04, 2012 - 05:41 am: Edit

Dear Mr. Cole,

I am reading through this and trying to understand. Your main concerns - as I see them - that are driving the change to non-graphical SSD's are:

#1 - People who pay for SFBOL but don't buy modules because they are already on SFBOL for free.

#2 - People who steal SSD's off of SFBOL for use in face to face games, again without paying.

Regarding #1, one idea would be to use a DLC-based system instead. Where $60/year buys you the "Basic Set" of SSD's. Then if you want Advanced Missions, or various Modules, you just pay extra for their SSD's. Is there any reason why that wouldn't work? I know I certainly wouldn't mind paying for the privilege of the SSD's we use.

Regarding #2, I submit that the new non-graphical SSD's won't solve the problem. People can still download/steal them anyway, and play with them. Yes, they won't be as much fun to play with, but are still totally playable. An alternative solution would be to implement server-based storage of SSD files. Then the SSD's could only be accessed if your registered name has clearance to get them.

Would you reconsider these options? I don't know what the exact plan is with non-graphical SSD's. But I do much prefer the existing SSD's, and I know I speak for many others when I say that.

I also 100% support ADB protecting its copyrights.

Thanks for your consideration.

By William T Wilson (Sheap) on Tuesday, September 04, 2012 - 07:17 am: Edit

Vix, both of those have been discussed at length - including examples of the new SSD style. SVC has already rejected your option #1 because he doesn't think the pricing will work and option #2 will be part of the solution going forward.

------

SVC is probably right that assigning guards through a single guard assignment table is better, otherwise you can't tell where your BPs are.

------

I went ahead and coded up my "Functional Mockup" as I discussed last week - hey, it's still Monday somewhere. I tried to explain it, but what I was proposing was misinterpreted so I just made a demo. Anyway, it's visible here:
http://lights.sheap.net/~fluffy/sfb/ssd.html
(I realize this does not technically meet the requirements for an SFU fansite; I hope under the circumstances SVC will overlook this. I will take it down as soon as the SSD issue is resolved).

You'll need a Java-enabled browser to play with it. Theoretically, it works with 1.5 Java, but I have only used it with 1.6 and 1.7. If anyone has trouble seeing it, a screenshot (showing details of the batteries) is here:
http://lights.sheap.net/~fluffy/sfb/screenshot.png

Some notes, because this is only a functional mockup:

I used a Romulan Tournament Firehawk SSD and the Romulan Firehawk ship art from the "doodle" thread in new product development. I used the TFH, not because I want to convert tournament ships, but because I didn't want to use a "paid" ship and because I am mostly a Romulan player. The SSD is bigger than it needs to be (and I probably should have used a better font) but I didn't know how it would look when I started. The SSD resembles SVC's example as closely as I could make it, but I have the artistic talent of a donkey, so it's not perfect.

Based on what I know about SFBOL, the code is intended to be similar to the data model currently used by the client, or at least adaptable. I am willing to work with Paul to integrate this into the client (I offer to help write code on a regular basis, but Paul has never accepted the offer), or I will give him the source code and he can do it himself, or he can ignore it and do it over, and I won't be cranky if what he does is at least as good. I spent less than a day on this and most of that time was spent fussing with putting the boxes in the right place, so I think the effort should be manageable (and it would have taken even less time than it did except I haven't written Swing code since 2005).

Weapons are combined into a single box if they are the same type of weapon with the same arc. On the example firehawk, the S-torps and some phasers are combined, but most are not, as practically every weapon on the ship has a different firing arc. Some things which are separate box groups on the paper SSD are combined: the shuttles, the center warp, the S-torps, the hull, etc etc.

Every system on the ship is tracked individually, but the display is intended to be extra-useless for tabletop. The systems are color-coded by damage (not by type). A green system has no damage, a yellow system has some damage, and a red system has been totally destroyed. If a system is yellow, the color coding works like a health meter and shows at a glance what percentage of the system is remaining. There is also a "health meter" for the whole ship at the top of the screen, since it's no longer easy to see if you have taken just a couple of hits or are a sea of red. It turns red if the ship is crippled (ok, it turns red if the ship has more than 50% damage - I didn't include the rules for crippling by engine or weapon damage, it's a mockup).

You can get more details on any system group by clicking it. The details are all-text and clicking a new group closes the details for the previous group, so there is no practical way to extract this information and use it tabletop. The only information in the details is information about the specific game state, so there would be no point in trying to extract it anyway. The purpose of the "special" column in detail is to contain the numbers needed for sensor/scanner/damcon. There is a bug where the details window doesn't stay where you put it. Sorry (mockup!).

Colorizing by type would be possible in the system name, so long as contrast is preserved.

If a system is undamaged, then the number of boxes is displayed as a single number. If it has been damaged, it is displayed as "3/5" where 3 is the number of boxes remaining out of 5 total. If it has been damaged and has hasty repairs, it is displayed as "2+1/8" where there are 2 intact systems and 1 hasty system out of 8 total.

Firing arcs are defined in the specific weapon definitions (which I know SFBOL has because it displays it when you take damage). Unlike current SSDs, there is no 'painting boxes' on the background. The background is a plain piece of ship art and the code generates everything else, so all that would be necessary to make a new ship definition is to select a piece of art and drag things into the right places. Getting all the various boxes and text and everything to fit made gen-2 SSDs take about five times longer to make than they should have, and with this, one piece of ship art would suffice for a given hull and almost all its variants. If it's possible to import an old-style ship definition (and I hope it would be) then the whole conversion project could be done in a relatively short time due to simplified definitions.

Note that weapons details have additional information not present for systems details (this information is of course bogus in the mockup). Weapon IDs come from the weapon definition, non-weapon systems are just given sequential numbers (because of an oversight these numbers start at 0, rather than 1). In a real SSD, guarded status would only be displayed to the owner, of course.

The Firehawk in the example has taken some damage. The mockup is in "edit ship mode" - indeed it ONLY has edit ship mode - and you can see the display change as you edit the systems, which is done by going to any system details and clicking the status for a particular system (i.e. it works just like the current SFBOL in edit mode, except it's text).

------

One thing I still oppose is doing "summary boxes only" and then going back later and doing it again. No one will want to make summary-only SSDs and I doubt it's actually much more work because so much else in the client (ea, damage, weapons status, etc) is already based around individual systems. Let's just do it right the first time.

By Josh Driscol (Gfb) on Tuesday, September 04, 2012 - 08:02 am: Edit

I think it looks good but is a bit hard for me to read.

By William T Wilson (Sheap) on Tuesday, September 04, 2012 - 08:13 am: Edit

Yeah, the font size is actually exactly the same as the traditional SSDs but because the overall SSD is lower contrast it's harder to see. If I did it again, I'd make the text bigger, but that would mess up all the positioning.

By David Zimdars (Zimdarsdavid) on Tuesday, September 04, 2012 - 09:46 am: Edit

William - I think Clint is trying to provide polite customer feedback - with the knowledge that this feedback is asking the company to reconsider a business position. Perhaps ADB can give some guidance where or how to send polite feedback of this nature; where might be politely noted without being disruptive to an open conversation which has moved onto other topics. It is understandable such feedback might be posted here; but it is also understandable that the open mic engages many people who are not the decision makers. I am not trying to undermine Clint; I happen to agree with him. Which I believe was duly noted earlier. Since ADB has publicly moved the topic of this thread on- I just wonder if there is a way to send polite feedback without being disruptive.

By Jean Sexton (Jsexton) on Tuesday, September 04, 2012 - 10:02 am: Edit

David and anyone else -- a good way of sending feedback is via email to SVC. Please put something specific in the subject line so it doesn't get deleted as spam. If you email him, do make sure that any firewalls or spam traps are already set up to let his email to you get through.

By Ted Fay (Catwhoeatsphoto) on Tuesday, September 04, 2012 - 10:19 am: Edit

David,

Suggestion before you send email feeback to SVC on this issue - as he has pretty much made up his mind. Go back through this whole thread and re-read it. There's a decent possibility your feedback has been submitted and considered already, and you probably don't want to belabor a point that has already been set in stone.

By Steve Cole (Stevecole) on Tuesday, September 04, 2012 - 10:32 am: Edit

Exactly correct. That exact suggestion was made before, seriously considered, and found not to work for many reasons (not the least of which is that one person who pays the fee and posts the SSDs ruins things for every honest person).

Suggesting it again is not really productive. We've been there and discussed that already. Suggesting it again and expecting me to consider it all over is just going to waste a bunch of time reaching the same conclusion. It's not my fault you were not here when that happened, but you're not suggesting anything new. We've been there, We considered that, it failed to work.

ADB has always welcomed feedback and has used/considered more of it than any game company in history. But when you're suggesting an old idea already rejected, you're not accomplishing anything.

By Steve Cole (Stevecole) on Tuesday, September 04, 2012 - 10:37 am: Edit

William: thanks for using my battleship turret image. I love those.

Seriously, if you guys want, I can send you one or two sample images you could use to play with instead of the battleship turret ones that might be distracting to some players.

By Nick G. Blank (Nickgb) on Tuesday, September 04, 2012 - 11:00 am: Edit

That mockup is cool. I think I prefer the Fed Com color scheme (weapons, power, and system categories, etc.) to the stoplight style (green/yellow/red), but I do like the overall health bar along the top, that is useful.

By Gary Carney (Nerroth) on Tuesday, September 04, 2012 - 06:18 pm: Edit

One question about the art used; if the new-gen SFBOL SSDs were to have graphical representations of the ships on them (akin to a Ship Card from Federation Commander), could any of the top-down images from Sandrine's 3D work for the Starline 2500 line be candidates for inclusion?

For example, the FireHawk SSD which William did a mock-up for could perhaps use something like this; and ditto for other ships (like the SparrowHawk in the same image) which have been substantially re-imagined in the 2500 range.

I asked this about use in FC Ship Cards, but they were not suitable there; but if the nature of the new-gen SSDs was different enough, and if they were intended for viewing on-screen rather than in-print, perhaps they might work here.

(In fact, if the images were such that they were only clear on-screen, and didn't work in print, that in and of itself could help encourage them to be only used for SFBOL, as opposed to being used as competition for in-print SSDs/Ship Cards.)

By Marc L. Buckley (Karibus) on Tuesday, September 04, 2012 - 06:53 pm: Edit

Hey All, Seems like an issue that is slowing down the conversions is maching up the ssd boxes with the background image of a given ship. A solutions I would suggest is similar to what web designers do. Measure everthing in pixels to create templates for a given class of ship. Then we could do the following:

1. Divide the ship image into coordinated sectors for front, back and mid body. As well as nacelles.
1. Find the smallest unit of box. (a single box with a heading)
2. Find the min/max padding (whitespace) for a box.
3. Using a list of systems per ship, dole out the system boxes to the appropriate sectors for that class of ship (ie 1st warp box with 15 counter goes to center of nacelle 0. 1st Hvy weapon with 2 counter goes to center/top of nacelle).
4. Even out the spacing at the end or tweak where blank spaces would exist for upgrades.

Once the main program/script was made, the rest would be setting up the new templates per ship class rather than doing each one. What's nice is that the padding rules would keep the boxes from hitting the edge. It may take the use of a graphics program to find the intial center points per area like adobe. Another things would be makeing sure the ship lists were properly delimited. I believe it would save time and be useful when creating new ship ssd's.

My Half a Cent. Doable or not? You decide.

By Matthew Potter (Neonpico) on Tuesday, September 04, 2012 - 08:23 pm: Edit

I'd prefer letting humans at each of the SSDs this time around. Sure it's a little slower, but there's several (well established) SSD Definitions that are missing things (usually refits that came in after the SSD was initially defined. Such as Early-Year refits)

By John Smith (Johnsmith) on Wednesday, September 05, 2012 - 01:10 am: Edit

Re: Sheap's mockup - Wow, I love the health bar! I vastly prefer that to the FCOM color coding. I do agree that it's difficult to read due to contrast. I personally prefer the basic ship outline, but I think this is a better draw for new players. It's more "sexed up", and will be more visually interesting and compete better with video games the younger generation is used to playing. Hopefully, it will help draw new players in.

Re: dropdown menus/popup boxes - As Sheap said, would it not be easier to incorporate them from the start, especially with all the volunteer manpower willing to do work on the 3G SSDs?