BoM German Career Bug (?), AI Only Shoot Down Bombers

[Bluewulf]

Hello Everyone,

 

I have noticed in my Battle of Moscow German Career that when AI flights go out (I am not on that flight and the flight is auto resolved) that the AI only shoots down bombers. Exactly one bomber every time (if they shoot something down at all.) Doesn't matter the type of mission. It can be ground troops cover, river crossing cover, free hunt. If they shoot anything down at all, it is a single bomber (1 Heavy). AI have flown dozens of flights by now with the same results.

 

It seems like they should be running into fighters (Light) or ground attack (Medium) at least some of the time. And if so should be able to score a kill against that type once in a while. When I am leading/on the flight they occasionally shoot down an enemy fighter or ground attack plane, but when its an AI mission only...it's a single bomber, and that's it.

I find this very strange. Has anyone else run into this? Does this occur in the Soviet campaign as well? Could this be a bug? 

[LukeFF]

It's not a bug - it's just the way it's coded right now.

[PatrickAWlson]

This is probably destined for the suggestions or complaints section, but before it gets there: Dev suggestion

 

Find all units in range of the AI pilot.  Randomly select a unit.  Randomly select a plane type flown by that unit at that time.  Believable variety.

[Zeev]

13 hours ago, LukeFF said:

It's not a bug - it's just the way it's coded right now.

Just FYI a bug is usually located in the code. ?

[PatrickAWlson]

1 hour ago, Zeev said:

Just FYI a bug is usually located in the code. ?

 

A bug is also not "I don't like it".   A bug is "It's supposed to work this way and it doesn't".  I agree with the OP that the feature is not ideal by any means, but it's not a bug.  It works exactly as it was intended to work.

 

If that sounds pedantic, it's really not.  Software developers working on a system of any complexity are inundated with requests and complaints.  We have to distinguish between "we messed up" and "we could do better".  The first needs to be attacked and resolved right away.  The second gets evaluated and queued up with all of the other things that could be done.  

 

If I was evaluating possible changes I would try to get this one done.  It is low priority in the sense that nothing is broken, but seems easily enhanced - low hanging fruit.  

 

Hope that makes some sense.

[Zeev]

2 hours ago, PatrickAWlson said:

 

A bug is also not "I don't like it".   A bug is "It's supposed to work this way and it doesn't".  I agree with the OP that the feature is not ideal by any means, but it's not a bug.  It works exactly as it was intended to work.

 

If that sounds pedantic, it's really not.  Software developers working on a system of any complexity are inundated with requests and complaints.  We have to distinguish between "we messed up" and "we could do better".  The first needs to be attacked and resolved right away.  The second gets evaluated and queued up with all of the other things that could be done.  

 

If I was evaluating possible changes I would try to get this one done.  It is low priority in the sense that nothing is broken, but seems easily enhanced - low hanging fruit.  

 

Hope that makes some sense.

I would not want to be working with a team with an attitude of "we messed up". Every developer even the best one can introduce any bug if its low or high priority.
And thanks for lecturing me on R&D, but no thanks as I am working in this field for many years.
"We messed up" is usually comes from the product managers and higher management (not team) when the customer demands a fix.
We are the customer. As much as I, and I say it again, appreciate the hard work of the devs, a constructive feedback on these issues needs to be written in this forum periodicly so this issue gets higher priority to being fixed.

Edited June 19, 2021 by Zeev

[PatrickAWlson]

1 hour ago, Zeev said:

I would not want to be working with a team with an attitude of "we messed up". Every developer even the best one can introduce any bug if its low or high priority.
And thanks for lecturing me on R&D, but no thanks as I am working in this field for many years.
"We messed up" is usually comes from the product managers and higher management (not team) when the customer demands a fix.
We are the customer. As much as I, and I say it again, appreciate the hard work of the devs, a constructive feedback on these issues needs to be written in this forum periodicly so this issue gets higher priority to being fixed.

 

I feel the opposite per acknowledging a mistake.  Continuous improvement.  I'm not talking about self flagellation, or worse, finger pointing at others.  Just an acknowledgement that an a error occurred and should be learned from.  Nothing wrong with a mistake unless you keep making it.

 

 

If you're in R&D then you know the difference between a bug and an enhancement.  Your initial response to Luke kind of surprises me.  Luke Was stating that the code is behaving as intended, therefore not a bug.

 

 

