Frank,
Overall it looks good. There are issues:

1) The K-Refit Phaser boxes do not line up with the boxes that they replace. (They need to otherwise the refit will not work)

2) When it comes to the Y175 refit the DRN-B box does not line up to the DRN-A box.

Other than that it looks great.

Randy,
Are you sure :

1) You have updated to the latest version of the client. (It is a requirement because alot of the necessary features are not in previous versions of the client)

2) You are using the "SFB Graphical New SSD Definition Tool"

I don't see where I see to click on the boxes. I say "Click to position the boxes." (You will be prompted to position the boxes when you "Import Old Ship Definition". I say "Adjust the position of the boxes. Use the 'Edit\Move' and 'Edit\Align' to move the boxes around."

If you already have boxes on the screen. and you click on a box and it pops up with the dialog box, it is because you have not switched mode which is Step #13. "Select Menu Item 'Tool\Selection Mode'"

By Randy Blair (Randyblair) on Sunday, November 11, 2012 - 09:58 pm: Edit

Hmmmm...not sure if I have or not. Where do I download it from? (That should be telling in and of itself.)

By Shawn Hantke (Shantke) on Sunday, November 11, 2012 - 10:31 pm: Edit

Open up the client, go to help, and then update client.

By Paul Franz (Andromedan) on Sunday, November 11, 2012 - 11:05 pm: Edit

An updated version of the client will be released tomorrow. With some additional support for working on the next gen SSDs.


1) Change the "Show Both Base and Refits" to effect selection.
2) Add Align All. This can be used with #1 to align base and refits to match.
3) Add "In Sync" option that will keep the boxes that are in the same position in different refits to move at the same time.

By Xander Fulton (Dderidex) on Monday, November 12, 2012 - 01:08 pm: Edit

Question on this...I know a big focus of the update is on getting existing SSDs into the game, but this new third-generation layout offers some MASSIVE improvement possibilities for X-refits. (For example - 1 'APR' replaced with 2 'XPR'...very super easy to do, now, as it just involves incrementing a number and nothing else)

The only thing this capability would really require to work would be the ability for a player, before a match, to be able to 'edit' (temporarily) any SSD for use in the match. Change the system type of some boxes (Phaser-1 to Phaser-1X), change the number of boxes in a system (APRs replaced with two XPRs each), etc. Then have a way for both players to sign-off on the ship to 'commit' the change for the match (no more changes allowed, then) and use it in play.

With the old system, this was mostly impossible as SSD modifications - especially anything changing number of boxes - were rather ridiculously complex. Now that it's extra-super-easy to do so...

By Paul Franz (Andromedan) on Monday, November 12, 2012 - 02:15 pm: Edit

Xander,
My only question about partial refits that I have is: how often are they used?

By Xander Fulton (Dderidex) on Monday, November 12, 2012 - 02:32 pm: Edit

More often that the pure X-ships, in my experience.

By Francois Lemay (Princeton) on Monday, November 12, 2012 - 10:08 pm: Edit

Thanks Paul.
I was unaware of the lining up thing.

Does seem you now have an auto adjust for lining these things up ?

Cheers
Frank

By Paul Franz (Andromedan) on Tuesday, November 13, 2012 - 06:14 pm: Edit

Frank,
Yup. It will be released tonight.

By Francois Lemay (Princeton) on Sunday, December 02, 2012 - 04:51 pm: Edit

Just did the D5 Crusiser and D5A.

Sent to Paul for quality control before proceeding further.

Still not sure how to implement the refits ?


Cheers
Frank

By Paul Franz (Andromedan) on Monday, December 03, 2012 - 06:04 am: Edit

Frank,
I will review your ships today.

When it comes refits, they are automatically imported and when you are importing old ship definitions. If you notice the window the denotes what type of box you are placing and the refit for that the box. After you import the old ship definition then you should select each refit in the "Refit List" windows and make sure that they look good.

When it comes to variants, you should use the "File\Apply Variant Ship Definition", that will keep the boxes the same across the ships. To use it, load up the Next Gen Ship Definition for the Base ship (e.g. D5, D7), then click on the menu item. Select the Old Ship Definition for the Base ship. Click Open. Select the Old Ship Definition for the variant. (e.g. D5A, D5G, D7A, D7C) You will then be prompted for placing any boxes that do not match the base boxes.

By Matthew Potter (Neonpico) on Monday, December 03, 2012 - 12:46 pm: Edit

So variants are going to be part of the base hull definition? (So there won't be a seperate D5A definition, just a D5 file with a checkbox for the D5A "refit"). That's kinda shiny.

.... or are you saying that you're importing both defs (the base ship and the variant) so that the variant's boxes all show up at the same spots (and then the base-ship boxes that shouldn't be there are somehow deleted later).

By Paul Franz (Andromedan) on Monday, December 03, 2012 - 10:16 pm: Edit

No. Variants will not be part of the base hull definition.

The idea is that you take the base hull definition and apply the variant to it. Then save it as the variant.

I am saying that you apply the variant to the base hull NextGen definition. This will keep as many boxes as possible in the same exact location increasing the consistency between the different variants of a ship.

By Eric Smith (Badsyntax) on Wednesday, December 19, 2012 - 10:59 am: Edit

First, I've seen the ship definition files, and could easily write a script to go through thousands of them, find center points for systems, and put numbers there instead of drawing boxes. If it helps.

Second, if this system is going to be used, why not just make standard locations for all the systems, and not need to make special SSDs at all?

For example, there could be a control area with flag/bridge/aux/emer/scty, a power area with warp/btty/apr/awr, a systems area with trac/trans/lab/prb/specsens, a hull area with hull/cargo/bks/fab/works/repair, and so forth.

The ship graphic could still be in the background, just take the smallest ship hull and make all the stuff fit in it.

This way ships can be defined purely with a # and count of systems. Perhaps sections could be specified (like boom/saucer or main hull) as well, and it could always be assumed the boom/saucer take damage last.

Essentially, this would allow the ability to convert thousands of ships in seconds, and adding new ships, well, *super* easy and can be done with notepad.

As it seems the "SSDs" will no longer look like the ships they represent, there really isn't a point in trying to keep the system in the same location.

For that matter, why use an SSD style system at all?? Why not just use bar graphs grouped like I mentioned above, and perhaps just an area for the weapons with arcs drawn art in small pie charts.

Another option is to build templates for hulls. A Fed CA has a single template that can be used by the CAD, CVD, CVS, etc, etc. Then you just place item A in slot B. This is kinda what the old Starfleet Command computer game did, and it worked out pretty well.

It just seems there are much better ways to present data to the users than just replacing a bunch of boxes with a dropdown. A hideous interface won't exactly be attracting new paying customers, and will actually turn off some that would pay if it wasn't so, well, ugly.

By Paul Franz (Andromedan) on Thursday, December 20, 2012 - 06:28 am: Edit

Eric,
So, if I understand you correctly, you are suggested that we either:

1) Put the boxes in specific locations and don't worry about the underlying graphic.

2) Just use the numbers with possibly slider bars to show how many of each box exists

If so,

1) This would be pretty ugly and I don't think people will like it.
2) We had this at one time, as it is, it is still an option in the code.

BTW, the option to "build templates for hulls" this is kinda of what happens now except that you create a base ship definition and then you apply the variants (i.e. Fed CA gets converted to the new SSD format and then using uses the CVD ship definition creates the new SSD format).. What I am thinking you are talking about when it comes to this is a little different but I don't think just having the variants definitions (i.e. what has been deleted and/or added) really works.

By Eric Smith (Badsyntax) on Thursday, December 20, 2012 - 11:44 am: Edit

Sure wish I could create what I can imagine!

Let me *try* to explain what I was talking about a bit more:

Ship silouhette. Lets use a Fed NCL as an example. There is a single hardpoint where FH phasers go, 1 on each side where the side phasers go, and perhaps 2 at the front where things like photons or drones would go. Then there are a couple in the rear sides for Ph3s. Those are your weapon hardpoints, and EVERY NCL chassis uses those hardpoint locations. The NCL hull is defined in a single file. For each variant, the contents of those hardpoints are specified, and a new ship doesn't need "designed". So a NCL has 2 Ph1 each in HP1-3, and 4 Photons in HP4. A CAD would have 4 Drones in HP4, and a NSC would have special sensors. Anyway, these hardpoints are shown over a drawing/silouhette of the ship, and there is plenty of room to show decent sized pie graphs to visually show the actual arcs. Each of these hardpoints would be a grouping of weapons, and could have 1 to 6 weapons within them.

Then, underneath your ship that shows all the weapons, you have a small area where it shows things like power, science, systems, etc. Power would have each warp engine, APRs, batteries, again in groups as they appear on the SSDs, just with a number there instead. Science would have the probe/labs, command the flag/bridge/aux/emer/scty, and so on.

Since you just define the weapon hardpoints of the hull in a single place, it is super easy to add new variants, and anybody can do it in notepad. This makes all the hulls feel about the same, requires only a very small amount of work, and its far easier to store and access the data.


I have tried on more than a few times to create a database structure for SFB ships. I came to a few conclusions:
#1. Each possible variant needs its own detail, there is no way to track refit changes efficiently. However, the refits are still tied back to the base model or dependency refits.
#2. Most of the systems are pretty consistent. So tracking things like "F_HULL=8" or "F_HULL=4,4,2" is far easier than tracking all the unique systems. Basically everything but weapons is easier to track that way, as all of those systems have no values other than the number of boxes in a group, and the type.
#3. Weapons need tracked separately, with values like #, Type, Arc, arc without warp, reloads, special abilities, etc. There are a lot of various special rules out there for weapon mounts.
#4. I have tried to use boarding diagrams for advanced boarding party combat, and it appears it just isn't supported anymore. I kept coming across ships with no data, so I'm guessing that rule is just, well, no longer usable. This sucks IMO, as its really required in some situations. I do think that small dotted lines between sections would have been SOOOOOO much easier to deal with, and I actually draw them on my SSDs to see where the sections are and what they connect to.

I think I actually have every single federation ship entered into excel, with all of the necessary data, but haven't gotten any further.

I've actually tinkered with making a real time conversion a few times, and could code it, but without advanced boarding party combat, graphics, support, and permission, I just never went very far with it.

By Steve Cole (Stevecole) on Sunday, June 16, 2013 - 12:51 am: Edit

Where are we on this? How many have been done? How many old ones remain?

Nine months ago there were 3,500 ships to convert with a quota of at least 100 per month. Somebody needs to tell me how many we're actually done and it should be 900+.

If you needed ship graphics from me nobody asked for them.

We need to set up a schedule to delete 200-300 of the old ones every month and add new ones as fast as you can. This is now on ADB's radar and progress WILL be made.

By Eric Smith (Badsyntax) on Sunday, June 16, 2013 - 12:50 pm: Edit

was a decision ever made on exactly how they were to look after?

By Paul Franz (Andromedan) on Wednesday, July 31, 2013 - 09:21 pm: Edit

Eric,
Yes. It looks like this Klingon F5C.

By Paul Franz (Andromedan) on Wednesday, July 31, 2013 - 09:23 pm: Edit

Current Status:

Klingon D7 - Kenneth Jones (Waiting on converted defs)
Klingon D6 - Paul Scott (Waiting on converted defs)
Klingon D5 - Frank Lemaay (Have 1, waiting on the rest of the converted defs)
Klingon F5 - Joshua Driscol (Received)
Klingon C8 - Randy Blair(Waiting on converted defs)

By Steve Cole (Stevecole) on Wednesday, July 31, 2013 - 10:23 pm: Edit

Go team!

By Paul Scott (The_Rock) on Wednesday, July 31, 2013 - 10:29 pm: Edit

I suck! So sorry Paul. I will get on it soon. I really really promise. Mine will all be done by the end of August.

By Randy Blair (Randyblair) on Wednesday, July 31, 2013 - 11:01 pm: Edit

I suck, too.
Same time frame as Mr. Scott.
(But I will admit I have no idea what I'm doing.)

By Kenneth Jones (Kludge) on Sunday, August 04, 2013 - 12:54 pm: Edit

Paul I've spent a fair bit of time trying to log in under Demo mode.

This is what I've been getting.

You haven't established a connection yet
Couldn't establish connection to fa.f7.1243.static.theplanet.com on port6,668.

I was trying to update the client and was going to do at least a couple of the D7 defs this coming week. (The few I had finished were lost when i had to replace my HD and apparently they didnt get backed up.)

March was the last time I updated and according to my security programs the Client is still approved even though every time I fire it up I have to agree. But its been that way for a couple years.

By Josh Driscol (Gfb) on Sunday, August 04, 2013 - 02:50 pm: Edit

There has been a more recent update to the client and a change in server.