Thread

Bots vs 'usual' Avatars (Sdk)

Bots vs 'usual' Avatars // Sdk

1  2  |  

baggis

Feb 15, 1999, 3:21am
Hi,

Is there a way to make a bot act like a 'human controlled' avatar in the
meaning that it 'knows' about solid objects and also has 'gravity' ?

So far I've only seen that a SDK bot moves by using a given Y-coordinate
that has nothing to do with if it's above, at the same level or below
(inside) an object ( for ex. a house ) that an 'normal (human)' avatar is
able to walk on.

Also, when a 'normal' avatar walks into a solid object it stops ( unless
pressing Shift and 'walk-through' is enabled ), a SDK bot merely walks
through the object.

Tnx

/Jan ( AW cit 'Baggis' )

edward sumerfield

Feb 15, 1999, 1:20pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
The SDK does not support collision detection. We have discussed ways of
<br>implementing it ourselves but as there is no way of getting the constraints
<br>of each object from the sdk, you have to maintain your own list of
object
<br>sizes. I posted an array of all the sizes of objects in AW once. I
am not
<br>sure if anyone is using it.
<p>No gravity either. Must implement 10meters/sec/sec acceleration downwards
<br>yourself, but of coarse, must have collusion detection first or you
will
<br>just keep on falling.
[View Quote]

baggis

Feb 15, 1999, 1:45pm
This is a multi-part message in MIME format.

------=_NextPart_000_003D_01BE5902.A0937EA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Seems the SDK could be improved ? ;-)=20

/Baggis
[View Quote]


------=_NextPart_000_003D_01BE5902.A0937EA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 =
transitional//en">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Seems the SDK could be improved ? ;-) </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>/Baggis</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] =
href=3D"mailto:36C83B27.4C5D5C8 at poboxes.com">36C83B27.4C5D5C8 at poboxes.com=
</A>&gt;...</DIV>The=20
SDK does not support collision detection. We have discussed ways of=20
<BR>implementing it ourselves but as there is no way of getting the=20
constraints <BR>of each object from the sdk, you have to maintain =
your own=20
list of object <BR>sizes. I posted an array of all the sizes of =
objects in=20
AW once. I am not <BR>sure if anyone is using it.=20
<P>No gravity either. Must implement 10meters/sec/sec acceleration =
downwards=20
<BR>yourself, but of coarse, must have collusion detection first or =
you will=20
<BR>just keep on falling.=20
<P>&nbsp;</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003D_01BE5902.A0937EA0--

byte me

Feb 15, 1999, 4:38pm
It is close to imposible for Roland to put collision detection into the
SDK its self because he will have to allow the SDK to retrieve object
paths which could be used by hackers or object stealers to get the
address to a worlds object server, and plus there is cases when you do
not need collision detect, but others you do...

[View Quote] > Seems the SDK could be improved ? ;-) /Baggis
>
[View Quote]

edward sumerfield

