Game System Refresh

[amis92]

Discussion started in #34 by @Millicant.

There is an initiative to clean up and organize our gst better.

I feel it's good time for us to learn about branches. It's independent "copy" of repo from a given time, which can be independently modified. Currently we have only master, from which we do releases. That's good. We'll need a development branch, on which we'll test the new Game System and comment on it. I'll go ahead and create it. @Millicant , your job will be then to put your gst in that new branch.

Changing branches is rather straightforward in GitHub app. There is branch name (master by default) in upper-right part when you're in repo view. If you click on it, you'll see branches (most of the time only master) and here you need to choose which branch to work on. It's best to change between branches while there are no uncommited changes, as these changes will stay.

So I've created new branch, new-gst. @Millicant, could you share your gst refresh with us on this branch, please? Then we'll discuss changes.

[Sandy756X]

This is a fantastic idea! I was wondering how I could make progress without it ruining the main data files. I will gladly upload my gst.

There is one slight issue that I hope can be resolved, however. As mine is an edit of the existing, it had, until recently, the same unique ID as the current gst. Battlescribe does NOT allow two gst's with the same ID to be present. I changed mine (generate new id) but this eliminated all catalogues that were previously linked to it.

Herein lies the issue: I don't know how (if there is a way) to change a catalogue's parent gamesystem. Since the data is largely the same, it should be as easy and changing the reference ID somewhere in the file. Anybody know how? If so, this would prove to be a singularly simple way to track which catalogues have been altered to match the updated gst (ie only the ones that are being worked on will even show up).

[amis92]

Well I think it'll be easier for now to change the new GST's Id back to the original. Not sure how that may impact other catalogues.

Maybe start with uploading gst with IDs copied back again from current one, and we'll see. Changing id of origin gst in catalogue is impossible in BattleScribe, only by raw editing of xml. And it may lead to errors. Well, leaving it with new gst may too, but we'll think on that later. Let's try now with just gst changes.

As for showing up only those which are being worked on - don't worry. Simpy adding [WIP] in inside name will be enough (don't mean the filename tough!).

Oh, and if we're working on new one, simply change id of the old gst (generate), and keep it for reference, or just simply delete, we can always switch branches, open the old one, switch back to dev branch and open our new to work on. :) Power of git!

[Sandy756X]

Unfortunately using the same ID won't be possible as the Roster Editor immediately flags the error and will not allow any list editing whatsoever. In order to proceed, a new ID will be necessary. I'm going to investigate raw editing, otherwise we move into drastic measures.

EDIT: Okay just tried it out. Works fine. Opened it up in notepad, copied the gamesystem id and version number - pasted into the file and blammo. Works just fine.

[amis92]

Oook I'm not sure what id is where now. The thing with new ID all the way down the future is, when we publish it, the guys at the other end - users - will get two systems - one old, and one new.

I am not sure this is what we want. I think we should keep on modifying the old file, ie. keep IDs, and when releasing, just increase gst version number.

The other way is what you're trying to do, which is essentially creating new system.

I repeat, I am on the side of evolution, not creating new one, but I'll listen to arguments.

[amis92]

Ok, I've looked through it, now I can say what I think.

You've cleared up profiles the way I think is good, as 6th edition unified statlines, structure points are now transformed into HP anyway, and transport capacity and fire points just aren't usable anyway most of the time.

But the way Force Types are reorganized isn't the best.

First of all, I don't know much, but if it would be possible, I'd throw Horus Heresy out, and get it it's own system. I don't know how much it uses 40k's catalogues, but it's just quite separate system.

Second, you threw No Force Org, and I think it needs to stay - BUT maybe we can discuss this. I think it was needed for some checks otherwise uncheckable, as (No Category) allows none somehow.

And third - well, from what we hear 7th edition is imminent (24th May pre-orders), so I suggest to hold on with changes to gst. Let's relax and collect power to kick some asses when 7th hits! It's going to be busy time ;)

Here I will start outlining what we need to do anyway (suggestions to add to it welcome):

• Clean up profiles: leave only:
  • Unit
  • Walker
  • Vehicle
  • Wargear Item
  • Weapon
• Throw out Horus Heresy to it's own system (done)
• Discuss No Force Org Slot (discussed: needed)
• Clean Up Knight & Inquisitorial Detachments & Legion of the Damned (merge)

Off the top of my head, merging Knights into standard FOC could look like this: Leave Knights as Knight category. In game system, modify HQ and troops to set minimum to 0 on condition Knights has at least 1 selections, and modify Knights catalogue so that it sets maximum to 3 or to 6 depending on which Parent Force Type they are part of.

LotD may be more tricky if at all madeable. Wh40k as it is started to modify game system organisation back from army-specific codexes, which BattleScribe doesn't support currently.

[Sandy756X]

Okay I figured it out!

Previously I believed that a new ID was necessary because BS won't allow two gst files with the same ID. What I DIDN'T know is that github automatically switches the files over to whichever branch you're working on. Meaning they can have the same ID because they won't both be present at the same time!

EDIT: NO I was wrong it doesn't do that! It only does that with the branch, meaning the master files stay put and the branch is added/removed as you swich.

Sorry, I am brand new to github so I am learning a lot here. I apologize for making things more complicated. :)

I will have to think about the rest and get back to you - that being said I highly doubt that 7th ed will change much for us.

[Toreador13]

No Force Org Slot does need to be in the game system file as most armies have units that do not take a traditional slot. It makes it a lot easier to group those units together,

[Sandy756X]

@Toreador13 it doesn't actually need to be a fabricated slot, however. If those units that do not take up a traditional force org slot have their category blank, they still show up in the roster editor under "No Category." The only argument I can see right now for leaving "No Force Org Slot" in is what @amis92 mentioned where checks need to be applied. However, we can only apply those checks in the gst file, where I still don't see a need.

My case is for simplicity - my aim is to eliminate anything unnecessary, and so far I still see "No Force Org Slot" as unnecessary.

Additionally - see edit above. Github does NOT switch based on branches. Refresh GST is going to have to have a unique ID for now. Possible answer: do everything under a new ID and then for release, manually adjust all catalogues and new gst BACK to the previously existing ID. Unless there's an easier way...

[Toreador13]

The biggest issue, and the reason we originally changed it had to do that when you added other formations, units were showing up when they shouldn't and caused quite a bit of confusion. I don't remember the whole issue, but we discussed it a little on the catalogue and it fixed the issue we were having.

[Sandy756X]

Interesting. @Toreador13 any chance you can link me to that discussion so I can educate myself? Thanks!

[Toreador13]

It started here http://catalogue.randomhit.org/viewtopic.php?f=5&t=156&p=2466&hilit=no+force+org+slot#p2466 have to register to see it if you aren't there already. I am Mr Dark.

[amis92]

Ah yes now I remember. So to sum up, when you create roster, and add force type Fortifications using let's sat Tau catalogue, you had choice of Fortifications and No Category entries too - which caused confusion and couldn't be controlled. So for the sake of Fortifications and Formations categories, and possibly in your version, Lords of War force types, No Force Org was created, and choices for this are allowed in regular Detachments.

[Toreador13]

That is it. And that was even at the beginnings of this when it was simple. Seems so long ago, now we have dataslates, allies, Inquisition, Legion of the Damned, Knights, Lords of War,... am I missing anything else here that you can take all included in one army list? I am not sure if it would currently cause a problem, but back then it did when we were just starting out with all of this.

On Tue, Apr 29, 2014 at 3:38 PM, Amadeusz Sadowski <notifications@github.com

wrote:

Ah yes now I remember. So to sum up, when you create roster, and add force type Fortifications using let's sat Tau catalogue, you had choice of Fortifications and No Category entries too - which caused confusion and couldn't be controlled. So for the sake of Fortifications and Formations categories, and possibly in your version, Lords of War force types, No Force Org was created, and choices for this are allowed in regular Detachments.

— Reply to this email directly or view it on GitHubhttps://github.com/BSData/wh40k/issues/38#issuecomment-41728927 .

[Sandy756X]

Thanks @Toreador13, I read through that a bit.

@amis92 thanks for the explanation. That makes much more sense now. Basically the problem isn't choices not having a category, it's choices that have no category showing up where they shouldn't.

I'm sure this has been brought up but this would all be much simpler if catalogues could modify categories/force type requirements....

Would a catchall detachment type be feasible? As I've stated, adding force types willy-nilly is not a clean way of dealing with the issue. However, there is definitely a chance that is it the only way...

[Sandy756X]

Also @amis92 I was initially against separating Horus Heresy from the regular gst, but the more I think about it my only hesitation is future updates/version changes. I don't want it to get left behind as updates come along. Separating them would mean that somebody would have to make any changes/updates twice, since HH still uses the core 40k rulebook. If that is not a problem, I might actually be for it.

[Toreador13]

I will look tonight at the second book and see if there are any other changes. I don't have access to the third yet, so we will have to wait for someone to spend that money.

On Tue, Apr 29, 2014 at 4:19 PM, Jordan Millikan notifications@github.comwrote:

Also @amis92 https://github.com/amis92 I was initially against separating Horus Heresy from the regular gst, but the more I think about it my only hesitation is future updates/version changes. I don't want it to get left behind as updates come along. Separating them would mean that somebody would have to make any changes/updates twice, since HH still uses the core 40k rulebook. If that is not a problem, I might actually be for it.

— Reply to this email directly or view it on GitHubhttps://github.com/BSData/wh40k/issues/38#issuecomment-41733587 .

[Toreador13]

Millicant, I think that has been brought up before, and would require a ton of work from Jon. And having the No Force Org was for a catch all for anything in the future that didn't fit in a slot. We had very few in the past, but started seeing some in every list. So like you said, it's only really there for better display purposes. Which, I think is also why the different detachments make sense. It makes it easier to present all the wackiness that GW has been doing as of late. We have allies, but then they throw in Inquisition and Legion of the Damned which follow a completely separate way to ally. Then comes Knights, which is it's own and very different primary and ally, and isn't a Lord of War for all intensive purposes. It might be better for this kind of decision to be made after we see if 7th edition does come out at the end of the next month and clears any of this up. Right now it really is in disarray.

[Sandy756X]

Frankly I concur. :)

Fair enough on the work from Jon - that was more of a comment than a request, as I'm sure it would have been done or mentioned if it was easily accomplished. Jon has provided us with a pretty kickass system, we just have to decide how to respond to the lack of uniformity in the recent releases. (The only thing I really want from him is the hide/show entries!)

Well I'm in favor of just sitting on this until 7th rolls around and re-evaluating from there. The only part I would very much like to see refreshed is the profile types. It is a mess, and as (I think) we have agreed, there are only a few types that are truly necessary.

[amis92]

I agree on sitting till 7th hits, and I agree on cleaning up profiles. Maybe cleaning up profiles could be done before 7th hits. Let's leave reorganizing Force Types for now.

[Toreador13]

Yep, the clean up has been a long time coming as a lot of things were in a transitional state. Now that all of GW and FW seems to be using a lot of the same terms we should be good. I hope they don't go and mess it all up again in a month.

On Tue, Apr 29, 2014 at 4:41 PM, Amadeusz Sadowski <notifications@github.com

wrote:

I agree on sitting till 7th hits, and I agree on cleaning up profiles. Maybe cleaning up profiles could be done before 7th hits. Let's leave reorganizing Force Types for now.

— Reply to this email directly or view it on GitHubhttps://github.com/BSData/wh40k/issues/38#issuecomment-41736006 .

[ghost]

I agree with removing redundancy - updating the page ref on profiles is annoying when you're updating a codex, just an extra faff you don't need. You need the 'Battle Formation' category for Apoc. Transport capacity seems quite relevant on the vehicles/walkers/units that use it; I'm not sure that should be done away with.

[Toreador13]

Page reference is totally obsolete now with Epub, Itune and paper releases. It makes no sense anymore, and is less than useful. Transport capacity is something I do use quite a bit, but do we just do that as a rule instead of in the profile?

On Tue, Apr 29, 2014 at 10:04 PM, khambatta notifications@github.comwrote:

I agree with removing redundancy, plus the page ref on profiles is annoying when your updating a codex. Transport capacity seems quite relevant on the vehicles/walkers/units that use it though, and you need the 'Battle Formation' category for Apoc.

— Reply to this email directly or view it on GitHubhttps://github.com/BSData/wh40k/issues/38#issuecomment-41756268 .

[ghost]

There are a couple of Ork transports where it varies depending on your upgrades. Putting it in the profile means you can use modifiers to suit. Are Orks the only faction with Walker-transports & Creature-transports?

[Stegadons]

Nids have creature transports only

-------- Sākotnējā ziņa --------

No: khambatta notifications@github.com

Datums:30.04.2014 07:04 (GMT+02:00)

Kam: BSData/wh40k wh40k@noreply.github.com

Tēma: Re: [wh40k] Game System Refresh (#38)

There are a couple of Ork transports where it varies depending on your upgrades. Putting it in the profile means you can use modifiers to suit. Are Orks the only faction with Walker-transports & Creature-transports? — Reply to this email directly or view it on GitHub.

[amis92]

Well, once Tyranids had mycetic spore. Nowadays only Orks probably. Well we could leave Vehicle (Transport) just for that additional single ch-stic. I'd rather do that as a rule tough. You know, @khambatta, rules can have description modified too. ;)

Page refs were introduced in times when BS hadn't had it's own anyway. Now Profiles have double page refs. I suggest writing only printed book refs, as in the rest we can use the magic of Ctrl+F really.

[Sandy756X]

I disagree with leaving the extra transport profiles. My intent was to make them look as similar as possible to the way they are listed in GW/FW publications. Transport info is not listed in the primary profile, but in a text box below. Unless that changes, I suggest we stick with eliminating transport profiles. Especially since info like number of access or fire points is extra messy, since that info is explained in greater detail in a text box. Having the numbers for those is irrelevant without their locations.

[ghost]

That makes sense.

It looks like the updated edition of 40k will use percentages for the FOC. I guess we'll have to wait and see how this affects the 'No Force Org' units.

[Gary-B2]

I like the Transport profile. The reason is i want as little space taken up when i print or look up a Roster. Having it show up later down the page means more searching. I think this is somewhere where we have an improvement over GW.

I think if we come up with a shorthand description of Hatches, eg. 2 Sides, 1 Rear instead of the GW description which is alot more text.

[Jonskichov]

OK, catching up after a bit of absence (I got distracted making Arma3 missions... I am easily distracted). And in no particular order here are some responses :)

• I am certainly on board with a gst cleanup :) As noted by others, as long as the gst ID in the catalogue files matches up to the ID in the gst file, and as long as the category and force type IDs remain the same inside the gst, then all should be well. That's important! We shouldn't change the category IDs, even if we change the gst ID.
• Personally I like that transports had additional fields for capacity/access points/fire points/whatever. Perhaps I should modify BattleScribe to only show profile cells that have contents? This way the additional transport profile items can be included in the basic Vehicle stat lines, but won't show up in the output unless they're filled in?

• Big one: I think we should re-gen the IDs for ALL the data. There I said it. Yes this will be painful for users: they'll end up with the data duplicated - though they can just delete all data and re-download, and their old rosters will no longer link up to data. Also painful for us - we have to be organized and get everyone to check in any WIP, then one person refreshes all IDs and checks in, then we all check out. We will also no-longer be able to take data from the Randomhit forum to get their changes.

  So why do I think we need to do this? We are drifting further and further away from the original Randomhit data. The further apart our data is from theirs, the more difficult and error prone it becomes to merge in their changes with our data. At what point do we decide that our data is different enough from theirs to be considered completely separate? We will get there sooner or later. Better to bite the bullet in the early days and just make the change IMO. The earlier we do it, the less users are effected too.

• Waiting for 7th/6.5th to come around is probably best! We don't want to make all these changes and then find out that we have to make a whole bunch of different changes after the new version drops :)
• Re. hiding stuff, I'll (finally) bow to you guys' requirements and add it in. When an item is not editable or available (min/max are 0, or min/max are the same), then they will not be displayed. I could additionally add a "hide" checkbox like on rules/profiles if that'd be useful?

[Sandy756X]

I'm on board with all of that.

If profiles could be set so that empty fields are excluded - I would be more open to keeping the transport options in the profile. I still think it's a bit wonky to have access and fire points, since those require text explanations, but I won't throw a fit if I'm overruled. Point is: if they don't show up for units that don't have data for them, I'm cool with it. It would still leave us with only the 5 profiles: Vehicle, Unit, Walker, Weapon, Wargear and that way if the first three have transport capacity, it will show up. If not, same as before. Glorious.

As far as the rest - yes. I will help as able.

And finally - I said it in the other issue too but I would definitely appreciate the "hidden" flag on entries AND entry groups! Along with the ability to modify that (ie hide/show). Oh man I would get you so many lizards... :)

