Friday Update, January 27, 2012

[Flanker35M]

S!

So true Tvrdi But again no hardware will run a bad code no matter how you tweak it. Sometimes it feels that in these days of console porting being THE thing and coder relying on hardware getting stronger is a reason why we get crap codes that are buggy. I can be totally wrong, but why should a sloppy coder bother with optimizing his code when he can think that let the hardware crunch it. I bet not even today with all the high end hardware around their full potential is even used...

[LoBiSoMeM]

Originally Posted by Flanker35M

S!

So true Tvrdi But again no hardware will run a bad code no matter how you tweak it. Sometimes it feels that in these days of console porting being THE thing and coder relying on hardware getting stronger is a reason why we get crap codes that are buggy. I can be totally wrong, but why should a sloppy coder bother with optimizing his code when he can think that let the hardware crunch it. I bet not even today with all the high end hardware around their full potential is even used...

+1. Sad but true.

[tota]

As someone who is coding this really sets me up.
I think you simply cannot compare - 40 years ago you perhaps had the time to tweak and optimize a small piece of code, and working hard you could perhaps achieve a perfect, but very small tool.
The code base of Cod however must be HUGE, most of the work probably gets into just getting all the mess somehow organized, and it would take unimpossible amounts of manpower to do everything perfect. Complexity is the problem,not lazy or sloppy coders.... its just plain insulting to insinuate they would not care because of the available hardware.

Originally Posted by tota

As someone who is coding this really sets me up.
I think you simply cannot compare - 40 years ago you perhaps had the time to tweak and optimize a small piece of code, and working hard you could perhaps achieve a perfect, but very small tool.
The code base of Cod however must be HUGE, most of the work probably gets into just getting all the mess somehow organized, and it would take unimpossible amounts of manpower to do everything perfect. Complexity is the problem,not lazy or sloppy coders.... its just plain insulting to insinuate they would not care because of the available hardware.

Nobody said they are bad programers....but something went wrong (whatever it is) so we have what we have (OK now the sim is better than on release)...not that they had few weeks for coding and 3d models....

[ACE-OF-ACES]

There was a time that software coding could really impact performance.. Back in the assembly coding days.. I know I wrote a lot of assemble for a lot of different systems.. Once the higher level languages came out, the performance was very 'compiler' depended, and in a few cases a good assembly programer could write code that had better performance than what the 'compiler' provided.. But these days you would be hard pressed to write assemble code better than a 'compiler' could do it.. And with all the APIs and SDKs at your disposal makes it even harder to write 'bad' code unless the API and/or SDK itself contains 'bad' code. Thus the real issues these days is in how close to the edge of the envelope you want to code at.. As with the Microsoft DX11 API, One of the reasons CoD is defaulted to DX10 feature levels is because there were 'issues' with the DX11 feature levels in the DX11 API at CoD release time.. That is to say 1C was making use of DX11 feature levels in the DX11 API that were not that debugged yet (a Microsoft issue) thus 1C had to wait for Microsoft to fix those issues in the DX11 API before they could make use of those DX 11 feature levels, since that did not happen before CoD release, 1C limited the feature levels to DX10

[Flanker35M]

S!

Tota, the rant was not directed towards you nor was taking a stance on the state of CoD code when Luthier took over. It is easier to make bloated code than optimize and as you said, time is different.

But again as a coder you learn over the years how to be better etc. I can say I know a sh*tload more of my work now than when I started, routines have developed and knowledge to even evolve current ways of working and work packages are there. This same is applicable to coders as well, they for sure develop ways to do it better..or am I wrong?

And to add to this. We ALL know that Maddox Games had EIGHT years of previous knowhow on making a flight sim, the original IL-2. And there were other work Oleg was involved with but not in the limelight. No lack of knowhow there, right? So can you say CoD is efficiently made if 8 years of knowledge BEFORE starting CoD, which took 7 years to complete, would not teach anything?

I try to say that the team KNEW, and still do, what they were/are doing, had the experience and lessons from previous STILL living project to make CoD. Whatever happened behind the scenes is out of bounds to speculate, but frankly ask yourself this: How could they improve something already made to be even better, how to utilize knowhow from what has been done to make a product that stands head above the rest. Because IMO Luthier and team can not hide behind a curtain of not having experience nor not knowing what they were doing.

Not an attack against CoD dev team, but voicing my opinions. I wish and hope CoD and it's sequels will make it and be THE benchmarks of WW2 and beyond flight sims. Period.

[Blackdog_kt]

Originally Posted by zapatista

exactemundo !!

that is exactly the type of technical feature many other il2 old timers here are interested in, and it is incomprehensible they havnt given us access to at least some of these new features, even if it was initially with a basic interface at first and (with a list of the new features/options), so we know what is possible to access and control.

remember oleg's AA gun screenshots with the different ammo type boxes next to it ? at that time (some years ago), he indicated that when certain amo type ran out for the gun, it couldnt fire that type anymore (presumably till resupplied). Additionally the complex AA setup, with an interacting multiple component system involving search light, radar, gun crew, and ammo type available, so that if one element failed, or was destroyed by the enemy (like search light or radar element), it made the AA gun emplacement less effective, or put it out of action completely. Now THAT is what I call progress ! and it is what is needed to lift SoW out of the il2 airquake domain.

similarly discussions took place over the years with the SoW devellopers about what should happen when airfield munitions or fuels stores were destroyed (or runways damaged), and the way that should affect performance of that airfield and its ability to refuels and rearm aircraft landing there. once an airfield like that was made non operational, except for still allowing emergency landing of damaged or low on fuel aircraft, [b]it would/should take a certain amount of time for new supplies to arrive [/b (which is possible to copy fairly exactly from historical events, in the same way that restoring a damaged landing strip can determined).

AND those supplies had to arrive by road or rail normally (only very few came by air except some exceptional circumstances, like Stalingrad or Berlin). this again can be simulated fairly accurately, by having AI truck convoys of a particular size traveling at regular intervals on the road system from point A to point B, and having similar rail supply trains. targeting those in the game would then block the supplies from arriving at destination (for the time you keep being able to find and destroy them) when means the airfield they are designed for stays out of action or only operates partially. additionally, in certain map situations you might be able to cut rail and road bridges, or other parts of the transport network, with a similar result (again having work teams rebuilding those at a given time rate, and unless you keep destroying them regularly they become operational again). as a reminder, Mig Alley, the Korean war sim from 10 years ago already had a significant amount of those features built in, and it was one of the main reasons it stood out from other sims of the same era.

from oleg we know a lot of this, and even significantly more, is built into BoB/SoW, to not have some type of interface for it and no documentation for it is incomprehensible and a major flaw in 1C’s and luthiers management approach. it would set the sim apart from many other products right now, and it would make current users/customers much more tolerant of some of the major flaws they have to put up within the last year (and yes we are happy the project wasn’t canned, and if the buggy release was the only alternative to survival of the series let it be so)

this same AI interface should also provide details on how to control AI activity from road vehicles, rail network, and shipping (including AI bomber and fighter formations being tasked from point A to attack point B etc). ie rather then have some random train travel from A to B as me have now (or having a few people try and edit ini files with a hit and miss approach), we know this can/could be configured by some dedicated mission/campaign interface giving access in great detail for road/rail/sea/air elements active on a map. to have some basic instructions and information on these type of features is essential to keep the frustrated and shrinking fan base interested.

since most of those features are already built in, imo it should only take one or 2 programmers a couple of weeks to provide the documentation and a basic interface for it (even if some of those features are incomplete at this stage, many of them should already be available)

imo for luthier priorities right now should be
1) finish rebuild of gfx engine to get required gameplay performance and improved visual look of environment (he is doing this, but only 1 or 2 programmers are working on it i b suspect)
2) fix major FM DM problems that are know to be an isue right now, and fix distant object visibility problem (for aircraft and ground objects)
3) provide information and means to control ground/rail/airfield/aircraft resources, with implementation of some of these complex "roll on" effects once one element or important object of an airfield or other part of the map (like bridge or railway line) is damaged. Additionally, allow for basic AI routines to be created for vehicles on roads and at airfields, so the maps start to come alive. similarly allow scripting of ground military vehicle actions, eg have vehicle types ABC move to objective XYZ while having predetermined interaction modes with "object" they encounter (engage enemy, avoid enemy, capture objective etc)
4) correct some major scenery errors, and make england look like england rather then some generic map
5) provide full dynamic campaign engine for 24/7 online/ofline gameplay (with partially scripted unfolding events, as we know was olegs choice), so some of the events that historically made BoB so unique can be recreated, having for ex multiple waves of large bomber formations targeting specific objectives etc
only after that can there be talk of doing anything for BoM (other then maybe having some unemployed modelers work on some new objects if there is nothing else for them to do right now).

the only thing CoD is good for right now, is a limited type of airquake in a very buggy gameplay setting, while trying to move around in a virual world in an underperforming gfx engine, its a far cry from what was intended or anticipated, so they need to fix some of these issues SOON !

I can mostly agree with your vision of the sim, but let's not move this back into "it's all their fault!" territory

If we are to be honest with ourselves, at least half of the mess is the community's fault too: the people who ask for such features that you and i expect are much less than the people who are mighty upset about graphic issues (and i don't mean valid performance/stability issues, but simply aesthetic issues).

We all remember the fuss about DX11 before release, now we see people speculating about how it might have been better to stay with OpenGL. Well, imagine you are the project manager and have to keep this community happy, it's impossible because everyone has different priorities and some even ask for completely opposite things.

I think that as long as they keep working on it and they have the cash to keep doing it, we will get a sim worthy of the legacy of the previous series.

I wish it wasn't like this, but that's how things go with sims these days: if you don't have military customers to pay for a sim that you can then take the top-secret stuff out and release to the public (like DCS) or sell individual add-ons for high prices (civilian flight sim add-ons and some train sims), you are going to release what you have and hope you have enough money to keep working on it.

