1  |   Order by index

Jun 28, 2003, 6:03pm

There seems to be some problem with the actual world server in
combination with older (3.3) sdk versions.

When in global mode, it is quite easy and reliable to get an
object_click event in small worlds (eg. 10NSWE), while in bigger worlds,
it is almost impossible to get such an event at all, even not when the
avatar clicking and the application monitoring are the only two
instances in the world.
Clicking on an object 10, 20 and more times often yields but 1
click_event raised, often none at all. The avatar in question is,
though, recognized fine via avatar_add, avatar_change and avatar_delete
on every occasion.

Logging the application out and in, logging the avatar out and in, even
using a different dsl line or computer all make no difference and result
in the same no-event. Same for different time periods of raising
sdk_wait. Whether it is 1000 or 100 miliseconds all make no difference.

Is this a global incompatibility of world server 3.4 with sdk 3.3 - or
just a bug?

Jun 28, 2003, 6:17pm

Happens both with Object_click and _select, with or without global mode
and with or without a previous object enumeration.






[View Quote]

Jun 28, 2003, 6:32pm

The problem has, in fact, to do with the global mode. When I place the
application at 0N 0W, I get item_click events up to 20 cells away from
it, beyond that is a pure matter of luck.

HOWEVER, and this is where the fun starts...

when I place the application at 25N, I do NOT get events from 20 cells
around this position, but reliably, again, only withinthe 20 cells from
0N 0W, while even right next to the application location, click events
are not much likely to be recived (a matter of luck, as I said <g>).






[View Quote]

Jun 28, 2003, 8:00pm

do you have the same problem with 3.4 sdk?

MilesTeg


"kf" <none at junk.mail> a écrit dans le message de news:
3EFDF37C.B74 at junk.mail...
> There seems to be some problem with the actual world server in
> combination with older (3.3) sdk versions.
>
> When in global mode, it is quite easy and reliable to get an
> object_click event in small worlds (eg. 10NSWE), while in bigger worlds,
> it is almost impossible to get such an event at all, even not when the
> avatar clicking and the application monitoring are the only two
> instances in the world.
> Clicking on an object 10, 20 and more times often yields but 1
> click_event raised, often none at all. The avatar in question is,
> though, recognized fine via avatar_add, avatar_change and avatar_delete
> on every occasion.
>
> Logging the application out and in, logging the avatar out and in, even
> using a different dsl line or computer all make no difference and result
> in the same no-event. Same for different time periods of raising
> sdk_wait. Whether it is 1000 or 100 miliseconds all make no difference.
>
> Is this a global incompatibility of world server 3.4 with sdk 3.3 - or
> just a bug?

Jun 28, 2003, 8:28pm

No, idea, there is no 3.4 for VB yet <eg>.

However, this is more of a general problem, as Xelag noted before
already on another occasion, some applications are supposed to run with
different versions of a world server and at least the main events are
expected to be consistant through the versions - and if not, at least
some note in the sdk would be helpful.

This is definitely not a sdk issue, but a world server issue - since the
very same applications run fine with the old (3.3) world servers.

IMO there are some more world server problems as well, I heard eg. about
the CT rights not to be respected properly, and personally, I experience
some strange behaviour of ratings settings when world parameters are
changed in some cases (I am still investigating that, some world simply
set the rating themselves to a different value...) and two other issues
that also appear buggy to me, I also managed already twice to crash the
world server out of the blue from the browser - so I hope there will be
soon a world server update in which this problem here could be addressed
as well. :-)





[View Quote]

Jun 28, 2003, 8:45pm

ok , so if you expect this to be a worldserver issue, then it is probably
related to some trouble I experienced with sdk 3.4 and posted on the beta a
while ago. this was the lost of click event.
This haven't happened to me for a while now tho.
The only way I found to fix that problem is to restart the world and reload
the properties from a dump.

I hoep this help.

Regards,
MilesTeg