Feb 15, 1999, 6:32pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Interesting. It was my understanding that it was the browser that made
the connection to the worlds object server so it is very easy to find its
address just by entering the netstat -an command at the appropriate time.
<p>AW Browser --- ( login ) ---------------------> Universe server
<br>AW Browser &lt;-- ( worlds list ) ----------------- Universe server
<br>AW Browser --- ( get world IP and port ) ----> Universe server
<br>AW Browser --- ( enter world ) --------------> World server
<br>AW Browser &lt;-- ( object information ) --------&nbsp; World server
<br>AW Browser --- ( connect to web server -----> Object server
<br>AW Browser &lt;-- ( GET object ) --------------- Object server
<br>AW Browser --- ( disconnect ) ----------------> Object server
<p>So, anyone, even object stealers, should have no problem in their theft,
even without the SDK. I didn't even realize this was a problem.
<p>In some worlds you can see the object server name in the Settings->World
mennu option.
<p>Collision detection is possible for the SDK but it will be some time
coming I think. Once this version is stable and released then I would be
interested in seeing the list of prioritized enhancements.
[View Quote]

byte me

Feb 15, 1999, 8:16pm
Well I tried using the SDK's AW_WORLD_OBJECT_SERVER and it returned anm
empty stirng until I put it in a world I had caretaker in... Roland did
this to protect people, and no you can not see the server in AW either,
you could back in 1.2 and lower...

[View Quote] > Interesting. It was my understanding that it was the browser that made
> the connection to the worlds object server so it is very easy to find
> its address just by entering the netstat -an command at the
> appropriate time.
>
> AW Browser --- ( login ) ---------------------> Universe server
> AW Browser <-- ( worlds list ) ----------------- Universe server
> AW Browser --- ( get world IP and port ) ----> Universe server
> AW Browser --- ( enter world ) --------------> World server
> AW Browser <-- ( object information ) -------- World server
> AW Browser --- ( connect to web server -----> Object server
> AW Browser <-- ( GET object ) --------------- Object server
> AW Browser --- ( disconnect ) ----------------> Object server
>
> So, anyone, even object stealers, should have no problem in their
> theft, even without the SDK. I didn't even realize this was a problem.
>
> In some worlds you can see the object server name in the
> Settings->World mennu option.
>
> Collision detection is possible for the SDK but it will be some time
> coming I think. Once this version is stable and released then I would
> be interested in seeing the list of prioritized enhancements.
>
[View Quote]

=?iso-8859-1?q?eep=b2?=

Feb 15, 1999, 9:37pm
Um, Byte, it's not too hard to get the object server of the world you just entered, you know. Just look in the cache directory and see which directory is the newest. Duh.

[View Quote] > It is close to imposible for Roland to put collision detection into the SDK its self because he will have to allow the SDK to retrieve object paths which could be used by hackers or object stealers to get the address to a worlds object server, and plus there is cases when you do not need collision detect, but others you do...

roland vilett

Feb 16, 1999, 1:43am
This is a multi-part message in MIME format.

------=_NextPart_000_0067_01BE591B.7A2FE1E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If anyone has any suggestions for how to provide this easily, I'm all =
ears. As far as I can tell, it would be a mammoth project to include =
object collision within the SDK itself. Object collision would mean =
that, among other things, the SDK would have to download all the objects =
from the object path itself, unzip them, and load them in to RenderWare =
(note this would require that SDK apps now link to the RenderWare DLLs) =
in order to determine their geometry in order to check for collisions.

Some features I've been contemplating for future versions of Active =
Worlds may at some point make it so that an object's basic dimension =
information might be something that an SDK application could query from =
a world server. If this were provided then some basic collision =
detection could be provided, although it should be noted that object =
dimensions are not sufficient to provide highly accurate collision =
detection, only the more basic "bounding box" collision. The more =
precise polygon-based collision detection that the AW browsers provides =
requires knowledge of the complete geometry of the object.

-Roland

[View Quote]


------=_NextPart_000_0067_01BE591B.7A2FE1E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>If anyone has any suggestions for =
how to provide=20
this easily, I'm all ears.&nbsp; As far as I can tell, it would be a =
mammoth=20
project to include object collision within the SDK itself.&nbsp; Object=20
collision would mean that, among other things, the SDK would have to =
download=20
all the objects from the object path itself, unzip them, and load them =
in to=20
RenderWare (note this would require that SDK apps now link to the =
RenderWare=20
DLLs) in order to determine their geometry in order to check for=20
collisions.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Some features I've been =
contemplating for future=20
versions of Active Worlds may at some point make it so that an object's =
basic=20
dimension information might be something that an SDK application could =
query=20
from a world server.&nbsp; If this were provided then some basic =
collision=20
detection could be provided, although it should be noted that object =
dimensions=20
are not sufficient to provide highly accurate collision detection, only =
the more=20
basic &quot;bounding box&quot; collision.&nbsp; The more precise =
polygon-based=20
collision detection that the AW browsers provides requires knowledge of =
the=20
complete geometry of the object.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>-Roland</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] ------=_NextPart_000_0067_01BE591B.7A2FE1E0--

rjinswand

Feb 16, 1999, 4:20am
This is a multi-part message in MIME format.

------=_NextPart_000_001B_01BE5931.76FCC860
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_001C_01BE5931.76FCC860"


------=_NextPart_001_001C_01BE5931.76FCC860
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Rather than have each bot do the object downloading it'd make a lot =
more sense in many ways to have the world server do this and maintain =
its own specialised object cache. Unfortunately, again we have the =
problem with Renderware tying us to a platform though... because only =
the Windows version of the world server would have these facilities.
Alternatively someone could write a generic C rwx loading library (for =
geometry only) and that could be incorporated into the world server.
Lots of possibilities, lots of work, lots of issues.

Rjinswand


Basically we're talking about a second database for the world server... =
the world server=20
[View Quote]
------=_NextPart_001_001C_01BE5931.76FCC860
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!doctype html =
public "-//w3c//dtd html 4.0 transitional//en">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#f0f0f0>
<DIV><FONT color=3D#000000 size=3D2>&nbsp; <FONT size=3D3>Rather than =
have each bot do=20
the object downloading it'd make a lot more sense in many ways to have =
the world=20
server do this and maintain its own specialised object cache.&nbsp;=20
Unfortunately, again we have the problem with Renderware tying us to a =
platform=20
though... because only the Windows version of the world server would =
have these=20
facilities.</FONT></FONT><FONT size=3D3></FONT></DIV>
<DIV><FONT color=3D#000000><FONT size=3D3></FONT></FONT><FONT =
size=3D3>&nbsp;=20
Alternatively someone could write a generic C rwx loading library (for =
geometry=20
only) and that could be incorporated into the world server.</FONT></DIV>
<DIV><FONT size=3D2><FONT size=3D3>&nbsp; Lots of possibilities, lots of =
work, lots=20
of issues.</FONT></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;=20
<STRONG><EM>Rjinswand</FONT></EM></STRONG></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Basically we're talking about a =
second database=20
for the world server... the world server </FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] ------=_NextPart_001_001C_01BE5931.76FCC860--

