1.11 Patch Update, 18 Oct 05

[Wags]

Today the test team was given version 08 of the 1.11 patch. In version 07, a severe problem when exiting a multiplayer mission was discovered and there were some issues with MP messages being sent incorrectly. Hopefully 08 will be a release.

 

-Matt

[NEODARK]

Cool, cant wait for final :)

 

thanks for the heads up.

[Maulkin]

Thanks alot Wags for keeping us informed of the progress. It feels good to see things moving forward and I am really glad you guys found that MP bug. Keep up the great work, and fingers crossed on the latest version.

[Guest ThomasDWeiss]

Thanks. :)

[Sleek]

:icon_jook :D

[kydius]

Good to know that, thanks Wags!

[ViperVJG73]

"Hopefully 08 will be a release." Yea............! ;)

[Pilotasso]

Just a small regard here:

 

when you guys change the code to do the thing Y why does its instructions mess up with things X, Z, W?

 

When I programed numeric methodology (mathematics of interpolation and analisys of error) on pascal I seperated each family of actions into seperate procedures ("blocks" or subprograms) so if I needed to correct a bug in the Y thing, X,Z and W things wouldnt be ramdomly messed up...

 

Ity apears that in LOMAC a bit of everything is mixed together.

 

EDIT: speaking of sub programs; I noticed while programing my EXE's (and I made a few CPU killers)

that an organized subprogram flowchart not only looks nice, not only its alot easier to debug, but it runs like 2 ,3 or even 4 times as fast. Gives alot to think doenst it?

[Maulkin]

Just a small regard here:

 

when you guys change the code to do the thing Y why does its instructions mess up with things X, Z, W?

 

When I programed numeric methodology (mathematics of interpolation and analisys of error) on pascal I seperated each family of actions into seperate procedures ("blocks" or subprograms) so if I needed to correct a bug in the Y thing, X,Z and W things wouldnt be ramdomly messed up...

 

Ity apears that in LOMAC a bit of everything is mixed together.

 

EDIT: speaking of sub programs; I noticed while programing my EXE's (and I made a few CPU killers)

that an organized subprogram flowchart not only looks nice, not only its alot easier to debug, but it runs like 2 ,3 or even 4 times as fast. Gives alot to think doenst it?

 

I am pretty sure they would have to use some kind of psuedo coding style to tackle a complex project like this. And while modular programming is very useful to minimize cross-referenced bugs you are still going to have dependancies. This is very common with projects that are very large with many developers working on it at once. It is too large for one person to be able to know every single detail.

 

I have worked as a designer for 5 years and 10 years as a validation engineer (fancy name for 'tester') in the telecom market and it is a very common occurance for one bug I find to be fixed but in turn causing something else to break.

[Brit_Radar_Dude]

Pilotasso - in theory you are quite correct in what you said, and for the reasonably small scale programming you did - can also be true in practice.

 

Whilst software developer try their best to take the same programming methodology into large scale software projects (like Lomac), it isn't quite so successful. As soon as you have more than one person working on the project, then wave theory goodbye because then you have all the problems involved in organising people as well.

And you can increase it by a big factor when you are dealing with real-time software projects. I know - I have been doing it for over 20 years on various telephone exchanges, military and ATC radars, military comms, etc.....

[Olgerd]

Just a small regard here:

 

when you guys change the code to do the thing Y why does its instructions mess up with things X, Z, W?

 

When I programed numeric methodology (mathematics of interpolation and analisys of error) on pascal I seperated each family of actions into seperate procedures ("blocks" or subprograms) so if I needed to correct a bug in the Y thing, X,Z and W things wouldnt be ramdomly messed up...

 

Ity apears that in LOMAC a bit of everything is mixed together.

 

EDIT: speaking of sub programs; I noticed while programing my EXE's (and I made a few CPU killers)

that an organized subprogram flowchart not only looks nice, not only its alot easier to debug, but it runs like 2 ,3 or even 4 times as fast. Gives alot to think doenst it?

 

Everything in system code can influence on everything in applied code. One small change can affect many other parts of the program when you change core things. We had to do this while fixing some bugs in the patch code.

[Bug11]

especially when using things like global variables where local variables should be used and no 'data dictionary' is maintained to prevent such things happening.

[bflagg]

it's nice to know the status of the patch...

 

thank you

[Olgerd]

especially when using things like global variables where local variables should be used and no 'data dictionary' is maintained to prevent such things happening.

 

I am speaking about more speciphic things like 'objects storage types and hangling' or 'methods of LAN units initialization' etc...

[Pilotasso]

thanks for you kind replies. OK, Im going to expand the focus of my previous post by saing this:

 

I think its not quite a complexity problem that dictates "messy programming"

Might be time deadlines, team funding and organization. I remenber a long time ago a professional software designer walked on these forums and stated that game programers usualy didnt have advanced degrees on software, rather that they know how to program but not exactly know the system in a way that would allow them a more efficient program.

 

And I think about realy proffessional military SIM developers such as:

http://www.es.com/ (also posted here a few weeks ago)

Could be that RISC processors work much faster (Im not a digital electronics wiz, are these used?) but those programs simply run much better. The example I showed, just looks amazing too (someone ranted LOMAC's looked better but I dont think so)

 

Theres no memory leaks no stuttering no nothing. Any obvious lack of perfomance related bugs are surely ironed out. I mean Im willing to bet their programing is much more organized in the way I said than LOMAC.

 

Im not comparing the 2 directly since these SIM's run on totaly different machines because in the proffessional SIM's you need the hardware to cope with large polygon and object count. Im rather referring to relative efficiency. Since on both cases youll get all the detail as each machine can muster, but the concept and essence are basicaly the same.

[ALDEGA]

It isn't surprising in any software that has any level of complexity.

[BBushe]

Just a small regard here:

 

EDIT: speaking of sub programs; I noticed while programing my EXE's (and I made a few CPU killers)

that an organized subprogram flowchart not only looks nice, not only its alot easier to debug, but it runs like 2 ,3 or even 4 times as fast. Gives alot to think doenst it?

 

yep, it does give me a lot to think about. Like when I was programming also in pascal by coincidence) I knew that a flowchart is used for only small programs, other types of charts are used for real programs. How big was were your programs? I have no idea how big LOMAC is but I would guess it's several million lines of code, thousands of subroutines, and more variables than the weather. Add to that a number of different coders, with their unique style of coding and annotating (if you're lucky) and you've got a major nightmare job on your hands.

 

I'm pretty sure they have sub-modules, son of sub-modules, and son of daughter of nephew of great-grand-niece thrice removed-modules. I'm not having a swipe Pilatasso, but you are comparing building a house (no small underaking) to building a city.

[Floyd]

EDIT: speaking of sub programs; I noticed while programing my EXE's (and I made a few CPU killers)

that an organized subprogram flowchart not only looks nice, not only its alot easier to debug, but it runs like 2 ,3 or even 4 times as fast. Gives alot to think doenst it?

 

This theory reminded me of ... this:

 

http://www.heuse.com/cphumor.htm

 

and now for my German speaking friends

 

Es steht dort im Prozessorfeld

Seit kurzem ein Professorzelt.

Davor sitzt ein Professor

Und braet einen Prozessor.

Da kommt ein Rechnerarchitekt

Und fragt ihn, ob der Chip denn schmeckt.

Da laechelt der Professor:

Nur Software schmeckt noch besser.

 

Don't _EVER_ lose your sense of humour !

[adi-Michael]

FINALLY!! Wonderfull test team! GOOD WORK!

[Pilotasso]

especially when using things like global variables where local variables should be used and no 'data dictionary' is maintained to prevent such things happening.

 

You will ALWAYS have global variables. Thing is you should use these to join up the subprograms together not managing what each suprogram does inside.

[Maulkin]

Here is an example where your modular programming still wont help you and I wont reference the obvious one of using globals in code (which is, by definition, not modular).

 

Lets say you are designing one module and for efficiency and speed you use memory pointers. You decide to add in a more complex model which will now require an addition 8 bits to a given allocated memory space. At the same time another designer, who is unaware of how you plan on solving your challenge, creates a pointer to the same 8-bit memory space. You end up with a race condition where both modules, probably unrelated to eachother, end up trampling eachothers data.

 

Or even more funny when someone uses an object type and then passes that back to the calling procedure only to have another procedure reference that value as a different object type.

 

There are lots of ways modular programming can have cascading errors.

[Floyd]

Theres no memory leaks no stuttering no nothing. Any obvious lack of perfomance related bugs are surely ironed out. I mean Im willing to bet their programing is much more organized in the way I said than LOMAC.

 

So, if you're willing to pay the price of this fabulous program - go and get it!

It's always

Quality - Cheap - Time

and you can choose only 2 of 3 ;-)

[golfsierra2]

And you can increase it by a big factor when you are dealing with real-time software projects. I know - I have been doing it for over 20 years on various telephone exchanges, military and ATC radars, military comms, etc.....

 

Think ACCS ???!!!!

[Pilotasso]

How big was were your programs?

 

I rarely counted the lines in my programs (booooring!), but one time I did, and I counted like in excess of 500 lines of code...about 250 KB in total size

 

I have no idea how big LOMAC is but I would guess it's several million lines of code, thousands of subroutines, and more variables than the weather. Add to that a number of different coders, with their unique style of coding and annotating (if you're lucky) and you've got a major nightmare job on your hands.

 

..maybe, but remenber the total lines of code in the game are counting all the other files apart from the EXE suchs as DLL's graphics interphace and even 3D model action. The LOMAC EXE is slighly less than 4 MB,certainly much less than million lines of code, and I think most bugs come from it. Just check the size of each LOMAC EXE version. All Dll's are pretty small and each does a specialized task judging by their names.

Given the size of my programs (example above) it would require about 16 people to work 10 hours (I made that one on 1 day) to do the same amount of data. Of course Im not comparing the overall difficulty level of programing flight dynamics and numeric methodology.

 

 

I'm pretty sure they have sub-modules, son of sub-modules, and son of daughter of nephew of great-grand-niece thrice removed-modules. I'm not having a swipe Pilatasso, but you are comparing building a house (no small underaking) to building a city.

 

No problem I fully understand what your trying to say. I just hoped some day someone would pick a task for each team menber to do a subprogram for each aspect of the SIM. It would require to get better organized. Someone would have to keep track of variables that are referred externaly to other subprograms and then mingle it together. Even if thats not possible in the purist terms I put it, it would be an investiment not a cost to converge to this methodology.

[Maulkin]

Of course Im not comparing the overall difficulty level of programing flight dynamics and numeric methodology.

 

Dont you mean your not comparing the overall difficulty level of programming flight dynamics, user interface, network communication, AI, and graphics engine to numeric methodology? ;)

 

Just so you understand Pilotasso I am not trying to slam you at all. Understand that these kind of bugs are very common, even in medium sized projects, which is why the testing process has what is called 'regression testing' to minimize the chance that bugs like that dont slip through.