1  2  3  4  5  6  ...  10  |   Order by default

Nov 11, 2002, 1:30am

Is there any example on how to query, store and save terrain data using
the VB sdk? The method is different from the one described in the C sdk,
but no examples are supplied, just the list of variables in the readme
file.

Now, before trying to figure it out myself by trial and error, my
question: Is there anybody who managed to get it working already - and
if yes, would you mind to give an example on it?

Any help/hint is much appreciated! :-)

Dec 4, 2002, 12:18am

- The minimum movement up and down appears to be unchanged, at least
there is no noticeable difference for me.

- Movement has become _extremely_ slow in most areas, the slowdown has
at least a factor of 5-10. I didn't find out the reason yet, but it
probably has either to do with collision detection or with rendering
distant items. When I walk it, is 70% of the time at speed x, 20% of the
time at speed x/2 (nearly standing still) and 10% of the time at speed
x*y (where x*y is the normal speed in v446.

- The same applies to moving up and down, though to a lesser degree.

- "Sliding" along a vertical wall and standing on a vertical floor only
works in one direction (here: S->N) normally, in the other direction it
only works at an almost parallel angle.

- Pressing the (unassigned) CTRL key alone left me move sideways (to the
left) also down, when in the air - while shift+arrow key let me also
move sideways, but slower to the left and much slower to the right.

- When moving, touching the floor is noticeable (the rendering stops for
a moment and then speeds up again, also the movement speed for a tenth
of a second)

- The update process crashes the update program

client v447, DirectX T&L, Ti4400, P3/1000

Dec 4, 2002, 12:33am

[View Quote] Ack :-(
This posting was supposed to go into the beta group - can maybe someone
please move it over there or delete it here - I will post it again into
the beta group?

Apr 15, 2003, 3:17pm

I am also waiting. :-( He once said it will be released when 3.4 comes
out.





[View Quote]

Apr 15, 2003, 3:41pm

That was before, when 999 was still often in AW.


[View Quote]

Jun 11, 2003, 11:57am

Normally, when a bot is disconnected (eg. line is disconnected), he will
automatically reconnect when it is possible again.

However...

I noticed, that with bots in global mode, they often (or always?) log
back in normal (non-global) mode.

The documentation does not say whether this is the intended behaviour or
not, but it appears to me that, on/after each disconnect, the wisest
decision is to destroy the instance and log the bot back in manually.

Jun 11, 2003, 12:00pm

Maybe it is a good idea to collect all the oddities of the current sdk,
(especially in global mode) - so the developers will have it easier to
look up the bugs. :-)

With no doubt, the sdk is an integral part of the AW environment and
deserves a high level of attention as well.

Jul 1, 2003, 5:36pm

Actually, even the browser do not see changes all the time:

Make an application in which a click on an avatar will change this
avatar type and call in 2-3 friends to click on each other.
What happens now is that sometimes, you can see the change, sometimes
not, sometimes the bot sees it, sometimes not, sometimes one or another
avatar cannot see it unless they leave the world and re-enter, etc.

The process is totally unreliable since the effects are random at best
<g>.







[View Quote]

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: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 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, 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, 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, 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, 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: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 21, 2003, 1:36pm

VB can, via Windows API call, also get the GMT and the settings for the
local time zone (which you need to calculate the actual time difference
between VRT(=GMT-3) and the local time).

Another, very easy, method would be to have people put in the time
difference to GMT into the ini file of the application and then work
internally only with GMT-3 +- x



[View Quote]

Nov 19, 2003, 8:29am

IMO such a concept will be added with V 4.0






[View Quote]

Dec 3, 2003, 5:27pm

Although your investigation is correct, and short disconnects cause,
indeed, all sorts of problems, it is not the whole of this problem.

The missing avatar name issue happens as well when a connection had not
timed out either by the universe or the world, and the same is true for
bots changing their avatar type unmotivated.
As for the chat, I had already circumstances in which chat of certain
persons was not received anymore, even when they did not time out - they
simply, after a while, stop reporting to the sdk.

The whole sdk issue appears to require a basic overhaul of the affected
mechanisms, unfortunately, there is none - NONE - response whatsoever to
the reported problems from the side of AW.
The problem is that a good number of sdk applications cannot be trusted
anymore and become simply unuseable for environments that rely on them,
and this is not exactly a "minor" flaw. Furthermore, the constant
ignorance of the existing problems is not satisfactory at all.





[View Quote]

Dec 7, 2003, 5:02pm

copied from worldbuilders:



[View Quote]

Dec 11, 2003, 5:56pm

Yes, I agree, this is a bug - unless a bot is, by the developers,
supposed to keep the avatar with which he logged into the universe.

Even with the workaround, which I use also, I see the avatar switching
back and forth between the type the server sets and the type I force him
back into - and this happens although I issue the command right away:

Result = sdk.aw_state_change
Result = sdk.aw_int_set(AW_AVATAR_TYPE, mytype)
Result = sdk.aw_int_set(AW_AVATAR_GESTURE, 0)
Result = sdk.aw_avatar_set(mysession)

In this regard, even when the programmer provides type and gesture on
each state_change (which is, btw, a huge unnecessary server load, eg.
when multiple bots are moving) - it will not work correctly, so this
cannot be a non-feature, but only a bug.

Actually, when you set another gesture than 0, the gesture will start
again and not continue - this might look quite funny in certain
circumstances <g>.



[View Quote]

1  2  3  4  5  6  ...  10  |   Order by default