[Opensim-dev] Opensim-dev Digest, Vol 65, Issue 7

Thu Jan 10 01:38:12 UTC 2013

That is impressive movement - there are pros and cons to different NPC approaches.  I would have thought the Linden 
server-side pathfinding (assuming that's what you're talking about) would not be too heavy on resources, though, 
especially compared to client-side NPCs.

On 09/01/13 17:56, Dave Gubser wrote:
> Re: This may not be the place to post this, however....may be of interest to
> all that follow this thread.
>
> Opensimulator / Second Life non-server based NPC? (Dahlia Trimble stated at
> the bottom of her second video -  "Here's a demo of an auto-navigating
> (SERVER-SIDE) NPC character", which implies the npc is driven by a engine
> attached to the server. (ie server side engine and needed access to the
> server to impliment navigation.) On the other hand, the navigation system I
> built does not require a plug in be installed on the server. It does all the
> mapping and navigating by itself (think of an external browser with
> capabilities to map and navigate any Opensimulator or Second Life simulator,
> allowing the NPC(s) to perform tasks and requires less bandwidth and server
> power than a normal Avatar.) Both approaches to NPC navigation have merit
> and the work involved is non-trivial. Functional NPCs (not the server power
> hogging mess Second Life came out with.) will give Opensim "Content"
> capabilites whereby NPCs, going about their business, will enrich the user
> experience. Picture transporting to a simulation of a 13th century village
> and finding "nobody" there. Now picture the same village with NPCs filling
> rolls until their human owners come in and take control of the NPCs body, ie
> standard virtual world human interaction. Have to run... My 5 yr. old is
> screaming for help.... she's busy flinging arrows at the NPC dragon
> attacking her village!! :)
>
> Dave Gubser
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
> opensim-dev-request at lists.berlios.de
> Sent: Tuesday, January 08, 2013 11:17 PM
> To: opensim-dev at lists.berlios.de
> Subject: Opensim-dev Digest, Vol 65, Issue 7
>
> Send Opensim-dev mailing list submissions to
> 	opensim-dev at lists.berlios.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.berlios.de/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
> 	opensim-dev-request at lists.berlios.de
>
> You can reach the person managing the list at
> 	opensim-dev-owner at lists.berlios.de
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>     1. Re: 0.7.5 rc1, missing support for the DTL/NSL module
>        (What Virtual World - Guy Quicksand)
>     2. Thread.Abort() considered harmful (Justin Clark-Casey)
>     3. Opensimulator / Second Life non-server based NPC	navigation
>        (Dave Gubser)
>     4. Re: Opensimulator / Second Life non-server based NPC
>        navigation (Dahlia Trimble)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 8 Jan 2013 23:29:55 +0100
> From: "What Virtual World - Guy Quicksand" <guy at whatvirtualworld.com>
> To: <opensim-dev at lists.berlios.de>
> Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL
> 	module
> Message-ID: <3A9F5DC3D0AB482BABCC0EAA16B24E71 at MARGRIET>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> 	reply-type=response
>
> Thanks Justin,
>
> I found it was the search/profile module not any other as i had recompiled
> dtl allready.
> I still have to see if it works now, but i had no errors after removing the
> search and profile dll's.
> These 2 dll's where automaticly copied to the folder for setting up the
> simulator allong with all proper ini files.
> Still the dtl module is not working but we got a step forward, they probably
> need the profile module to work properly.
> Will do some more testing will let you know how it goes.
>
> Thanks for everything.
>
> Best regards,
>
> Martin Forster
>
> ----- Original Message -----
> From: "Justin Clark-Casey" <jjustincc at googlemail.com>
> To: <opensim-dev at lists.berlios.de>
> Sent: Tuesday, January 08, 2013 12:02 AM
> Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL module
>
>
>> I suspect the compiled DTL/NSL module is looking for Mono.Addins v0.5
>> whereas recent changes now mean that Mono.Addins v0.6 is shipped.
>>
>> If this is so, you really either need to recompile the DTL/NSL module (or
>> ask the authors to do so in preparation for the final release of 0.7.5),
>> or redirect the DTL/NSL assembly [1] to load the 0.6 module even though
>> it's looking for 0.5 (or ask the authors).  I can't say for sure if this
>> will work though there's a good chance.
>>
>> [1] http://msdn.microsoft.com/en-us/library/twy1dw1e%28v=vs.90%29.aspx
>>
>> On 07/01/13 01:31, James Hughes wrote:
>>> Yes, please paste a full error output on pastebin.com and the link here.
>>> Be sure no passwords or other sensitive
>>> information is included.
>>>
>>> Thanks!
>>> BlueWall
>>>
>>> On 01/06/2013 05:32 PM, What Virtual World - Guy Quicksand wrote:
>>>> Hello James,
>>>>
>>>> I have been searching for additinal dll''s in system paths, none found.
>>>> I am using the Mono.addons from the opensimulator, and no the module
>>>> does not come with its own version.
>>>> Personaly i dont think the module is failing as i get the same error on
>>>> a fresh ( without anny aditional modules ) opensim 0.7.5 rc1.
>>>> My effort you point out below was that i replaced the effected files
>>>> from git changes on this subject to see if i get it running.
>>>> I am probably over 30 hours now trying to solve this isue, that is why i
>>>> called out for help as i cant pinpoint this isue.
>>>> I even tried to use the .config files from 0.7.3 as they where
>>>> different.. also no solution.
>>>>
>>>> Strange thing is that the older git 13c4fd7 is running fine.
>>>> I cant find any other mono.addin* files in any path that could be
>>>> accesed, i dont know if the mono.addins search locations by them selfs?
>>>> The robust is running just fine, only the simulator is giving this
>>>> error.
>>>> ( i asume this error couses all external modules to not load, as i dont
>>>> have this error on the win7 box and modules are working there just
>>>> fine )
>>>>
>>>> If you need a full error output, please let me know.
>>>>
>>>> Best regards,
>>>> Martin forster
>>>>
>>>>
>>>> ----- Original Message ----- From: "James Hughes"
>>>> <jamesh at bluewallgroup.com>
>>>> To: <opensim-dev at lists.berlios.de>
>>>> Sent: Sunday, January 06, 2013 8:57 PM
>>>> Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL
>>>> module
>>>>
>>>>
>>>>> On 01/06/2013 09:15 AM, What Virtual World - Guy Quicksand wrote:
>>>>>> Hello all.. hope to post this to the right section.
>>>>>> I have been trying to update our beta simulators to 0.7.5 rc1.
>>>>>> It seems it has a problem at the mono.addins.
>>>>>> Error log(part):
>>>>>> log4net:ERROR DefaultRepositorySelector: Unhandled exception in
>>>>>> GetInfoForAssembly
>>>>>> System.IO.FileLoadException: Could not load file or assembly
>>>>>> 'Mono.Addins, Versi
>>>>>> on=0.5.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one
>>>>>> of
>>>>>> its depe
>>>>>> ndencies. The located assembly's manifest definition does not match
>>>>>> the
>>>>>> assembly
>>>>>> reference. (Exception from HRESULT: 0x80131040)
>>>>>> File name: 'Mono.Addins, Version=0.5.0.0, Culture=neutral,
>>>>>> PublicKeyToken=0738eb......
>>>>>
>>>>> Can you see any other copies of Mono.Addins in the path on that
>>>>> system, or does the module distribute it's own version of them?
>>>>>
>>>>>> I have done next:
>>>>>> replaced :
>>>>>> bin/Mono.Addins.CecilReflector.dll
>>>>>> bin/Mono.Addins.Setup.dll
>>>>>> bin/Mono.Addins.dll
>>>>>
>>>>>
>>>>>
>>>>> Mono Addins have been updated to support some new capabilities on the
>>>>> Robust server.
>>>>>
>>>>> The distributed versions are what should work. Changing them might
>>>>> cause further issues. First, let's see if there are additional copies
>>>>> around. Also, if you remove that module, does it report the error?
>>>>>
>>>>> Thanks
>>>>> BlueWall
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>> --
>> Justin Clark-Casey (justincc)
>> OSVW Consulting
>> http://justincc.org
>> http://twitter.com/justincc
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 09 Jan 2013 01:42:33 +0000
> From: Justin Clark-Casey <jjustincc at googlemail.com>
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] Thread.Abort() considered harmful
> Message-ID: <50ECCB09.8060503 at googlemail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Over the past couple of months, I have been struggling with an issue where
> mono 2.10.8 would sometimes crash badly on a
> heavily loaded simulator (2000+ scripts).  Symptoms are 100% cpu use,
> simulator locking up with all threads waiting on a
> lock which no other thread holds or crashing with native stack trace
>
>   From analysis, this seems to be due to the use of Thread.Abort() to
> terminate script threads whose events do not
> complete within a short (or sometimes no) timeout.  This is used in llDie()
> and llResetOtherScript(), amongst other things.
>
> The use of Thread.Abort() is considered harmful, leading to the kind of
> system instability described above [1] [2] [3],
> etc.  This affects scripts running in both separate AppDomains and the same
> AppDomain, since script functions constantly
> reach into core OpenSimulator code.
>
> One could extend the timeout, but there is a tradeoff with timely script
> stopping.  Also, even a large timeout would not
> guarantee that threads would not be aborted.
>
> Therefore, I will probably soon investigate a mechanism for stopping scripts
> without calling Thread.Abort().  This will
> probably involve the use of Thread.Interrupt() for Sleeps and the insertion
> of 'should I stop' flag checks in generated
> code where that code may be long running (e.g. control structures for, goto,
> etc. and user defined functions).  This is
> the normal approach one would take to co-operatively stop threads and avoid
> the chance of leaving Mono/.NET in a bad state.
>
> The existing Thread.Abort mechanisms will remain default until this approach
> is shown not to have significant
> bugs/problems.  However, I think in the long term we have to stop using
> Thread.Abort() by default since it is not a safe
> thing to do.
>
> Comments welcome.
>
> [1] http://stackoverflow.com/questions/1051838/killing-a-thread-c
> [2] http://msdn.microsoft.com/en-us/library/7a2f3ay4%28v=vs.80%29.aspx
> [3]
> http://stackoverflow.com/questions/2251964/c-sharp-thread-termination-and-th
> read-abort
>

-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc