| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
*By default, it is set to startup_commands.txt. Simply add a list of commands separated by a new line to be run or change the file by changing the path of a startup commands file in OpenSim.ini
|
|
|
|
| |
and body parts. [Note while you can edit these, at the moment your changes won't be saved between restarts. This will be fixed very soon.]
|
|
|
|
|
|
| |
* We now have CylinderShape
* This commit dedicated to the birth of techno house.
|
| |
|
|
|
|
| |
change and improve how we handle caps.
|
|
|
|
|
| |
Although there seems to sometimes be a problem of when you login again, old notecards and scripts will have their permissions messed up and you won't be able to even view their text. This seems to be related to the client's cache, and if you clear your client's cache, on the next login they should be fine again. [I have a couple of ideas about what might be causing this so hopefully will have it fixed soon.]
|
|
|
|
| |
from the create menu in the inventory window. Although currently you can't update/edit them (and have those changes saved).
|
|
|
|
|
|
|
| |
stored in the inventory database and you will still have that texture in inventory on later logins (Again only in standalone mode with authentication.)
Also there might be some problems if you upload textures in other regions to the start one (due to us not updating the CAPS url properly).
|
|
|
|
|
|
|
| |
them be stored in database (so are there on next login). Again only works in standalone mode with Account/password authentication turned on. [Creating new inventory items should be working very soon.]
The test is to make sure that it hasn't broke grid mode at all.
|
|
|
|
|
|
|
|
| |
standalone mode and using sqlite).
In standalone mode, if you have account authenticate turned on (setting in opensim.ini) then when you create a new account, a set of inventory is created for that account and stored in database (currently only a set of empty folders). Then during login the database is search for that set and sent to the client in the login response.
More functions will be added soon, like creating new folders (and a bit later items) from the client inventory window.
|
| |
|
|
|
|
| |
bit and also should help to integrate the inventory server (when it is wrote/finished).
|
| |
|
| |
|
| |
|
|
|
|
| |
that we can tell what prims belong to the same SceneObjectGroup. If sdague has a different method in mind when he gets back then he can change it then.
|
|
|
|
| |
userprofiles.yap to get opensim to start)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Temporary have had to rename the OpenSim.DataStore.MonoSqlite project to OpenSim.DataStore.MonoSqlite1, as I'm not sure what was done to stop the old project name being included in the VS2005 solution.
Also some config changes:
OpenSim now has a INI (OpenSim.ini) file that it will read some config settings from (if the ini file exists).
Added Mono.Data.SqliteClient.dll so that we can use the same code for sqlite on Windows and mono/linux. (from what I can tell Mono class libraries have a MIT license so there should be no problems with us including this dll).
So now to get the basic prim storage working , you need to first create the sqlite database file from the sqlite3-prims.sql in share directory. Then in the OpenSim.ini file, change the storage_plugin so it points to OpenSim.DataStore.MonoSqlite1.dll (storage_plugin = OpenSim.DataStore.MonoSqlite1.dll). Then in your region.xml files change the DataStore value so it is the name of your database file (at the moment you need a different sqlite3 database file for each region).
|
|
|
|
|
|
| |
PLEASE NOTE: that with this revision some prim related features may be broke for a while. (things like linking prims and the parcel prim count.)
Also this revision may not work on mono, but that will be fixed soon.
|
|
|
|
| |
of enabling the new SceneObject classes.
|
|
|
|
| |
works for now.
|
|
|
|
| |
download), but still a few problems, it seems that the client has a quite short timeout for receiving a texture and if the whole texture isn't sent within this time, the client will request the texture again, With quite small textures this is fine, but it seems that with larger textures we can't send them fast enough and a infinite loop develops where the client keeps requesting a texture and we keep trying to send it, but are never fast enough. So I've for now put code in that so that the server will try to send a texture only once and then after that will ignore future requests from that client for that texture.
|
|
|
|
| |
tries to load them.
|
|
|
|
|
|
|
| |
xml file (OpenSimAssetSet.xml). (remember to make changes to the set, you will also need to delete the old asset .yap file, so that it is recreated).
Also the set of items in the OpenSim inventory Library can also now be set from a xml file (OpenSimLibrary.xml).
|
|
|
|
|
| |
* Minor shape koncept experiments
|
|
|
|
| |
even after you cross a region boundary.
|
| |
|
|
|
|
| |
things are kept in sync.
|
| |
|
|
|
|
|
| |
* fixed 'show users' format bug.
|
|
|
|
|
|
| |
* Removed unused SendPrimitiveToClient that didn't have rot.
|
|
|
|
|
|
|
|
|
|
|
| |
* NetworkServersInfo settable without config file
* DefaultHomeLoc throws if getted before setted
* Removed nonsensical sandbox distinction
* Refactored default config file creation
* Some more small refactorings on shapes
|
| |
|
|
|
|
| |
configdir, datadir.
|
| |
|
|
|
|
| |
estate_settings.xml using the configuration system.
|
|
|
|
|
| |
4 spaces found everywhere else.
|
| |
|
|
|
|
|
|
|
| |
This helps reduce confusion for linux people that have white background
terminals.
|
|
|
|
| |
class.
|
|
|
|
|
| |
Updated libsl to latest version.
|
|
|
|
|
|
|
|
| |
/Part2).
Updated the JavaVM to a later version I did (basically some clean up and a little bit more functional).
Added SendLoadURL method to IClientAPI.
|
| |
|
|
|
|
|
|
| |
where you could only login once with a given id in standalone mode.
|
|
|
|
|
| |
* ExternalHostName supports "SYSTEMIP" again.
|
| |
|
| |
|
|
|
|
| |
logins should now work properly), done a temporary fix, but agents need to be stored seperately from userprofiles in DB4o.
|
|
|
|
| |
folder or anything so there is at the moment no way to recover deleted objects.
|