------=_NextPart_000_001B_01BE5931.76FCC860
Content-Type: text/x-vcard;
name="Rjinswand.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Rjinswand.vcf"

BEGIN:VCARD
VERSION:2.1
N:;Rjinswand
FN:Rjinswand
ORG:Rjeneration
URL:
URL:http://table.jps.net/~rjins/rjeneration
EMAIL;PREF;INTERNET:bcnu at psicorps.com
REV:19990216T062059Z
END:VCARD

------=_NextPart_000_001B_01BE5931.76FCC860--

edward sumerfield

Feb 16, 1999, 1:53pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#F0F0F0">
I believe the RenderWare graphics libraries are available on multiple platforms.
I thought this was a good reason why they were chosen by AW in the first
place.
<p>If the object file transfer is migrated into the world server you would
be adding a significant load onto it as opposed to distributing that load
onto each browser machine.
<p>Roland, the AW browser must already have the code to do the object downloading
and uncompressing in it. Is it not possible to include some of this in
the SDK. This would give you the advantage of maintaining the same cache
algorithms. There is just no rendering of the objects once you get them.
<p>I agree you would need the renderware dlls to use the sdk but I don't
think that is a big issue. You could pretentiously package the SDK into
two portions, the existing AWSDK.dll and then a AWCOLLISION.dll plus renderware
dlls. This would allow bots that do not require collision detection to
be shipped in a smaller package.
[View Quote] </body>
</html>

rjinswand

Feb 16, 1999, 3:39pm
This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BE5990.501D1B00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0016_01BE5990.501D1B00"


------=_NextPart_001_0016_01BE5990.501D1B00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RenderWare is only available for PC and Mac these days... they dropped =
all UNIX support with 2.1 I think. It IS a big deal requiring the =
Renderware DLLs for using the SDK. :/

Rjinswand


[View Quote] Roland, the AW browser must already have the code to do the object =
downloading and uncompressing in it. Is it not possible to include some =
of this in the SDK. This would give you the advantage of maintaining the =
same cache algorithms. There is just no rendering of the objects once =
you get them.=20

