There have been times I have seen other players use talents that I thought would work well with a certain build, but I didn't necessarily like the rest of the tree. Other times I find myself wondering where more ranks of something might be. I own every CRB and sourcebook. So I added all the talents to a spreadsheet.

https://docs.google.com/spreadsheets/d/11-b8Dug4K8-AKok2_UdxsNimWd58CAxOgJS9n2JO4bY/edit?usp=sharing

Sheet1 is my initial effort.

I have been experimenting with different formats in Sheet2. Any advice, or feedback is welcome. Feature requests are also welcome. Sheet1 just feels too clumped together. Sheet2 feels harder to read. Note that Sheet2 is not complete, I have about 1/3 of all talents converted to the other format. Requires a lot of copying and pasting.

I've had ideas for indicating which talents are ranked. If I find a layout where each spec listed has its own cell (like Sheet2), I was considering doing some type of color coding to indicate which career they are in, or possibly which book the specialization is found in.

Groovy. Time for some multidimensional analysis. Need to know the cost of each instance and how much it'd take to get straight to it from the top of the tree, too.

Groovy. Time for some multidimensional analysis. Need to know the cost of each instance and how much it'd take to get straight to it from the top of the tree, too.

Oh boy. Could be done.

Thank you!

This is a great start. As it is now, I have to edit OggDude's xml in Notepad++, searching for instances. This is much better.

So, on first glance, one thing that strikes me is that there are Careers and Specializations, and it can be very useful to know both pieces of information if you’re looking for a given talent.

Moreover, the CRBs are not the only source for Specializations — there are new Hired Gun specializations in “Dangerous Covenants”, and your list doesn’t seem to indicate which book and/or page a given Career/Specialization or Talent is found on.

It’s a very good list, but I have found that when lists get this large, you have to make several iterations through the data and how it is organized, before you can start making some real sense of things.

But this is a great start! Thanks!

EDIT: I’m working on a master list of all known species that are potentially available for PCs, based on the official ones from FFG, the ones from the “Unofficial Species Menagerie”, and the ones written up in the “Great Movie Alien Compendium” thread. I’ve got almost 100 entries by now, and I’m nowhere near done. So, I know your pain.

I've done something similar for the career/spec skills, but in MS Access (database program). The data is way more useful and accessible if you create it as a database.

I've done something similar for the career/spec skills, but in MS Access (database program). The data is way more useful and accessible if you create it as a database.

I don't have access to anything like that, nor the knowledge to make use of it. Thanks though.

So, on first glance, one thing that strikes me is that there are Careers and Specializations, and it can be very useful to know both pieces of information if you’re looking for a given talent.

Moreover, the CRBs are not the only source for Specializations — there are new Hired Gun specializations in “Dangerous Covenants”, and your list doesn’t seem to indicate which book and/or page a given Career/Specialization or Talent is found on.

It’s a very good list, but I have found that when lists get this large, you have to make several iterations through the data and how it is organized, before you can start making some real sense of things.

But this is a great start! Thanks!

EDIT: I’m working on a master list of all known species that are potentially available for PCs, based on the official ones from FFG, the ones from the “Unofficial Species Menagerie”, and the ones written up in the “Great Movie Alien Compendium” thread. I’ve got almost 100 entries by now, and I’m nowhere near done. So, I know your pain.

Yeah. I want to make it a bit better in that regard with knowing the source.

Any feedback for the format I am using on Sheet2 of the document?

Any feedback for the format I am using on Sheet2 of the document?

Not yet. I need to spend some more time digesting the formatting and the information.

I've done something similar for the career/spec skills, but in MS Access (database program). The data is way more useful and accessible if you create it as a database.

I don't have access to anything like that, nor the knowledge to make use of it. Thanks though.

There are many SQL database engines that are legally free. NoSQL, MySQL, PostgreSQL, etc... And you can even interface to them via Excel. And knowledge can always be gained.

There are many SQL database engines that are legally free. NoSQL, MySQL, PostgreSQL, etc... And you can even interface to them via Excel. And knowledge can always be gained.

None of those give you an easy web interface to interact with the data once it is in the system.

And you seem to be looking a gift horse in the mouth.

There are many SQL database engines that are legally free. NoSQL, MySQL, PostgreSQL, etc... And you can even interface to them via Excel. And knowledge can always be gained.

None of those give you an easy web interface to interact with the data once it is in the system.

And you seem to be looking a gift horse in the mouth.

No, he Kallabecca was just pointing out there are a bunch of free database programs available. there's no ingratitude in either Kalla's post or mine.

Imy original post stands: a database would be hugely more useful. unfortunately, the currently posted format is a but useless for creating suchba database

IMO, the absence of a good SQL database program is a HUGE failing of GoogleDocs, or whatever they call their pseudo-office collection. I think OfficeLibre MIGHT have an Access clone, though

I use Excel as an import format for databases all the time. I disagree that Excel is a poor substitute. Additionally, with the filtering and sorting options that are now standard in Excel, wrapping the data in an Excel Table allows all kinds of sorting and filtering options. It's how I do low-level analysis before I start building data models.

Awesome work.

Anyway to add the corresponding cost for the those talents?

Awesome work.

Anyway to add the corresponding cost for the those talents?

Yes and no. I currently do not have anything indicating how many times a talent shows up in a specific tree, so putting a cost on there won't work as it stands. I could do something like: Dedication - Slicer (25). Then with a talent found multiple times, something like: Grit - Slicer (5, 10, 15) [note, I made these up as examples]. This would require a format where each specialization listed has its own cell in the spreadsheet, and I'm not sure I've found a format I like for that yet.

Really, the most useful (as in, robust and accessible ) way to record this data would be to have a table with the following data:

• Specialization
• Talent Name
• Position

Position could be coded using two column/fields (one for the column position, one for row position) or one column/field containing a double digit number (or, really, double character) where the first digit/character denotes the row and the second denotes the column. For example, the talents in the upper left hand corner of the Techician/Mechanic tree would be (in CSV format):

First Method

Mechanic, Gearhead, 1, 1

Mechanic, Toughened, 1, 2

Mechanic, Redundant Systems, 2, 1

Mechanic, Solid Repairs, 2, 2

Mechanic, Solid Repairs, 3, 1

Second Method

Mechanic, Gearhead, 11

Mechanic, Toughened, 12

Mechanic, Redundant Systems, 21

Mechanic, Solid Repairs, 22

Mechanic, Solid Repairs, 31

The former method is more 'matrix-y' in notation, the latter is more 'graph-y' in notation. This is the most useful method because it would let the spreadsheet's data management systems (e.g. sort, filter, pivotTables, etc) work most effectively, especially if you separate the notation for columns and rows, as in the first method. However, this method is a total PITA for obvious reasons: it requires a massive amount of data entry.

Some additional notes:

• The data re: costs of the talents can be inferred from the row position, so there's little need to record that information separately.
• Alternatively, you could code either the column, or the row position with letters, instead of numbers if you wanted to separate them.
• OfficeLibre does have an Access clone, so anyone does have access do a semi-robust, visual database program (Supported on Windows, OSX and Linux)
• I'd use the the 'second method' above if you wanted to include the links between the talents. However, if really you want to get into that, I'd recommend picking up a book on graph theory. I can recommend a few that I think should be available for free.

Finally, if you do any work with databases, then you know their limitations in managing any kind of complex data. Excel (and other graphical spreadsheet programs) are great for entering data, and crap for manipulating it if there are any kinds of relationships between fields, as there are in the talent trees. Personally, I don't really think this the appropriate venue to discuss it, unless the OP wants to. I think it's too off-topic and would be hijacking the thread.

Really, the most useful (as in, robust and accessible ) way to record this data would be to have a table with the following data:

• Specialization
• Talent Name
• Position

Position could be coded using two column/fields (one for the column position, one for row position) or one column/field containing a double digit number (or, really, double character) where the first digit/character denotes the row and the second denotes the column. For example, the talents in the upper left hand corner of the Techician/Mechanic tree would be (in CSV format):

First Method

Mechanic, Gearhead, 1, 1

Mechanic, Toughened, 1, 2

Mechanic, Redundant Systems, 2, 1

Mechanic, Solid Repairs, 2, 2

Mechanic, Solid Repairs, 3, 1

Second Method

Mechanic, Gearhead, 11

Mechanic, Toughened, 12

Mechanic, Redundant Systems, 21

Mechanic, Solid Repairs, 22

Mechanic, Solid Repairs, 31

The former method is more 'matrix-y' in notation, the latter is more 'graph-y' in notation. This is the most useful method because it would let the spreadsheet's data management systems (e.g. sort, filter, pivotTables, etc) work most effectively, especially if you separate the notation for columns and rows, as in the first method. However, this method is a total PITA for obvious reasons: it requires a massive amount of data entry.

Some additional notes:

• The data re: costs of the talents can be inferred from the row position, so there's little need to record that information separately.
• Alternatively, you could code either the column, or the row position with letters, instead of numbers if you wanted to separate them.
• OfficeLibre does have an Access clone, so anyone does have access do a semi-robust, visual database program (Supported on Windows, OSX and Linux)
• I'd use the the 'second method' above if you wanted to include the links between the talents. However, if really you want to get into that, I'd recommend picking up a book on graph theory. I can recommend a few that I think should be available for free.

Finally, if you do any work with databases, then you know their limitations in managing any kind of complex data. Excel (and other graphical spreadsheet programs) are great for entering data, and crap for manipulating it if there are any kinds of relationships between fields, as there are in the talent trees. Personally, I don't really think this the appropriate venue to discuss it, unless the OP wants to. I think it's too off-topic and would be hijacking the thread.

This is really outside of the scope of what I am attempting to accomplish.

My goal was to create a resource that told you which talents were in which tree, so that you can then refer to that tree to determine if it is something you want for your character or not. Career and book each specialization is located in are fairly important to that process. Cost and position on tree is secondary, simply because this resource isn't intended to help you find the most efficient way to pick up 10 instances of Toughened or Grit, etc. It will tell you where they are, but you have to decide if it fits your character and is worth the XP investment.

This is really outside of the scope of what I am attempting to accomplish.

My goal was to create a resource that told you which talents were in which tree, so that you can then refer to that tree to determine if it is something you want for your character or not. Career and book each specialization is located in are fairly important to that process. Cost and position on tree is secondary, simply because this resource isn't intended to help you find the most efficient way to pick up 10 instances of Toughened or Grit, etc. It will tell you where they are, but you have to decide if it fits your character and is worth the XP investment.

That's fine. The purpose of my quoted post was not intended to be telling you what to do, but suggesting an alternative method that provides more flexible access to what your stated purpose is. In your current version for sheet 2, you can't use Excel's native data sort and filter. In sheet 1 you can, but you can't go the other direction (view a summary of talents in a spec) without some degree of hassle. Additionally, you can't display how many ranks of a ranked talent occur in a tree.

You state above Sheet1 one is too spread out, but sheet2 is harder to read. You seem to be asking for feedback, so my feedback is that using the same format to both store and display the data is bad idea. The proposition above helps solve that, using one format (suggested above) to store the data, and a separate format (e.g. pivot tables) to display the data.

However, after some thought, I think this might be an effort to replicate something that already exists: This data has almost certainly been transcribed as part of OggDude's Character Generator application. It's probably more efficient to take the tables from this information (with the author's permission and accreditation, of course).

Never mind that last part. I downloaded his character generator and the data is stored in .xml files, not a database format, so you'd have to translate data out of the current format.

This is really outside of the scope of what I am attempting to accomplish.

My goal was to create a resource that told you which talents were in which tree, so that you can then refer to that tree to determine if it is something you want for your character or not. Career and book each specialization is located in are fairly important to that process. Cost and position on tree is secondary, simply because this resource isn't intended to help you find the most efficient way to pick up 10 instances of Toughened or Grit, etc. It will tell you where they are, but you have to decide if it fits your character and is worth the XP investment.

That's fine. The purpose of my quoted post was not intended to be telling you what to do, but suggesting an alternative method that provides more flexible access to what your stated purpose is. In your current version for sheet 2, you can't use Excel's native data sort and filter. In sheet 1 you can, but you can't go the other direction (view a summary of talents in a spec) without some degree of hassle. Additionally, you can't display how many ranks of a ranked talent occur in a tree.

You state above Sheet1 one is too spread out, but sheet2 is harder to read. You seem to be asking for feedback, so my feedback is that using the same format to both store and display the data is bad idea. The proposition above helps solve that, using one format (suggested above) to store the data, and a separate format (e.g. pivot tables) to display the data.

However, after some thought, I think this might be an effort to replicate something that already exists: This data has almost certainly been transcribed as part of OggDude's Character Generator application. It's probably more efficient to take the tables from this information (with the author's permission and accreditation, of course).

Never mind that last part. I downloaded his character generator and the data is stored in .xml files, not a database format, so you'd have to translate data out of the current format.

I do appreciate the feedback, and I see what you are saying. Even if I likely won't switch to a database format, I don't mind thinking through what it would provide.