[amis92]

Yay. Showing only filled columns would help alot. But then would they be grouped by filled columns? ie. would transports be grouped together? That would be simply awesome.

I'm for re-gen'ing IDs. Trying to merge changes from more and more differed catalogues would be just bad. As I understand, new IDs would be generated for categories and it would be enough? Or not?

So besides that, we wait.

[Jonskichov]

Hmm now you guys talk about it, there's more to showing/hiding profile cells than a simple "don't show". Probably won't do this for the upcoming release. @Millicant is right too, long text explanations don't really fit in profiles. Perhaps these are better as Rule items.

@amis92 Re IDs:

• Regen ID for Game System
• Find and replace GameSystemId in all catalogue files
• Regen IDs for all Catalogues

The Force Type and Category IDs inside the Game System must stay the same

[amis92]

@Jonskichov, forgive my curiosity, but why do the Category Ids have to stay the same? Or is it can as in changing them will make it much more work for us to do?

Pozdrawiam, Amadeusz Sadowski

wysłane z Lumii 820

-----Wiadomość oryginalna----- Od: "Jon Taylor" notifications@github.com Wysłano: ‎2014-‎05-‎07 16:18 Do: "BSData/wh40k" wh40k@noreply.github.com DW: "Amadeusz Sadowski" amis.tau.92@gmail.com Temat: Re: [wh40k] Game System Refresh (#38)

Hmm now you guys talk about it, there's more to showing/hiding profile cells than a simple "don't show". Probably won't do this for the upcoming release. @Millicant is right too, long text explanations don't really fit in profiles. Perhaps these are better as Rule items. @amis92 Re IDs: Regen ID for Game System Find and replace GameSystemId in all catalogue files Regen IDs for all Catalogues The Force Type and Category IDs inside the Game System must stay the same — Reply to this email directly or view it on GitHub.

[Sandy756X]

@amis92 yeah at the very least it would mean needing to track down every single entry and re-select it's category. Pain. Though there certainly may be other reasons as well.

On that very same note, there is something I may have failed to mention up until this point: There is a significant ass-pain involved with the update of the profiles. When you remove a column (like I did with pg) all your existing profiles freak out. You have to go to each and every one and fix them.

This is an irritating but fortunately short process. I revamped each of my catalogues in roughly 15 min apiece. It simply involves re-selecting the appropriate profile type and then copy-pasting the data for wargear (or for long weapon/vehicle/unit types) and quickly re-entering the profile numbers for vehicles/walkers/units.

That being said - I STRONGLY recommend we finalize our approach to profiles prior to any adjustments. To me, that means we either abandon the idea of hidden profile cells (fine with me - as I've already stated I prefer a cleaner profile with text data in a rule) or we wait until Jon can decide that he does want to move forward with that process.

Last question @Jonskichov just to clarify - you plan on skipping hidden profile cells for the now, not hidden entries/entry groups right? If you can't tell, I'm beyond excited for the latter.

[amis92]

Oh, @Milicant, let me be clear: I have no intent on doing it by hand anyway. I'm gonna write some C# or other mini-program to do it for me. Or maybe start using xslt, as I hear it's powerful.

And then cleaning up ids or removing obsolete characteristics, changing their place etc. is plain easy. No matter how many id's would have to be changed.

I will of course share these scripts/xslts, if someone would like to see it.

[Sandy756X]

haha @amis92 that sounds like a WAAAY smarter way to do it! Ugh to think of all the time I spent, and would have spent! I'm really glad that you have the know-how to make that happen because frankly, I was seriously dreading that process.

[amis92]

C# and XSLT away, you can use smart text editors like Notepad++ and regular expression find-and-replace 'em. Though profile repairing would be harder.

So as there will be no smart profile showing in foreseeable future, I think we need to remove the transport-specific characteristics. Do we agree? I do understand sometimes it would be handy, but from what I know, most transports do have additional rules for capacity, and fire points are simply too descriptive (text-containing). We may leave Vehicle (Transport) profile, as it's most often, and let it have capacity. Other transport types are non-standard (they don't even officially exist in rulebook, transport is their special rule), so surely we wouldn't have them.

[ghost]

Is it worth considering having a profile type "Transport" with just the categories for capacity/fire/access? That'd eliminate all the transport types & be more uniform than using rules.

[Stegadons]

I think we don't need profile for transports - just stick with the profiles used in rulebook - "transport" is usually a type of "vehicle" and transport specific info should be added as a "rule". Why is it even necesary - how often you don't know capacity or firepoints of transport in army you play?

[Sandy756X]

@Stegadons that's essentially my viewpoint as well.

My vote - NO TRANSPORT profile types of any kind. Too messy.

[Toreador13]

I agree. A lot easier as a rule. But I often have to check and recheck transport capacities, but it is mostly because I play a lot of different armies, I can never keep them straight. A rule is how I started doing them in Bolt Action also.

[amis92]

@Toreador13 or anyone actually, can you remind me what for do we need categories Additional X Detachment (and entries for that in catalogues)?

[amis92]

Haha, I found a nice picure over here (http://www.teambelgium.eu/?p=5717)

Helps understanding FOC alot in our situation. O.o

[Sandy756X]

Well, it might. Have you seen the leaked WD stuff? Unbound armies are approaching.... Hopefully there will be some consolidations on the rest of this as well.

Either way - nice find! If FOC structure stays somewhat the way it is, that will be immensely helpful.

[amis92]

Well I think Unbound will actually be the easiest ;) Just throw inside all categories with max -1;D Here is hoping for more uniformity (though personally I think nothing will change).

Also there is a rumour of "Competitive" Supplement for November which could introduce % system into the game.

[Jonskichov]

@Millicant I've skipped the hidden cells, I think this will be a bit of a pain to get right for (IMO) not a lot of benefit. I've implemented hidden entries/groups in 1.14.01 :)

