altf4 / realtimetactics Goto Github PK

Currently, there is only one "type" variable for messages, and it's owned by the parent Message class. As the number of types increases, this field is getting crowded. It's time to make more.

Each message Class should have its own sub-type. And then the existing Message's "type" field should be made to just hold an enum of what class the message should be. (IE: An aide in casting the Message to the correct child class) Each child class will have their own enum that describes what exact message is being sent.

If you have 11 or more matches on a server, the GTK client is supposed to include additional matches on other tabs of the match list view. But it doesn't.

There needs to be a changed_tab event handler on the match list view, which queries the server for the matches that should go in that tab.

After upgrading to Fedora 18, which uses Boost 1.5.0, there is a known bug with Boost and Fedora in which Boost.Thread links to Boost.System, but that link is found to be invalid, requiring both boost_thread-mt and boost_system-mt to be linked. RTT_Client_OGRE will not compile without adding a -lboost_system-mt argument. The latest Boost update for Fedora supposedly fixed the issue, however it still persists in RTT for some reason. At this time I'm unaware if it affects any other distro, however it's supposed to be Fedora specific.

Currently, RTT_Client_OGRE will not build on Fedora without this option, bu should build on others.

To reproduce:

1. Set up a server and one client. Connect the client and go into a match.
2. Press the leader check mark on the client around 12-20 times.

Should crash now.

Complains about:

*** glibc detected *** ./Debug/RTT_Client_GTK: double free or corruption (fasttop): 0x09de7240 ***

You can stop the crash by commenting out the lines

row[playerColumns.isLeader] = true;
row[playerColumns.isLeader] = false;
(4 of them)

inside case LEADER_CHANGE: of the void *CallbackThread(void * parm) function of RTT_Client_GTK

The match leader is the player in a match who is able to change any settings. Including starting the game. By default, the leader is the stater of the match. But the leader role should pass to someone else if the leader leaves, or it is assigned to someone else.

The length of types such as ints and chars is taken for granted in the serialization code. In order to be portable, we need to make sure that all variables are the exact width we want them to be, no assumptions.

We want to be able to save data for a gameboard to file. So that someone can make maps (called gameboard in the code) and save them. We could also then have a visual map editor separate from the current game client and server code.

The basics of what are needed is pretty simple. Maximum lat and long, elevations... The movement penalties to each tile, etc... The complicated part comes in not from the game engine, but the art actually. How to store that is an interesting question.

• Maybe XML?
• Plain whitespace separated text?

There is a combo box defined as:

CEGUI::Combobox *playerTeam;

Which is then assigned to a value only in a conditional. This conditional might not get hit. And then all the instances below where playerTeam is accessed will segfault.

There should be an else statement to the 'if' at the top of TeamChangedEvent() to handle this case.

The libRTT_Common dependency in each project is set to look for libRTT_Common.a in the Debug build directory, so all other project will fail to build when compiled as release.

Once more properly defined and implemented, write a wireshark dissector for the RTT protocol. So that it is easier to debug messages being passed.

One of the columns in the match lobby should be a checkbox for each player, where they can specify if they're ready to start the match. The match won't start without all players being ready.

Should the leader be able to change other player's "ready" checkboxes?

It's in the Client_Terminal only right now, and that's wrong.

Don't put any using keywords in headers, sine that forces any users of it into that namespace.

Change them all to this:

GameMessage message;

instead of:

GameMessage *message = new GameMessage();

Way better. Faster, harder to screw up. No memory leaks. Fewer lines of code.

Take a pass through all of the function definitions and see if there's any use of pointers that could safely be made into references. Refs are safer and nicer than pointers when you can use them.

RTT_Server after last commit does not compile, like MatchLoop.cpp line 43: usleep(tickDelta);
gives the error: "usleep was not declared in this scope".

I've recently started this naming scheme are really liked it. It gives you a really quick idea of the scope of variables you're using. Member variables stick out like a sore thumb. Very useful.

structs can have passing and all kinds of internal silliness that can make direct memory copy errors. You have to assume that both ends of the communication were both made with the same compiler and everything, which we don't want to assume.

So change any instances of direct copies to/from structs and memory with copies of their contents. This is notably present in the message serialization code.

Looks like a permissions thing. Usually this isn't a problem because you don't try to write to the directory yourself. You're supposed to use syslog to do it. Maybe OGRE isn't using syslog to do logs, but rather writes directly to the file itself. If so, we'll have to figure something else out.

When changing the team of another player, when not the leader, the server will drop the offending player from the match.
This bug exists in both the GTK and OGRE clients.

Steps to reproduce:

Start a server and two clients
create a game and join that game with both clients
in the client that is not the leader, attempt to change other player's team.

Mysteriously, nothing happens when you choose Team 1 from the dropdown menu.

