DEBUG: AI does diplomacy with itself

[Ekmek]

Originally posted by BureauBert

Diplomacy:
AI's are still making diplomacy with themselves -- litterally: This time I noticed the Turks having a withdraw agreement with themselves (with previous builds I had AI's declaring war on themselves).

this has also been reported by Protra but I haven't seen it in a game (yet?) apparently there is no message but the icon pops up in the diploacy screen with diplomacy icons even though the AI hasn't met anyone else and hasn't had those treaties with the player.

[Ekmek]

I think it might be from here:

Fromafar

Revision 580

Crash repairs: civapp.cpp (Rulesets handling), priorityqueue.h, SlicFunc (handling proposals with more than 8 arguments).
Original behaviour compatibility preparation: added treaty ending setting to ProfileDB.[b]
MP diplomacy agreement index correction.[/b]
Various minor corrections (types, unused variables etc.).

Modified: ctp2_code\ai\ctpai.cpp 
Modified: ctp2_code\ai\ctpaidebug.cpp 
Modified: ctp2_code\ai\diplomacy\AgreementMatrix.h 
Modified: ctp2_code\ai\diplomacy\agreementmatrix.cpp 
Modified: ctp2_code\ctp\civ3_main.cpp 
Modified: ctp2_code\ctp\civ3_main.h 
Modified: ctp2_code\ctp\civapp.cpp 
Modified: ctp2_code\ctp\ctp2_utils\AvlTree.h 
Modified: ctp2_code\ctp\ctp2_utils\c3files.cpp 
Modified: ctp2_code\ctp\ctp2_utils\pointerlist.h 
Modified: ctp2_code\ctp\fingerprint\shroud.c 
Modified: ctp2_code\ctp\fingerprint\shroud.h 
Modified: ctp2_code\gs\database\StrDB.cpp 
Modified: ctp2_code\gs\database\profileDB.cpp 
Modified: ctp2_code\gs\database\profileDB.h 
Modified: ctp2_code\gs\outcom\c3rand.cpp 
Modified: ctp2_code\gs\slic\SlicEngine.cpp 
Modified: ctp2_code\gs\slic\SlicEngine.h 
Modified: ctp2_code\gs\slic\SlicFrame.cpp 
Modified: ctp2_code\gs\slic\SlicFunc.h 
Modified: ctp2_code\gs\slic\SlicSegment.cpp 
Modified: ctp2_code\gs\slic\SlicStruct.cpp 
Modified: ctp2_code\gs\slic\slicfunc.cpp 
Modified: ctp2_code\gs\slic\slicfuncai.cpp 
Modified: ctp2_code\gs\slic\slicif.cpp 
Modified: ctp2_code\gs\slic\slicobject.cpp 
Modified: ctp2_code\gs\utility\PQueue.h 
Modified: ctp2_code\gs\utility\QuadTree.h 
Modified: ctp2_code\gs\utility\TurnCnt.cpp 
Modified: ctp2_code\gs\utility\TurnCntEvent.cpp 
Modified: ctp2_code\gs\utility\gameinit.cpp 
Modified: ctp2_code\net\general\net_action.cpp 
Modified: ctp2_code\net\general\net_city.cpp 
Modified: ctp2_code\net\general\net_diplomacy.cpp 
Modified: ctp2_code\net\general\net_endgame.cpp 
Modified: ctp2_code\net\general\net_info.cpp 
Modified: ctp2_code\net\general\net_terrain.cpp 
Modified: ctp2_code\net\general\net_vision.cpp 
Modified: ctp2_code\net\general\network.cpp 
Modified: ctp2_code\net\general\network.h 
Modified: ctp2_code\net\general\networkevent.cpp 
Modified: ctp2_code\net\io\net_anet.cpp 
Modified: ctp2_code\net\io\net_anet.h 
Modified: ctp2_code\net\io\net_thread.cpp 
Modified: ctp2_code\robot\aibackdoor\priorityqueue.h 
Modified: ctp2_code\robot\pathing\A_Star_Heuristic_Cost.h 
Modified: ctp2_code\robot\pathing\CityAstar.h 
Modified: ctp2_code\robot\pathing\Path.cpp 
Modified: ctp2_code\robot\pathing\Path.h 
Modified: ctp2_code\robot\pathing\RobotAstar.cpp 
Modified: ctp2_code\robot\pathing\astar.cpp 
Modified: ctp2_code\robot\pathing\robotastar2.cpp

[Martin Gühmann]

At least I confirm that there is a problem, with incorrect diplomacy. Playing with the Barbarians I get report about treaty expiring even if I don't have any treaties as Barbarian leader.

-Martin

[Ekmek]

I looked through agreementmatrix.cpp and didn't see any differences that would cause this. Where else should we look?

[Martin Gühmann]

You could update your working copy to revision 579 and check whether the bug is there. And of course to test this you have to start a new game use the cheat editor to switch to the Barbarians and use the /rnd chat window command to run the game let's say for 200 turns and than you should see whether the problem is there or not.

-Martin