[Sandy756X]

@Jonskichov I'm so very happy about the hidden entries/groups! Oh man, please go check out the Horus Heresy stuff as I've implemented it there! There is a bug I've noticed, it's posted as an issue on the HH repo.

As far as hidden cells, I certainly didn't mean to push for that. It would be a nice solution for those who wanted Transport info to remain in the profile, but since I'm an advocate of cutting them I ultimately don't see that as a loss. :)

Hidden entries/groups is amazing - THANK YOU!!

[Sandy756X]

Okay so new rulebook in hand: Detachments are handled a little differently. Unbound should be easy - add an "Unbound" detachment with -1 everything. Users will still have to add multiple unbound detachments if they wish to use units from multiple codicies, but I don't see any reasonable way around that.

Regular detachments are now referred to as "Battle-forged" and include a Combined Arms Detachment (the regular FOC we know and love) and Allied Detachment (same as before). However, you are not restricted to a single detachment of any type. So, you can have two (or three, eight, whatever!) Combined Arms Detachments (CAD) as well as any number of Allied Detachments. It seems those are essentially the only Detachments available to Battle-forged armies for now, though it seems clear that more will be arising shortly to offer new/different bonuses.

As far as Force Org slots (also now called Battlefield Role) they have officially added "Other" and it mentions Imperial Knights specifically in the description. The rules also specify that all units must belong to a detachment BUT "occasionally a unit's army list entry will state that it does not take up a Force Org slot" (I'm assuming this includes Knights, inquisition, etc) "These units can be included in any Detachment, even if all the slots of the appropriate Battlefield Role are filled with other units or if the Detachment had no slot for their Battlefield Role." Yikes! Not sure how we're going to implement that.

[amis92]

Nay, "occasionally a unit's army list entry will state that it does not take up a Force Org slot" (I'm assuming this includes Knights, inquisition, etc) "These units can be included in any Detachment, even if all the slots of the appropriate Battlefield Role are filled with other units or if the Detachment had no slot for their Battlefield Role."

That's just our No Force Org Slot all again, nothing special here.

I'm putting final touches to my Reshaper and I have essentially ready XSLT, which means today I'll throw it all upside down ;) (that's what I was talking about, with ID regeneration and profile touch-ups (removing Pg etc.).

I think I'll put up branch for 7th ed and give a one day trial for rest of us interested in trying if all works well, then merge into master.

PS I do own our new sweet rulebook, I reeeally like it.

[amis92]

So here it goes: BSReshaper Now I'm gonna test it and see how it explodes ;D You can try it out too, just remember to use it on git folder - in case you'll need to clone it again ;)