ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
Bots vs 'usual' Avatars (Sdk)
Bots vs 'usual' Avatars // SdkbaggisFeb 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 sumerfieldFeb 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] baggisFeb 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> </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>>...</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> </P></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_003D_01BE5902.A0937EA0-- byte meFeb 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 sumerfieldFeb 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 <-- ( worlds list ) ----------------- Universe server <br>AW Browser --- ( get world IP and port ) ----> Universe server <br>AW Browser --- ( enter world ) --------------> World server <br>AW Browser <-- ( object information ) -------- World server <br>AW Browser --- ( connect to web server -----> Object server <br>AW Browser <-- ( 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 meFeb 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 vilettFeb 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. As far as I can tell, it would be a = mammoth=20 project to include object collision within the SDK itself. 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> </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. 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 "bounding box" collision. 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> </DIV> <DIV><FONT size=3D2>-Roland</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: = 5px"> [View Quote] ------=_NextPart_000_0067_01BE591B.7A2FE1E0-- rjinswandFeb 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> <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. =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> =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> Lots of possibilities, lots of = work, lots=20 of issues.</FONT></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2> =20 <STRONG><EM>Rjinswand</FONT></EM></STRONG></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV> </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 sumerfieldFeb 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> rjinswandFeb 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> RenderWare is = only available=20 for PC and Mac these days... they dropped all UNIX support with 2.1 I=20 think. It IS a big deal requiring the Renderware DLLs for using = the=20 SDK. :/</FONT></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><FONT = size=3D3></FONT></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2> <FONT=20 size=3D3><STRONG><EM>Rjinswand</EM></STRONG></FONT></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV> </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>>...</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> = 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> Lots of possibilities, lots of work, lots of=20 issues.</FONT> <FONT color=3D#000000><FONT = size=3D-1> =20 <B><I>Rjinswand</I></B></FONT></FONT> <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 sumerfieldFeb 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 sumerfieldFeb 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². 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 knupeFeb 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 youngFeb 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 vilettFeb 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. 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. = 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. 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 "dingbats" font.</FONT></DIV> <DIV><FONT color=3D#000000 face=3D"" size=3D3></FONT> </DIV> <DIV>Finally, and most seriously, there is a licensing problem. = 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. If the SDK included=20 RenderWare, no developer could legally release any program they wrote = using the=20 SDK.</DIV> <DIV> </DIV> <DIV>In short, I do think that collision detection in the SDK is = something that=20 can and should be done. 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> </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>>...</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. Lots of possibilities, lots of work, lots = of=20 issues.</FONT> <FONT color=3D#000000><FONT=20 size=3D-1> =20 <B><I>Rjinswand</I></B></FONT></FONT> <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 wandererFeb 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 knupeFeb 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] baggisFeb 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 sarkozyFeb 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 sumerfieldFeb 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] rjinswandFeb 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-- tammy joFeb 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 sarkozyFeb 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 vilettFeb 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] roluFeb 18, 1999, 7:38pm
Actually this number is lower when someone is above you than when he is
under you. Rolu [View Quote] |