[Ekmek]

I think it goes farther than 577 Bureaubert posted tis in the playtest thread (around 573)

BTW in some of the previous builds I had AI's declaring war on themselves ("the Zulu have declared war on the Zulu"), I didn't yet notice that in the current (rev573) build, but maybe this indicates some general issue with the game recognizing who is able to declare war on whom .

Argh! Really this the only bug out there I can think of. After solving this I think we ought to release a new playtest.

EDIT: I went thhrough the revision reports to see where we when into ai/diploamcy. The only pre-573 I found was way back in 539 with regardevent.cpp but this houldn't b the cause and the problem wasn't reported back then.

could it be in player?

[Martin Gühmann]

Originally posted by E
could it be in player?

So why don't you test it?

-Martin

[Ekmek]

Testing hasn't helped I'm not sure where in the code it is or what to look for.

and between 539 and 573 there have been a lot of revision (I cant test 40 revisions) but the hard part was that when Bureaubert started reporting it, I was play testing myself and not getting it.

I'll keep looking but I'm not sure how the AI diplomacy thing works.

[Martin Gühmann]

Why do you want to test all of them? All you have to do is to test revision 573. If the problem is not there you have to test a later revision. If it is there you have to test an earlier revision like 539. If it isn't there you have to test a later revision. A revision in the middle between 539 and 573. So revision 556 would be the next one. And than you start the procedure again until you have the revision in question.

-Martin

[Ekmek]

I'll give it a shot. I was just hoping that you had better knowledge about the diplomacy code and maybe you had an idea where to look.


EDIT: reverting just had three files so I updated to revision 539 then compiled. HOWEVER, I saved all my builds I have 538 then 542 (then everything after that!) 539 was the only one I was missing. Glad I saved all those revisions!

[Ekmek]

Okay I ran some tests.

I switched to barbarian and went 200 turns here's what happened

542 - ok
572(b) - ok
589 (most recent) - BUG
573 - ok
574(b) - ok
577(b) - barbs at war nothing else seemed normal (might be when i had the barb war code
583b - barb war then by turn 153 a lot of weird treaties.

SO I'm assuming its between 577 and 583 and looking at the code its either your 578

http://apolyton.net/forums/showthread.php?postid=4445901#post4445901

or Fromafar's 580

http://apolyton.net/forums/showthread.php?postid=4447518#post4447518

but agreementmatrix looked ok the last time i looked so maybe its diplomat? or maybe ctp2_code\net\general\net_diplomacy.cpp ???????

[Martin Gühmann]

Originally posted by E
SO I'm assuming its between 577 and 583 and looking at the code its either your 578

http://apolyton.net/forums/showthread.php?postid=4445901#post4445901

or Fromafar's 580

http://apolyton.net/forums/showthrea...18#post4447518

Now you have just a few revisions left. And of course you can also test these.

Originally posted by E
but agreementmatrix looked ok the last time i looked so maybe its diplomat? or maybe ctp2_code\net\general\net_diplomacy.cpp ???????

Be careful with those assumptions, the defect might be locatedd at an unexpected location. The problem with incorrect farmer allocation was introduced by Fromafar, by redesigning the database record files.

Modifying those files could produce a lot of harm at various places in the game.

-Martin

[Ekmek]

I think its 580 in the net_diplomacy. I found this:

// - Corrected agreement index computation in NetAgreementMatrix::Unpacketize.

so I'm thinking of reverting to the pre-580 version of these functions to see what happens (I figure I might have to change the h file too)

[Fromafar]

Nope. The change in net_diplomacy is the proper fix for MP: the original Activision code had the receiver and sender reversed when computing the index. Reverting this file will not do anything to correct the problem for SP.

I made an error when generalising the index computation. You have to look there to find it. I will postpone correcting it till tomorrow, so you have 1 more day to work it out for yourself without cheating .

[Ekmek]

hmm

Well I see 580 had this in agreementmatrix.h

	size_t AgreementIndex
    (
        PLAYER_INDEX const &    sender_player,
		PLAYER_INDEX const &    receiver_player,
        PROPOSAL_TYPE const &   proposalType    = PROPOSAL_NONE
    ) const
	{
		Assert((sender_player   < m_maxPlayers) &&
               (receiver_player < m_maxPlayers) &&
               (proposalType    < PROPOSAL_MAX)
              );

		return static_cast
            ((PROPOSAL_MAX * (receiver_player * m_maxPlayers) + sender_player) +
             proposalType
            );
	}

versus this pre-580 one...

	sint32 AgreementIndex(const PLAYER_INDEX & sender_player,
							     const PLAYER_INDEX & receiver_player) const
	{
		
		Assert(sender_player < m_maxPlayers);
		Assert(receiver_player < m_maxPlayers);
		return PROPOSAL_MAX*(receiver_player * m_maxPlayers +  
			sender_player);						  
	}

I really don't get why was it was changed or where the error is at. Should I just restore it to the old (the pre-580) one?

if I had to guess though I would say a parentheses is off in the return on the new one????