Network branch merge

[daniel.santos]

I'm merging my most recent changes with the source forge network branch, hurray! =)  And I have some questions for Silnarm:

I see you've refactored lots of small things (includes & such) and it would help if I could chat with you in IRC or something.  It would appear that the bulk of the changes are for windows compatibility and also some removal of includes, I presume that aren't needed. Along the lines of refactoring, the project definitely pulls in too many includes, causing a lot of things to recompile when you change header files (more than should be, and some of that is probably my fault too

Mostly, I'm looking at the changes between revisions 34 and 139 in the network branch.  Further, please make sure you set "svn:eol-style" to "native" on any new text files you check into the repository so it plays good across platforms (I fixed this on the network branch, but not any of the others yet).

EDIT: Oh, the multiply-defined symbols in the STRINGY_ENUMS is because you removed the "#define GAME_CONSTANTS_DEF" and added GAME_CONSTANTS_DEF to game/game.vcproj's PreprocessorDefinitions and it's not intended to be global.  The way this works is that you define GAME_CONSTANTS_DEF when you include game_constants.h *once* and you do not define it the rest of the time -- that was the cleanest solution I could come up with and still use the STRINGY_ENUMs, which I rather liked.

EDIT #2: We can't remove the "protected:" from line 132 of shared_lib/include/platform/socket.h.  If something else needs access to those members, it should be incorporated in some way that maintains proper encapsulation.  I don't like the idea of a getSocketObject() method that returns the SOCK field, but I would rather that that making it public! =)  The ideal mechanism would be to implement them in the Socket class(s) or add a friend class.

[silnarm]

I see you've refactored lots of small things (includes & such) and it would help if I could chat with you in IRC or something.  It would appear that the bulk of the changes are for windows compatibility and also some removal of includes, I presume that aren't needed. Along the lines of refactoring, the project definitely pulls in too many includes, causing a lot of things to recompile when you change header files (more than should be, and some of that is probably my fault too

Yeah, the changes should have just been to get it to compile, a couple of things I should have mentioned:
I took some care to make sure I was getting the correct equivalents, but with the link problems I gave up trying to run it fairly early, so no guarantees  
Also, at first, I was just trying to get it to compile... somewhere along the way I started thinking about where this platform specific stuff should be, and putting it in the right place. There'll be plenty of stuff from the earlier period that is probably not in a very appropriate location.

I'll make sure to be on IRC this weekend, I'm busy tonight (Friday), but I've got almost a whole days head start on you I'll be on from Saturday morning, which should be Friday night for you (at least I think, I haven't done the math).

The removed headers was my first (naive) and only attempt to solve the multiple defs, everything did compile without them though, so it appears the weren't needed  
Rest assured, I'll be inadvertently adding my share too Would be nice to go through and cull what we can.

EDIT: Oh, the multiply-defined symbols in the STRINGY_ENUMS is because you removed the "#define GAME_CONSTANTS_DEF" and added GAME_CONSTANTS_DEF to game/game.vcproj's PreprocessorDefinitions and it's not intended to be global.  The way this works is that you define GAME_CONSTANTS_DEF when you include game_constants.h *once* and you do not define it the rest of the time -- that was the cleanest solution I could come up with and still use the STRINGY_ENUMs, which I rather liked.

Ok, I think I did that because I was getting unresolved externals... Yeah, I've just built it with it defined and then undefined in game_constants.cpp, and it gives unresolved externals for the EnumNames.

EDIT #2: We can't remove the "protected:" from line 132 of shared_lib/include/platform/socket.h. ...

Yeah, sorry... if you hadn't figured already, I'm the 'get it going, any old how first, then get it going properly' type. I frequently make things public for debugging purposes and forget...

[daniel.santos]

ok, I got it merged and compiled, but I haven't tested yet.  If you are still getting the unresolved thing, then it may be due to game_constants.h getting into the pre-compiled header when we don't want it to?  Anyway, so you are in Melbourne, I'll figure out the math for that.  But your sunday morning will be my Saturday night, I think....  To be honest, I didn't analyze what you did too much, I just accepted most of the changes, I think I only rolled one of them back because it broke something else.  I'll follow up later with details on how it goes.

EDIT: Oh yea, at least until we have a pretty setup program, I would prefer to link everything statically on windows, so maybe change the zdll.lib back to zlib.lib?  And here I'm presuming that zdll.lib is the dll implementation of the zlib.  I think zlib is pretty tiny anyway.  Like you said, half of the current executable is xerces-c!

[Coldfusionstorm]

, wait, does this mean....

_lowers his voice_

new netcode soon?

_candles are lit in my eyes_!