I mean, look at RoF. It took 18 months after the release to get it where it is and it's a simpler engine in some aspects (ballistics for all guns are very similar, not so many ammo types, lower object limits per mission, reduced dot visibility ranges, etc), either by restriction or optimization because it can(eg, since the speeds/distances involved are smaller, there is less need for a high air to air spotting distance).

CoD can handle (or at least, it's supposed too) a couple thousand ground objects in a single mission, visibility range needs to be higher, etc, etc, so it's no wonder it's a tough job.

The good thing is that the hard part seems to be behind us. When the next patch is released and performance/stability optimizations are finally complete, we can then start moving onto the stuff that has added gameplay value: fixing the control logic inconsistencies and control bugs in all aircraft and correcting the FMs, so we can start to fly raids of 20 bombers or more online and have some serious fun

[Force10]

Originally Posted by ACE-OF-ACES

There was a time that software coding could really impact performance.. Back in the assembly coding days.. I know I wrote a lot of assemble for a lot of different systems.. Once the higher level languages came out, the performance was very 'compiler' depended, and in a few cases a good assembly programer could write code that had better performance than what the 'compiler' provided.. But these days you would be hard pressed to write assemble code better than a 'compiler' could do it.. And with all the APIs and SDKs at your disposal makes it even harder to write 'bad' code unless the API and/or SDK itself contains 'bad' code. Thus the real issues these days is in how close to the edge of the envelope you want to code at.. As with the Microsoft DX11 API, One of the reasons CoD is defaulted to DX10 feature levels is because there were 'issues' with the DX11 feature levels in the DX11 API at CoD release time.. That is to say 1C was making use of DX11 feature levels in the DX11 API that were not that debugged yet (a Microsoft issue) thus 1C had to wait for Microsoft to fix those issues in the DX11 API before they could make use of those DX 11 feature levels, since that did not happen before CoD release, 1C limited the feature levels to DX10

I'm sure quite a few folks wish 1C optimized the code a little better for DX9 since DX11 was off the table for the time being. Right now, running the sim in DX9 performs worse than DX10. It might have helped people with more mid-range hardware fly the sim with better results.

[robtek]

Originally Posted by Force10

I'm sure quite a few folks wish 1C optimized the code a little better for DX9 since DX11 was off the table for the time being. Right now, running the sim in DX9 performs worse than DX10. It might have helped people with more mid-range hardware fly the sim with better results.

DX9 doesn't mean it runs faster than DX10.

DX10 is the optimized and extended DX9 in the end.

And finally, when you program for the future it's contraproductive to go to the past, you stay with the present and from there on.

[Codex]

Originally Posted by Flanker35M

S!

Tota, the rant was not directed towards you nor was taking a stance on the state of CoD code when Luthier took over. It is easier to make bloated code than optimize and as you said, time is different.

But again as a coder you learn over the years how to be better etc. I can say I know a sh*tload more of my work now than when I started, routines have developed and knowledge to even evolve current ways of working and work packages are there. This same is applicable to coders as well, they for sure develop ways to do it better..or am I wrong?

And to add to this. We ALL know that Maddox Games had EIGHT years of previous knowhow on making a flight sim, the original IL-2. And there were other work Oleg was involved with but not in the limelight. No lack of knowhow there, right? So can you say CoD is efficiently made if 8 years of knowledge BEFORE starting CoD, which took 7 years to complete, would not teach anything?

I try to say that the team KNEW, and still do, what they were/are doing, had the experience and lessons from previous STILL living project to make CoD. Whatever happened behind the scenes is out of bounds to speculate, but frankly ask yourself this: How could they improve something already made to be even better, how to utilize knowhow from what has been done to make a product that stands head above the rest. Because IMO Luthier and team can not hide behind a curtain of not having experience nor not knowing what they were doing.

Not an attack against CoD dev team, but voicing my opinions. I wish and hope CoD and it's sequels will make it and be THE benchmarks of WW2 and beyond flight sims. Period.

I agree with what you're saying Flanker but there is the other side of the coding environment which I call tunnel coding (i.e. tunnel vision). It's the type of coding mindset you can get into when you're so focused on a project for so long that you can (not saying you will) loose the ability to try new ideas and / or direction when coding for the same problem. It's soooo prevalent in the gaming world that you can see it. Case in point CoD's AI, to me it's almost a straight copy and paste from IL-2. Unreal Engine, only now has it got DX10 features, Bethesda's combat system (Skyrim / Fallout), pretty much unchanged since Elders Scrolls came out.

It's a catch 22 as well in terms of trying something new, because trying new ideas means increase development time and costs, and if I were investing in a game I'd be saying "if it ain't broke don't fix it, just improve it". The majority of CoD is a complete departure from the old engine, but there is still a lot of IL-2 1946 in there as well, and it's a monumental task in front in front of Illya and the team.