Found and corrected bugs in 3.2.1

[softcoder]

My family and I have been playing (and creating our own factions) for the past number of months. Since v3.2.1 (we use the linux version in Ubuntu 8.10) we noticed when playing on our LAN with 3 players that we get numerous crash scenarios or corrupt game starts. After spending a long time debugging I have found a few items that the authors should possibly look at in order to fix these:

1. Firstly there seems to be a random timing issue when opening a socket (not sure if this is linux specific). I added some retry code to allow glest to not crash but simply wait until the socket is available:

Code: [Select]

void ClientSocket::connect(const Ip &ip, int port){
sockaddr_in addr;
memset(&addr, 0, sizeof(addr));

    addr.sin_family= AF_INET;
addr.sin_addr.s_addr= inet_addr(ip.getString().c_str());
addr.sin_port= htons(port);

int err= ::connect(sock, reinterpret_cast<const sockaddr*>(&addr), sizeof(addr));
if(err < 0) {
    char szBuf[1024]="";
    sprintf(szBuf,"#2 Error connecting socket for IP: %s for Port: %d err = %d errno = %d [%s]",ip.getString().c_str(),port,err,errno,strerror(errno));
    fprintf(stderr,szBuf);

        if (errno == EINPROGRESS) {

            fd_set myset;
            struct timeval tv;
            int valopt;
            socklen_t lon;

            fprintf(stderr, "EINPROGRESS in connect() - selecting\n");
            do {
               tv.tv_sec = 10;
               tv.tv_usec = 0;

               FD_ZERO(&myset);
               FD_SET(sock, &myset);

               err = select(sock+1, NULL, &myset, NULL, &tv);

               if (err < 0 && errno != EINTR) {
                  sprintf(szBuf, "Error connecting %d - %s\n", errno, strerror(errno));
                  throwException(szBuf);
               }
               else if (err > 0) {
                  // Socket selected for write
                  lon = sizeof(int);
                  if (getsockopt(sock, SOL_SOCKET, SO_ERROR, (void*)(&valopt), &lon) < 0) {
                     sprintf(szBuf, "Error in getsockopt() %d - %s\n", errno, strerror(errno));
                     throwException(szBuf);
                  }
                  // Check the value returned...
                  if (valopt) {
                     sprintf(szBuf, "Error in delayed connection() %d - %s\n", valopt, strerror(valopt));
                     throwException(szBuf);
                  }

                  errno = 0;
                  fprintf(stderr, "Apparent recovery for connection sock = %d, err = %d, errno = %d\n",sock,err,errno);

                  break;
               }
               else {
                  sprintf(szBuf, "Timeout in select() - Cancelling!\n");
                  throwException(szBuf);
               }
            } while (1);
        }

        if(err < 0)
        {
            throwException(szBuf);
        }

        fprintf(stderr, "Valid recovery for connection sock = %d, err = %d, errno = %d\n",sock,err,errno);
}
}
2. The random corrupt startups occurs due to an incomplete NetworkMessageLaunch message sturcture. This structure does not contain 3 additional booleans that exist in the gamesettings class and therefore some network players start with 0 resources and/or units. I corrected that by modifiying the NetworkMessageLaunch class:
Added these 3 missing booleans:

        int8 defaultResources;
        int8 defaultUnits;
        int8 defaultVictoryConditions;

like this:

Code: [Select]

class NetworkMessageLaunch: public NetworkMessage{
private:
static const int maxStringSize= 256;

private:
struct Data{
int8 messageType;
NetworkString<maxStringSize> description;
NetworkString<maxStringSize> map;
NetworkString<maxStringSize> tileset;
NetworkString<maxStringSize> tech;
NetworkString<maxStringSize> factionTypeNames[GameConstants::maxPlayers]; //faction names

int8 factionControls[GameConstants::maxPlayers];

int8 thisFactionIndex;
int8 factionCount;
int8 teams[GameConstants::maxPlayers];
int8 startLocationIndex[GameConstants::maxPlayers];
int8 defaultResources;
        int8 defaultUnits;
        int8 defaultVictoryConditions;

};

private:
Data data;

public:
NetworkMessageLaunch();
NetworkMessageLaunch(const GameSettings *gameSettings);

void buildGameSettings(GameSettings *gameSettings) const;

virtual bool receive(Socket* socket);
virtual void send(Socket* socket) const;
};