I agree you would need the renderware dlls to use the sdk but I =
don't think that is a big issue. You could pretentiously package the SDK =
into two portions, the existing AWSDK.dll and then a AWCOLLISION.dll =
plus renderware dlls. This would allow bots that do not require =
collision detection to be shipped in a smaller package.=20

[View Quote] Rather than have each bot do the object downloading it'd make =
a lot more sense in many ways to have the world server do this and =
maintain its own specialised object cache. Unfortunately, again we have =
the problem with Renderware tying us to a platform though... because =
only the Windows version of the world server would have these =
facilities. Alternatively someone could write a generic C rwx loading =
library (for geometry only) and that could be incorporated into the =
world server. Lots of possibilities, lots of work, lots of issues. =
Rjinswand Basically we're talking about a second database for the world =
server... the world server=20
[View Quote] ------=_NextPart_001_0016_01BE5990.501D1B00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 =
transitional//en">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#f0f0f0>
<DIV><FONT color=3D#000000 size=3D2><FONT size=3D3>&nbsp; RenderWare is =
only available=20
for PC and Mac these days... they dropped all UNIX support with 2.1 I=20
think.&nbsp; It IS a big deal requiring the Renderware DLLs for using =
the=20
SDK.&nbsp; :/</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
size=3D3></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; <FONT=20
size=3D3><STRONG><EM>Rjinswand</EM></STRONG></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] =
href=3D"mailto:36C99497.F0FAEE95 at poboxes.com">36C99497.F0FAEE95 at poboxes.c=
om</A>&gt;...</DIV>I=20
believe the RenderWare graphics libraries are available on multiple=20
platforms. I thought this was a good reason why they were chosen by =
AW in=20
the first place.=20
<P>If the object file transfer is migrated into the world server you =
would=20
be adding a significant load onto it as opposed to distributing that =
load=20
onto each browser machine.=20
<P>Roland, the AW browser must already have the code to do the =
object=20
downloading and uncompressing in it. Is it not possible to include =
some of=20
this in the SDK. This would give you the advantage of maintaining =
the same=20
cache algorithms. There is just no rendering of the objects once you =
get=20
them.=20
<P>I agree you would need the renderware dlls to use the sdk but I =
don't=20
think that is a big issue. You could pretentiously package the SDK =
into two=20
portions, the existing AWSDK.dll and then a AWCOLLISION.dll plus =
renderware=20
dlls. This would allow bots that do not require collision detection =
to be=20
shipped in a smaller package.=20
[View Quote] though... because only the Windows version of the world server =
would=20
have these facilities.</FONT></FONT><FONT size=3D+0>&nbsp; =
Alternatively=20
someone could write a generic C rwx loading library (for =
geometry only)=20
and that could be incorporated into the world =
server.</FONT><FONT=20
size=3D+0>&nbsp; Lots of possibilities, lots of work, lots of=20
issues.</FONT>&nbsp;<FONT color=3D#000000><FONT =
size=3D-1>&nbsp;&nbsp;&nbsp;=20
<B><I>Rjinswand</I></B></FONT></FONT>&nbsp;&nbsp;<FONT=20
color=3D#000000><FONT size=3D-1>Basically we're talking about a =
second=20
database for the world server... the world server</FONT></FONT>=20
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">Roland=20
[View Quote] ------=_NextPart_001_0016_01BE5990.501D1B00--

------=_NextPart_000_0015_01BE5990.501D1B00
Content-Type: text/x-vcard;
name="Rjinswand.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Rjinswand.vcf"

BEGIN:VCARD
VERSION:2.1
N:;Rjinswand
FN:Rjinswand
ORG:Rjeneration
URL:
URL:http://table.jps.net/~rjins/rjeneration
EMAIL;PREF;INTERNET:bcnu at psicorps.com
REV:19990216T173956Z
END:VCARD

------=_NextPart_000_0015_01BE5990.501D1B00--

edward sumerfield

Feb 16, 1999, 5:15pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#F0F0F0">
Why is a big deal to have to include the Renderware DLLs?
[View Quote] </body>
</html>

