Archive through September 01, 2012
Star Fleet Universe Discussion Board: Star Fleet Battles: Star Fleet Battles Online:
SFB Online Client:
Ships Submitted:
Archive through September 01, 2012
Will we have them for tournament ships? Wouldn't seem to be a problem since they are free to download on the web site.
I don't see any reason for things to be done two different ways when either way works just fine for your purpose and one works much better for mine.
Steve Cole:
Got thinking about this last night. Based off of the current setup, SFBOL clearly has a record of every box on the SSD. I'm pretty sure that it's got the box type and the arc information available to it as well.
IF you'd be willing to ditch the "shell" positioning (the outline of the ship and putting the FA photons at the front of the forward hull, for example), you could write something that read the SFBOL files and wrote out the new format and be done with in about two days versus two years.
I'd be glad to pitch in the coding effort it.
Mike
I would much rather fork SFBOL into the current version and SSD format for tournament ships plus a new format for games that use SSDs that should be purchased. As I said, I'm highly nostalgic. While I am sure, a few of my online friends would throw tomatoes and pitchforks; and perhaps Paul Franz as well; I would rather see (as a last resort) the non tournament portions disabled completely than be forced to migrate for the benefit of the smaller audience on SFBOL. I know that opinion sounds awfully curmudgeon - but it was the fidelity to the classic SFB style which in large part brought me back.
That is not up to me, but from what I have seen in this topic, everybody wants the artistic format and "ditching the shell" would be something nobody liked and already rejected. It sounds like what they feared I was talking about, even if I wasn't talking about that.
I have fewer problems with underlying graphics to "sex up" the SSD. However, the accomdations to prevent tabletop game play (such as no individual boxes) are stil major alterations to the game experience and aesthetic. If you really want to play a non tournament game; you may be willing to accept that. It is possible that many of the posters are a) terrified that this is an all or nothing offer; and b) too courteous to suggest throwing their non tournament (minority) colleagues under the bus. I am suggesting a third option (Fork) which maximizes the "if it ain't broke don't fix it portion" while addressing the problem child. This also has the advantage that the smaller portion of the customer base (who are the most motivated to do so) can debug the new SSDs and their implementation in the client. If after they are debugged, the new SSDs are acclaimed by all as the superior experience; the tournament game could migrate.
Box level tracking is important, but it does not have to be in the form of boxes.
Hasty repairs and guards are rules used in every tournament game. So the new system needs a way of dealing with it. that does not mean we need a 1:1 on boxes; but it does mean that Paul needs to have a system to deal with tracking boxes that are not specifically listed on the SSD.
I recognize that is a challenge, but it is not one that should be insurmountable.
I said earlier that I saw no reason for two kinds of SSDs, second-gen for tournaments and third-gen for everything else. I still think so, but I'm ok with converting the tournament ships last and reviewing the matter when we reach that point, assuming that ends this sturm and drang over this.
Converting tournament ships last and reviewing the matter at the point prior to switchover ends any sturm and drang from me.
OK, practical, pragmatic, honest question time:
I bought C3A (Andromedan Threat File) and E3 (Borak) at my FLGS. The store keeps a good stock of ADB products "on the shelf" and I support their doing so by buying product there.
Being several months or a year ago, I did not save the game store receipt as I had no expectation of a reason to do so.
Will I be able to eventually use my purchased product online on SFBOL? Or must I buy the product twice to do so?
If I must buy product "only from ADB" to use on SFBOL, I will no longer purchase any of them from my local retailer.
On a related note, I bought C3A from e23. Is it possible to confirm that someone bought an electronic version of a product from e23, or does it have to be through the ADB cart?
In the chat SVC said there might be a one time exception made for honest players that have purchased the products in stores. Because older products are grandfathered in, the Borak and C3A are the only products affected (that I know of). Going forward, you have to buy direct from ADB.
I'm also doing a mockup of an SSD enhancement that hopefully SVC will approve of, that provides no avenue for piracy or freeloading, and that doesn't break game rules that expect individual systems to be tracked. To avoid causing preconceptions and allow the debate to cool, I'm just going to show it when it's done, probably on Monday. Hopefully everyone will like it.
Dale, Terry, we would handle cases such as yours individually, by email. I bet there is a screen shot you could take with your user name and your library on e23 -- maybe that could be explored?
One thought on the question of using "countdown" boxes on the gen3 SSDs: ithe one place I can see this creating a problem is with drone racks. Consider a C7: it really doesnt matter if you have individual boxes for the 4 FX p-1. Fired phasers are destroyed befoe unfired ones and ahasty repair could simply cause an FX p-3 to appeaer while decreasing the destroyed p-1 count by one. Each of the four drone racks, however, might have a completely different loadout, meaning that which specific rack is destroyed may have significant tactical implications.
Jason, countdown boxes will work fine for drone racks. When taking damage, you will still be prompted for which drone rack to destroy. The countdown will just show how many racks you have left. Rack stores would still be available in the Expendables window.
The only tricky part about countdown boxes is the "Edit Ship" function, which currently allows each box to be independently set to one of three states: "undamaged", "damaged" and "repaired". To fix this, it would be better to have an actual damage repair popup instead, which allows you to select the repair type (CDR, EDR, "fix mistaken damage"), the type of box to repair, and the individual box (if it matters). Having a new repair popup would also allow the client to track CDR repairs, which is something it doesn't do now.
Ok. Here are a few things about the SSD 3.0 (or whatever we want to call it).
Sample D7 Conversion Ship Definition
1) There will always be a need to keep some boxes separate due to:
a) H&R/Guard rules.
b) Boom/Saucer separation rules.
2) To do a colorized version will mean that the ships will need to be larger than the example that Steve Cole showed, due to #1.
3) The weapons for the most part will need to be separate due to charging rules and the need to keep this simple.
4) The colorized version (i.e. like Fed Com) take up 4x the space therefore 4x to download.
5) I think if we can get people to volunteer to convert the Original Ship to the New Ship Format we can get it done faster than waiting on Steve Cole and Co. creating new colorized versions.
6) Making the summary boxes colored like the Fed Com ship cards does not help and it hurts people that are color blind. and personally I don't like them. (Seeing a cornucopia of colors on a ship definition is annoying to me, but maybe I am just old)
Paul Franz
P.S. I am surprised that the whole discussion has not been moved to a separate thread but I think it is a little late now to move it.
IMO an elegant, practical, and workable solution - nice job Paul.
Im happy to volunteer my time doing conversions.
Paul, I really like the new sample. I don't personally have a problem with eliminating the boxes and going to numerals. Frankly, I even like it better than the boxes in some ways.
One thought: Is there any way the current status of each section can be displayed as a fraction of the total? "22/22" for a full shield, for example; "18/22" after a 4-point hit, etc. In the absence of the graphically marked off boxes, I think it would help keep in mind just how much you've lost.
I've done older style defs before this wouldn't be that hard (pretty easy IMO) But there is still the minor problem of box trcking for partial repairs etc etc.
If I hasty repair a LWarp as AWR it needs a slash at the number or something similar. Maybe a hard number showiung the MAX # of boxes as well.
Don't have a clue how easy this would be to code but its an idea.
My Klink took 3 LWarp hits I've now hastily repaired one of them. Hard is BOLD.
LWarp
15/12/1
I will volunteer to help with the conversion project.
BTW: Is will it be possible to use the existing counters with the new defs? That would speed things along.
How will the volunteers get the ship line drawings, is it possible to get them from the 2.0 definitions ourselves or will you be sending the volunteers the ship outlines.
I know on Talk Shoe you said it would be easy for you to write a program that would extract the image part of the SSD from all the definitions quickly.
A cheat sheet with a common set of generic boxes and system lables all in the same font would really speed things up for us.
Please dont change the tournament SSD's.
Gregg
Gregg that a dead horse they will be last but SVC wants SFBOL defs fixed the same way.
Paul's prototype is good in my book, since the most critical systems (weapons) are kept as separate boxes. I did not think this would meet the standards set by SVC. My proposal would be slightly different and would also allow weapon boxes to be combined. However, I am fine with this general SSD layout. There are only a couple of nits:
* I bet I could win the Platinum Hat in the 60-warp Klingon. 
* Instead of just "#1" etc it would be better as "Shield #1"
* As has been mentioned, displaying a damaged warp engine as for example 8/15 would be better so you can tell how much damage you have. 8/15/1 for a hastily repaired warp engine would be fine with me. Engines are pretty much the main non-weapon system to receive hasty repairs.
* Dam con needs a whole track because otherwise EDR does not work. Sensor and scanner would be better with a whole track (so you can tell if they've been damaged and, if they should happen to be damaged, how badly it will hurt you). Excess damage does not need a track.
* It's OK with me if shuttle boxes are combined so long as the actual shuttle state in the expendables is preserved.
* I have no problem doing H&R/guards the old fashioned way.
* Something will have to happen for PA panels since each PA panel box contains a lot of information.
* Systems that are not adjacent but it doesn't matter that they aren't adjacent should be combined into one box (i.e. the impulse, tractors and transporters). Even for ship separation, it doesn't actually matter (other than sensor/scanner) because if a ship separates, and they rarely do, you need to add another counter/SSD anyway and in that case you will end up editing the SSDs anyway.
I would color code boxes by damage, rather than by type of box. Yellow for some damage, red for all systems destroyed, uncolored for undamaged.
1. As I have have said before, i am happy to volunteer.
2. I do not like this version. reasons and discussion to follow.
3. I think the color version with the nice Fed Com style graphic is, by far, the best looking. That is the one that makes me excited to get the tournament ships done even. B&W with Fed Com is also nice. This version is the one that makes me hope the project takes forever so, with tournament ships being done last, I never have to actually use them. I'll help no matter what, but this version will be a big disappointment with it's only benefit being that it makes Steve happy, but makes the client inferior to what it is now.
4. I think making this version and then going back and doing them in color with a nice graphic is a waste of time. Why not just start with the end goal?
5. What is the rationale for all the clutter boxes? For example, instead of one Impulse box with "4" in it, you have 2 Impulse boxes each with "2". You have three separate transporter boxes. three separate tractor boxes (H&R might be the reason for that), two separate battery boxes and two separate security boxes. There is also the matter of the boom impulse, but that one probably needs to be tracked separately, annoying that it is, since it is an APR box that is hit on impulse. I suppose one could lump it in with the other 4 impulse and let the players deal with whether they want it to be destroyed last or second to last.
6. If ANY of the reason for #5 is boom separation I highly recommend that that should just be something the client chooses not to handle for the players. It is a very, very rarely used rule and even when used it rarely has any real consequence on the game. (Frankly, Steve can consider this a petition to eliminate it from the rules ). It is really a "for color" rule rather than an actually functionally useful rule.
6. How are you dealing with "hasty repairs"? This is an essential rule to deal with, at least for tournament play.
More questions to follow after seeing responses.
