Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008304opensim[GRID] Asset Servicepublic2018-03-12 20:012019-04-21 03:24
Assigned To 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0008304: Random textures are getting stuck in request queue
DescriptionOn OpenSim 0.9 (Master revision) If I log in to an OpenSim instance with a clean viewer cache I have noticed that some textures seem to randomly get stuck in the request queue (As seen in the Texture Console, CTRL + SHIFT + 3) and they will either stop downloading completely or download will progress extremely slowly (Maybe 1% every 5 or 10 seconds). This results in the affected textures remaining gray or blurry for a long time. I have noticed a lot of times it seems to be materials textures doing this (Usually normal maps) and it will result in a very fuzzy and/or misaligned bump look; but sometimes standard textures (diffuse) will do it as well. The only thing I've found that seems to help is to relog, go to a different region and then come back, or just simply wait until it decides to completely load in which can take quite a while.

Attached to this mantis is an example of the issue occurring. As can be seen; there are not that many textures waiting to be downloaded, but all of them are stuck in this state while the rest of the scene seems to have loaded in properly.

I have verified that these aren't damaged images or even particularly large images (The ones stuck in this example are at max 256x256) and they do eventually load after a while, but it doesn't always get stuck on the same images either, it appears to be at random.

I have also tried OpenSim in various different configurations including standalone, grid, default settings, and a new database but nothing seems to help. Unsure if this is a viewer or OpenSim issue (or perhaps both?) but testing on an older version of OpenSim (0.8.x series) I don't see this issue. Used the same viewer in both cases (Singularity).
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Attached Filesjpg file icon texture queue.JPG [^] (74,449 bytes) 2018-03-12 20:01

png file icon 8ad28e5ede07428025e6af7e6f189acd[1].png [^] (955,297 bytes) 2018-11-04 22:31
png file icon textureconsole.png [^] (200,120 bytes) 2018-11-04 23:28

- Relationships

-  Notes
aiaustin (developer)
2018-10-26 03:59
edited on: 2018-10-26 04:00

I see the blurry textures issue and they that take a LONG time (over 3 minutes) to finally crisp up.

I see its been an issue for others for some time too. Some suggestions include that the HTTP downloads and queue can have problems and one potential fix is to change a debug setting called TextureFetchConcurrency: Maximum number of HTTP connections used for texture fetches. Oddly the DEFAULT setting for this is 0 it seems. But setting it to 4 or 8 did not seem to make much (any?) difference.

Using latest 0.9.1 dev master versions right up to 506 (2018-10-25). Bullet physics. Windows 10 version 1803. Firestorm (64Bit SL/OS). 100mbps wired internet link.

Anyone got thoughts on how to help with this, and whether its a viewer side thing, or if anything on the OpenSim server end can help?

aiaustin (developer)
2018-10-29 04:31
edited on: 2018-10-29 04:40

I tested with Singularity 1.8.7 (Windows 64 bit) on AiLand grid on latest dev master and that was also VERY slow. After 30 minutes a small set of perhaps 50 textures on faces of simple cubes had not finished loading and of those that were not still grey the image was blurred. This has been an issue since March or April 2018 on dev master branch. It does not seem to be only a Firestorm viewer issue (my usual viewer).

Singularity log shows this sort of thing as avatar is sitting on region waiting for textures after 30 minutes or so...

2018-10-29T11:32:12Z INFO: display_stats: FPS: 261.90
2018-10-29T11:32:12Z INFO: display_stats: VBO: 394 glVBO: 737
2018-10-29T11:32:13Z WARNING: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: Request to "" timed out for HTTPGetResponder
2018-10-29T11:32:13Z INFO: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: Effective URL: "". [^]
2018-10-29T11:32:13Z INFO: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: Hostname seems to have been still in the DNS cache.
2018-10-29T11:32:13Z INFO: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: The socket was most likely already connected (or you connected to a proxy with a connect time of under 0000006:0000010 ms).
2018-10-29T11:32:13Z WARNING: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: The SSL/TLS handshake never occurred according to the timings!
2018-10-29T11:32:13Z WARNING: HTTPGetResponder::completedRaw: CURL GET FAILED, status:497 reason: Timeout was reached
2018-10-29T11:32:13Z WARNING: LLTextureFetchWorker::doWork: No response from server (HTTP_INTERNAL_ERROR_CURL_TIMEOUT): [^]
2018-10-29T11:32:13Z WARNING: SGHostBlackList::add: Requested adding to blacklist: [^]