=?iso-8859-1?q?eep=b2?=

Feb 16, 1999, 6:11pm
I must question this, as if the ability to uncompress objects in encrypted ZIPs is allowed, what's to prevent SDK developers from getting them?

[View Quote] > Roland, the AW browser must already have the code to do the object downloading and uncompressing in it. Is it not possible to include some of this in the SDK. This would give you the advantage of maintaining the same cache algorithms. There is just no rendering of the objects once you get them.

edward sumerfield

Feb 16, 1999, 6:36pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I am not entirely sure what you are questioning Eep&sup2;. Why should we
"prevent SDK programmers from getting them". All objects are freely available
from the object servers anyway.
<p>I have found no "encrypted" zips on the aw object server. I have found
files that are suffixed with .zip but are actually just .gz compressed
files. No encryption just compression in standard formats.
[View Quote]

walter knupe

Feb 16, 1999, 7:20pm
Well, security by hiding an implementation in the aw browser is no security
anyway...

the gain would be bots acting a lot more "natural", or a bot which uses
completely different methods for 3d display than the browser...

and the loss is close to nothing.

Walter aka Faber

Eep² schrieb in Nachricht <36C9D0F1.2420FE88 at tnlc.com>...
>I must question this, as if the ability to uncompress objects in encrypted
ZIPs is allowed, what's to prevent SDK developers from getting them?
>
[View Quote]

shamus young

Feb 16, 1999, 7:25pm
Some objects are encrypted to prevent wholesale theft of objects. While aw
and many others are not passworded, other worlds do have an object password
in place.

When you log into a world, the browser gets the world password and uses it
on the objects it downloads. If this abaility was given openly to sdk users
within their program they would have to have the password in order to
unzip - thus allowing anyone with the sdk to get a world artwork password.

But to answer Eeps question: There would be ways around this problem, for
example:

1) only giving the password to bots with caretaker rights. (thus only the
caretaker of the world could get the password, which they already have
anyway) Thus if your bot entered a world where it did not have caretaker it
would not have access to any of the objects.

2)hide the password <>decryption scheme within the sdk itself, so that I
would simply call aw_get_object("objectname.rwx") and the sdk would return
the model - thus never allowing the programmer access to the password.



There are other ways, im sure. I doubt Roland was really proposing that we
open some giant security hole. :)

Shamus Young
Artwork / World Developer
Activeworlds.com, Inc
Email: shamus at activeworlds.com
Personal Homepage: http://users.penn.com/~shamus/
================================================
- - --= A C T I V E W O R L D S =-- - -
See the future of the net in a 3D interactive world!
http://www.activeworlds.com


[View Quote] [View Quote] I must question this, as if the ability to uncompress objects in
encrypted ZIPs is allowed, what's to prevent SDK developers from getting
them?
[View Quote] > Roland, the AW browser must already have the code to do the object
downloading and uncompressing in it. Is it not possible to include some of
this in the SDK. This would give you the advantage of maintaining the same
cache algorithms. There is just no rendering of the objects once you get
them.

roland vilett

Feb 16, 1999, 7:25pm
This is a multi-part message in MIME format.

------=_NextPart_000_0023_01BE59AF.CF743180
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

For the reasons that RJ stated, as well as many others. For one thing, =
RenderWare is not available under Unix, and a Unix port of SDK is =
currently very high up on the to-do list. Also, it would immensely =
bloat the SDK out from a single 80K DLL to hundreds of K with multiple =
DLLs making it that much more difficult for newbies to get a handle on =
things. To me, including RenderWare with the SDK in order to provide =
collision detection would be like including Windows98 with a PalmPilot =
just so you could use the "dingbats" font.

Finally, and most seriously, there is a licensing problem. RenderWare =
is a licensed product. Our license does not give us the right to =
re-distribute it to developers for their own applications. If the SDK =
included RenderWare, no developer could legally release any program they =
wrote using the SDK.