"kf" <none at junk.mail> a écrit dans le message de news:
3EFE15A5.77C4 at junk.mail...
> No, idea, there is no 3.4 for VB yet <eg>.
>
> However, this is more of a general problem, as Xelag noted before
> already on another occasion, some applications are supposed to run with
> different versions of a world server and at least the main events are
> expected to be consistant through the versions - and if not, at least
> some note in the sdk would be helpful.
>
> This is definitely not a sdk issue, but a world server issue - since the
> very same applications run fine with the old (3.3) world servers.
>
> IMO there are some more world server problems as well, I heard eg. about
> the CT rights not to be respected properly, and personally, I experience
> some strange behaviour of ratings settings when world parameters are
> changed in some cases (I am still investigating that, some world simply
> set the rating themselves to a different value...) and two other issues
> that also appear buggy to me, I also managed already twice to crash the
> world server out of the blue from the browser - so I hope there will be
> soon a world server update in which this problem here could be addressed
> as well. :-)
>
>
>
>
>
[View Quote]

Jun 29, 2003, 1:24pm

With the new sdk version 32 (3.4), the problem of no-events outside the
inner 20NSWE cells does NOT occur, interestingly. I will investigate
that a bit further <g>.



[View Quote]

Jul 5, 2003, 7:32pm

I have to revise what I wrote a few days ago.

An object click farther away than ca. 23-24 cells from a bot position is
still NOT noticed at all by a sdk application using sdk v32 (VB) and
world server v56 (Linux).

It works fine for the first couple of minutes after starting the
application, but then, after a while, only the object clicks near to the
bot location (in this case, it was 23 cells) raise an event anymore. In
fact, when I make a copy of the object and place one within the zone and
one just a few cm away outside the zone, then one object reports every
time while the other object reports, after a short while, never anymore.

The position of the clicker is of no matter here, it works when the
clicker is inside or outside the above mentioned distance from the bot,
only the object position determines whether or not the click event will
be recognised.

Restarting the world server etc. does not solve this problem, only
constantly restarting the application will do.

This problem appplies so far ONLY to the object click (left mouse)
event, avatar click events are raised and chat events also (there are
sometimes problems with certain session numbers, but it might be related
to the application).










[View Quote]

Jul 10, 2003, 5:22am

After more testing, it seems that the reliable click detection distance
is in the wrost case no more than just 12 cells away from the bot
location, which let me think that, although being in global mode, the
normal property perception range (up to 12 cells from the bot location =
1 zone) must have to do with this problem.

To remind again how this problem manifests: From a certain distance to
the bot location on, item clicks are not properly propagated to the sdk
anymore, meaning that in the best case, only some (and only for a
limited time span) and in the worst case, no item click event at all is
being raised, while eg. the avatar click event is correctly reported in
any distance (so the application is logged in and working correctly).



[View Quote]

Jul 10, 2003, 9:04pm

Is this an issue with global bots as well, or just standard-rights bots?

--
Shamus Young
Email: shamus at activeworlds.com
Home Page: www.shamusyoung.com


[View Quote]

Jul 10, 2003, 10:07pm

I experience this generally with global bots. I did not try many
combinations of worlds and settings yet, but it certainly happens in
worlds bigger than 20 NSWE and with terrain and water (latest world
server, latest sdk).
Re-starting the world or doing complete dumps and reloads won't change
it, just sometimes, shortly after login, it works in rare cases, but
after a while, all item click events beyond ca. 12 cells from the bots
location stop.

This started with the 3.4 world server - on the 3.3 world server, it
worked fine in the same world and with the same application (thus, a 3.3
sdk in a 3.4 world shows the same incorrect behvaiour).




[View Quote]

Jul 11, 2003, 4:51am

Mutation is a P70 world handled by an invisible bot in global mode and it
works fine.
it uses sdk 31

I am wondering, in your test , are you using a visible global mode bot?
the fact it is a visible bot could be the origin of the problem.

Regards,
MilesTeg

"kf" <none at junk.mail> a écrit dans le message de news:
3F0DFE9F.7321 at junk.mail...
> I experience this generally with global bots. I did not try many
> combinations of worlds and settings yet, but it certainly happens in
> worlds bigger than 20 NSWE and with terrain and water (latest world
> server, latest sdk).
> Re-starting the world or doing complete dumps and reloads won't change
> it, just sometimes, shortly after login, it works in rare cases, but
> after a while, all item click events beyond ca. 12 cells from the bots
> location stop.
>
> This started with the 3.4 world server - on the 3.3 world server, it
> worked fine in the same world and with the same application (thus, a 3.3
> sdk in a 3.4 world shows the same incorrect behvaiour).
>
>
>
>
[View Quote]

Jul 11, 2003, 6:18am

