DESIGN/PROJECT: GovernmentsModified complete

[Martin Gühmann]

Originally posted by Maquiladora
the rest of the warrior is the same.

Actually I wanted to know what this line prints into the log file :

DPRINTF(k_DBG_GAMESTATE, ("CTPDatabase::Access: index: %i, numRecords: %i\n", index, m_numRecords));

And for the debugger we still have to figure out the problem, but not today, I just committed the big AI fix. Well now the harasses you with its units, so that you can kill them one by one. Looks like there is still some work needed to make the AI build up strength.

-Martin

[Maquiladora]

Originally posted by Martin Gühmann

Actually I wanted to know what this line prints into the log file :

DPRINTF(k_DBG_GAMESTATE, ("CTPDatabase::Access: index: %i, numRecords: %i\n", index, m_numRecords));

Oh

I don't know it, or rather, I could print screen to show the call stack window in the debugger before I had to close the debugger with the "break" or "continue" popup, maybe that will show it.

[Martin Gühmann]

Originally posted by Maquiladora
I don't know it, or rather, I could print screen to show the call stack window in the debugger before I had to close the debugger with the "break" or "continue" popup, maybe that will show it.

No, just press F5, afterwards you have pressed retry, or better press ignore.

-Martin

[Maquiladora]

Originally posted by Martin Gühmann

No, just press F5, afterwards you have pressed retry, or better press ignore.

When I press retry or ignore I get this:



and when I close the game with ctrl+alt+del (I have to or I can do nothing) I see this:



and I have to press break or continue or I can't do anything in the debugger. When I press either of those the "call stack" and "autos" windows disappear.

[Martin Gühmann]

Originally posted by Maquiladora
and I have to press break or continue or I can't do anything in the debugger. When I press either of those the "call stack" and "autos" windows disappear.

That happens if you close the program, so nothing to worry about, as long as we don't worry about why the nonexclusive program parameter doesn't work.

Anyway, now the program has executed long enough to execute the following line:

DPRINTF(k_DBG_GAMESTATE, ("CTPDatabase::Access: index: %i, numRecords: %i\n", index, m_numRecords));

So what did it print into the log file?

-Martin

[Maquiladora]

Originally posted by Martin Gühmann


That happens if you close the program, so nothing to worry about, as long as we don't worry about why the nonexclusive program parameter doesn't work.

Anyway, now the program has executed long enough to execute the following line:

DPRINTF(k_DBG_GAMESTATE, ("CTPDatabase::Access: index: %i, numRecords: %i\n", index, m_numRecords));

So what did it print into the log file?

-Martin

I was about to tell you it hadn't been entered into the log again, but I checked and I guess found it. This time I pressed F10 quite a lot before terminating the game and the debugger, so I guess it eventually went through.

ctpdatabase.cpp@359 : CTPDatabase::Access: index: 2147483647, numRecords: 74

I've also attached the log in case I've got the wrong part again.

[Martin Gühmann]

Originally posted by Maquiladora
I was about to tell you it hadn't been entered into the log again, but I checked and I guess found it. This time I pressed F10 quite a lot before terminating the game and the debugger, so I guess it eventually went through.

Actually that already showed your second screenshot, it went to the access violation, that means it had passed the point, needed for writing to the access log.

Originally posted by Maquiladora

ctpdatabase.cpp@359 : CTPDatabase::Access: index: 2147483647, numRecords: 74

Well that isn't a database index. If you display it as hexadecimal number you get this: 7fffffff

Looks like something wasn't initialized, anyway I fixed it, you just need to update to the latest revision. By the way you can also look onto the diff from the TortoiseSVN log messages.

-Martin

[Maquiladora]

Originally posted by Martin Gühmann

Looks like something wasn't initialized, anyway I fixed it, you just need to update to the latest revision. By the way you can also look onto the diff from the TortoiseSVN log messages.

Yeah I checked the diff, and well at least I understood what you did to fix it.

Now I'll try to fix the production time in the build manager, then compile the latest revision and test both.

[Maquiladora]

Now I'll try to fix the production time in the build manager, then compile the latest revision and test both.

Well I finally fixed it, and everything else in editqueue. But could someone (Martin? ) take a look at this first before I commit it. ui/interface/EditQueue.cpp attached.

Specifically, is how I identified the current player good enough. Is there a better way? I tested it and it works fine at least.

Also in entries such as:

g_theGovernmentDB->Get(player_ptr->GetGovernmentType())->GetRank();

Is it really necessary that I add the 2nd argument to get the government again here? And for g_theGovernmentDB->Get entries at all?

[Martin Gühmann]

Specifically, is how I identified the current player good enough. Is there a better way? I tested it and it works fine at least.

Better? Well instead of this:

PLAYER_INDEX owner = g_selected_item->GetCurPlayer();

You could do this:

sint32 govType = g_player[g_selected_item->GetCurPlayer()]->GetGovernmentType();

This has the advantage that g_player[g_selected_item->GetCurPlayer()] is only called once, and since you already store a value in memory, then you can use the final one. Probably this is faster, but you won't notice.

Also in entries such as:

g_theGovernmentDB->Get(player_ptr->GetGovernmentType())->GetRank();

Is it really necessary that I add the 2nd argument to get the government again here? And for g_theGovernmentDB->Get entries at all?

What you have here is enough.

-Martin