Bug Report

[ZPB II]

A bit more digging up reminded me why I felt a bit funny, all my earlier spigot memories got blended into the very recent 37mm gun usage which is a new addition in MG. There was also a Stielgranate 42 for the 50mm PAK and it was a bit more obscure than the 37mm one.

It's working as intended, they're wee bit inaccurate rounds but when they land it's lights out. (in my first test with the 37mm ATG I took out 3 Churchills with a single gun, all with Stielgranate 41 rounds. Not so much knocking on the door but instead bringing the entire wall down)

[kensal]

I just had a peak round the inter web and found this - a reference to a stielgranate for 50mm pak

"It may also be of interest that there was a 5cm Stielgranate 42 available for use with the 5cm PaK 38. Similar to the 3.7cm Stielgranate, this was also an AT round with the ability to penetrate 180mm of plate. However it was a different shape due to the tail needing to fit over the 5cm's muzzle brake. The recommended maximum engagement range was 150m.

(p196, German Artillery of WW2, Ian V. Hogg)

Apparently Stielgranaten were also available for firing from the captured 47mm AT guns employed by the Germans, both Czech and French"

http://theminiaturespage.com/boards/msg.mv?id=305973

[YankeeDog]

Yes; there was a Steilgranate spigot round for the Pak38; we went through this shortly after CMBN came out -- it was actually news to me as well at that time.

My understanding is that it was functionally identical to the one for the Pak36, but with a re-engineered tail end so that it would fit the 50mm barrel.

IIRC, it was pretty rare. BFC must have had some information that at least a few were present in Normandy to include it in CMBN.

So no; no bug. They're powerful, but not very accurate so don't expect miracles from them.

EDIT: Well, I see you guys found your own answers... and quickly!

[ZPB II]

There's a lot of really weird pictures to be found on the internet, but a Stielgranate 42 attached to the barrel of a Pak38 sure isn't one of them.

It's easier to find pictures of naked midget luchadores wrestling on the hood of a Schwerer Ladungsträger.

[Vanir Ausf B]

Your understanding is correct IMO. But being a 3D model, doesn't mean, that every answer this model gives must be a full representation of it's 3D model.

For example if I ask you, where you are now, you could tell me the coordinates of the mass centre of your body, or you could give me a full 3D-CAD-model with all coordinates.

You obviously would tell me only the coordinates of a point, although you are a 3D object.

This means, that bunker objects or vehicles, although they are fully modelled in 3D, could have methods implemented, to allow an efficient calculation without the need to make demanding calculations with their 3D-model.

Imagine the bunker-object as being fully defined with all coordinates and all kinds of variables and behaviour.

But besides this detailed model, the model also can answer in any way, it is programmed to answer.

For example two methods:

TellMeYourPosition and

TellMeYourPositionQuickly

The first method could mean that a 3D-model is returned, with coordinates of all corners, while the second method could be defined as returning only the coordinates of the centre of the action spot, where it is located.

We don't know, if the LOS procedure asks the model for a simple and fast answer, or if the model can't give a detailed answer because it is only a vector with an associated graphics model and therefore is returning only a simple answer. Steve has mentioned, that the models are indeed fully 3D. Therefore I'd say, that what we see with the LOS-tool is the result of a quick and simple answer. Not because it was not possible to give a precise answer, but because of technical restrictions which I think are CPU related.

That is an intersting theory but it isn't just LOS. Bunkers also have the same LOF rules as vehicles, which are different from the LOS rules. Both friendly and enemy units have LOS though bunkers and vehicles but only friendly units have LOF through them. LOF is blocked for enemy units. What CPU issue requires that? And how does a CPU issue explain the tooltip labeling bunkers as vehicles?

[Michael Emrys]

I may have encountered a couple of bugs yesterday that I will mention here. I set a movement path for a team consisting of one shortish segment in Hunt only to see them go off at a 90° angle when I hit Go. Unfortunately I don't have a save game file, because apparently my copy of MG has stopped saving turns. I was, as is my habit, saving each turn after giving orders. However, when I tried to go back to the beginning of the turn's orders phase, I discovered that only the first turn had been saved (I was now in about the seventh turn).

I am going to be busy today, so it may be tomorrow before I can look further into both these problems, but I thought I'd mention it now in case anyone else has encountered either of them.

Michael

[GJR144]

That is an intersting theory but it isn't just LOS. Bunkers also have the same LOF rules as vehicles, which are different from the LOS rules.

Why not?

Each object can have LOS and LOF methods and they do not need to have anything in common at all, or these methods could even be identical.

Both friendly and enemy units have LOS though bunkers and vehicles but only friendly units have LOF through them. LOF is blocked for enemy units. What CPU issue requires that?

That the enemy LOF is blocked, is almost the proove that the model is represented in 3D for certain demands, while it is only represented as point for other demands.

An explanation could be, that as a design decision LOF blocking for enemy units is seen as more necessary than blocking LOF of friendly units.

This could mean, if an enemy projectile hits an object a 3D-calculation with data from the 3D-model is used, while friendly fire ignores certain objects and therefore this safes CPU cycles.

If you assume a 50:50 friendly:enemy force, this could reduce the CPU cycles for these calculations around 50 percent.

And how does a CPU issue explain the tooltip labeling bunkers as vehicles?

This must not necessarily be a CPU issue, but maybe it's just a tiny bug: maybe the method used for vehicles is being reused for bunkers and the label simply has not been renamed yet?

Another aspect:

Buildings use a more complex LOS calculation. But contrary to vehicles this complex calculation is initiated only, if the action spot is in LOS. This also indicates, that things must be highly optimized and all kind of tricks are used, to keep the processing power down.

Maybe they could replace all the optimizations easily with methods dealing all the time with the 3D-models? But then maybe the necessary amount of RAM would become that huge, that it would become unplayable on most machines?

It is important to understand that in OOP the object and it's behaviour (methods) are two completely different things. That's the beauty of it. Objects can be completely changed without any impact on the rest of the program, or the behaviour of objects can be completely changed without touching the objects. What we see on screen is only the result of the intentionally used behaviour of the object, but the user does not know, how complex - or how simple - the underlying objects really are.

It's like observing shadows. How the real things that create the shadow look like, can't be judged by looking at the shadow.

[Vanir Ausf B]

That the enemy LOF is blocked, is almost the proove that the model is represented in 3D for certain demands, while it is only represented as point for other demands.

I see no evidence at all that bunkers or vehicles are ever treated as a single point on the map. Rather, it appears that they are simply ignored in certain circumstances.

An explanation could be, that as a design decision LOF blocking for enemy units is seen as more necessary than blocking LOF of friendly units.

This could mean, if an enemy projectile hits an object a 3D-calculation with data from the 3D-model is used, while friendly fire ignores certain objects and therefore this safes CPU cycles.

If you assume a 50:50 friendly:enemy force, this could reduce the CPU cycles for these calculations around 50 percent.

The reason LOS and LOF rules are the same for vehicles and bunkers is because they are both units. See below.

This must not necessarily be a CPU issue, but maybe it's just a tiny bug: maybe the method used for vehicles is being reused for bunkers and the label simply has not been renamed yet?

And why would the method used for vehicles be reused for bunkers? I say it is because bunkers basically are vehicles with regards to how the game engine looks at them.

Another aspect:

Buildings use a more complex LOS calculation. But contrary to vehicles this complex calculation is initiated only, if the action spot is in LOS. This also indicates, that things must be highly optimized and all kind of tricks are used, to keep the processing power down.

When the game is initiated it creates a LOS map of every action spot on the map to every other action spot. This map is kept in RAM and referenced whenever a unit does an LOS check. Units do not block LOS because units are not part of the LOS map. Buildings do block LOS because they are part of the LOS map. Units and buildings are fundamentally different types of objects. Buildings are terrain. The game engine clearly treats bunkers as a type of unit, not a type of building. This is demonstrably true and I don't know why the idea is controversial.

[GJR144]

This is demonstrably true and I don't know why the idea is controversial.

Learn OOP, then you maybe will understand what I'm talking about.

[Vanir Ausf B]

Don't talk down to me. Your statements clearly show that you do not understand how the game functions.

[Vanir Ausf B]

Maybe you should tell BFC to go learn OOP since you know how their game works better than they do.

One of the most important shortcuts is establishing a "LOS map" of the entire battlefield which is, basically, a precomputed LOS check. Units don't scan the terrain map directly, they scan the LOS map. So it doesn't matter what is on the terrain map, it matters what is in the LOS map. Since the LOS map is precomputed, it can't possibly know about things that move around dynamically since that would require constant recomputing the LOS map data. So much so that it would probably negate the reasons for having the LOS map in the first place. Which brings us back to the point about this shortcut being necessary for the game to run at all.

The upshot is that units can not block LOS because they are not tracked in the LOS map. Because the LOS map is mandatory for a CM type game to function, there's no room for argument.

[GJR144]

You claimed that bunkers were treated as vehicles. Then I tried to explain for complete idiots the concept of OOP and now you bring the LOS map. The LOS map is an abstraction object to reduce CPU demand! The LOS map has nothing to do, how objects are modelled in the game. Again: how LOS is handeled says NOTHING how the objects are modelled within the game.

You are making technical conclusions about inner game mechanics you can't do without detailed knowledge about the class structures.

[Vanir Ausf B]

You claimed that bunkers were treated as vehicles.

And they are. Demonstrably so. Or at least they are treated as units, and vehicles are the type of unit most similar. Bunkers are definitely not a type of building.

The LOS map has nothing to do, how objects are represented in the game. Again: how LOS is handeled says NOTHING how the objects are modelled within the game.

Ahem.

The upshot is that units can not block LOS because they are not tracked in the LOS map.

Call me an idiot if you want, but at least I can read.

[altipueri]

Does that mean that a forward observation officer obscured from the view of a sniper by a tank would not be obscured by the tank because the LOS rule ignores the tank?

[Vanir Ausf B]

Correct. However, the tank would block line of fire.

EDIT: Actually, I'm not sure about that. I am pretty sure the tank would block LOF -- but not LOS -- from another tank, but IIRC the LOF rules are different under some circumstances for vehicles and non-vehicles. I'd have to test it.

[Michael Emrys]

I may have encountered a couple of bugs yesterday that I will mention here. I set a movement path for a team consisting of one shortish segment in Hunt only to see them go off at a 90° angle when I hit Go. Unfortunately I don't have a save game file, because apparently my copy of MG has stopped saving turns. I was, as is my habit, saving each turn after giving orders. However, when I tried to go back to the beginning of the turn's orders phase, I discovered that only the first turn had been saved (I was now in about the seventh turn).

I am going to be busy today, so it may be tomorrow before I can look further into both these problems, but I thought I'd mention it now in case anyone else has encountered either of them.

Update on this.

I was able to restart the scenario from the first turn which was saved, and have played through about fifteen turns without either of the two problems reported above appearing. So it looks like the first appearance may have been some kind of fluke, like a random cosmic ray striking a memory cell or something. Wherever the gremlin came from, he seems to have gone back and I am happy not to have him around.

Michael

[waclaw]

a quick battle, as in CMFI/GL auto purchases is almost same vehicles AA - it's probably a bug?

[ioannis1]

Its not really a bug but you can see When you pick up in Quick battle the Luftwaffe the FO appears three times , and i wonder what the Kriegsmarine with the Luftwaffe have to do.

Is it misspell or have i messed up my installs?

P.S Sorry for my English

[ioannis1]

Oh the picture is very small how can i made it larger?

[A Canadian Cat]

Upload the picture to another server. Your own web service account or photo bucket and then use the URL provided by that service to insert the picture here.

[akd]

Its not really a bug but you can see When you pick up in Quick battle the Luftwaffe the FO appears three times ,

I can see it well enough. Due to the way TO&E for QBs is built, sometimes duplicate teams show up under specialist teams.

and i wonder what the Kriegsmarine with the Luftwaffe have to do.

Is it misspell or have i messed up my installs?

P.S Sorry for my English

Really not sure know what you are asking here, but I don't see any reason to think your install is messed up.

[ioannis1]

Thanks

http://i833.photobucket.com/albums/zz257/ioannis33/bugs_zps890a011e.jpg

Never mind my mistake

[A Canadian Cat]

You can still create the message with the image embedded by using the [ I M G ] tag:

Look for the button that looks like a mountain with a yellow sky and a dot in the top right corner. Press that and paste the image URL into the dialog and will create the correctly formatted tag for you in the message.

[ioannis1]

Thank you for your help but.... where did i find this button?

[A Canadian Cat]

In the toolbar when you are editing a message. In the full editor (what you see when you hit the new replay button) it is in the second row of buttons fifth from the right. The yellow one.