In short, I do think that collision detection in the SDK is something =
that can and should be done. It's just that using RenderWare isn't the =
right way to do it. A future solution where the world server (or perhaps =
another server accessible via the SDK) has far more intimate knowledge =
of object geometry is far more appealing.

-Roland
[View Quote] RenderWare is only available for PC and Mac these days... =
they dropped all UNIX support with 2.1 I think. It IS a big deal =
requiring the Renderware DLLs for using the SDK. :/ Rjinswand =20
[View Quote] Roland, the AW browser must already have the code to do the =
object downloading and uncompressing in it. Is it not possible to =
include some of this in the SDK. This would give you the advantage of =
maintaining the same cache algorithms. There is just no rendering of the =
objects once you get them.=20

I agree you would need the renderware dlls to use the sdk =
but I don't think that is a big issue. You could pretentiously package =
the SDK into two portions, the existing AWSDK.dll and then a =
AWCOLLISION.dll plus renderware dlls. This would allow bots that do not =
require collision detection to be shipped in a smaller package.=20

[View Quote] Rather than have each bot do the object downloading =
it'd make a lot more sense in many ways to have the world server do this =
and maintain its own specialised object cache. Unfortunately, again we =
have the problem with Renderware tying us to a platform though... =
because only the Windows version of the world server would have these =
facilities. Alternatively someone could write a generic C rwx loading =
library (for geometry only) and that could be incorporated into the =
world server. Lots of possibilities, lots of work, lots of issues. =
Rjinswand Basically we're talking about a second database for the world =
server... the world server=20
[View Quote] ------=_NextPart_000_0023_01BE59AF.CF743180
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 =
transitional//en">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#f0f0f0>
<DIV><FONT color=3D#000000 face=3D"" size=3D3>For the reasons that RJ =
stated, as well=20
as many others.&nbsp; For one thing, RenderWare is not available under =
Unix, and=20
a Unix port of SDK is currently very high up on the to-do list.&nbsp; =
Also, it=20
would immensely bloat the SDK out from a single 80K DLL to hundreds of K =
with=20
multiple DLLs making it that much more difficult for newbies to get a =
handle on=20
things.&nbsp; To me, including RenderWare with the SDK in order to =
provide=20
collision detection would be like including Windows98 with a PalmPilot =
just so=20
you could use the &quot;dingbats&quot; font.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"" size=3D3></FONT>&nbsp;</DIV>
<DIV>Finally, and most seriously, there is a licensing problem.&nbsp; =
RenderWare=20
is a licensed product. Our license does not give us the right to =
re-distribute=20
it to developers for their own applications.&nbsp; If the SDK included=20
RenderWare, no developer could legally release any program they wrote =
using the=20
SDK.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In short, I do think that collision detection in the SDK is =
something that=20
can and should be done.&nbsp; It's just that using RenderWare isn't the =
right=20
way to do it. A future solution where the world server (or perhaps =
another=20
server accessible via the SDK) has far more intimate knowledge of object =

geometry is far more appealing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-Roland</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] =
href=3D"mailto:36C9C3EA.3019C74C at poboxes.com">36C9C3EA.3019C74C at poboxes.c=
om</A>&gt;...</DIV>Why=20
is a big deal to have to include the Renderware DLLs?=20
[View Quote] geometry only) and that could be incorporated into the =
world=20
server.&nbsp; Lots of possibilities, lots of work, lots =
of=20
issues.</FONT>&nbsp;<FONT color=3D#000000><FONT=20
size=3D-1>&nbsp;&nbsp;&nbsp;=20
<B><I>Rjinswand</I></B></FONT></FONT>&nbsp; <FONT=20
color=3D#000000><FONT size=3D-1>Basically we're talking =
about a=20
second database for the world server... the world=20
server</FONT></FONT>=20
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: =
5px; PADDING-LEFT: 5px">Roland=20
[View Quote] ------=_NextPart_000_0023_01BE59AF.CF743180--

the wanderer

Feb 16, 1999, 7:32pm
Number one would work, but number two still creates a problem. My app
makes the call as you state and then simply saves the now unencrypted
rwx file in a seperate directory.

