SITREP

[Dave 'Arjuna' O'Connor]

That's OK Kip. The state of play at the moment is that when we started looking at the east front battles, we realised that many of these need big maps and the amount of time required to create these is huge. So Pavel has taken upon himself the herculean task of creating an import feature for the MapMaker (MM). So far it now imports elevation data from standard GIS data sets that are publicly available and then it converts these to our height layers in the MM. This alone will save hundreds of hours or laborious tracing. I had a Hangouts session with him on Saturday and got to see how it works. I was impressed. He's working on additional import features so we can download other terrain types - eg waterways, vegetation, roads etc. We need to be careful with these as most of the commonly available data sets are all modern and many of the roads, in particular have changed since WW2.

I've been working up a design document on what I loosely refer to as Planning Enhancements. This extends things beyond sequential tasking and triggers. It was born from a discussion I have been having with Peter Winship (aka John Connor) about the way the generic AI reassigns units away from their historical at start locations. It's a by product of the force allocation routines. I had revisited these five times and I realised that we needed to prevent rather than cure. Hence we really need for the scenario designers to be able to assign at-start orders to units in the ScenMaker (SM).

If we can support this along with sequential tasking and triggers we in effect create a Scenario Specific Scripting (SSS) feature. In essence we allow the scenario designers to generate a plan within the SM. From that I thought well why not allow them to generate multiple plans, categorise them, weight them and then let the AI choose one of these at startup or allow the user to select one or a category. So we add a random dimension to it.

Then I thought why not include this in the game itself and allow the player to generate plans either while the game is paused or running and then allow him to commit one of the plans that he has created to be the current plan. It will then flush out the existing current plan and use the new one. In effect what we simulate here is the fact that at an operational HQ you will have your Three shop (OPS) running the current battle and your Five shop (PLANS) preparing plans for future phases.

It's still in the design stage and will be implemented in stages. But I thought it best to get the design nutted out so we can cater for the future development.

So we are making progress, but I appreciate that it's slow from your perspective.

 

[john connor]

It all sounds fantastic. I love the idea of being able to select a pre-designed plan. And, of course, I'm really keen on being able to script at-start positions. Those sound like really big and significant upgrades to me. Thanks for the update, Dave.

 

[rocketman]

That's OK Kip. The state of play at the moment is that when we started looking at the east front battles, we realised that many of these need big maps and the amount of time required to create these is huge. So Pavel has taken upon himself the herculean task of creating an import feature for the MapMaker (MM). So far it now imports elevation data from standard GIS data sets that are publicly available and then it converts these to our height layers in the MM. This alone will save hundreds of hours or laborious tracing. I had a Hangouts session with him on Saturday and got to see how it works. I was impressed. He's working on additional import features so we can download other terrain types - eg waterways, vegetation, roads etc. We need to be careful with these as most of the commonly available data sets are all modern and many of the roads, in particular have changed since WW2.

I've been working up a design document on what I loosely refer to as Planning Enhancements. This extends things beyond sequential tasking and triggers. It was born from a discussion I have been having with Peter Winship (aka John Connor) about the way the generic AI reassigns units away from their historical at start locations. It's a by product of the force allocation routines. I had revisited these five times and I realised that we needed to prevent rather than cure. Hence we really need for the scenario designers to be able to assign at-start orders to units in the ScenMaker (SM).

If we can support this along with sequential tasking and triggers we in effect create a Scenario Specific Scripting (SSS) feature. In essence we allow the scenario designers to generate a plan within the SM. From that I thought well why not allow them to generate multiple plans, categorise them, weight them and then let the AI choose one of these at startup or allow the user to select one or a category. So we add a random dimension to it.

Then I thought why not include this in the game itself and allow the player to generate plans either while the game is paused or running and then allow him to commit one of the plans that he has created to be the current plan. It will then flush out the existing current plan and use the new one. In effect what we simulate here is the fact that at an operational HQ you will have your Three shop (OPS) running the current battle and your Five shop (PLANS) preparing plans for future phases.

It's still in the design stage and will be implemented in stages. But I thought it best to get the design nutted out so we can cater for the future development.

So we are making progress, but I appreciate that it's slow from your perspective.

Importing maps with topographical data would be awesome and save a ton of time. Currently working on the Juno sector of D-day. It is fun, but takes a lot of time. Regarding your other comment about at-start orders, is that a restriction to at-start placement also? As this i significant in a Juno beach scenario I should probably wait for that feature. Another feature that I would like that is related to this is to have completely static units that under no circumstances will move.

 

[john connor]

You can set up static units in the estab maker, Rocketman. Just duplicate the unit you want static and then tamper with it. I forget how, but I have done it before (even I - and I'm very frightened of the estab maker....)...

Peter

 

[Kurt]

It all sounds fantastic. I love the idea of being able to select a pre-designed plan. And, of course, I'm really keen on being able to script at-start positions. Those sound like really big and significant upgrades to me. Thanks for the update, Dave.

Likewise I am excited to here all this .

 

[kipanderson]

Dave,

thanks for the very full reply.

All does sound great. Just what I hoped for. The important thing is that it is being worked on. Certainly am looking forward to it. The Eastern Front and operations go together perfectly for all the well rehearsed reasons.

Tremendous.
All the best,
Kip.

 

[dw20]

Thanks for the update!

 

[Iconoclast]

great information Dave. Maybe a "future road" sticky would help newcomers and alike to find that kind of info quickly?

Cheers,

A

 

[Dave 'Arjuna' O'Connor]

Nah, we've got enough 'sticky' threads already. I'll often canvass new stuff here in the SITREP thread or I will raise a new thread on the particular issue.

 

[john connor]

Is there any kind of likely time frame for these things, Dave? I mean for the coding changes to defensive at-start positions etc, the scenario scripting, and then for mounted stuff and, ultimately, an EF pack?

Peter

 

[Miquel Ramirez]

So Pavel has taken upon himself the herculean task of creating an import feature for the MapMaker (MM). So far it now imports elevation data from standard GIS data sets that are publicly available and then it converts these to our height layers in the MM. This alone will save hundreds of hours or laborious tracing. I had a Hangouts session with him on Saturday and got to see how it works. I was impressed. He's working on additional import features so we can download other terrain types - eg waterways, vegetation, roads etc. We need to be careful with these as most of the commonly available data sets are all modern and many of the roads, in particular have changed since WW2.

Pavel is the best person for that job anybody could think of, really.

All the best,

Miquel.

 

[magomar]

Importing elevation data? really ? That would be great !! But, would that imply more elevation levels? Because the current number severly limit the ability to accurately represent areas with very rough terrain and elevation differences.
Anyway this feature would save a lot of work and will help create more realistic scenarios, for sure !!

 

[Dave 'Arjuna' O'Connor]

We won't be increasing the number of elevation layers just yet as that would involve a substantial change to the map data structures and will impact performance. Let's take it one step at a time.

 

[Rob]

Hi,

Just wondering how things are going...... any chance of a quick update??

Thanks!

Rob.

 

[Rob]

Hi,

Just wondering how things are going...... any chance of a quick update??

Thanks!

Rob.

Bumpity, bump!!

 

[Dave 'Arjuna' O'Connor]

Sorry Rob, been off sick with a bad head cold. So much for the flu shot I took earlier this year.

Re development. I haven't been doing a lot on that front. I have spent a lot of time working up some videos. David Heath should post these up soon. There should be a marketing one we hope to use to attract new customers and a how to play one. It goes for about forty minutes. I have another even more detailed tutorial one but I haven't finished that one yet. Pavel has been working on the GIS import feature that we have high hopes for. This should enable the creation of a lot more mapping from existing GIS data. He's got it working for elevation and a some of the terrain type layers but there's more to do.

 

[ioncore]

Just adding few words to Dave's SITREP on the import feature.
The functionality is already there and working, however, I find current user interface overcomplicated.
Also, as the feature itself requires close interaction with a contemporary GIS software and geospatial data (that might not be a kind of activity a casual scenario creator excels with), we wanted to create a really detailed step-by-step guide. That guide would explain people how to create a CmdOps maps using GIS + CmdOps + new import feature combined, starting with just scanned paper maps and going all the way up to the creation of a complete and ready scenario map in GIS (and importing these to CmdOps, of course).

 

[Rob]

Wow, that would really be something!

Thanks for the responses guys!

Rob.

 

[Dave 'Arjuna' O'Connor]

I realise I have been quiet on the forum of late and for that I apologise. It's been a difficult time for me personally. My youngest child has been in hospital and is still there. My youngest brother went into hospital a few weeks back as well. On top of that I have been trying to get CO2 onto Steam; finish off the second edition of our Trial of Strength board wargame; publish another book in my sci-fi series (see http://www.warpdrivepublishing.com/); and submit a proposal to the Australian Defence Department's Leading Edge Program (LEAP).

In relation to LEAP, our proposal was to develop the Command Ops engine to provide decision support and experimentation and analysis. We've got past two gates in that program so far. We will be giving a more detailed proposal shortly followed by a demo. If the capability manager likes that then we will be aiming to work up a project for funding approval in the first quarter of next year.

So as you can see I have been busy, but not on developing CO2. I am going to wait till it is released on Steam and then make a judgement call based on sales as to how much time I can put into the development of CO2. Before it goes onto Steam I will do a new build incorproating the minor bug fixes I have done over the past few months. Hopefully this will be done in the next few weeks.

 

[BigDuke66]

No need to apologize, family goes first.
I hope everything turns out well for your family and you.