Guild of Writers

Posted: **Sat Oct 08, 2011 7:53 am**

Okay, this seems to basically work offline, after I figured out how to use that weird console ;-)

. Great work, Sirius - honestly I had already given up on this ever working in POTS.

I also installed all the files on Deep Island, so you can go ahead and try it out there without editing prp files on your own... however,
Uru crashes when I enter the tube. I don't know yet what this is caused by, the prp files are the same as offline.

The only other issues I experienced so far are related to the control panel: As soon as I click some area that is not clickable (for example, one of the black squares between the lines you can put the blockers on), the avatar leaves the chair. That's quite annoying as I keep accidentally hitting those...
Besides, (some of) the buttons on the panel can even be operated when I am not sitting on the chair... is that meant to happen? IMHO the other Uru panels do not allow that, you have to click them (or the chair in front of them) to be able to operate them.

Posted: **Sat Oct 08, 2011 9:52 am**

I'm now sure that the Multistage behavior causes the crash because the SmartSeek before it doesn't work.
I'm also almost sure I know the fix.
In the Python File, line 55-56, the Behaviors are attributed with:

Code: Select all

sTubeMulti = ptAttribBehavior(43, 's tube entry multi', netForce=0)
nTubeMulti = ptAttribBehavior(44, 'n tube entry multi', netForce=0)

In every other Python file I looked in, they use netForce=1, or uses the default value, which is 1.
So, maybe you should try with:

Code: Select all

sTubeMulti = ptAttribBehavior(43, 's tube entry multi', netForce=1)
nTubeMulti = ptAttribBehavior(44, 'n tube entry multi', netForce=1)

AND at line ~910:

Code: Select all

        if (id == nTubeEntry.id):
            trigger = PtFindAvatar(events)
            print 'entered team 1 tube, run behavior'
            ageSDL.setIndex('nWallPlayer', 0, PtGetClientIDFromAvatarKey(trigger.getKey()))
            trigger.avatar.runBehaviorSetNotify(nTubeMulti.value, self.key, 1)  ##changed
        if (id == sTubeEntry.id):
            trigger = PtFindAvatar(events)
            print 'entered team 2 tube, run behavior'
            ageSDL.setIndex('sWallPlayer', 0, PtGetClientIDFromAvatarKey(trigger.getKey()))
            trigger.avatar.runBehaviorSetNotify(sTubeMulti.value, self.key, 1)  ##changed

(here I changed the 0 at the end to a 1, that's again the netForce flag)

diafero wrote:Okay, this seems to basically work offline, after I figured out how to use that weird console

That's why they added journals in the observation rooms, and added new textures to the panel in MOULa. It's far from being intuitive.

diafero wrote:The only other issues I experienced so far are related to the control panel: As soon as I click some area that is not clickable (for example, one of the black squares between the lines you can put the blockers on), the avatar leaves the chair. That's quite annoying as I keep accidentally hitting those...

That's a problem with the SittingModifier. That's its default behavior.

diafero wrote:Besides, (some of) the buttons on the panel can even be operated when I am not sitting on the chair... is that meant to happen? IMHO the other Uru panels do not allow that, you have to click them (or the chair in front of them) to be able to operate them.

Yes, the region is too big.

If you want, I can fix these. I could use another Multistage Behavior for the chairs, controlled by Python to exit only when you press the right/down/left key. That would be again more lines in the Python file, but it can be done. For the buttons, I can change the region in which you must be to activate them (there is another one for the big button which is a lot smaller)... or edit the region.
For now I think it doesn't really matter.

Posted: **Sat Oct 08, 2011 11:33 am**

I tried that patch, but it does not change anything, the crash still occurs. I also watched the network communication and server logs, but it does not seem like the crash is caused by the server (sometimes the client crashes when it is kicked, for example) - there are no error messages on the server side, just the expected timeout.

If you want, I can fix these. I could use another Multistage Behavior for the chairs, controlled by Python to exit only when you press the right/down/left key. That would be again more lines in the Python file, but it can be done. For the buttons, I can change the region in which you must be to activate them (there is another one for the big button which is a lot smaller)... or edit the region.
For now I think it doesn't really matter.

Yeah, probably it's not worth it...

Posted: **Sun Oct 09, 2011 2:20 am**

Damn, I really thought it was the problem... Anyway, I guess it is better to leave it this way. I don't understand why this message wasn't netforced.

I realised yesterday I might have left an error in the team room PRPs... however this kind of error should have occured both online and offline...
I'll check again.

EDIT: it seems the blockers are crashing the client as well, so even if we manage to fix the suit machines, it still won't work.
That's quite strange, all these bugs don't appear offline...

Posted: **Sun Oct 09, 2011 5:01 am**

Behavior in general should not be netforced. It means that your client will be controlling another player's avatar which IMO is bad practice. This can cause avatars to go through animations multiple times. netForce=0 is the default for behavior so in fact there was no need for Cyan to add that.
With netForce=0 your client will still show the avatar animation of any player locally but won't be forcing it to other clients. So what netForce=1 does here is make all clients force each other to show the same thing (which they were already doing anyway).
So why do we rarely see a plethora of avatar animations? Fortunately a behavior has to finish first before it can be restarted this way. So we only notice these errors (which are common in Cyan's programming as well) when there are very high latency clients around.

Netforced behavior should be used when it is preceded by a notification which is filtered down to one client (for example the one who pushed a button or the automatically assigned game master).
Edit: On second thought, I remember trying to use netforce on a behavior and finding that the flag didn't make any difference. It refused to be netforced no matter what. So maybe this is even hard disabled. Anyway, a behavior can definitely be netforced (and netpropagated) when it is part of a responder so the above still applies.

Posted: **Sun Oct 09, 2011 5:45 am**

Yeah, I was mistaking. Cyan's default value is netForce=0 in PotS PlasmaTypes.py, and I read the PlasmaTypes.py from MOULa... in which netForce is defaulted to 1.

However in this file:

Code: Select all

if (avatar != PtGetLocalAvatar()):
    print 'not activated by me'
    return
if (id == nTubeEntry.id): # that's the one we're interested in
    # ..etc

So it should be netforced for this behavior, right ?

The two other behaviors (for touching the exit buttons) are not netforced, but they aren't controlling which avatar is the triggerer. It is controlled however, once the avatar touched the button (to make sure only ONE client send the new game state, and only ONE client links the player to the Nexus).

The exit region at the top of the Wall does not seem to check the player... so every clients should try to link the avatar to the Nexus and change the game state, right ? Doesn't sound the best way... I think there are other wrong objects anyway...

Posted: **Sun Oct 09, 2011 6:30 am**

Sirius wrote:However in this file:
Code: Select all
if (avatar != PtGetLocalAvatar()):
    print 'not activated by me'
    return
if (id == nTubeEntry.id): # that's the one we're interested in
    # ..etc
So it should be netforced for this behavior, right ?

The responders under "if (id == nTubeMulti.id):" which are executed next are netforced. Only one client should run them. Seeing the avatar walk that last step instead of gliding is hardy worth the trouble of correcting all the subsequent events IMO.

Sirius wrote:The exit region at the top of the Wall does not seem to check the player... so every clients should try to link the avatar to the Nexus and change the game state, right ? Doesn't sound the best way... I think there are other wrong objects anyway...

True. A local avatar check could be added here.

Posted: **Sun Oct 09, 2011 9:36 am**

I reset the Python to how you sent it to me, Sirius - if anything should be changed, please tell me ;-)

Posted: **Mon Oct 10, 2011 7:05 am**

Awesome!
When you guys are finished testing and debugging this, and I get back from Nairobi, I can provide an easy installation script for those who don't have the time or skills to do the manual installation. A subset of my unfinished UruDistro, actually.

Posted: **Wed Oct 12, 2011 2:01 pm**

Wonderful, wonderful! The dream of an actually playable group wall lives and seems to breathe! thank you deeply!

Guild of Writers

Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall

Re: Back on the Wall