NetworkMessageLaunch::NetworkMessageLaunch(const GameSettings *gameSettings){
data.messageType=nmtLaunch;

data.description= gameSettings->getDescription();
data.map= gameSettings->getMap();
data.tileset= gameSettings->getTileset();
data.tech= gameSettings->getTech();
data.factionCount= gameSettings->getFactionCount();
data.thisFactionIndex= gameSettings->getThisFactionIndex();
data.defaultResources= gameSettings->getDefaultResources();
    data.defaultUnits= gameSettings->getDefaultUnits();
    data.defaultVictoryConditions= gameSettings->getDefaultVictoryConditions();

for(int i= 0; i<data.factionCount; ++i){
data.factionTypeNames[i]= gameSettings->getFactionTypeName(i);
data.factionControls[i]= gameSettings->getFactionControl(i);
data.teams[i]= gameSettings->getTeam(i);
data.startLocationIndex[i]= gameSettings->getStartLocationIndex(i);
}
}

void NetworkMessageLaunch::buildGameSettings(GameSettings *gameSettings) const{
gameSettings->setDescription(data.description.getString());
gameSettings->setMap(data.map.getString());
gameSettings->setTileset(data.tileset.getString());
gameSettings->setTech(data.tech.getString());
gameSettings->setFactionCount(data.factionCount);
gameSettings->setThisFactionIndex(data.thisFactionIndex);
gameSettings->setDefaultResources(data.defaultResources);
    gameSettings->setDefaultUnits(data.defaultUnits);
    gameSettings->setDefaultVictoryConditions(data.defaultVictoryConditions);

for(int i= 0; i<data.factionCount; ++i){
gameSettings->setFactionTypeName(i, data.factionTypeNames[i].getString());
gameSettings->setFactionControl(i, static_cast<ControlType>(data.factionControls[i]));
gameSettings->setTeam(i, data.teams[i]);
gameSettings->setStartLocationIndex(i, data.startLocationIndex[i]);
}
}


[titi]

oh thanks so much
I hope this will fix my problems!
I will try it and if it works,I will contact martino and ask him to inlude this patch

[softcoder]

One more thing... we play with network consistency checks turned off... there is a basic problem (i'm sure there are numerous others) when running in this mode.. the most significant one is that all connected computers must have the exact same # of units and they must be loaded in the same order. This is due to how units get loaded in glest.. they get loaded alphabetic i think and a unique ID is assigned to each unit (starting at 1). This ID gets passed around during game play and if one client tells the others to do a command or use a unit that the others don't know about.. get get game out of synch errors. On my end I added a new network message that does a kind of handshake between server and all clients to check the total unit count just before starting the game (After all units are loaded on each PC). If the loaded unit counts are not equal then the game quits (but at least you know there is a problem with unit count mismatch).

Thanks

[titi]

Me and and my sons always play with consistency checks on and we !!never!! get out of sync in local LAN!
Why do you have to play in this without network consistency checks?

And you mentioned new factions    . With new models too??
Can we download them somewhere?

[softcoder]

My sons and I are getting involved in some open source projects. Glest and BloodFrontier are both games that we download and mod them to suit our needs (due to our Christian Faith we don't play with magic etc). My sons recently got blender working and the glest plugins for blender too. They are making new factions with new models and tweaking the xml settings to ensure fair play.

With that said.. because we are always changing content (for the next while) having consistency checks turned on would make things very difficult for network play since everything has to match (but for now they won't while we are editing things). This is why we turned off the checks. Also I found by changing the static const int networkFramePeriod= 30; (instead of 10) also made things much more stable and we are able to play a long 3 player game (4 player still seems VERY choppy and unusable for some reason). At some point we may post the new factions but not until the bugs have been worked out.

Thanks

[titi]

OK, I hope we will see some nice results one day . ( and please don't forget to upload your work when its done! )
If you don't like the magic faction what about the persian/indian or norsemen factions, are they ok?

( by the way are getting very off topic here I hope its ok when I (re)move our little conversation in the next days )

[softcoder]

As we did with Blood Frontier so we did with those factions in glest... we modified those models / animations / sounds to suit our acceptance. In the case of Blood Frontier we re-branded the game "TeamFest" in addition to modifying models etc. before deploying on the workstations.

Thanks

[martiño]

Hi, just to let you guys know that i will be looking into fixing this in the mainline as soon as i have some time.

Regards.

[martiño]

This is now included in 3.2.2. Thanks for your help.