Quabs (split from Minkata Shard Updates)

[D'Lanor]

It does not seem to be fixable with Python.

I have debugged this on Cyan's shard using the GoW internal client (a method I dislike but at this time there is no other option). I was able to find the line which causes the crash. The owner change message from the server is handled fine btw but when Python reacts and changes the variable self.isAIOwner to 1 the client crashes. This is unexpected. It puzzles me that changing a simple variable can do that.
I managed to avoid that crash by leaving the variable alone. Then I tried to transfer quab control to player 2 using brain.setLocallyControlled(1) instead of brain.setLocallyControlled(self.isAIOwner) which should do the same. This however fails and does absolutely nothing.

My conclusion for now is that Python cannot transfer quab control to another player once it has been set. So can someone figure out if there is anything wrong with the client code that handles this?

[Christian Walther]

• Found another mention in the documentation (not sure it adds anything new at this point): https://bitbucket.org/OpenUru_org/moss/ ... ist#cl-116
• I’ve removed what I assume is the workaround:

  Code: Select all

  --- a/GameState.cc      Sat Mar 31 15:42:50 2012 +0200
  +++ b/GameState.cc      Sun Apr 15 15:39:43 2012 +0200
  @@ -1360,7 +1360,7 @@
     // to link in will be assigned the owner. Setting it to 1 (which is not a
     // valid KI number) works around these problems. Using -1 feels like it
     // could trip a special case in client code.
  -  m_owner = 1;
  +//  m_owner = 1;
     GameMgr::player_left(player, server);
     if (m_players.size() == 0) {
       // we can revive the game next time someone arrives, so fix up the owner
  

  on my local server and did some testing with two CWE-ou clients. I didn’t get a crash on owner transferral, but did get the exception mentioned in the link above, and fearless quabs. I also saw other intermittent anomalies like different players seeing different numbers of quabs, and quabs being fearless for one player but not the other. Haven’t investigated under what circumstances those occur (and probably won’t have time to).

[D'Lanor]

Found another mention in the documentation (not sure it adds anything new at this point)

Yes, it is helpful. It says the quabKeyList is never populated for anyone but the game master who spawns the quabs. I haven't figured out yet how to populate that list for the other players since it can only be generated at quab spawn time.
PtGetAIAvatarsByModelName which is used by the other players just retrieves ptCritterBrain objects, and not the actual quab avatars. The name suggest otherwise though. This method btw is not documented in Plasma.py so maybe there are more undocumented features I am missing.

[Hoikas]

I wouldn't mind doing some science on this client crash. Just so I understand what's happening: the client will crash when the unmodified ahnyQuabs.py tries to reassign ownership to another player (due to owner link out), correct?

@D'Lanor: There are several undocumented python functions, unfortunately. We should probably get python to spit out some documentation at some point, but for now...

Code: Select all

PtGetAIAvatarsByModelName
Params: modelName
Returns a list of tuples representing the matching ai avatars

(ptCritterBrain, strUserString,)

[D'Lanor]

No, the owner change message is handled fine. The client only crashes when Python tries to change the variable self.isAIOwner which makes no sense to me at all.
Trying to trap the error with a try: statement fails to prevent the crash.

[Hoikas]

No, the owner change message is handled fine. The client only crashes when Python tries to change the variable self.isAIOwner which makes no sense to me at all.
Trying to trap the error with a try: statement fails to prevent the crash.

You're right. It doesn't make sense because that's not the problem

It seems that the plAvBrainCritter are being thrown away when the player that created them links out but the python glue object still exists, so we get trapped in access violation hell when ahnyQuabs.OnUpdate tries to call a ptCritterBrain method... A good quick and dirty fix would be to recreate the quabs when the ownership is reassigned. A real fix would involve fixing the reference counting so that they don't get thrown away...

[D'Lanor]

You're right. It doesn't make sense because that's not the problem

Hmm, how does that explain why I don't crash when I leave that self.isAIOwner variable alone? When I crash I don't even get as far as OnUpdate. Of course when I don't change that variable I also remove the self.isAIOwner condition from OnUpdate which then fails on the missing quabKeyList without crashing.

Respawning the quabs seems a good solution to me. Especially since the quabKeyList is a randomly shuffled list of quab avatar keys. So it cannot be replicated by anyone but the game master. Other players can retrieve the quabBrainList from the userstring in PtGetAIAvatarsByModelName but then they still don't know which critter brain belongs to which quab. Unless we put the avatar key in the userstring as well and convert it back to a key (if that is even possible).

[Hoikas]

I don't know for certain... I didn't try changing the python at all--I had to ask someone if I could link their avatar around a bit in order to do my debugging. On a related note, ahnyQuabs.__del__ should be causing the quabs to be thrown away for everyone in the age. That can't be good.

[D'Lanor]

Except that it doesn't remove them completely. It could be worth trying to remove that __del__ section. That will be my last attempt to fix this with Python. I already spent way too much time on this without getting any positive results.

Edit: Nope, doesn't work. The only difference is that now both players crash.

Edit 2: Hard disabling netForce before unloading the quabs does not help either (even if I apply that to both the avatar and the key). I'm out of ideas now. The problem as I see it is that we cannot do that respawn workaround unless we get rid of the old quabs first.

[Hoikas]

netForce doesn't affect the quab unloading process... it's always sent over the network. The engine side of this crap needs a lot of love :/