Right now, read() commands on a socket wait forever. Sometimes, we might not want to. Especially on the server. If we're only expecting an acknowledge message, then we can probably do without receiving it if it comes too late or if the client dies uncleanly.

I cannot seem to reliably reproduce this, I've only seen it once. But server crashes are serious, so here is what I know about it:

I was testing two clients out in the Ogre3D code, then quit out of the Ogre code back into the match lobby when the server spit out:

RTT_Server: malloc.c:4631: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed.
Aborted

Judging from this: http://stackoverflow.com/questions/7759696/what-does-this-error-suggest I would say that the error is due to us not deleting on object when we should. We'll have to take a close look at data reads from the server.

Running the server under valgrind would also be a good idea.

A general UI/UX design is now needed. Keeping in mind that CEGUI will be used to render the UI, it is time to design the UI and UX(user experience).
A few guidelines:

• Real Time Tactics is not the final name for the game, and is probably going to be used as the engine name. Do not include it in the design.
• The design should be clean and functional, and preferably as minimalistic as possible.
• The theme of the game is Steam Punk, so the look and feel should fit that style.
• Hexagons are of to use.

There needs to be mutexes (probably read/write locks) on the matchList and the playerList.

Pick one not currently in use in the well known ports list, and use it by default.

In the common code, we use a scoped enum type. (Where you specify the exact data type) Which apparently is only available as of c++0x. Which is totally fine, but it produces a compiler warning. (Which we wan to eliminate):

warning: scoped enums only available with -std=c++0x or -std=gnu++0x

But when you throw in the "-std=c++0x" compiler flag, a whole slew of build errors ensue.

Try to figure out wtf is going on, here.

Currently, when a client joins a match they have no idea what the current settings are in terms of map, game speed, victory condition, etc...

That should really be bundled up into a MatchSettings struct and sent out when the match is joined.

The basic protocol for exchanging client authentication information is present. But the actual authentication mechanism isn't,

When we delete a Player in QuitServer(), the damned Player shows up again when we call AuthenticateClient().

I haven't the foggiest clue why. I'm considering dropping Google densemaps because they have been such a pain to deal with so far. Terrible documentation (non-existent) and strange code behavior.

Should make it so that it takes the local time zone into account when printing times as strings.

There is a bug that adds in gaps between players in a match lobby window. It might be because of player ID differences.

Once a client has join a server, then leaves that server, that client cannot re-join that server. Different clients can join that server(but only once), and a client can join different servers, but only once. Output from RTT_Server:

[mark@MarkFedora64 RTT_Server]$ ./Debug/RTT_Server
Client: Authenticated!
Player: has left.
ERROR: Authentication Failure
ERROR: Authentication Failure
ERROR: Authentication Failure
Client: TEst Authenticated!
Player: TEst has left.
ERROR: Authentication Failure
ERROR: Authentication Failure
ERROR: Authentication Failure
ERROR: Authentication Failure

The count of players is provided in the MatchDescription which is also sent in that same message. Instead, the JoinMatch() function in ClientCore should return a bool, and the message have the player count removed.

We make a call to "new MatchListColumns();", but it's not clear whether that object ever gets cleaned up. It might get managed by the parent widget. But I suspect not. This might be causing a memory leak by not cleaning it up.

in order to better access the client functions from any interface, it will be preferable to build the client as a library to link against. Currently, the client is an executable.

In much of the protocol handler code, we simply check for our desired message type. And if it's not correct, send out an error message. But we shouldn't reply to error messages with more error messages. For one, it's redundant. And two, it could possibly lead to an infinite loop.

When a player joins a match, the team number that appears is not set to "Team 1" (as the default should be). It appears to be set as whatever the player's team number used to be in the last match they were in.

We do a SHA256 hash of the user's password, but really need to salt it, too. Find either how to do this in the library, or just do it manually.

Should allow for different levels:

debug, info, warning, error, critical

Also should write to file and to sterr. Output should be easily parsed so you can just view particular kinds of logs.

The lobby_message object is created early on, but never deleted. Have to add a delete command before any return.

Particularly about where the server thinks that the client should be. Sometimes we'll get an error where the client thinks he's in a match lobby, but the server thinks he's in the main lobby. So the client just gets stuck there sending the wrong messages. We need to have the server tell the client where he ought to be in error conditions, so he can reset.

The problem is that the ProcessLobby commands on the client side only have one error condition. So we don't know the difference between a benign error, and a critical one. So when the server dies. we go back and ask for another message. Then get another error, etc...

To let the server know when the client is leaving.

The playerList and matchList hash tables contain only pointers to objects. So that essentially means that we should be doing locking any time a match or player is accessed. Which is bad. Change the hash tables to contain actual object contents.

Then we can get a copy of the object and immediately unlock. If we want to submit that object back into the table, then you have to relock and go back and do it.