[Gambit21]

5 hours ago, PatrickAWlson said:

 

If I was evaluating possible changes I would try to get this one done.  It is low priority in the sense that nothing is broken, but seems easily enhanced - low hanging fruit.  

 

 

Yep

I’ve automated several different layers of logic in a few “all possibilities exist” randomized mission files (similar to how the career is built)..so I know it’s possible. This includes randomized enemy aircraft, randomized friendly aircraft, randomized airbase “scenery” vehicles etc.  

[JG27_Steini]

5 hours ago, PatrickAWlson said:

 

I feel the opposite per acknowledging a mistake.  Continuous improvement.  I'm not talking about self flagellation, or worse, finger pointing at others.  Just an acknowledgement that an a error occurred and should be learned from.  Nothing wrong with a mistake unless you keep making it.

 

 

If you're in R&D then you know the difference between a bug and an enhancement.  Your initial response to Luke kind of surprises me.  Luke Was stating that the code is behaving as intended, therefore not a bug.

 

 

 

It might be both, intented or a bug. You can not be sure until you have seen the code. The simple routine is so easy to make that i would say it is more a bug then a direct intention by the programmer.

[LukeFF]

1 minute ago, JG27_Steini said:

It might be both, intented or a bug. You can not be sure until you have seen the code. The simple routine is so easy to make that i would say it is more a bug then a direct intention by the programmer.

 

Dude, it's not a bug - I've asked the developers about this, and it's been stated that it's just the way things are coded right now. It's the same reason why you don't see things like parked planes being registered as killed on AI-only missions - they've not been accounted for in the code.

 

These are the parameters the game looks at when calculating kills on AI-only missions:

 

Average Plane Kills

Average Ground Kills

Average Balloon Kills (a holdover from ROF but will prove useful of course for FC)

Average Building Kills

Average Train Kills

Average Ship Kills

 

So, as you see, the Plane Kills category is very generic. So, in order to get more fidelity in the Average Plane Kills category, the code will need to be updated. But, is categorically not a bug the way things are currently coded.

[JG27_Steini]

1 minute ago, LukeFF said:

 

Dude, it's not a bug - I've asked the developers about this, and it's been stated that it's just the way things are coded right now. It's the same reason why you don't see things like parked planes being registered as killed on AI-only missions - they've not been accounted for in the code.

 

 

Thanks for the clarification. It is unfortunately one of the many things that have been done very lazy. One of the things that make me crazy is that every single hunting squadrons has destroeyd ships, uboats, factories etc. they simple give every pilot is simple (dump) statistic.

Edited June 20, 2021 by JG27_Steini

[Dakpilot]

47 minutes ago, JG27_Steini said:

 

Thanks for the clarification. It is unfortunately one of the many things that have been done very lazy. One of the things that make me crazy is that every single hunting squadrons has destroeyd ships, uboats, factories etc. they simple give every pilot is simple (dump) statistic.

 

Maybe it is a language thing. 

 

But saying it is very lazy would assume the programmer/coder was meant to do something a certain way  but decided to slope off and have a coffee and a smoke rather than complete a task. 

 

As I said it is probably just a language issue, but I have always had the feeling the team work very hard and go the extra mile, it seems a little insulting to see this 'lazy' word crop up multiple time (not just from you) 

 

-rant off-

 

Cheers, Dakpilot 

[jollyjack]

yep, i never got any impression that the IL2 crew is lazy: Steini, time for some well meant excuses!

[JG27_Steini]

6 hours ago, Dakpilot said:

 

Maybe it is a language thing. 

 

But saying it is very lazy would assume the programmer/coder was meant to do something a certain way  but decided to slope off and have a coffee and a smoke rather than complete a task. 

 

As I said it is probably just a language issue, but I have always had the feeling the team work very hard and go the extra mile, it seems a little insulting to see this 'lazy' word crop up multiple time (not just from you) 

 

-rant off-

 

Cheers, Dakpilot 

 

As a programmer i know that one can be very lazy in a single task doing it too simple. In this special case it would have been take only 1-2 minutes more to divide the +1 to a fighter plane or other targets. Now a random pilot gets +1 bomber, thats the most simple way to handle it. A better approach would be to find a routine to let pilots get more kills by their experience. It also would have been take 1min to program a case where a normal squadron would not been have destroyed several Uboats. When you understand my words that the WHOLE team is lazy that it is your fault, it was lazy in this case and other cases. Often the small things make a game great. Progammer make errors and bug, thats normal and if a well meant criticism triggers you, you should know that bug reporting make the game better and why should the team make better when we do not discuss problems. And you should know that many player play this game in SP mode and those little things ruins your immersion quickly. Maybe not for all, but for many enough. As LukeFF stated above the team is aware of those small weaknesses, probably many years ago.

Edited June 20, 2021 by JG27_Steini

[Dakpilot]

I am not a programmer (toand I certainly was not "triggered" lol)

 

Your experience in this field is greater than mine . The lazy programmer should have spent another 1 or 2 mins on his job...off to the gulag with the lazy bugger 

 

(Or maybe the situation is not so simple, I do not know)

 

Cheers, Dakpilot

 

[BraveSirRobin]

2 hours ago, JG27_Steini said:

 

As a programmer i know that one can be very lazy in a single task doing it too simple. In this special case it would have been take only 1-2 minutes more to divide the +1 to a fighter plane or other targets. Now a random pilot gets +1 bomber, thats the most simple way to handle it. 

Or it might not be that simple.  A change like that might cause other issues that you’re not aware of.  Because you haven’t seen the code.

[PatrickAWlson]

1 hour ago, BraveSirRobin said:

Or it might not be that simple.  A change like that might cause other issues that you’re not aware of.  Because you haven’t seen the code.

 

I am pretty sure that equipment is not accounted for in the campaign.  If that is the case then saying "Hans shot down a Yak"  should not have any ripple effects.  If there is no inventory then there is no obligation to remove a Yak from somebodies inventory just because you said Hans shot one down. 

 

But ... you might be right too.  I have worked in code that produces good business outcomes but, internally, is shockingly bad.  That "badness" usually manifests itself as difficulty in making seemingly simple changes.  It works ... just don't breath too hard on it  .  Hoping the 1C code is in better shape than that.  Based on the rate of modification that we see  seems to be.

[BraveSirRobin]

I’ve made plenty of changes that I thought would be simple and turned out to be quite difficult.

[JG27_Steini]

19 hours ago, BraveSirRobin said:

Or it might not be that simple.  A change like that might cause other issues that you’re not aware of.  Because you haven’t seen the code.

 

If the career mode would be complicated and takes hundred's of variable into account i would say you are right here. But the missions dont seem to have a variety in amount of planes. You can shot down 10+ planes each day and you can be sure the enemy brings full amount of planes back to the next mission. This might have been possible for the VVS but the Luftwaffen would not have had a chance to fill this gap. So it does not matter whether the +1 is an fighter/bomber/heavy bomber. If my pilots shoots down 4-6 planes each mission the +1 from an random AI makes no difference at all. Behinde the scene there might be some logic, but the kill type should be random, it would not break any rule. There several other examples of simple code in career mode.

 

1. Squadrons always starting with questionable statistics. 

2. Only 1 random pilots get's 1 bomber as kill.

3. Flight never follow an leader/wingman system. You dont have static leader or wingman. It is all random.

4. You dont have a static number/flight group you might use in the statistic to enjoy your own career and get used to your wingmen.

5. There is no simple kill list. 

6. Your plane settings are not safed you will alway redo your settings and will forget it sometimes.

 

Those are very simple tasks and easy to do for a talented team like 1C that can simulate plane aerydynamics. And yes, thatswhy i call it lazy, because i know what was archieved in extrem more complicated modules like AI, flight and damage modules.

Edited June 21, 2021 by JG27_Steini

[Dakpilot]

What you are talking about is workflow and priority not "lazy"

 

One thing has been obvious for many years now is that they make a plan and stick to it, perhaps to rigidly for many people, but they have their people and know what can be done in a Time frame. 

 

You may see it as lazy, but should this be ahead of fixing other 'easy' coding necessities, when things are too flexible you end up with terminal feature creep like Clod, releases are not on time and funding is cut, what you see as lazy is more likely necessary to keep the franchise alive, not in the perfect state that we all want, but at least still in existence and improving, with all our inputs we have less knowledge than them on what it takes to keep their company afloat, you/we may think we could do better.. But it is not laziness 

 

Cheers, Dakpilot 

[JG27_Steini]

45 minutes ago, Dakpilot said:

What you are talking about is workflow and priority not "lazy"

 

One thing has been obvious for many years now is that they make a plan and stick to it, perhaps to rigidly for many people, but they have their people and know what can be done in a Time frame. 

 

You may see it as lazy, but should this be ahead of fixing other 'easy' coding necessities, when things are too flexible you end up with terminal feature creep like Clod, releases are not on time and funding is cut, what you see as lazy is more likely necessary to keep the franchise alive, not in the perfect state that we all want, but at least still in existence and improving, with all our inputs we have less knowledge than them on what it takes to keep their company afloat, you/we may think we could do better.. But it is not laziness 

 

Cheers, Dakpilot 

 

You dont get it. It was make to simple (lazy) from the start. Now it is more complicated to include, the programmer might left the team or other reasons. The career mode system has not changed since 4 years, in comparison Patrick is programming more and more funtions in his free time. I dont call the team lazy, understand the difference and you will get what i mean. Even the best programmer makes functions too simple, thatswhy the code should be reviewed from to to time. Same thing as we have with all other modules. And the team had a lot of opportunities to do that. New functions come every half year (currently markings, logos, DM visualisation, drop tanks) so there would be to time review existing modules and solve those easy jobs.

Edited June 21, 2021 by JG27_Steini

[Dakpilot]

I think we are talking cross purposes here. 

 

I imagine the career code is left over from RoF times, and we don't know the circumstances when it was created. 

 

Only the team know how and when it is easy or possible to assign resources to certain aspects. 

 

I don't think I can add anything further to the conversation. 

 

All of us have improvements we prefer to be done ahead of others, but saying it is just 1 or two minutes of coding needs to be done and thus it is lazy that 'our' concern has not been attended to seems pointless without knowing the exact procedure within the company/team which none of us have. 

 

Out. 

 

Cheers, Dakpilot 

[JG27_Steini]

8 minutes ago, Dakpilot said:

I think we are talking cross purposes here. 

 

I imagine the career code is left over from RoF times, and we don't know the circumstances when it was created. 

 

Only the team know how and when it is easy or possible to assign resources to certain aspects. 

 

I don't think I can add anything further to the conversation. 

 

All of us have improvements we prefer to be done ahead of others, but saying it is just 1 or two minutes of coding needs to be done and thus it is lazy that 'our' concern has not been attended to seems pointless without knowing the exact procedure within the company/team which none of us have. 

 

Out. 

 

Cheers, Dakpilot 

 

You are right that we dont know, but if you take this example. Each time you kill a plane, you code that in a file/database. Next, we have a view that reads that database. Ready is your pilot log. A nice, short and very appreciate functions all simulations had from the very beginning. Estimated time for a skilled programmer/designer? I guess 2 day's. Code reviewing is important, but somehow the team likes to improve visualistions more than other modules.

[BraveSirRobin]

3 hours ago, JG27_Steini said:

 

If the career mode would be complicated and takes hundred's of variable into account i would say you are right here. But the missions dont seem to have a variety in amount of planes. You can shot down 10+ planes each day and you can be sure the enemy brings full amount of planes back to the next mission. This might have been possible for the VVS but the Luftwaffen would not have had a chance to fill this gap. So it does not matter whether the +1 is an fighter/bomber/heavy bomber. If my pilots shoots down 4-6 planes each mission the +1 from an random AI makes no difference at all. Behinde the scene there might be some logic, but the kill type should be random, it would not break any rule. There several other examples of simple code in career mode.

 

1. Squadrons always starting with questionable statistics. 

2. Only 1 random pilots get's 1 bomber as kill.

3. Flight never follow an leader/wingman system. You dont have static leader or wingman. It is all random.

4. You dont have a static number/flight group you might use in the statistic to enjoy your own career and get used to your wingmen.

5. There is no simple kill list. 

6. Your plane settings are not safed you will alway redo your settings and will forget it sometimes.

 

Those are very simple tasks and easy to do for a talented team like 1C that can simulate plane aerydynamics. And yes, thatswhy i call it lazy, because i know what was archieved in extrem more complicated modules like AI, flight and damage modules.

I’m just going to respond with a quote from a well known programming expert.

 

On 6/20/2021 at 1:46 AM, JG27_Steini said:

 

You can not be sure until you have seen the code.