| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
replace anymore.
|
| |
|
|
|
|
| |
OpenSimDefaults! :0
It is updated now.
|
| |
|
|
|
| |
Conflicts:
OpenSim/Region/PhysicsModules/ConvexDecompositionDotNet/Properties/AssemblyInfo.cs
|
| |
|
|
| |
exactly what the viewer does, but it's close enough, and the elapsed time can be measured.
|
| |
|
|
| |
AssemblyVersion("0.8.2.*")
|
| | |
|
| |
|
|
|
|
| |
bots in motion.
Previously, adding this behaviour after physics (p) would leave the bot to drift off for ever in its last movement direction.
|
| |
|
|
|
|
|
| |
This allows one to log the packets received by a particular bot that are not duplicates of already received packets.
Similar to the OpenSimulator command at the same name but currently any positive level logs all received packets.
No facility yet for logging outgoing packets.
For debug purposes.
|
| |
|
|
|
|
| |
machine.
Also adds "show status" command to pCampbot that currently just shows bot connecting state
|
| |
|
|
| |
9//2/14 http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2014-09-02. Find the binaries, sources and README in ./share/32BitLaunch if needed.
|
| |
|
|
| |
Also only write console lines for actually connected bots.
|
| |
|
|
| |
If you want to stop existing behavious, add the None behaviour.
|
| |
|
|
|
|
|
| |
previous behaviour active
Also closes behaviours on disconnect instead of interrupt, though this makes no practical difference.
If existing behaviour is None, other added behavious will not take affect until None is removed (as this is an infinite wait until interrupted).
|
| |
|
|
|
|
|
| |
an event rather than polling connection state every 100ms
This kind of polling is very expensive with many bots/polling threads and appears to be the primary cause of bot falloff from the client end at higher loads.
Where inbound packet threads can't run in time due to contention and simulator disconnect timeout occurs.
|
| |
|
|
|
| |
This adds the "show stats", "stats record", etc. commands and information on available Threadpool threads, etc.
It also adds the Watchdog which logs warnings if time between executions is unexpectedly large.
|
| |
|
|
|
|
| |
int.MaxValue
This is to avoid issues where many bots connect to a single end point with multiple regions, where each region requires a long-lived poll connection for each bot.
|
| |
|
|
| |
However, disconnecting now halts any current connection, with the possible exception of the single currently connecting bot.
|
| |
|
|
| |
we can continue to run status commands whilst bots are disconnecting.
|
| |
|
|
| |
locking entire bot list for almost 100% of connection time.
|
| |
|
|
| |
The "Sculpt" field in prims is used for both Sculpties (where the assets are Textures), and real meshes. Meshes require a different download URL than textures.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the C# column can't be found in the positionMap (but the line can),
use the map immediately after it while correcting for the offset,
unless that results in an LSL position before the previous LSL position
in the positionMap.
The idea behind this heuristic is that in most, if not all cases C#
consumes more characters than LSL (for example LSL_Types.LSLInteger
instead of just 'integer').
Thus if the distance between the columns of two markers differ in
the C# and LSL file, the distance in the C# file will be larger.
Moreover, we can assume that every time this happens we will have
a marker at the beginning of the longer 'keyword', because those
keywords were generated by us in the first place.
For example:
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
1 2
will always have markers at the beginning of the long keywords
'LSL_Types.LSLInteger' and 'LSL_Types.LSLString'.
If an error is generated in between (for example at the beginning
of the function name 'f2') then the correct position is found
by using an offset relative to 2 rather than 1.
Note that a case where this isn't working correctly is
when the user adds extra spaces. For example:
LSL: integer f2( string s)
would still use the start of 'string' as reference and
then go backwards 3 characters only because the corresponding
C# still looks like
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
only 3 chars difference
and the reported error at 'f2' would be here:
LSL: integer f2( string s)
^
This can only be fixed by generating a mapping for 'f2' itself, or
generating a mapping whenever the amount of spaces is changed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a compile error reports a colum/error that is not an exact
match in the positionMap dictionary, the last position in the
map with a line number and position before the reported error
should be returned.
The old code had the following problems:
1) It returns l,c - which are line and column of the C# file, not LSL.
2) It doesn't set l to 'line' when the map has an entry with 'line'.
3) It sorts the map without taking columns into account, which may
result in a random order of the columns. With my mono implementation
the columns were reversed in order.
For example, if the map contains the following lines:
99,5,49,10
100,30,50,10
100,40,1,0
101,5,51,10
and a translation of 100,35 was requested,
then the old code would compare '100' with the keys in
the first column - setting l to that key while it is
smaller. Hence, l is set to 99.
Then it finds the key 100 and doesn't update l.
Because of the reversed sort order, it first compares
the column 35 with 40, finding that it is smaller
and therefore it stops; returning 99,1 instead of finding
the correct 100,30 entry and returning 50,10.
This patch causes 50,10 to be returned.
The remaining problems after this patch are:
1) The sorting might not be necessary at all.
2) The is code duplication (I fixed both instances,
but really there should be no code duplication
imho).
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
SetPreviousAppearance()
|
| | |
|
| |
|
|
| |
doing for understanding the load that AgentUpdate packets incur on the server.
|
| |
|
|
| |
Also fixes some issues in associated solution files
|
| | |
|
| |
|
|
| |
disconnected.
|
| |
|
|
|
|
| |
BotManager rather than Environment.Tickcount
Otherwise, since bots are now created all at once, a bunch will get exactly the same tickcount and hence number sequences
|
| | |
|
| | |
|
| |
|
|
|
|
| |
[Startup] section.
These are long unused but confusingly will be seen in the [Startup] section on a "config save".
|
| | |
|
| | |
|
| |
|
|
| |
for all bots if no bot number is given
|
| |
|
|
|
|
|
| |
than controlling from the main action loop
This is to avoid excessive and inconsistent delays between behaviours that currently need to embed sleeps in other actions (e.g. physics) and other behaviours.
Might need a more sophisticated approach in the long term.
|
| |
|
|
|
|
| |
or bot it disconnected.
In this case, it is used to turn off jump when physics testing behaviour is removed.
|
| |
|
|
|
|
| |
during operation.
Doesn't currently work very well as stopping physics, for instance, can leave bot travelling in old direction
|
| |
|
|
| |
behaviour <behaviour-name> <bot-number>" console commad
|