2018-10-29T11:39:19Z INFO: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: The socket was most likely already connected (or you connected to a proxy with a connect time of under 0000006:0000010 ms).
2018-10-29T11:39:19Z WARNING: AICurlPrivate::curlthread::HTTPTimeout::print_diagnostics: The SSL/TLS handshake never occurred according to the timings!
2018-10-29T11:39:19Z WARNING: HTTPGetResponder::completedRaw: CURL GET FAILED, status:497 reason: Timeout was reached
2018-10-29T11:39:19Z WARNING: LLTextureFetchWorker::doWork: No response from server (HTTP_INTERNAL_ERROR_CURL_TIMEOUT): [^]
2018-10-29T11:39:19Z WARNING: SGHostBlackList::add: Requested adding to blacklist: [^]
2018-10-29T11:39:19Z WARNING: LLTextureFetchWorker::callbackDecoded: DECODE FAILED: id = 036f8268-5b96-48d7-8cef-a84acd1e0442, Discard = 0
2018-10-29T11:39:19Z WARNING: LLTextureFetchWorker::doWork: 036f8268-5b96-48d7-8cef-a84acd1e0442: Decode of cached file failed (removed), retrying

aiaustin (developer)
2018-10-29 05:01

And a similar test with console logging on for Firestorm 5.1.7 …

2018-10-29T11:58:28Z INFO: newview/llviewerdisplay.cpp(237) : display_stats: FPS: 157.50
2018-10-29T11:58:33Z WARNING: llcorehttp/_httplibcurl.cpp(435) : LLCore::HttpLibcurl::completeRequest: HTTP pipelining possibly out of sync, request wanted: 599-9467 got: 0-18446744073709551615 url: [^]
2018-10-29T11:58:33Z WARNING: llcorehttp/_httplibcurl.cpp(435) : LLCore::HttpLibcurl::completeRequest: HTTP pipelining possibly out of sync, request wanted: 599-13023 got: 0-18446744073709551615 url: [^]
2018-10-29T11:58:34Z INFO: #Mesh; newview/llmeshrepository.cpp(5149) : LLMeshRepository::metricsUpdate: EventMarker {'fetches':i4,'reason':'Mesh Download Quiescent','scope':'Login','start':r40.937635,'stop':r57.479034,'sys_cpu':r0.000000,'teleports':i1,'user_cpu':r0.000000}
2018-10-29T11:58:38Z INFO: newview/llviewerdisplay.cpp(237) : display_stats: FPS: 159.60
2018-10-29T11:58:38Z WARNING: llcorehttp/_httplibcurl.cpp(435) : LLCore::HttpLibcurl::completeRequest: HTTP pipelining possibly out of sync, request wanted: 1535- got: 0-18446744073709551615 url: [^]
2018-10-29T11:58:38Z WARNING: llcorehttp/_httplibcurl.cpp(435) : LLCore::HttpLibcurl::completeRequest: HTTP pipelining possibly out of sync, request wanted: 1535- got: 0-18446744073709551615 url: [^]
2018-10-29T11:58:38Z WARNING: llcorehttp/_httplibcurl.cpp(435) : LLCore::HttpLibcurl::completeRequest: HTTP pipelining possibly out of sync, request wanted: 767-4609 got: 0-18446744073709551615 url: [^]
2018-10-29T11:58:48Z INFO: newview/llviewerdisplay.cpp(237) : display_stats: FPS: 163.30
2018-10-29T11:58:58Z INFO: newview/llviewerdisplay.cpp(237) : display_stats: FPS: 184.90
2018-10-29T11:59:02Z WARNING: #CoreHttp; llcorehttp/_httppolicy.cpp(434) : LLCore::HttpPolicy::stageAfterCompletion: HTTP request 000002453FF58D80 failed after 0 retries. Reason: Timeout was reached (Easy_28)
2018-10-29T11:59:02Z WARNING: #CoreHTTP; llmessage/llcorehttputil.cpp(282) : LLCoreHttpUtil::HttpCoroHandler::onCompleted: Possible failure [Easy_28] cannot POST url '' [^] because Timeout was reached
aiaustin (developer)
2018-11-02 04:36

