MantisBT - Issues
Updated: 57 min 41 sec ago
After configuring OpenSim.ini mails and even tried several configurations, I still get this error message on the console when I try to send an email.<br /> <br /> [EMAIL]: DefaultEmailModule Exception: Unrecognized authentication type
Although I reported this in the ongoing "unknown user" issue report <a href="http://opensimulator.org/mantis/view.php?id=6625">0006625</a>, it really should have its own Mantis.<br /> <br /> Here is my post from that report:<br /> <br /> <br /> # # # # # # # # # # #<br /> <br /> <br /> After several weeks of pretty low incidence of UMMTGUN8 chat, yesterday's dance at OSG was the opposite -- many users displaying as unknown (and I had just cleared my viewer cache prior to going).<br /> <br /> This morning I re-cleared my cache and logged into my own grid and waited for my inventory to load. As it did so I saw the following appear in the console:<br /> <br /> 09:25:40 - [USER MANAGEMENT MODULE]: No grid user found for 0bbacbb9-951a-46ea-b195-21e50919cf3b<br /> 09:25:40 - [USER MANAGEMENT MODULE]: Sending Unknown UserUMMTGUN8 for 0bbacbb9-951a-46ea-b195-21e50919cf3b to Aine Caoimhe since no bound name found<br /> 09:25:40 - [USER MANAGEMENT MODULE]: No grid user found for 17bec164-656f-4c7f-9dcc-5dc398662c4d<br /> 09:25:40 - [USER MANAGEMENT MODULE]: Sending Unknown UserUMMTGUN8 for 17bec164-656f-4c7f-9dcc-5dc398662c4d to Aine Caoimhe since no bound name found<br /> 09:25:40 - [USER MANAGEMENT MODULE]: No grid user found for 7015566e-e5be-3010-e68c-86abc0a5546c<br /> 09:25:40 - [USER MANAGEMENT MODULE]: Sending Unknown UserUMMTGUN8 for 7015566e-e5be-3010-e68c-86abc0a5546c to Aine Caoimhe since no bound name found<br /> 09:25:40 - [USER MANAGEMENT MODULE]: No grid user found for cdfa6ca6-6f7d-4f30-9ddf-fde2179ccc51<br /> 09:25:40 - [USER MANAGEMENT MODULE]: Sending Unknown UserUMMTGUN8 for cdfa6ca6-6f7d-4f30-9ddf-fde2179ccc51 to Aine Caoimhe since no bound name found<br /> 09:25:40 - [USER MANAGEMENT MODULE]: No grid user found for e1877ad3-5b5a-45cd-9e31-d74d7c3798c8<br /> 09:25:40 - [USER MANAGEMENT MODULE]: Sending Unknown UserUMMTGUN8 for e1877ad3-5b5a-45cd-9e31-d74d7c3798c8 to Aine Caoimhe since no bound name found<br /> <br /> I investigated those ids in my inventory and discovered that every single one of them is related to a calling card in my suitcase of a person I have accepted an offer of friendship from while in another grid (ie the offer was made while I was visiting another grid) and they come in "pairs" of calling cards: one that has the friend's user name as the calling card name and a second one that has Unknown UserUMMTGUN8 as the card name. Each pair of cards has the same UUID as the creator. I have other pairs of friends' calling cards where the UUID doesn't appear as UMMTGUN8.<br /> <br /> Inspecting further, I notice that in my opensim.friends table I have far fewer entries than I have calling cards/friends, and that the only ones that are listed in the table are the ones where the calling card pair is "correct". All of the other UUIDs from calling card friends do not have any entry in the friends table.<br /> <br /> I seem to recall some months ago that when I accepted a friendship offer while visiting another grid, I was asked to re-confirm that friendship offer upon returning to my own grid. I conducted an experiment where I deleted the "bad" card pair of a friend who was displaying as Unknown and who wasn't in the friends table, then offering them friendship again (while visiting their grid). I saw an entry in my own console as the pair of calling cards are added to my inventory but when I returned to my own grid I was not asked to reconfirm the offer and the UUID was not added to my friends table. Upon returning to visit, that user's chat displays as UMMTGUN8.<br /> <br /> I assume that this HG friends issue is the most likely cause of most (perhaps even all) of the Unknown Users I saw at yesterday's dance and is also the reason neither I nor they are notified when either of us logs in.<br /> <br /> If someone visits me in my grid and either of us offers and accepts friendship, the entry *is* correctly added to the friends table (I don't know if their own host grid does so, though...haven't tested it).<br /> <br /> So it seems to me that something in the HG friends mechanism is fubar and a fix is likely to solve many of the remaining issues.<br /> <br /> At the time of the above tests I was running r/23560 opensim-56f565b on my grid and was visiting the Close Encounters region of OSG which is likely to be running a very up-to-date version (probably the most recent OSG build with Akira's usual tweaks). Viewer I was using was Firestorm 4.4.2 (34167) Jul 2 2013 00:49:02 (Firestorm-Release) with OpenSimulator support.<br /> <br /> # # # # # # # # # # #<br /> <br /> I also included a screencap in that Mantis report showing the pairs of calling cards, both good and bad.<br /> <br /> I also notice several other issues:<br /> <br /> 1. I frequently see a notice in console that one of my HG friends has logged in but my avi does not receive a corresponding in-world notice, nor does the friend get updated to show as online. This happens with both known and unknoown HG friends (in fact unknown friends never result in an in-world notice which isn't all that surprising). It does not appear to be an issue that is consistently related to a user...one friend could log in and out multiple times and sometimes I will receive the notice and other times I won't.<br /> <br /> 2. Ditto for log-outs. I haven't tested thoroughly enough to say whether there are occasions where I won't receive a log-off notice for a friend but did previously receive a log-in notice, nor whether their status is correctly updated in the viewer.<br /> <br /> 3. HG IMs do not succeed for a friend who logs in but for whom I don't receive an in-world log-in notice. Any attempt from either of us to message one another will result in an offline message.<br /> <br /> EDIT: added:<br /> 4. If you decline a friendship offer when HGed you are subsequently re-offered that same friendship each and every single time you return to that grid. <br /> <br /> <br /> Needless to say, all of the above combine to make HG friends highly unreliable (almost non-functional) at present.
Since the change from abort to co-op script terminations I have been seeing a lot of these errors. They seem to be triggered by scripts inside attached objects and when the avatar logs out, there is a flood of these errors on the console. Doesn't happen every time and I'm not sure if its totally limited to scripted attachments.
For a long time when using ODE I had a personal rule of thumb to never have my step-to-step height difference greater than 0.25m and usually kept it at 0.2m or even 0.15m.<br /> <br /> After switching to Bullet almost a year ago these simple prim stairs worked fine (though Bullet would occasionally struggle with 0.25m steps); however a month or two ago the mesh shape was altered in Bulletsim (to help with the ground issue iirc) and now Bullet is having a very, very hard time with shallow stairs but not with steeper ones. I get noticeable "stuttering" in avi motion when attempting to walk up a simple straight flight of 0.15m or 0.2m stairs, but completely smooth movement up slightly steeper stairs at 0.25 or even 0.3m. I suspect it has something to do with the shape of the new bounding box.<br /> <br /> It would be nice not to have to build invisible ramps over absolutely every staircase just in the off chance that Bullet has trouble with it so anything you can do to smooth this out would be super
This patch fixes several problems with the permissions system in OpenSim. The most important fix is to the way folded permissions are used. A few other minor problems are also fixed.<br /> <br /> An object's folded permissions are the permissions of the items in the object's inventory. If an object contains a no-copy or no-transfer item then when the object changes ownership the object itself should also become no-copy or no-transfer. But currently OpenSim doesn't always apply the folded permissions, so users that receive an object may have more permissions over it than they should.
I brought this up at a dev meeting a week or two ago and am now reporting it here so there's some readily-locatable reminder/record of it.<br /> <br /> When attempting to HG TP home from another grid, I am unable to return to any region that I host on a computer in the same network as my viewer; however I have no trouble returning to any other region in the local grid.<br /> <br /> When my IP address is initially sent to the destination region informing it of my request to tp, the region received my outward facing IP. Then after "consulting" with the grid login service, when the second check of my IP is made by the region, the IP address that shows in console is my local network router's IP (192.168.1.1) which of course doesn't match the initial one so the tp is refused.<br /> <br /> I discussed this further with Justin at the end of the meeting and we conducted a couple tests of me moving between OSCC and my self-hosted region where he confirmed the bug.
It's been a while since I last did conventional terraforming (perhaps 18 months) but I needed to make some tweaks in the last few days and found the behaviour of the basic bulldozen tools to be significantly different than I'd remembered.<br /> <br /> - The "raise" tool requires a strength setting of at least <a href="http://opensimulator.org/mantis/view.php?id=30#c15">0000030:0000015</a>%-20% before the terrain seems to move at all<br /> <br /> - The "lower" tool seems to work fine, making very small changes at near-zero settings<br /> <br /> - The "flatten" tool seems to work fine.<br /> <br /> - The "smooth" tool seems extremely aggressive in its smoothing, even at near-zero settings. In the past I could set the slider very low and gradually make the contours I wanted, but now even the slightest click at near-zero results in a huge (undesired) smoothing <br /> <br /> - The "roughen" tool I can't comment on since I rarely if ever used it in the past so have no basis for comparison<br /> <br /> - I haven't tested the revert funtion
Per discussion at the last several dev meetings I'm creating this report because I can't locate the original report where I described this behaviour.<br /> <br /> It seems that on occasion one or more assets worn by an agent in a region are not sent to another agent in the region. When this happens the only way the agent will ever receive the asset is to log out and then back in again. If the wearer relogs the asset still never gets sent.<br /> <br /> Conditions that appear to make this more likely to occur:<br /> - high region traffic -- I notice it most with 10+ avi in a region<br /> - large asset size -- I notice it occurring far more commonly with mesh, but it will also happen with sculpties and textures worn as attachments<br /> - it seems most common when the wearer is a hypergrid visitor to the region rather than a native avatar but the agent who is failing to see something can be either<br /> - when it happens, it's not consistent in the sense that if I tp into a region where there are already 10 avi and I'm wearing 2 mesh items, many will see me complete, one or two may only see item A and one or two may only see item B
EM terrain downloading does not work. It shows messages "downloading terrain" and "download finished" but there is no file in the folder pointed to.<br /> <br /> This is my first post here so forgive me for not knowing what to do. I am not a techy type.
I noticed that when i enabled the option to have offline IM sent to email in my viewer preferences, it didn't appear to save the new values.<br /> <br /> After looking through the code I have found that when the service is asked for the preferences, it first retrieves the email from the user account and then saves the preferences before then reading them again and returning. This means that offlineImViaEmail is effectively reset to default values when it is requested. Following the code there are a couple of things that stand out. Bellow is my interpretation of what is happening and some questions i have about some of the steps.<br /> <br /> 1) Region module creates a blank prefs object, assigns the uuid and passes it to the grid service. What is the reason for sending a blank object at this point rather than just the uuid?<br /> <br /> 2) The grid service gets this object. The first thing it does is check if there is an email address but there will never be one as its an empty object waiting to be populated and returned. Is there any cases where the method is given a full prefs object when requesting them?<br /> <br /> 3) Now it has detected no email address, it reads this from the user account and saves the prefs object to the database. This is where the defaults are written. Only the email address is set because it was read from the user account.<br /> <br /> 4) It now reads back the prefs it has just saved and returns that to the region.<br /> <br /> Please let me know if there is something I'm missing here.<br /> Thanks :)
0007400: Console feature that can automatically build a random city including buildings, roads, & terrain. Aurora source code attached.
Aurora once had a feature that would save hundreds of hours of work by automatically building a random city including buildings, roads, and terrain. The full source code for the Aurora module will be attached to this mantis and is also available for download here: <a href="https://github.com/CobraElDiablo/CityModule">https://github.com/CobraElDiablo/CityModule</a> [<a href="https://github.com/CobraElDiablo/CityModule" target="_blank">^</a>]<br /> <br /> It would be wonderful if this could eventually be converted to work with Opensim.
Setting serverside_object_permissions = false in the [Permissions] section of OpenSim.ini does not seem to have an effect in some cases.
Warp 3d Error on the console. <br /> <br /> 02:41:45 - [WARP 3D IMAGE MODULE]: Failed to decode asset 3f7101a8-e9d8-4b1f-bf1a-a3c05c7637b3, exception System.ApplicationExcepti<br /> on: Error while reading bit stream header or parsing packets. ---> System.IO.IOException: Position beyond EOF
1. When opening the Preferences panel in any viewer the console will log the following error:<br /> <br /> 22:09:43 - [PROFILES_DATA]: AgentInterestsUpdate exception Argument cannot be null.<br /> Parameter name: obj<br /> 22:09:43 - [PROFILES_DATA]: Get preferences exception Cannot cast from source type to destination type.<br /> <br /> <br /> 2. When hypergridding to another grid the console will log the following error:<br /> <br /> 22:35:58 - [PROFILES_DATA]: GetAvatarNotes exception Cannot cast from source type to destination type.
It looks like XEngine has some mismatch regarding the types of some LSL constants for llAttachToAvatarTemp. This doesn't happen for llAttachToAvatar.
When you have a multi prim linkset with a collision even in the root prim, collisions on child prims don't trigger the event.
0007397: [EVENT MANAGER]: Delegate for TriggerOnNewInventoryItemUploadComplete failed - continuing. Document does not have a root element
Avatar on one grid (e.g. OSCC14 grid or LFGrid) visits Openvue or AiLand grids (both on r/15618 quite recent dev master) and on clicking a box that gives inventory via a script the inventory does seem to appear fine, taking a while. But the folder with the given items appears at top level of "Inventory" not in "My Suitcase" as expected. And the two grid servers give red error indicating a failure at the completion of the inventory upload to the visitor's grid.<br /> <br /> An indicative error (many repeats like this perhaps for each separate asset involved)...<br /> <br /> 17:07:34 - [HG ASSET MAPPER]: Starting to send asset 42bca80f-79c2-485a-93d7-654<br /> b357992f0 with children to asset server <a href="http://cc.opensimulator.org:8002">http://cc.opensimulator.org:8002</a> [<a href="http://cc.opensimulator.org:8002" target="_blank">^</a>]<br /> 17:07:34 - [EVENT MANAGER]: Delegate for TriggerOnNewInventoryItemUploadComplete<br /> failed - continuing. Document does not have a root element. at System.Xml.X<br /> mlTextWriter.WriteEndDocument()<br /> at OpenSim.Region.CoreModules.Framework.InventoryAccess.HGAssetMapper.Rewrite<br /> SOP(String xmlData) in d:\Temp\opensim-7100475\OpenSim\Region\CoreModules\Framew<br /> ork\InventoryAccess\HGAssetMapper.cs:line 339<br /> at OpenSim.Region.CoreModules.Framework.InventoryAccess.HGAssetMapper.AdjustI<br /> dentifiers(Byte data) in d:\Temp\opensim-7100475\OpenSim\Region\CoreModules\Fr<br /> amework\InventoryAccess\HGAssetMapper.cs:line 189<br /> at OpenSim.Region.CoreModules.Framework.InventoryAccess.HGAssetMapper.PostAss<br /> et(String url, AssetBase asset) in d:\Temp\opensim-7100475\OpenSim\Region\CoreMo<br /> dules\Framework\InventoryAccess\HGAssetMapper.cs:line 145<br /> at OpenSim.Region.CoreModules.Framework.InventoryAccess.HGAssetMapper.Post(UU<br /> ID assetID, UUID ownerID, String userAssetURL) in d:\Temp\opensim-7100475\OpenSi<br /> m\Region\CoreModules\Framework\InventoryAccess\HGAssetMapper.cs:line 483<br /> at OpenSim.Region.CoreModules.Framework.InventoryAccess.HGInventoryAccessModu<br /> le.PostInventoryAsset(UUID avatarID, AssetType type, UUID assetID, String name,<br /> Int32 userlevel) in d:\Temp\opensim-7100475\OpenSim\Region\CoreModules\Framework<br /> \InventoryAccess\HGInventoryAccessModule.cs:line 220<br /> at OpenSim.Region.Framework.Scenes.EventManager.TriggerOnNewInventoryItemUplo<br /> adComplete(UUID agentID, AssetType type, UUID AssetID, String AssetName, Int32 u<br /> serlevel) in d:\Temp\opensim-7100475\OpenSim\Region\Framework\Scenes\EventManage<br /> r.cs:line 2182
After starting the recording of stats to a log file, I see 3 repeated messages generated on the console, every 5 seconds when the stats are being recorded. Turning off the stat recording stops this behavior. Repeated start/stops yield the same results.<br /> <br /> I have been able to reproduce this on 3 different simulators all on the same server.<br /> <br /> The message repeated to the console is;<br /> Got a bad hardware address length for an AF_PACKET 16 8
I brought this up at last Tuesday's dev meeting but thought I should document it here as well. When OSG first went down I decided to set up a "quick and easy" HG standalone as a short terms solution so I downloaded the Diva OpenSim 0.8.0 post-fixes version (dated 8/10/2014) and created a new schema in MySQL for it. When it became apparent that OSG would be down for a more extended time, I downloaded and built the latest git to a new folder, set it to use the database I'd created and used with the Diva install, and deleted the Diva install folder from my system. When I do git builds for OSG I add the profiles and search add-ons prior to building, but for the standalone HG I did not -- so it's built directly using the exact current git master.<br /> <br /> While still using the Diva install I created a single group for my "grid", and then during HG travels my avi was invited to join several other groups. As soon as I did that, upon returning home I received notices that I was at my allowed number of groups and would have to leave on in order to join one of the others I had been invited to.<br /> <br /> I wasn't particularly concerned about this, thinking it was a hold-over from the past when Diva kindly included a limited version of groups with that restriction. However, I expected after updating to V2 groups with current git master that this restriction would be removed but I am still experiencing the same issue if someone invites me to join a HG group.<br /> <br /> I have tested and was able to create additional groups in my own standalone so it appears that the group limit issue is only being triggered when you are invited to join a group on another grid.
The sim had been running fine for a few days, then a HG user logged in and the console was filled with "slow post request" and "Could not get contents of folder" warnings. After about 5 mins the HG user and another avatar present were logged out with "No Packets Received" warnings. After this, all networking seems to fail for the next hour at which point the problem was discovered and the region restarted.<br /> <br /> During the hour before restarting the console was being filled with "Request Timeouts" some to the robust presence service (on the same server) and a lot to the HG users xinventory service. Restarting also took along time as the requests to deregister from the grid service were timing out.<br /> <br /> I would speculate that the requests to the HG users grid were failing and this caused a backlog in network data.