A few kinda strange questions for Don and Andy...

[MarkSheppard]

I've always wondered about a few things on the entire SPCAMO project; perhaps you guys could help answer a few questions of mine (as long as they don't violate the agreement you signed with whoever controlled the Steel Panthers code and name; there have been so many acquistions and sales of old gaming names that it's hard to keep track of them all)

How did the guys at SSI contact you and give you the source code, and what format did it arrive in? Did you get CDs full of the stuff or what?

Did you guys have any programming experience before you started this project, or did you "learn on the job"?

How does the SPCAMO team work in regards to improvements for the game? Do you poll the team on what improvements they'd like to see in the next version, and then get coding on the feasible requests? E.G. where do the ideas for these new terrain types come from?

I apologize in advance if some of these questions sound a bit rude or unorthodox; but I've always been interested in how things are made, and how decisions are made in the process of making something e.g. Wide-Body on the design and development of the 747, and a book whose name escapes me at the moment about the development of the original Ford Taurus.

[DRG]

It's a long story. Here's the short version

The code arrived burned on a CD

Andy is a professional programmer. He's worked in just about everything up to and including defence related work. I " "learn on the job". Most of the Terrain work is mine and all the rest is Andy

Sometimes we ask for ideas, Sometimes we have a few dozen of our own and work from that. Sometimes they come from forums like this

Don

[JaM]

Don,i have one question, will there be a updated version of WinSPMBT, with new functions from WinSPWW2? (core unit delete etc...)

keep up good work, thanks that you keep my favorite game alive

[DRG]

Yes there will be an update of WinSPMBT

Don

[PatG]

While contemplating the .45 vs 9mm SMG section of the MG thread, two thoughts occurred to me. The first is that, as discussed many times before (especially by non-coders like me), many problems with armour thickness, weapon accuracy and other seeming inconsistencies could be fixed by using a larger variable in the code to hold values.

The second thought was the staggeringly enormous amount of work that would be required to check the type of every instance of every variable, re-work all the algorithms and redo all the bounds checking routines.

So in order to give us non-coders some idea of what it means to try and differentiate between 4mm and 8mm armour class 1 vehicles and M3 - MP40 SMG accuracy, my question is: In terms of orders of magnitude (1,000s, 10,000s, 100,000s), how many lines of code are there?

[Mobhack]

The source (CPP and H) is over 6Mb for all the sub projects.

The problems with using a larger variable in legacy code are legion. This code was written in the 90s to fit 386 PCs with 1MB memory, and where disk access was slow, and in any case MSDOS did not provide disk paging virtual memory swap file like windows does. So bytes and so on are common. Object oriented code not used, as back then the space for OO bloated things too much.

Simply changing variabl X from an unsigned byte in the main header file solves no problems, your problems have just started!

- If this variable forms part of any saved memory structure (save game files, OOB files etc), then you have just rendered all these data toast. You will have to build and test some sort of data-massage utility to convert all these files. Bad enough for all the stuff you have control of, but you have no control over any third-party stuff (scenarios, OOBS etc) out in the field.

- You then have to find out everywhere this variable is used, e.g. stuffed into a temporary holding variable, or passed as a parameter from some routine to a subroutine, and ensure these are appropriate. If not, you have to change these, and then recompile and find all the other things that call these subroutines and are now broken. Follow the chain into the subroutines, and check these for temporary holding variables and so on and repeat recursively. Be careful to check that any places it gets stuffed into are correct for signed or unsigned.

- Now check everywhere this variable (and any changed local copies) are used for maths routines, and bitwise logic operations and so on, check any bitmasks used etc. Check any "safety" code used on this inside routines for upper or lower bound tests. Now it is bigger, any result variable may need to be increased to fit. This can have yet more knock-on effects, especially if that result variable was say a global that is referred to in 9,999 other places and if you change the size, these routines all need fixing.

- Any variables that had to be changed to accomodate the knock-on effects of the changed variable need to be checked as if they were this new variable, and subroutines etc, and anything depending on these. If the variable(s) have file storage effect you need to add this to your data massage exercise.

- Assuming you have all these fixed (changing something is like snapping one link in a spider web. Sometimes one link is affected, sometimes it affects everything), you now need to check all your file i/o routines. Also - if this variable is something that can be input by the user (say in the scenario designer perhaps) - check all the UI I/O routines for that as well to ensure the correct conversions, upper and lower bounds checks and so on.

- Now check all your memory allocation (mallocs callocs, news etc) for things like file block data allocation etc.

- Oh joy!, your variable is now bigger. So if it is displayed anywhere in the User Interface you may now need to allocate more column space for it to allow for this. Maybe the extra space will fit the UI no bother, but be prepared to have to completely or at least partially rewrite some parts of the UI that require a new screen layout to accomodate the extra few columns due to lack of space. Fix and test UI, and if needed update any end-user documentation. (Changes involving any rearrangement of the game UI will probably take a lot of time. It is not forms-based, like say Delphi or C++ Builder is for Windows apps like the GameOptions launcher

- Now, repeat the exercise for all the utility programmes like Mobhack, map editor and so on. Remember that Mobhack uses Delphi (started as Turbo Pascal back in 95 ods, then Borland Pascal for Windows, then Delphi) as opposed to C++.

- Do some unit testing yourself. Fix any problems. Then release to playtesters, and see what unexpected side-effects arise. Fix any new problems. rinse, repeat as required. Build release package and issue to end users. End users will probably find cases the pre-release playtesting failed to spot..

That is about it for upsizing one variable. nothing for actually changing any algorithms using it (that is a "how long is a piece of string" sort of thing

Cheers
Andy

[MarkSheppard]

Wow Andy, That's a very comprehensive answer.

[Marek_Tucan]

I have to say that though my experiences with the programming are only small I have already been in a situations when I had "just to change one number" ending with a completely rewritten code And that meant some 100 lines, and even then it was often rather hard to keep everything running even after the change - in fact it'd be simpler to rewrite it from scratch... Well, maybe that was our professor's point

[PatG]

Thanks as well Andy. Your very comprehensive answer might need to go into a sticky faq thread somewhere.