Please test this again with 0.9.1 dev master releases 512 (2018-11-02 02:25) and later as a fix for serious TP issues related to HTTP event handling may have a bearing on this issue.
mewtwo0641 (reporter)
2018-11-02 06:57

@aiaustin - Just tried latest master (Commit 3e6342); But I can't tell much difference. Textures do seem to download a little faster over all since throttle methods were changed up recently... But there are still random textures that get "stuck" and once they're stuck they download super slowly (Takes minutes upon minutes). These are usually material textures but not always. As reported originally the affected textures are not very large (I saw mostly 256x256, maybe the occasional 512x512) and I have verified that they are not corrupt.
BillBlight (developer)
2018-11-02 08:45

@mewtwo, I actually wish I could replicate this, because it is annoying to users I know, but , I can't find what set of variables makes it happen .. Textures just pop right in .. The other thing Firestorm has the http pipeline force disabled in their code, regardless of what the checkbox says, you might try Alchemy and see if the textures still get stuck, at least that would point to something ..
mewtwo0641 (reporter)
2018-11-04 22:36

@BillBlight - It is quite annoying I agree. I am primarily testing on Singularity at the moment but Alchemy has also demonstrated this behavior as well in the recent past.

I've added an additional screenshot showing textures that are having a hard time completing download. This is still an issue at commit 9e274c. I have noticed that moving around for a little while and or moving the camera around randomly seems to help give those textures a "kick in the rear" and they may start moving again but it isn't consistent. I am wondering if there is a texture download priority issue (as indeed the related mantis would suggest)? My OpenSim.ini settings for texture priority are left at the default settings.
BillBlight (developer)
2018-11-04 23:30
edited on: 2018-11-04 23:34

This again is one of those things that is going to be hard to catch ...

I can't make it happen .. Cleared my cache went to several sims and within a few seconds up to a minute and a half I have all the textures ..

It is possible that some of the textures are either corrupt or from HG assets ..

Have you tested this specific problem on multiple sims?

If they are HG enabled can you give some locations to test?

I have attached an image of my texture console ....

and just as a fyi those textures that appear to be stuck I can confirm are from an HG asset .. but they do pop in ..

But the odd behavior is that the ones that appear to be stuck have no size info and just all at once "appear" ..

I can get no textures to hang in the middle ..

mewtwo0641 (reporter)
2018-11-04 23:58

@BillBlight - I don't have HG enabled on my grid and never have in the past so I am 99.9% certain these textures aren't from someone else's grid. I've also verified that these are not corrupt textures; Testing with the 0.8.X series of OpenSim every thing works completely fine and there's no issues with texture downloading. Even more perplexing is that ROBUST, all OpenSim instances, and the asset data base all reside on the same network as the computers and viewers that I am testing with. Nothing is being sent or received over WAN; It's all LAN (Although I do see this issue pop up on WAN configured instances).

The issue does show up in multiple different regions/sims.
aiaustin (developer)
2018-11-05 05:42
edited on: 2018-11-05 07:27

@mewtwo0641 you probably already know this...but Ctrl+Shift+4 brings up the viewer Debug Console and I found it interesting in finding some of the issues related to the TP failure problem in Mantis 8383. Maybe it could show something that will help diagnose the issue(s).

But note that in the log given by that debug console @Ubit told me to ignore warnings given once every 60 seconds per region in which the avatar has a child presence which are of form: HTTP request … failed after 0 retries. Reason: Bad Gateway (Http_502). [^]

BillBlight (developer)
2018-11-05 09:35
edited on: 2018-11-05 09:35

@mewtwo0641 What database are you using?

How many regions per instance?

(this could also be a strange loopback issue with the router/PC)

.9x is an entirely different animal than .8x comparing , "this does not happen in .8" is not really helpful.

current .9x uses a lot more http traffic than .8x did so it is a different type of networking traffic.

Is anybody else looking at this Mantis seeing the same thing? We could use more test cases.

aiaustin (developer)
2018-11-05 10:08
edited on: 2018-11-05 10:09

