That's hilarious Oggy

Oggy,

Great work as always.

I do have one question though. How difficult would it be to allow a particular type of enemy to be added multiple times in an encounter?

As an example, in the Beginner's Box game, at one point we ran into 3 groups of Stormtroopers, with each minion group having 3 members.

I can work around it by exporting the enemy type in question and importing it back in to create another instance, but that's rather clunky.

Oggy,

Great work as always.

I do have one question though. How difficult would it be to allow a particular type of enemy to be added multiple times in an encounter?

As an example, in the Beginner's Box game, at one point we ran into 3 groups of Stormtroopers, with each minion group having 3 members.

I can work around it by exporting the enemy type in question and importing it back in to create another instance, but that's rather clunky.

You probably still have 1.0.0.7. 1.0.0.8 should have fixed that problem.

Just want to say thank you for putting soooo much time and detail into this. I do love this app and look forward to more updates!

Is this working right with Minions in the encounter generator? It has 4 Minions having a starting skill rank of 4. Shouldn't this be starting at 3?

Is this working right with Minions in the encounter generator? It has 4 Minions having a starting skill rank of 4. Shouldn't this be starting at 3?

A minion group

counts the number of additional minions after the

first as the number of ranks in any of its listed skills

(so a group of four minions making a Ranged [Light]

check would count as having three ranks in Ranged

[Light]).

Yeah, that's a bug. Just fixed it. I had already fixed the wording of the text, but I forgot to actually fix the calculation. Next release

Which should be soon, by the way. Just finishing up on the vehicle sheets and that should be the last thing I have to do. It should definitely be out by Friday.

The next release of the software is now available using the standard link. This one adds vehicles and starships to the character generator! I know a lot of you have been looking forward to this. Hope you all like it.

• Added Attribute Bonuses to the specialization editor. You can have a specialization give bonuses to any attribute. To make a specialization "force-aware", just add 1 to Force Rating.
• Added scrolling to the panel-based forms so that you can reach all controls that might become hidden due to low resolution. This has been done for the main character generator window, the GM Tools window, and the edit adversary window.
• Starting skill rank of minion groups in the encounter sheet was incorrect. This has been fixed.
• The biggy for this release, the character editor now let's you purchase and upgrade vehicles, including starships. You can purchase as many as you can afford, add attachments and upgrade weapons, name it, add some brief notes for it, and print up a vehicle sheet (full-color and simplified, just like the other printed sheets). All vehicles, attachments, and weapons from the CRB are included.
• Added a vehicle summary on page 4 of the character sheet.

A big THANK YOU goes out to David and Declan for their generous donations. I really appreciate it!

I say this every time, but thanks for this! Vehicle purchases and upgrades are awesome!

One more file change I forgot to mention. In ItemDescriptors.xml, I added a talent descriptor for TRUEAIM. If you're copying descriptors by hand, be sure to include that one. It's at the end of the talent descriptor section.

omg!!! cant wait to get home from work now lol!!! You are awesome Ogg!

YES! VEHICLES! Thank you Oggy!

Oggy,

I'm here to ask for a couple more features again

Can we get modifications to the data files saved in their own file? This way each time there is an upgrade to the data, it won't be overwritten...

Perhaps something such as "Armor-custom.xml", if the custom file exists, load the data from that file, after loading the base data file. You would load data in 2 passes effectively.

I had changed the data for all talents in the data file and noticed, with the upgrade, it indeed set them all back

On the adversary sheet, is there a way you could perhaps make a more compact sheet? Perhaps 4 to a page?

Already found some bugs (and made an enhancement). These will be fixed in the next release:

• When adding the Reinforced Shield Generator attachment, the firing arc wasn't being saved with the character. This has been fixed.
• When selecting the Reinforced Shield Generator attachment, the choose arc dialog would always show all four arcs, even if the ship's silhouette was less than 5. This has been fixed.
• When any attachment is now active and has a choice option for a mod (currently, only the defense shield mod has such an option), a "Choose" button will now appear at the top right. Clicking this will run down all choices for an attachment. For instance, if you have the shield attachment with one base defense shield mod and have also selected one additional shield mod, clicking "Choose" will bring up the dialog twice, once for each mod.
• The generator was needlessly saving vehicle attributes with the character. As this is calculated by the generator based on other data, it is not required to be saved. It no longer is.

Oggy,

I'm here to ask for a couple more features again

Can we get modifications to the data files saved in their own file? This way each time there is an upgrade to the data, it won't be overwritten...

Perhaps something such as "Armor-custom.xml", if the custom file exists, load the data from that file, after loading the base data file. You would load data in 2 passes effectively.

I had changed the data for all talents in the data file and noticed, with the upgrade, it indeed set them all back

On the adversary sheet, is there a way you could perhaps make a more compact sheet? Perhaps 4 to a page?

Excellent idea. I've been trying to figure out an easy way to do merging, and I think you're on to something. What I could do is to consider all data that comes with the product as unchangeable base data and never actually modify it. All additions and changes would go into separate files in a separate directory structure. Then, both would be loaded and a simple add-or-replace merge would be performed. The only downside is that incorrect base data that is changed (such as a bad price for an item) wouldn't be updated if a custom change had already been made to that item. Not a biggie, I guess.

I'll have to think about this one

Oh, and what did you have in mind for the adversary sheet? A separate stat block sheet? If I remove wound/strain tracking, it would cease to be an encounter tracker Maybe I could add a print option to the stat block dialog if you just want stat blocks.

You can actually do this by hand now, really. Just open MS Word or Publisher or whatever you use as a word processor, and run the GM Tools. Click on an adversary, click "Stat Block", customize it however you want it to look, and click "Copy". Then, go back to your document and paste the image and resize it to your liking. Keep doing this and arrange however many you want or will fit onto a page.

This was kind of the purpose of the stat block generator. I figured GM's would want a simple way to add adversaries to their own documents, such as custom adventures.

Excellent idea. I've been trying to figure out an easy way to do merging, and I think you're on to something. What I could do is to consider all data that comes with the product as unchangeable base data and never actually modify it. All additions and changes would go into separate files in a separate directory structure. Then, both would be loaded and a simple add-or-replace merge would be performed. The only downside is that incorrect base data that is changed (such as a bad price for an item) wouldn't be updated if a custom change had already been made to that item. Not a biggie, I guess.

Oggy, I think this sounds promising! In fact, you might even be able to compile all user modifications into one file (or possibly directory would be better, MyData), or something like that. That we we can group our homebrew content (or say Age of Rebellion content) all in one file/directory, and just have the definitions for the things you have modified in that file/directory.

However, I forsee one problem. If you flag everything that you have defined as unchangeable, then descriptions wouldn't be changed, and it kind of defeats the purpose of modifying the files. I think if you just load your baseline data first at templates, then you can flag anything in the MyData files to overwrite anything different from the templates.

Yeah, I'm also interested in there being a way to upload a new version without invalidating the customized stuff I've created. Though it looks like specializations at least are saved in their own files, the big concern for me is talents and equipment, particularly as I've taken the time to add in newer talents from my Ways of the Force file and some of the AoRBeta material.

On the topic of equipment, one of the things I added were the "stun blaster" equivalents that the core rulebook says are available. Mechanically, they have the Stun Damage quality and cost half as much, so it'd be easier to add them in, perhaps as "Blaster Pistol, Stun" for the weapon name and then at half the credit cost of the standard version.

Also, not sure if this was corrected in the latest update, but the last version had the vibroknife listed at 750 credits instead of the 250 credits it's listed as costing.

So is there an easy way to update without losing my custom equipment items? How can I use the new equipment data file and keep my items (not a programmer)? Thanks

So is there an easy way to update without losing my custom equipment items? How can I use the new equipment data file and keep my items (not a programmer)? Thanks

Yeah, wait for the next release I thought about Valdier's idea and it was very sound. So, I spent the last part of today implementing it. Here's how it'll work:

The app will come with the "Data" directory. This directory will contain all the main data for the program.

When you change a description, or add or modify an item, you'll see a "DataCustom" directory. This directory will be a mirror of "Data" with the same structure, etc., but will contain only changes that you've made to the data. So, for instance, you change the description for the "Grit" talent. When you save the change, you'll see "Talents.xml" created in the "DataCustom" directory. This "Talents.xml" will contain just the "Grit" talent, assuming that's the only one you changed.

Similarly, if you add a species, or career, or something that exists in its own file, you'll see that file appear in "DataCustom". For instance, say you add the "Fuzzy Bunny of Death" species. When saved, you'll see "Fuzzy Bunny of Death.xml" inside the "DataCustom\Species" directory. If you change the description of an existing career, as another example, that career file will appear in the "DataCustom\Career" directory.

When data is loaded, it will load all of the main data first, then look in "DataCustom" and load that data separately. It'll then merge the data by adding custom data to main data, or by replacing main data with custom data that exists in both places.

For those who have already spent hours adding their own descriptions and the like, don't worry. There's going to be a "Convert" button in the data editor that will take you to the convert dialog. While there, you can do a two-step conversion. The first will copy all USERxxx items that you've added to the main data files over to the custom area, then remove them from the main files. For the second step, you'll be able to go through all data tables and look at all descriptions. Any that you've changed and want to keep, you can just check them (there will be select/unselect all buttons as well). When you're done checking them, click the button and they'll all be transferred over to your custom directory. After doing this, you can safely replace your data with data from any future release, and all your changes will be safe.

Again, the only issue with this is that existing data that I change in the main data files will not be seen by the program if you've also made some modification to it. For instance, if I change the price of "Backpack" in "Gear.xml", and you've already entered in an elaborate description of futuristic Star Wars duraplast micro-molecular backpacks that come in five festive colors, you won't see the price change because you're using your own copy of the item.

Anyway, I'll try to get this out tomorrow. In the mean time, please send me as many bug reports as you can on the last release so I can fix them I've only found two or three minor issues with my vehicles release, and I know there's a lot more waiting to be found!

Excellent idea. I've been trying to figure out an easy way to do merging, and I think you're on to something. What I could do is to consider all data that comes with the product as unchangeable base data and never actually modify it. All additions and changes would go into separate files in a separate directory structure. Then, both would be loaded and a simple add-or-replace merge would be performed. The only downside is that incorrect base data that is changed (such as a bad price for an item) wouldn't be updated if a custom change had already been made to that item. Not a biggie, I guess.

Oggy, I think this sounds promising! In fact, you might even be able to compile all user modifications into one file (or possibly directory would be better, MyData), or something like that. That we we can group our homebrew content (or say Age of Rebellion content) all in one file/directory, and just have the definitions for the things you have modified in that file/directory.

However, I forsee one problem. If you flag everything that you have defined as unchangeable, then descriptions wouldn't be changed, and it kind of defeats the purpose of modifying the files. I think if you just load your baseline data first at templates, then you can flag anything in the MyData files to overwrite anything different from the templates.

What I meant was that main data files would never be modified or touched. Any changes made, including changes to existing data, would be saved to your custom area (which will be called "DataCustom") and merged over the main data. If this custom data is deleted, it'll revert back to the original main data.

As an example, say you edit the damage done by a Vibro-sword (+2 is too wussy for you, you think it should be +5). That item will be stored in DataCustom\Weapons.xml. Before, if you clicked on Vibro-sword in the list, you'd be able to Modify it, but not Remove it. Now when you click on it, Remove will be available. If you click on Remove, when the list refreshes, Vibro-sword will still be there, but the damage will revert to what's in the stock data files.

Did that make sense?

Will this also include ability to customize/edit attributes on vehicles? (I gave my group a used ship that doesnt use stock stats).

And can you detach vehicles from characters so we can maintain a vehicle that doesnt necessarily belong to an individual player. Customized vehicles are really their own character in game!

Best GM tool ever! Keep it up!

Excellent idea. I've been trying to figure out an easy way to do merging, and I think you're on to something. What I could do is to consider all data that comes with the product as unchangeable base data and never actually modify it. All additions and changes would go into separate files in a separate directory structure. Then, both would be loaded and a simple add-or-replace merge would be performed. The only downside is that incorrect base data that is changed (such as a bad price for an item) wouldn't be updated if a custom change had already been made to that item. Not a biggie, I guess.

Oggy, I think this sounds promising! In fact, you might even be able to compile all user modifications into one file (or possibly directory would be better, MyData), or something like that. That we we can group our homebrew content (or say Age of Rebellion content) all in one file/directory, and just have the definitions for the things you have modified in that file/directory.

However, I forsee one problem. If you flag everything that you have defined as unchangeable, then descriptions wouldn't be changed, and it kind of defeats the purpose of modifying the files. I think if you just load your baseline data first at templates, then you can flag anything in the MyData files to overwrite anything different from the templates.

What I meant was that main data files would never be modified or touched. Any changes made, including changes to existing data, would be saved to your custom area (which will be called "DataCustom") and merged over the main data. If this custom data is deleted, it'll revert back to the original main data.

As an example, say you edit the damage done by a Vibro-sword (+2 is too wussy for you, you think it should be +5). That item will be stored in DataCustom\Weapons.xml. Before, if you clicked on Vibro-sword in the list, you'd be able to Modify it, but not Remove it. Now when you click on it, Remove will be available. If you click on Remove, when the list refreshes, Vibro-sword will still be there, but the damage will revert to what's in the stock data files.

Did that make sense?

Oggy,

i like the idea of immutabke base data. However, for the MyData implementation, I think it would be easier to do items and stuff by giving them a subtype. For example, I make a new blaster pistol. Now I want to add an attachment. Turns out I can't because there are no attachments allowed for USER0001. If you allow items or other data types to inherit the attributes of their parents, then all you would need to save in the custom file are the custom data changes. Everything else would be inherited from the parent. That way any changes or bug fixes to main item would be preserved, and you wouldn't run into compatibility issues with attachments and other mechanics that depend on certain type requirements. Does this make sense?

Will this also include ability to customize/edit attributes on vehicles? (I gave my group a used ship that doesnt use stock stats).

And can you detach vehicles from characters so we can maintain a vehicle that doesnt necessarily belong to an individual player. Customized vehicles are really their own character in game!

Best GM tool ever! Keep it up!

I don't think I'll get to a vehicle editor in the next release. I still have a number of editors to go, vehicles being one.

In an upcoming release, I'll be including the group concept. When you setup a group, you'll give it a name, include any saved characters as members, setup group obligation and give the group money, equipment, and vehicles. Members of groups will be able to contribute money, equipment, and vehicles to the group's pool, so if a character already has a vehicle, you'll be able to add him to a group, then have him donate the vehicle to the group. The vehicle will become detached from the character and attached to the group. And, of course, you'll be able to print up group sheets for the GM.

Oggy,

i like the idea of immutabke base data. However, for the MyData implementation, I think it would be easier to do items and stuff by giving them a subtype. For example, I make a new blaster pistol. Now I want to add an attachment. Turns out I can't because there are no attachments allowed for USER0001. If you allow items or other data types to inherit the attributes of their parents, then all you would need to save in the custom file are the custom data changes. Everything else would be inherited from the parent. That way any changes or bug fixes to main item would be preserved, and you wouldn't run into compatibility issues with attachments and other mechanics that depend on certain type requirements. Does this make sense?

The attachment issue can be fixed by me adding an attachment editor Which items can use which attachments is rather arbitrary in the book (only carbines, only rifles, only ranged weapons, armor that can be sealed, only Brawl weapons, etc), which is why I just specify which items can use which ones in a list.

Inheritance is an interesting idea, but would probably over-complicate things. For the first release of this, entire objects will be replaced. In future releases, I'll see about having property-level merging, but I'll have to think about how to do it with my current data structures.

Oggy my main concern is the Skill descriptions I have hand written in from the CRB. Will there be a checkbox for me to flag these as custom data? I don't want to have all Skill descriptions revert back to "see page xxx of the CRB" as a great use of this tool is introducing the game to new players and encouraging them to peruse the Skill list to understand how Skills work.

Thanks!