Ammo

[wodin]

BigDuke I don't understand your question..but Dave found some old code where he had chnaged something to do with increasing ROF..he then changed it again in the latest patch as he didn't realise he already changed it. This explains our ROF issues. Everything is in hand it explains your issues.

See post 26 in this thread.

[BigDuke66]

Check Estab ROF values for small arms and check the same values in-game, in the game everything is the double of the values listed in the Estab, that's what I mean.
For example the 7.92mm Kar 98 k:
In the Estab it has 2/4/6 as ROF
In the game it has 4/8/12 as ROF
And that the difference is so obvious that I wonder if I miss the point of the "2x" thing that Dave found.

So will the Estab values and the in-game values now be the same or what will be changed?

[jimcarravall]

ORIGINAL: BigDuke66

Check Estab ROF values for small arms and check the same values in-game, in the game everything is the double of the values listed in the Estab, that's what I mean.
For example the 7.92mm Kar 98 k:
In the Estab it has 2/4/6 as ROF
In the game it has 4/8/12 as ROF
And that the difference is so obvious that I wonder if I miss the point of the "2x" thing that Dave found.

So will the Estab values and the in-game values now be the same or what will be changed?

The item Dave found in the program doubled the rate of fire from the Estab during the game.

When he eliminates the function the Estab and game values will be the same.

[wodin]

Big Duke..when you think about it..your timings will then double which fits perfectly into Daves notion of around 45 mins or so fire.

[Arjuna]

I can confirm that ROF are now the same in the EstabEditor and Game

[BigDuke66]

Good good but now one thing worries me, there was a small test made with one of the last betas because of the casualties when units were close together and didn't it turn out that losses were quite historical?
Can't find it now but must be in one of the beta threads.
If the ROFs are now half of what they were in the test we will surely be moved of that spot again.

[wodin]

I think the change was made before the ROF got porked. If not I'm sure Dave is already aware of it.

[BigDuke66]

I doubt that:

// ALERT - FUDGE FACTOR - Dave 23 Feb 10

Looks to me like a change from 2010

[Arjuna]

Oh yee of little faith. At the same time as I fixed that fudge I also upped the accuracyAdjustment for small arms in the Fire routine this is a global adjustment value I use for modifying the hit probabilities after all other variables have been applied. I then tested the results on the tutorial doing several runs and noted that cas outcomes looked good. I'm happy with the results.

[BigDuke66]

Well I wouldn't mind if you make us happy too. [:D]

[wodin]

ORIGINAL: BigDuke66

I doubt that:

// ALERT - FUDGE FACTOR - Dave 23 Feb 10

Looks to me like a change from 2010

Actually that was OK..it was the fact he upped it again recently when he had already done it in 2010. It hasn't been broke since 2010 only when he upped ROF again recently when he had already done something in 2010, this is what caused the problem. Anyway it's fixed now. I was confident Dave has all bases covered anyway.

[RockinHarry]

Maybe some idea for future implementation. Adding some external *.ini file loaded with the game, that allows user edits of some ingame key variables, used globally for handling i.e suppression, casualty, ROF ect.? This way users could tweak some the stuff within certain limits to their liking this or other way around.

[wodin]

Would then become a nightmare beta testing patches etc people will moan about this and that forgetting they changed settings several moon ago..

I'm not a fan of people changing core game settings to be honest..unless they are doing a full mod. A game should work well without the need to fudge the settings in a different direction..if this is necessary then something needs to be changed by the developer. If someone finds something odd I'd rather they have to bring it up to the developer and give evidence for a change to benefit everyone..rather than just change it themselves and everyone else not benefit from it. I imagine if this had been possible some of the issues recently would never have been brought up as people would just be editing it all themselves, thus the game is all the worse for it.

[BletchleyGeek]

ORIGINAL: RockinHarry
Maybe some idea for future implementation. Adding some external *.ini file loaded with the game, that allows user edits of some ingame key variables, used globally for handling i.e suppression, casualty, ROF ect.? This way users could tweak some the stuff within certain limits to their liking this or other way around.

Exposing those parameters is indeed a good idea, Harry.

[Deathtreader]

ORIGINAL: Bletchley_Geek

ORIGINAL: RockinHarry
Maybe some idea for future implementation. Adding some external *.ini file loaded with the game, that allows user edits of some ingame key variables, used globally for handling i.e suppression, casualty, ROF ect.? This way users could tweak some the stuff within certain limits to their liking this or other way around.

Exposing those parameters is indeed a good idea, Harry.

In MP, wouldn't both players then need the same "tweaks" ??

[Arjuna]

There's pros and cons with exposing core game variables to public edits. For a small number of users it would be great for them to tinker with and see the different effects on play. For an even smaller number of scenario designers it may help them to balance a scenario by artificially adjusting this or that setting.

However on the con side of the fence I see this all the time in the open source military sims where there is such a plethora of different versions and where the data sets only work with this or that setting. It's a nightmare to manage. Moreover from a developer's point of view it would waste so much of our precious time chasing down supposed bugs that end up being due to changes in settings made by the scenario designer or user.

But an even bigger con is that in many cases these variables are used in different ways throughout the code and the code is very complex. Without access to the code itself you cannot see all the effects that a minor change in this or that setting will have on the various aspects of the game. If you make a change to setting A because you want X but you have no way of changing the way A is used in Y then you are going to end up being satisfied with X but disappointed with Y. So to make it work you really need access to the code so you can adjust the way it impacts Y.

We are definitely not making the source code publicly available. So I would prefer not to provide public access to these settings.

[Arjuna]

ORIGINAL: Deathtreader

ORIGINAL: Bletchley_Geek

ORIGINAL: RockinHarry
Maybe some idea for future implementation. Adding some external *.ini file loaded with the game, that allows user edits of some ingame key variables, used globally for handling i.e suppression, casualty, ROF ect.? This way users could tweak some the stuff within certain limits to their liking this or other way around.

Exposing those parameters is indeed a good idea, Harry.

In MP, wouldn't both players then need the same "tweaks" ??

Yes they would.

[BletchleyGeek]

ORIGINAL: Arjuna
But an even bigger con is that in many cases these variables are used in different ways throughout the code and the code is very complex. Without access to the code itself you cannot see all the effects that a minor change in this or that setting will have on the various aspects of the game. If you make a change to setting A because you want X but you have no way of changing the way A is used in Y then you are going to end up being satisfied with X but disappointed with Y. So to make it work you really need access to the code so you can adjust the way it impacts Y.

That's a very fine point, Dave. As I was thinking a bit more on this I realized that taken to its logical consequences, either the sources needed to be make public (which is a no-no) or rather, exposing the algorithms where those variables are involved, so users can override them with their own routines. This would require from them some programming ability, perhaps in some high-level, easy to learn, scripting language such as Python.

Besides that, it would be a major architectural undertaking in the engine, providing interfaces to load these user-defined routines at run-time. I have personal experience providing such interfaces into agent-based simulations, and it's an extremely work intensive thing and a major investment in highly-specialized (i.e. expensive) programming hours. It would also have quite an impact on run-time, reducing performance in a significant way.

And last, but not least, this would amount to introduce a third "leg" in the data that composes an scenario besides the terrain model (the map) and the forces model (the estab), which as you point out, it might well be a nightmare to manage if released into the wild. Another thing is that there was in place some sort of centralized effort to keep consistency, taking pains to steward a repository of internally consistent terrain, force and "parameters" databases. I've only seen this to work - most of the time - in the GRASS/GIS community, and it's subject to the vagaries of funding of academic or public agencies.

As Sabin cleverly points out, the major difference between tabletop wargames and computer wargames is that the former doesn't require specialized technical skills in order to tweak the model, just a reasonable command of English and elementary Math. This statement is very true now, in my opinion. However, seeing current trends I think that in a generation a significant amount of the population will have had some exposure to programming skills (seeing programming courses in Python or Visual Basic to crop up in Secondary School makes my heart feel warm & fuzzy). And, after all, wargaming is a hobby for the overeducated, isn't it? [:)]

[Arjuna]

I'm not sure I feel overeducated. Overburdened perhaps. [;)]

[RockinHarry]

The idea came from my current and past experiences with games like Steel Panthers WaW, Armed Assault and such, which offer some user customization in mentioned ways (or by means of ingame UI). It´s actually not on my personal wishlist, but thought it could relieve the devs some of the pressure, when people (like me) start to discuss things like casualty rates, suppression FX, Arty effectiveness and such. Off course if data and code structure does not allow it (yet), then it´s maybe worth an idea for CO2. [:)]