|
Post by blu3wolf on Jan 7, 2019 12:24:56 GMT
Hi all! Ive created an account here as Im interested in CNA. I dont own a copy as yet, and I dont know how Id find time to sink into this endeavor. I guess this is a step in the direction of finding other people crazy enough to consider it, though. Which I confess, that was the obstacle Id formerly considered most insurmountable.
Ive been reading through the rules here, and the errata here, and trying to get a handle on the processes involved - particularly for the Combat Segment. In particular, I've found a few things to puzzle over. Case 12.32 seems ambiguously worded, and Ive currently got two interpretations - Im not sure which is correct. One seems more 'correct' in terms of the wording, but that one also seems more convoluted and less 'sensible' to me.
Case 12.32 is reproduced below: The two differing interpretations hinge on the word, 'each'. The simpler interpretation would replace that word with the word, 'any' to remove any ambiguity. In that case, there could be only one Barrage against any given Target in a given Combat Segment. Multiple units placed Back in different hexes could not strike the same Target.
The more directly read interpretation, that each firing hex may barrage a target once and once only, has some minor concerns with it. For one, there could be up to 6 Barrages against any given Target in a given Combat Segment, by 6 different gun units placed Back (all in different firing hexes). For another, Case 12.14 would have no reason to exist: Unless Im missing something (and with 192 pages of rules, thats entirely possible), it seems like there is not much point to that restriction, if units outside their hex can make their own, separate Barrage? The rule would not prevent units from Barraging, unless Case 12.32 prevented multiple Barrages against the same Target.
I gather there are folks here that have actually played out Combat Segments, as I, have not. Id love to hear how you've played the game, and whether you have viewed Case 12.32 as preventing, or allowing, multiple Barrages from adjacent hexes against a given Target. I suppose, reviewing the errata, that it would hardly be the first error in wording the rulebook.
|
|
|
Post by blu3wolf on Jan 7, 2019 13:37:55 GMT
After a(nother) search through the forum, I discover that this ambiguity has been found and debated before! I rather approve of the discussion, as its given me insight I had missed formerly. I guess Ill go with that interpretation for my own case, as I can see the reasoning to make sense. It does fit the rules as written, too. I hadnt taken into account the effects of combined fire outweighing the effects of individual fires.
|
|
|
Post by blu3wolf on Jan 10, 2019 10:43:19 GMT
So discounting the rules question then, and just on the intro. Im feeling it appropriate to echo a comment I see posted to the Geek a few years back regarding an empty room?
|
|
|
Post by ATD on Jan 13, 2019 20:20:33 GMT
Not empty, just busy with things (including preparations). The new era of object oriented computer coding is something of a culture shock to be assimilated.
|
|
|
Post by blu3wolf on Jan 15, 2019 0:47:52 GMT
Its funny you should say that! Ive been trying to wrap my head around TDD and XP for C# lately. For the purposes of writing a paperwork replacement for CNA. Still more in the planning stages at the moment - determining the specific decisions the player makes so I understand the problem domain better. Once Ive got that handled, Im aiming to move towards coding proper.
|
|
|
Post by ATD on Jan 15, 2019 10:18:12 GMT
Much has been done (see attached) and it's not a trivial undertaking to include all necessary functions and values (such as residual fuel in the tanks of vehicles and "loaded" ammo. Attachments:
|
|
|
Post by blu3wolf on Jan 15, 2019 16:42:24 GMT
Much has been done (see attached) and it's not a trivial undertaking to include all necessary functions and values (such as residual fuel in the tanks of vehicles and "loaded" ammo. perhaps not from a single line in a database. From the perspective of writing code for it, that seems the easier of the many issues. Im encouraged to see you have what seems like a workable solution. Ive barely started coding here: github.com/Blu3wolf/CNA-Assistant/tree/implement-land-gameOn the other hand, I doubt I can offer you any assistance there. I dont really know my way around VB, other than that its supposed to be similar to C#. Presumably as they both compile to .NET IL, one figures they should transpile to one another. Ive used a VB class library once and thats about it. That and Ive hacked my way into a VB6 .exe with a hex editor, but that doesn't really help with understanding VB I think. The other discouraging part is that if there is another solution nearing completion, Ive that much less motivation to continue work on my own project. It was started more or less to keep me busy for a while, rather than to fill the rather niche corner of CNA logging software - but I rather like the idea.
|
|
|
Post by ATD on Jan 15, 2019 21:16:54 GMT
I didn't quite understand your first line but bravo for any attempt to code something. It's an awkward application to code, to say the least. The functions surrounding truck attachment (motorisation), equipment, supply trucks and the supplies themselves are fiddly. Then there's the hierarchical structure, attachments, assignments etc. and that's before we get onto the air side and facilities.
I should have done all this as a crowd funding project... All I want to do is play the bloody thing! : )
If you feel like doing something, entering the Axis land units at start would be good. It's possible to convert the existing data already in spreadsheets (decanting them into an Access database) but a good deal of pre-processing is necessary and probably some final editing - and checking.
|
|
|
Post by blu3wolf on Jan 16, 2019 0:30:35 GMT
my first line... perhaps Im not understanding the problem domain entirely but that doesnt seem difficult to model. There are if I recall, only a few places where fuel in the tanks is treated differently, right? Such as evaporation? If there were lots of places where its handling is unique, you could offline it into its own class, bundling that data and behaviour into an object.
Similarly, is there something special about how loaded ammo is treated? If not, just store it as an integer property of the TOE Strength Point - or of the unit, as I infer from the snippet of code and UI posted that perhaps the unit is the building block object you are using?
No doubt Im missing some complex use case that complicates things. Its a big rulebook.
|
|
|
Post by ATD on Jan 16, 2019 16:38:18 GMT
It may be true that you aren't aware of quite all the subtleties and it's probably pre-emptive to going to all that now, especially as I need to concentrate on getting on with the development.I'll then be free to discuss things at length, although endless communications with folks in the past has been a serious interdicting issue.
|
|
|
Post by rangerdave on Jan 22, 2019 0:32:19 GMT
Wow,
Looking at your screenshot shows me your light years ahead of me. I've played the Italian scenario 4 to 5 times. Completely finished twice. I've fiddled with access then excel as a source of player's aid to reduce the paperwork and time load of the game. Gave up on Access but still playing with Excel. If you need a data inputter, I can help. My VBA level is novice but I still get limited results. Now that i kid is in college i have the space and time to restart playing and developing my player's aid spreadsheets. If you want/need another player I can commit.
David
|
|
|
Post by ATD on Jan 25, 2019 19:20:00 GMT
Nice of you to say so; it's the coding behind it to make it work that is "tricky", being object-oriented.
You are well ahead of me (and nearly everyone else on the planet) in terms of game experience. Even allowing for a a few short cuts, that's quite an achievement.
The program is just about there in terms of facilitating complete unit input (full hierarchy to implement still). It's a simple matter to enter the data directly into the Access DB, though also easier to introduce and miss errors. The third approach would be to do what I did with the Commonwealth forces and hack the existing data from my original spreadsheets into the database. At least 70% of the data could be accounted in that way.
Probably best to use the new system, all things considered.
Right now it's a question of making time to complete at least stage one (Land Forces plus, some Air implementation and minimal book-keeping facilities for all the odds and ends. Give me a while to get on with that but of course, the more interested and active parties, the more motivational it is.
|
|
|
Post by blu3wolf on Jan 31, 2019 20:00:55 GMT
Case 21.51 says you should distinguish between Broken Down Vehicles, Destroyed Tanks, and Abandoned Vehicles, for the purposes of Capturing those Vehicles.
I cant seem to find where the rules are for abandoning vehicles? Little help?
|
|
|
Post by rangerdave on Feb 2, 2019 1:43:18 GMT
See Case 53.3
|
|
|
Post by blu3wolf on Feb 2, 2019 14:57:52 GMT
Much appreciated! I guess I dont see how that would come about, but at least Ive got a reference for what to do if it happens. My thanks.
|
|