Yes, it is a visible one - why would this be a problem? According to the
sdk documentation, the event raises independent of the bot visibility.

However, maybe I missed some earlier discussion about this issue;
unfortunately, all older discussions have disappeared from the
newsgroups, so I was not able to check those anymore. :(



[View Quote]

Jul 11, 2003, 6:28am

On second thought - it worked always fine with the 3.3 world server and
sdk, so when there is a problem, it must have been introduced with the
3.4 server version or the 3.4 sdk version.

The problem with chat sometimes not being received from certain
sessions, occured, however, already in the 3.3 version. It has never
been a real problem for me, so I did not investigate this further - I
just noticed that some (not many) sessions, after a while, all of a
sudden and from no noticeable reason stop reporting chat to the sdk in
global mode (a non-global bot does not have this problem).




[View Quote]

Jul 11, 2003, 6:48am

I tried now running the very same application without propagating the
status (invisible bot) and without using global mode:

Bot is at 6N, object to be clicked is on 19N.

1) When using an invisible bot, the problem stays the same, the click
event is first only rarely and after a short time not at all anymore
raised, but when the object is moved to 17N, it works reliably every
time.

2) When NOT using global mode, the click event is raised reliably every
time (provided the object stays within the perception range of the bot,
so it works eg. fine at 19N).


Therefore, the problem is definitely related to the global event state,
but I am not able to find out any further condition that could cause the
problem.






[View Quote]

Jul 11, 2003, 7:00am

well like i said, i have no problem with a global mode bot to detect click
in the whole world (P70)
May i suggest the problem could come from your code or the wrapper you use?


"kf" <none at junk.mail> a écrit dans le message de news:
3F0E78D3.7FB1 at junk.mail...
> I tried now running the very same application without propagating the
> status (invisible bot) and without using global mode:
>
> Bot is at 6N, object to be clicked is on 19N.
>
> 1) When using an invisible bot, the problem stays the same, the click
> event is first only rarely and after a short time not at all anymore
> raised, but when the object is moved to 17N, it works reliably every
> time.
>
> 2) When NOT using global mode, the click event is raised reliably every
> time (provided the object stays within the perception range of the bot,
> so it works eg. fine at 19N).
>
>
> Therefore, the problem is definitely related to the global event state,
> but I am not able to find out any further condition that could cause the
> problem.
>
>
>
>
>
>
[View Quote]

Jul 11, 2003, 4:13pm

This is very unlikely, because,

a) it stopped working reliably in the moment when I changed the WORLD
server from 3.3 to 3.4 with no change to code or wrapper altogether.

b) It works sometimes, but the event raising becomes morer and more rare
until it finally does not raise at all, while all other events, like
avatar click etc. keep working reliably.

c) It works fine as soon as I set global mode to OFF

I assume there must be another factor, maybe some combination of world
options, which breaks it.



[View Quote]

Jul 11, 2003, 6:33pm

I did now some extensive testing and...

the very same application works well in some worlds, works less good in
others and in a third group, it is very unreliable (all those worlds on
the same world server). Even when using the same world settings, it
behaves different in different worlds.
Within these worlds, the behaviour is consistent, though - eg. leaving
and coming back or stopping/starting the world will result in the very
same behaviour as before.

There seems to be some general pattern though: The slower the response
on an object click event, the more likely it will, sooner or later, not
raise an event at all.

I conclude that this is a world server issue, since the same application
yields on the same world server in worlds with same settings different
results.
It might have to do with how and where objects are stored and looked up
in the database and an object lookup takes up a very short time or a
long time (and when it takes a long time, some sort of event discard or
timeout takes place which subsequently then not propagates the event).
In worlds with an unreliable propagation, the "safe zone" is not
centered around the bot or the ground zero, but the "safe" rectangle can
be shifted into one direction (eg. you get reliable results up to 11N,
but down to 20S), which points also to an object-related reason.

The reason is definitely not the global mode itself and not the wrapper
or sdk either, since, like said above, in some worlds it works well, in
some less good and in others very unreliable (outside the "safe zone").

Changing the aw_wait value does not make a difference in all that, btw.

What I did not try yet is to set up a seperate world server and put the
"unreliable" worlds into it - if it is working then, it was a matter of
world server load situation either for the event queue or the object
storage lookup.







[View Quote]

Jul 11, 2003, 7:12pm

Did you try with another bot?
i am sure you can setup a xelagot or a preston and see if this bot detects
clicks that your bot doesn't detect. This is a needed test because it seems
that, so far, you are the only one having this problem.

Secondly, the problem could be a bug in sdk when the bot is in global AND
visible. just make your bot invisible in the worlds you found are
unreliable, this would help to clarify the problem. then you could try the
same with a xelagot and see if you see the same trouble.

Regards,
MilesTeg




"kf" <none at junk.mail> a écrit dans le message de news:
3F0F1DA6.4600 at junk.mail...
> I did now some extensive testing and...
>
> the very same application works well in some worlds, works less good in
> others and in a third group, it is very unreliable (all those worlds on
> the same world server). Even when using the same world settings, it
> behaves different in different worlds.
> Within these worlds, the behaviour is consistent, though - eg. leaving
> and coming back or stopping/starting the world will result in the very
> same behaviour as before.
>
> There seems to be some general pattern though: The slower the response
> on an object click event, the more likely it will, sooner or later, not
> raise an event at all.
>
> I conclude that this is a world server issue, since the same application
> yields on the same world server in worlds with same settings different
> results.
> It might have to do with how and where objects are stored and looked up
> in the database and an object lookup takes up a very short time or a
> long time (and when it takes a long time, some sort of event discard or
> timeout takes place which subsequently then not propagates the event).
> In worlds with an unreliable propagation, the "safe zone" is not
> centered around the bot or the ground zero, but the "safe" rectangle can
> be shifted into one direction (eg. you get reliable results up to 11N,
> but down to 20S), which points also to an object-related reason.
>
> The reason is definitely not the global mode itself and not the wrapper
> or sdk either, since, like said above, in some worlds it works well, in
> some less good and in others very unreliable (outside the "safe zone").
>
> Changing the aw_wait value does not make a difference in all that, btw.
>
> What I did not try yet is to set up a seperate world server and put the
> "unreliable" worlds into it - if it is working then, it was a matter of
> world server load situation either for the event queue or the object
> storage lookup.
>
>
[View Quote]

Jul 11, 2003, 8:48pm

The bot being visible or not does not make a difference.


[View Quote]

Jul 11, 2003, 9:32pm

I used Xelagot 3.419 for a cross check now (script:
avatar_object_click.txt) - with exactly the SAME results.

In fact, when running both applications at once, both see the same
events raised and the same events not raised.







[View Quote]

Jul 11, 2003, 10:15pm

Did you try to reload the properties of a world that you saw unreliable?
try and tell me if it fix your problem
because few months ago, i experienced several times a lost of click events
and found that reloading the properties was solving the problem. this
problem didn t occur to me for a long time now, what world server build are
you using?

Regards,
MilesTeg


"kf" <none at junk.mail> a écrit dans le message de news:
3F0F4815.207D at junk.mail...
> I used Xelagot 3.419 for a cross check now (script:
> avatar_object_click.txt) - with exactly the SAME results.
>
> In fact, when running both applications at once, both see the same
> events raised and the same events not raised.
>
>
>
>
>
>
>
[View Quote]

Jul 11, 2003, 10:23pm

1) I have set up a seperate world server only for one world and loaded
the non-working world fresh from dumps I just made: It still did not
work

2) Then I used an especially brutal attempt by using the complete
attributes set from another (working) world and implanted it into this
world - and ...

Now it worked! Every single object click event is raised , which turns
my attention now to the world attributes, since it seems that there must
be some setting in there which prevents the object click event from
being raised properly. To countercheck on this first,

3) I removed the "wrong" attributes set and re-loaded the original one
from the dump (same as in in the first try) and now it kept working,
which means the attributes are not responsible.

4) Fourth try then - I used again the original world server and deleted
the world from the server, then reloaded: not working, then, as in #3,
loaded attributes from another world - now sometimes not working, also
very slow, then reloaded original attributes and it did not work
anymore.
The world server load at this time was, BTW, 2 idling citizens, 6 idling
bots and 14 worlds with a combined 90,000 objects and P-80 size. Out of
that, this non-responsive world has ca. 4,000 objects in a P30 size.

5) Finally I ran again the seperate world server: works

=========================

Conclusion:

There is an issue with the world server, namely with the object
lookup/storage, which causes the world server even by a low load (the
above numbers I do not consider to be a "load") to become temporarily
unresponsive to object click events.

It might, as well, be a problem with the world ID number (in this case:
74), maybe high IDs in a world server are less responsive than lower
ones

A few weeks back, I asked about experiences or limitations with world
server loads, since I suspected by then already that there are
load/response issues, though I did not get any response. It might be a
good idea, when there are no recommendations, to keep the numbers of
worlds in a world server (this goes to the Linux version, with which I
tested it) low, probably around 10 running worlds altogether (unless the
number of stopped worlds also plays a role in this).

--------

Possible workarounds:

- Using seperate world servers (can be on the same physical machine
even) to reduce the load (probably coming either from the sheer world
number/ID or from object numbers around 100,000).

- Using object clicks only in a safe zone of ca. 12 cells around GZ







[View Quote]

Jul 11, 2003, 10:27pm

See my previous post for various checks, the world server build used it
the latest: 56 (happend with 55 before as well, did not happen with 43)
in the Linux version. I do not bother to try all this with a windows
version as well, but it would be interesting to know how the OS versions
differ, especially when it comes to load issues.




[View Quote]

Jul 12, 2003, 1:18am

[View Quote] > 1) I have set up a seperate world server only for one world and loaded
> the non-working world fresh from dumps I just made: It still did not
> work
>
> 2) Then I used an especially brutal attempt by using the complete
> attributes set from another (working) world and implanted it into this
> world - and ...
>
> Now it worked! Every single object click event is raised , which turns
> my attention now to the world attributes, since it seems that there must
> be some setting in there which prevents the object click event from
> being raised properly. To countercheck on this first,
>
> 3) I removed the "wrong" attributes set and re-loaded the original one
> from the dump (same as in in the first try) and now it kept working,
> which means the attributes are not responsible.
>
> 4) Fourth try then - I used again the original world server and deleted
> the world from the server, then reloaded: not working, then, as in #3,
> loaded attributes from another world - now sometimes not working, also
> very slow, then reloaded original attributes and it did not work
> anymore.
> The world server load at this time was, BTW, 2 idling citizens, 6 idling
> bots and 14 worlds with a combined 90,000 objects and P-80 size. Out of
> that, this non-responsive world has ca. 4,000 objects in a P30 size.
>
> 5) Finally I ran again the seperate world server: works
>
> =========================
>
> Conclusion:
>
> There is an issue with the world server, namely with the object
> lookup/storage, which causes the world server even by a low load (the
> above numbers I do not consider to be a "load") to become temporarily
> unresponsive to object click events.
>
> It might, as well, be a problem with the world ID number (in this case:
> 74), maybe high IDs in a world server are less responsive than lower
> ones
>
> A few weeks back, I asked about experiences or limitations with world
> server loads, since I suspected by then already that there are
> load/response issues, though I did not get any response. It might be a
> good idea, when there are no recommendations, to keep the numbers of
> worlds in a world server (this goes to the Linux version, with which I
> tested it) low, probably around 10 running worlds altogether (unless the
> number of stopped worlds also plays a role in this).
>
> --------
>
> Possible workarounds:
>
> - Using seperate world servers (can be on the same physical machine
> even) to reduce the load (probably coming either from the sheer world
> number/ID or from object numbers around 100,000).
>
> - Using object clicks only in a safe zone of ca. 12 cells around GZ
>
>
>
>
<snip>

To throw my 2 cents into this thread:
My Easter EggHunt (and the Christmas one) uses the HuntBot which relies on the object click event heavily. In the past I tried to use my standard world server on the Linux machine but it crashed in no time, so I had to switch to the Windows version. (I don't recall the version number but it was more than a year ago).
Now every time I hold a hunt, I just copy over the prop to a windows server and I use the build 43 for the event.
The hunt involves around 80,000+ clickable objects now and with 80 ppl clicking all over the place I guess it is a pretty heavy load. The Linux version just couldn't keep up with the demand.
I did not complain because I found a workaround (and I was prepared to switch over!) but I think this bug should be targeted sooner or later.

HTH
--
Andras
"It's MY computer" (tm Steve Gibson)

Jul 12, 2003, 8:08am

"andras" <andras at andras.net> a écrit dans le message de news:
3f0f7e06$2 at server1.Activeworlds.com...
[View Quote] I use a windows worldserver, that could explain i have no problem :)

MilesTeg

1  |   Order by index