[View Quote]

=?iso-8859-1?q?eep=b2?=

Feb 16, 1999, 9:02pm
If avatars only have collision detection based on http://tnlc.com/rw/rwx.html#collision (see "Avatars"), how are bots (still avatars) going to have any more ADVANCED collision detection?

[View Quote] > the gain would be bots acting a lot more "natural", or a bot which uses completely different methods for 3d display than the browser...

walter knupe

Feb 16, 1999, 10:11pm
Yep, point taken, you are right. Bots probably won't have a more advanced
collision detection.

Compared to actually no object recognition at all (and there for no
collision detection whatsoever) it would still be a huge improvement :)

but pure theoretical, bots that have access to the complete rwx file for
both avatars and objects, could for sure implement their own detection,
which can be much improved in comparison to the aw browser.

access to the rwx files and maybe helper functions to parse them hands all
those posibilities over to the bot programmer.

right now there is nothing. and copyright issues might make this case stay
that way.

Walter aka Faber

Eep² schrieb in Nachricht <36C9F918.BE2BE497 at tnlc.com>...
>If avatars only have collision detection based on
http://tnlc.com/rw/rwx.html#collision (see "Avatars"), how are bots (still
avatars) going to have any more ADVANCED collision detection?
>
[View Quote]

baggis

Feb 17, 1999, 3:22am
Cool to see all these interesting threads that my original question caused
:-)

I'm now 110% aware of that collision detection via SDK isn't possible right
now and is hard yet wanted to implement in the future !

Many thanks ppl !

( With hope the participates in here could manage to stay friendly and
overlooking with each other. Cause not being friendly and overlooking
generates so many and big threads that really wasts with my limited
bandwidth, my money and my time :-)

/Baggis

=?iso-8859-1?q?eep=b2?=

Feb 17, 1999, 5:50am
Well, I would rather have Roland implement better avatar collision detection, which then bots can take advantage of through the SDK. Avatars should at LEAST be using their bounding box for collision detect, not a bounding box that can't go smaller than 1m³. And gravity needs a little work too. When running (Ctrl and arrows) off things (hills for example), it seems like I am on the moon or something because I end up coasting much further than I should before actually hitting the ground. Then, if I stop moving, instead of momentum carrying be forward, I just fall straight down. This is physically inaccurate. Then of course the next step is to allow world control over the gravity setting (like allow the m/s to be changed; isn't gravity like 8.5m/s or something on Earth?).

Anyway, bots should be able to, because they're just avatars, be treated like any avatars (which already have collision detection).

[View Quote] > Yep, point taken, you are right. Bots probably won't have a more advanced collision detection.
>
> Compared to actually no object recognition at all (and there for no collision detection whatsoever) it would still be a huge improvement :)
>
> but pure theoretical, bots that have access to the complete rwx file for both avatars and objects, could for sure implement their own detection, which can be much improved in comparison to the aw browser.
>
> access to the rwx files and maybe helper functions to parse them hands all those posibilities over to the bot programmer.
>
> right now there is nothing. and copyright issues might make this case stay that way.
>
> Eep² schrieb in Nachricht <36C9F918.BE2BE497 at tnlc.com>...
> avatars) going to have any more ADVANCED collision detection?

andras sarkozy

Feb 17, 1999, 7:10am
g=9.81 m/s^2
Andras


[View Quote] > Well, I would rather have Roland implement better avatar collision detection, which then bots can take advantage of through the SDK. Avatars should at LEAST be using their bounding box for collision detect, not a bounding box that can't go smaller than 1m³. And gravity needs a little work too. When running (Ctrl and arrows) off things (hills for example), it seems like I am on the moon or something because I end up coasting much further than I should before actually hitting the ground. Then, if I stop moving, instead of momentum carrying be forward, I just fall straight down. This is physically inaccurate. Then of course the next step is to allow world control over the gravity setting (like allow the m/s to be changed; isn't gravity like 8.5m/s or something on Earth?).
>
> Anyway, bots should be able to, because they're just avatars, be treated like any avatars (which already have collision detection).
>
[View Quote]