As I noted elsewhere when investigating TP issues, I was also seeing stuck and blurry images, some even after 30 minutes stuck, region crossing failures leading to avatar going off over an adjacent region without the location changing correctly, etc. But these are all resolved in my two Windows 10 MySQL5.7 grids setups by using the latest dev master that fixed the XMLRPC issue... or commenting out the use of the XMLRPC port worked too.

But @mewtwo0641 said he was using the latest dev master and still has the blurry and stuck images problem, so there must be other causes or environments in which this happens.

BillBlight (developer)
2018-11-05 10:18

I guess I should have been more clear in what I said ..

I meant more people still having this issue, I saw it in the past but cannot replicate it now ..

I know it is a hard one to replicate, but this type of issue , the symptoms could be caused by multiple things.
aiaustin (developer)
2018-11-05 10:22

@mewtwo0641, just for a belt and braces approach and a clear test, can you check you are on the very latest dev master and then clear your cache (using Firestorm). Test again then so its a fresh download of all textures.
mewtwo0641 (reporter)
2018-11-06 19:05
edited on: 2018-11-06 19:09

@BillBlight - This is my setup for testing

Database: MySQL 5.6

Instance Setup: 12 regions on 1 OpenSim instance in Grid mode (No HG). At least half of those regions are completely empty and the remaining regions are pretty sparsely populated; Nothing too heavy on the objects, textures, or script counts. I would like to note that I have tried reducing this down to just 1 region and 1 instance but still saw the issue... So I am fairly certain that it isn't the number of regions I'm running.

Router: Linksys WRT1900ACS v2 running firmware DD-WRT v3.0-r37582 std (11/03/18) with NAT loopback enabled as described here [^] and here [^] . For sake of completion and ensuring it isn't the router itself; I have tested with a couple different brand routers with no difference.

System: AMD FX 8320 8 Core @ 3.5 GHz on 16 GB DDR3 RAM. (Monitoring CPU use and RAM use I don't really see either of those resources being taxed/stressed during normal every day use.)

Network: Everything is running on 10/100/1000 at gigabit speed; My test OS install is all on LAN, no WAN access (Though I've seen the issue on WAN as well)

@aiaustin - I am testing on the very latest master (commit 41df4d / November 6, 2018). I have been clearing my cache between each test to ensure that textures/mesh downloads are coming from OpenSim and not from my viewer cache.

I would like to mention that on my test setup, all services are local to each other, that is: MySQL, the database, ROBUST, and OpenSim instance(s) all reside on the same computer; actual hardware/no virtual machine. Everything is set to communicate with each other via and their appropriate ports. The only place in my config files that don't use the local host address is my regions, I've set that up to the computer that runs OS's LAN address so that other computers on my network can also log in. That in mind, I have tested both running my viewer on the computer that is running OpenSim, on a different computer not running OpenSim, and both scenarios to no apparent difference in the issue.

BillBlight (developer)
2018-11-06 19:14

just for added info,

State. The texture request's current state in the fetching/decoding state machine. States include:
"---" - The texture is not being fetched (hopefully because current discard <= desired discard). If red, invalid state.
"INI" - The texture is waiting to be processed by the state machine
"DSK" - Reading from local cache (cyan=header, blue=body)
"NET" - Indicates the texture is in the UDP request queue, but has not yet been requested from the servers
"SIM" - Waiting for UDP packet data from simulator
"HTW" - Resource waiting for HTTP resources prior to "HTP" state
"REQ" - Preparing to send HTTP request to grid
"HTP" - Waiting for HTTP response data
"DEC" - Decoding Image
"WRT" - Writing image to local cache
"END" - Waiting for a request for more data or deletion (after timeout)
"CRE" - Texture needs to be created
"FUL/BAD/MIS" - Debug, shouldn't happen (needs create, fully loaded, bad, missing)
Pkt. Handling information for recently-received data (mostly UDP-oriented):
White = packet received from simulator
Green = data requested from simulator
Yellow = texture processed by state machine
Bnd. Binding of fetched data to OpenGL:
Purple = Texture is currently bound (i.e. being rendered)

So definitely anything , INI, DSK, or NET are viewer side .. Also DEC means the viewer has the texture and is decoding it.

Only providing this so know where to look ..
mewtwo0641 (reporter)
2018-11-06 19:32

@BillBlight - That is good info, Some of those "codes" I had an idea of what they were for but most I just didn't.

I also forgot to mention, looking at the HTTP Console (CTRL + SHIFT + 7) to get an idea of the bandwidth use; It seems to be just doing nothing for a good chunk of time (Bandwidth use is showing 0 out of whatever the viewer's max is set to) even when there are still textures that haven't loaded yet or are "half" loaded.

I have a theory that camera position seems to have some bearing on this (Though perhaps it's only part of the issue). It seems like if there are any textures that were being loaded and the camera quit looking in that direction... They just stop downloading but they're still set at the highest priority. So any other "new" textures that the camera looks at get put in the queue but never do anything until you put your camera back on what was previously downloading to get the viewer to download the textures that were waiting previously in order for the viewer to start working on the newly queued textures. I'm not sure how I'd go about proving this but it does seem pretty consistent with what I have been seeing in my testings.
BillBlight (developer)
2018-11-06 19:33

If you are using Firestorm it does not do hardly anything HTTP in opensim, they have it neutered .. Regardless of those check marks ..
mewtwo0641 (reporter)
2018-11-06 19:42

I am using primarily Singularity actually. At some point though I'm going to run some tests with a few different viewers, namely, Singularity, Firestorm, Alchemy, and perhaps Phoenix Viewer for good measure.
BillBlight (developer)
2018-11-06 19:50
edited on: 2018-11-08 08:54

I'm using a modified FS with the HTTPpipeline re-enabled, to test with as well, but even on standard FS I can't make this happen, which is very weird. Not saying you are not seeing it, but one of those things hard to see the issue , when you CAN'T see the issue ... You know what I mean ..

mewtwo0641 (reporter)
2018-11-06 20:03

Yes I understand, intermittent issues are the absolute worst to deal with since you can't reproduce them 100% of the time with 100% accuracy. I would offer an OAR of the region(s) I'm seeing the issue in but unfortunately I'm not able to because these are regions containing projects (That are also afflicted by this issue) that I'm working on for some people and I am pretty sure they would be unhappy with me if I gave an OAR out of it :)
mewtwo0641 (reporter)
2018-11-07 20:46
edited on: 2018-11-07 20:48

This does seem a fair bit better by latest master (Commit 72d9bb; November 8, 2018) although the issue may have "shifted" onto other textures now. Some of the textures I have seen that frequently demonstrated the issue seem to rez in a fair deal better now and in a more consistent manner but other textures (Especially in the far background) seem to get stuck now. Changing UpdatePrioritizationScheme from the default to SimpleAngularDistance seems to help some while BestAvatarResponsiveness demonstrates this new issue a bit more.

In the texture console (CTRL + SHIFT + 3) am noticing that some textures are being sent on UDP now for some reason (As opposed to HTTP, or HTP as used by the texture console). Possibly they were moved from HTTP to UDP for whatever reason? Those are the ones that seem to be getting stuck for a while.

I wouldn't claim this resolved just yet; But will keep an eye on it and keep testing.

aiaustin (developer)
2018-11-08 08:19

@BillBlight … you added the note about the Firestorm viewer re "it does not do hardly anything HTTP in opensim, they have it neutered .. Regardless of those check marks .. ".

I wonder if you know the background to this and if it relates to a particular time when OpenSim (or the majority of grids that use OpenSim) did not support HTTP asset fetches. Is it timely to raise this over on the Firestorm JIRA to get the defaults for the OpenSim branch in their code changed to reflect the latest stable release at
UbitUmarov (administrator)
2018-11-08 08:20

just some notes:
 - Seems viewers request avatar textures (baked) via lludp. (NET and SIM on console) on the figure with several NET and according to the information bill pasted above from ll viewer docs, NET means viewer placed the request on its queue but still did not ask the region for it ( will change to SIM when it does it) region udp transfer basically as it was, under lludp throttles and less priority than other structural traffic. Reason why bakes are udp mb related to the fact that at sl http comes from cdn and bakes need to come from regions ?? just guessing.

 - SimpleAngularDistance should not have much impact on textures it just changes the order region sends prims to viewer, goal is larger in screen pixels size first. Note this will never be exact. Size in pixels is heavy to calculate and regions don't even have full information, so crude estimations are used
also camera position is ignored, only avatar position is considered. This is because cam position changes a lot and fast (see zoom out attached to avatar and rotating it for example)

 - SimpleAngularDistance + culling + moderated viewer draw distance, have indirect impact. Viewers will have less objects to consider on all the work needed to prioritize things, like textures requests ( also per LOD) but with avatar moving around fast, this will increase lludp traffic with object lists updates. Viewers to see to freeze deleting a lot of prims also.
Where Bill told fs does not do http he meant http pipeline feature. FS does http
Alchemy, at least the version I have, only does UDP on opensim, because of a typo they have on the texture caps name.
aiaustin (developer)
2018-11-08 09:15
edited on: 2018-11-08 14:07

Thanks for the explanation @Ubit

I spoke with Cinder and she does know about the Alchemy code typo in an earlier version... she tells me that version is now out of date. Also, a bit of background is that she says the GetTexture cap is deprecated within the Second Life protocol with the ViewerAsset capability taking its place and GetTexture is slated for removal in the Linden Lab code development path.

UbitUmarov (administrator)
2018-11-08 13:12

Thanks for the information.
GetTexture is a required OpenSim cap for http texture fetch and will stay so until further notice.
mewtwo0641 (reporter)
2019-04-13 21:39
edited on: 2019-04-13 21:39

This is still an issue for me as of master; but a new thing I have noticed is that gray unloaded textures are staying gray for longer than they used to, a lot of times indefinitely until I zoom onto them and start waving the mouse frantically over the gray prims and/or right clicking them and going into edit mode repeatedly to try to force the viewer to focus on those objects and load their textures. In especially bad cases I will have to use the reload textures function of the viewer or failing that a relog. While doing all that does (eventually) get the textures to load in; I don't think it should require that much workaround on the users' end to get things to load in.

UbitUmarov (administrator)
2019-04-17 05:26

This will always be a issue :(
in case of heavy load like arrinving in a new region, you just need to wait for the transfer to happen (without killing everyone else, ie throttled transfer)
but viewers also don't even ask for textures or LODs, when we do expect, they make decisions based on where they think we are looking. No rare occasions we see all fine, turn around and avatar meshes are not there or textures.
Viewers cache, and clever contents creation are fundamental for performance.
If we want large pretty regions, the (performance) quality of the contents needs to be a LOT better. Most content we have (and SL) is far from that.
Of course this does not mean all must be professional 3D creators, like we see now in other systems, but we all can learn.
mewtwo0641 (reporter)
2019-04-21 03:24
edited on: 2019-04-21 03:26

This is true, I have always seen it in some form or another with the random odd texture, but I've never seen it happen as frequently or on as many objects as I have in the past several months; It seems worse now than it used to be.

Not a whole lot has changed on the regions that I run in either; that is to say I haven't suddenly added a whole bunch of stuff or rezzed out super poorly optimized objects that could point to a possible dip in performance (Compared to what I had rezzed out before seeing this issue).

Also tried dropping all but just one region to check and see if perhaps another region was hogging resources/CPU that could possibly explain the performance drop but I still see this issue running only just one region up. CPU use is pretty light around appx 1% to 3%, Robust is using about 50 MB Mem, and OpenSim.exe is using around 150 MB Mem. There's not much on the region, no scripted objects, and no mesh objects.

I attempted to git bisect between commits e08b43569e36002f5e022304602e24465bd442b7 and master. Results were inconclusive due to the randomness of the issue, but as far as I can tell, this issue wasn't as bad at commit e08b43569e36002f5e022304602e24465bd442b7 as it is now. Best I can say at the moment is it has gotten worse sometime in the past 6 or 7 months.

- Issue History
Date Modified Username Field Change
2018-03-12 20:01 mewtwo0641 New Issue
2018-03-12 20:01 mewtwo0641 File Added: texture queue.JPG
2018-10-26 03:59 aiaustin Note Added: 0033264
2018-10-26 04:00 aiaustin Note Edited: 0033264 View Revisions
2018-10-26 10:39 Sheera Khan Relationship added related to 0008396
2018-10-29 04:31 aiaustin Note Added: 0033293
2018-10-29 04:33 aiaustin Note Edited: 0033293 View Revisions
2018-10-29 04:34 aiaustin Relationship added related to 0008383
2018-10-29 04:34 aiaustin Relationship deleted related to 0008383
2018-10-29 04:34 aiaustin Relationship added related to 0008382
2018-10-29 04:40 aiaustin Note Edited: 0033293 View Revisions
2018-10-29 05:01 aiaustin Note Added: 0033294
2018-10-29 09:51 UbitUmarov Relationship deleted related to 0008382
2018-11-02 04:36 aiaustin Note Added: 0033380
2018-11-02 06:57 mewtwo0641 Note Added: 0033388
2018-11-02 08:45 BillBlight Note Added: 0033389
2018-11-04 22:31 mewtwo0641 File Added: 8ad28e5ede07428025e6af7e6f189acd[1].png
2018-11-04 22:36 mewtwo0641 Note Added: 0033395
2018-11-04 23:28 BillBlight File Added: textureconsole.png
2018-11-04 23:30 BillBlight Note Added: 0033396
2018-11-04 23:31 BillBlight Note Edited: 0033396 View Revisions
2018-11-04 23:32 BillBlight Note Edited: 0033396 View Revisions
2018-11-04 23:34 BillBlight Note Edited: 0033396 View Revisions
2018-11-04 23:58 mewtwo0641 Note Added: 0033397
2018-11-05 05:42 aiaustin Note Added: 0033398
2018-11-05 07:27 aiaustin Note Edited: 0033398 View Revisions
2018-11-05 09:35 BillBlight Note Added: 0033399
2018-11-05 09:35 BillBlight Note Edited: 0033399 View Revisions
2018-11-05 10:08 aiaustin Note Added: 0033400
2018-11-05 10:09 aiaustin Note Edited: 0033400 View Revisions
2018-11-05 10:18 BillBlight Note Added: 0033401
2018-11-05 10:22 aiaustin Note Added: 0033402
2018-11-06 19:05 mewtwo0641 Note Added: 0033427
2018-11-06 19:07 mewtwo0641 Note Edited: 0033427 View Revisions
2018-11-06 19:09 mewtwo0641 Note Edited: 0033427 View Revisions
2018-11-06 19:14 BillBlight Note Added: 0033428
2018-11-06 19:32 mewtwo0641 Note Added: 0033429
2018-11-06 19:33 BillBlight Note Added: 0033430
2018-11-06 19:42 mewtwo0641 Note Added: 0033431
2018-11-06 19:50 BillBlight Note Added: 0033432
2018-11-06 20:03 mewtwo0641 Note Added: 0033433
2018-11-07 10:11 UbitUmarov Relationship deleted related to 0008396
2018-11-07 20:46 mewtwo0641 Note Added: 0033444
2018-11-07 20:48 mewtwo0641 Note Edited: 0033444 View Revisions
2018-11-08 08:19 aiaustin Note Added: 0033446
2018-11-08 08:20 UbitUmarov Note Added: 0033447
2018-11-08 08:54 BillBlight Note Edited: 0033432 View Revisions
2018-11-08 09:15 aiaustin Note Added: 0033448
2018-11-08 12:30 aiaustin Note Edited: 0033448 View Revisions
2018-11-08 12:31 aiaustin Note Edited: 0033448 View Revisions
2018-11-08 13:12 UbitUmarov Note Added: 0033450
2018-11-08 14:07 aiaustin Note Edited: 0033448 View Revisions
2018-11-08 16:01 UbitUmarov Note Added: 0033454
2018-11-08 16:01 UbitUmarov Note Deleted: 0033454
2019-04-13 21:39 mewtwo0641 Note Added: 0035102
2019-04-13 21:39 mewtwo0641 Note Edited: 0035102 View Revisions
2019-04-17 05:26 UbitUmarov Note Added: 0035139
2019-04-21 03:24 mewtwo0641 Note Added: 0035158
2019-04-21 03:25 mewtwo0641 Note Edited: 0035158 View Revisions
2019-04-21 03:26 mewtwo0641 Note Edited: 0035158 View Revisions

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker