CODE/PROJECT: New files=New .dsw file?

[MrBaggins]

A couple of the changes I'm making require a couple of new files, for a new class. I'm not sure if this has been done before, its not apparent from a brief scan of the altered source files.

If we add new files to the project (or workspace), then we should also distribute the workspace file, right? Anyone see any issue with this?

[Martin Gühmann]

There is one instace of a new file, the japanese.h, I don't know how 4thmoon handled it, but he added a japanese project file.

If I understood it correctly it requires a modified *.dsp file, and unfortunatly my version of VC++ 6 is not a full version and has a problem to read the path in the path variable I defined in the autoexec.bat. So I would need to change the file manually again.

-Martin

[MrBaggins]

Looks like you need both files... dsp & dsw.

[Martin Gühmann]

Originally posted by MrBaggins
Looks like you need both files... dsp & dsw.

That's not very comfortable for me, but sooner or later we have to add files, for instance it would also a good idea to replace the old database format of the civilisation database by the new one or RiskDB, DiffDB, ColorsDB, MapDB and maybe also ConstDB.

So I have to swallow the bitter pill.

-Martin

[ctplinuxfan]

Hi,

i also intented to add some files (e.g. a plugin replacement more portable).

Unfortunately, VC++ screws up dependencies, e.g. files were removed within the clean rules of gs/newdb, that's why i didn't post these additions yet, and these changes cover all projects except dbgen...

So I would need to change the file manually again.

My VC++ has the same problem. I replaced $(CDKDIR)\ by $(WkspDir)\..\..\bin\ in the workspace files. Unfortunately, i had to do this within VC++ for each target file and each target, because VC++ does not load workspace files you changed with unix tools like sed

replace the old database

If you mean gs/newdb i don't think that's a good idea. The main advantage of this implementation is a common codebase, i.e. decreased bug possibility. O.k., it's annoying if you have the authors edition of vc++ and need to confirm a popup coming up for each .cdb file... ;-)

For redesign, you can consider a lot of things, to either reduce bugs/bug possibility or increase performance:

• reducing use of objects
• stopping to pass temporary objects around
• event manager (using non pod-types for va_list args)
• avoid changing method parameters (passed by call by value)
• instance lifetime model (fixing memory leaks, etc.)
• reducing inter-class dependencies
• removal of changes to const char *& references
• using references where possible
• avoid unique names (like GUID GUID...)
• centralize initialization (sound/cd/legal cd check etc.)
• removal of dead code

However, if you consider a bigger redesign, a #ifdef ACTIVISION_ORIGINAL guard scheme tends to become impractical, maybe confusing

Ciao
Holger

[MrBaggins]

The main advantage for switching the rest of the old constant data records to the new style is that the parsers would be dynamically generated.

Right now... you can't change constdb without rewriting the parser, for instance, which is a little bit of a PITA.

I believe the big bit of missing functionality, and why they (maybe) didn't switch the other records over was that the old classes had serialization functions.

If we implement them for the new style then we should be able to switch them over without too many issues.

[Martin Gühmann]

Originally posted by ctplinuxfan
If you mean gs/newdb i don't think that's a good idea. The main advantage of this implementation is a common codebase, i.e. decreased bug possibility. O.k., it's annoying if you have the authors edition of vc++ and need to confirm a popup coming up for each .cdb file... ;-)

No, gs/newdb as its name suggests is the new database, not the old one, the old databases are the ones I mentioned above. And as MrBaggems mentioned the reason why I want to switsh also for the remaining databases is that with the new style database addions are done easily.

Well for the ThroneDB the main reaon is that they didn't switch is rather that the throne room in CTP2 is missing, maybe we should it rename to PalaceDB and the according text file Palace.txt, as I prefer a palace, or we could make it optional palace or throne room.

-Martin

[ctplinuxfan]

Hi,

sorry, seems i misunderstood something.
Moving the other dbs to the new db is of course a good idea.

Ciao
Holger