edward sumerfield

Feb 17, 1999, 11:25am
Point taken Roland. No Renderware dlls.

An extension to our thinking. Don't limit the design of collision detection to
avatars and objects. There are going to be many situations where an object
must collide with another object. For example, the ballbot would be really
cool if the ball could bounce of the wall.

[View Quote] > For the reasons that RJ stated, as well as many others. For one thing,
> RenderWare is not available under Unix, and a Unix port of SDK is currently
> very high up on the to-do list. Also, it would immensely bloat the SDK out
> from a single 80K DLL to hundreds of K with multiple DLLs making it that
> much more difficult for newbies to get a handle on things. To me, including
> RenderWare with the SDK in order to provide collision detection would be
> like including Windows98 with a PalmPilot just so you could use the
> "dingbats" font. Finally, and most seriously, there is a licensing problem.
> RenderWare is a licensed product. Our license does not give us the right to
> re-distribute it to developers for their own applications. If the SDK
> included RenderWare, no developer could legally release any program they
> wrote using the SDK. In short, I do think that collision detection in the
> SDK is something that can and should be done. It's just that using
> RenderWare isn't the right way to do it. A future solution where the world
> server (or perhaps another server accessible via the SDK) has far more
> intimate knowledge of object geometry is far more appealing. -Roland
>
[View Quote]

rjinswand

Feb 17, 1999, 11:46am
This is a multi-part message in MIME format.

------=_NextPart_000_0039_01BE5A38.E8597DC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Of course it WOULD be possible to implement collision detection in an =
SDK program presently... if you write the collision detection yourself =
and have a local directory/cache of objects for it to scan. For very =
specialised applications you don't even need a generic collision =
detection algorithm... Giving it a small selection of =
collision-detecting models would work for the case of the ballbot =
bouncing off walls.
If you wanted to write a generic collision detection bot for world =
owners to use without requiring a local cache of models, you could even =
have it accept the object password and path manually for downloading =
models from the website.
In short, you can do whatever you want to that requires bot collision =
detection in your own worlds NOW... provided you can figure out how to =
code it. *grin*

Rjinswand

[View Quote] ------=_NextPart_000_0039_01BE5A38.E8597DC0
Content-Type: text/x-vcard;
name="Rjinswand.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Rjinswand.vcf"

BEGIN:VCARD
VERSION:2.1
N:;Rjinswand
FN:Rjinswand
ORG:Rjeneration
URL:
URL:http://table.jps.net/~rjins/rjeneration
EMAIL;PREF;INTERNET:bcnu at psicorps.com
REV:19990217T134647Z
END:VCARD

------=_NextPart_000_0039_01BE5A38.E8597DC0--

rolu

Feb 17, 1999, 4:03pm
that varies, it's 9.82 here in Holland.

Rolu

[View Quote]

tammy jo

Feb 18, 1999, 10:43am
why don't you smart people test this by taking your cell.idx
and cell.dat files from the world you want have object
detection and then use a registry from the world to tell the
SDK which objects are there and what their boundaries are

Your Evil & Smart Pal
Horizons
#288611
King Pikachu
King Raichu
BuildW (currently not running at time of this post)

andras sarkozy

Feb 18, 1999, 4:32pm
No wonder! You are at least 300 meter closer to the center of the Earth!! <smiles>
Andras


[View Quote] > that varies, it's 9.82 here in Holland.
>
> Rolu
>
[View Quote]

roland vilett

Feb 18, 1999, 6:23pm
Since we're being geeky here, I feel compelled to point out that once you
are at the surface, as you move closer towards the center of a solid sphere,
acceleration due to gravitational attraction from the sphere does not
continue to increase...consider the extreme case, where you are approaching
the exact center of the earth: net acceleration becomes zero, since all
parts of the earth are around you pulling on you equally.

I know, you were joking :)

-Roland

[View Quote]

rolu

Feb 18, 1999, 7:38pm
Actually this number is lower when someone is above you than when he is
under you.

Rolu

[View Quote]

1  2  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2022. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn