Jump to content

Animesh Beta testing is HERE!!


You are about to reply to a thread that has been inactive for 2315 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

5 hours ago, Medhue Simoni said:

Now..... what say you?

I assume by now you've read more posts in the thread, including where Fluffy kinda drew me to a similar conclusion, giving up the calculated randomness for a reasonable approximation -- remember, the whole trick was that the speed of the animation varied according to the trajectory, currently done by script calculations but could be faked by a few dozen (or a few hundred?) distinct animations, and... actually, now that I think about it, the script would be nearly as complicated, but with slightly less runtime arithmetic. But anyway, the win was never in script lag (which just isn't a thing anymore) but in the rate of network updates, which would indeed be drastically reduced by replacing it all with Animesh.

But it concerns me that you say "The scripts to swap out this stuff has to call crap every .1 seconds or so, unlike animesh." That's a very difficult way to animate legacy mesh, which is typically done by cel-cycling texture animation that is set-and-forget as far as the sim is concerned. 

(In its details, the jellyfish example is unrepresentative, complicated by many design constraints, including having each jelly move totally independently while being in the same linkset with the others and the tank -- hence no KFM. Come to think of it, can one link multiple Animeshes together and have them animate independently?)

(EDIT: Or, wait. Re-reading your post, maybe one could rig a bunch of jellies to different parts of the same skeleton, then play multiple animations simultaneously, the way we can layer them on our avatars -- Animesh supports that, right? -- effectively animating the different jellies separately. Uh... within the constraint of the skeleton topology, I guess.)

I also mentioned accessibility to novice content creators, and there Animesh has a huge advantage. Very low barrier to entry, just slap together some animations and an off-the-shelf script and one's mesh is an animated product.

Edited by Qie Niangao
Link to comment
Share on other sites

1 hour ago, Klytyna said:

imagine the lag on a sim set to limit it's self to 50 avatars, if it had 1200 animesh npc bots scampering about...

Other than being comprised of polygons rigged to an animated skeleton, avatars and animesh objects have no similarity whatsoever.   Trying to compare an animesh object to an avatar connected to a client which is constantly sending data to (and receiving data from) the sim is like comparing a car being driven by a human with the automatic barrier at a car park or a railway crossing.

  • Like 1
Link to comment
Share on other sites

13 hours ago, Fluffy Sharkfin said:

Other than being comprised of polygons rigged to an animated skeleton, avatars and animesh objects have no similarity whatsoever.   Trying to compare an animesh object to an avatar connected to a client which is constantly sending data to (and receiving data from) the sim is like comparing a car being driven by a human with the automatic barrier at a car park or a railway crossing.

rez a scripted wandering prim thing, say a fish or a squid or a hopping prim zombie..., then rez an ao hud... link the ao huud to your prim zombie, or just copy the anims and scripts over...

Take the result back to inv, then rez 1200 copies on a sim... Enjoy the lag...

Animesh, to be animated will have a script calling poses, much like an AO, and if it wanders around then it'll have the wanderer script... sure, its NOT an avatar with a client, but trust me on this, 1200 lag tech scripted npcs made with animesh will lag like a b*tch...

That's why the hefty +200 LI overhead, so you WONT see every empty 512 on the Madlands with an animesh sales-greeter-npc...

"Hi Welcome to Lagtech Madlands Slum Rentals! I'm Sales Animesh NPC #1187... How can I help you today..."

Personally, I'd like to see the animesh LI overhead raised to 500...


 


 

  • Haha 1
Link to comment
Share on other sites

1 hour ago, Klytyna said:

Animesh, to be animated will have a script calling poses, much like an AO, and if it wanders around then it'll have the wanderer script... sure, its NOT an avatar with a client, but trust me on this, 1200 lag tech scripted npcs made with animesh will lag like a b*tch...

I am sorry, but I don't follow your reasoning here.    An object moving round by pathfinding or KFM presumably uses the same amount of region resources and makes the same demands of the computers of people who can see it, whether it's an animish object or not.   The simulator has to keep on updating client viewers with the object's new position, and the viewers have to keep on redrawing it.   So the only difference, it seems to me, is that the viewer will also have to draw the object animation, which isn't normally a big deal for most viewers, and doesn't put any significant strain on the simulator (it just has to send the animation to the clients, and that's it).

The reasons avatars put such a strain on the simulator is that the simulator has to send updates to all the avatars' clients, telling them what everyone on the region is doing.  The same applies to bots, since the simulator doesn't distinguish between the clients of bots and those of avatars.   So an animesh greeter should be far easier on the simulator, it seems to me, than a bot greeter, simply because the simulator doesn't have to keep updating the bot's client, needlessly, with information about people's movements.

Furthermore, I'm pretty sure that an object moving from one point to another using KFM or pathfinding involves the simulator in fewer physics calculations than does an avatar (or a bot)  walking the same route.   

I have animated both static and moving objects, so I know how frequently I have to change faces' alpha and also the complexity and frequency of some of the calculations the script has to do when I have it moving component parts of the object round with llSetLinkPrimitiveParamsFast.     A simple animation will do all that far, far more economically than we can do it at the moment.

Finally, while I've not done detailed tests, I did rez a fair number of raptors on one of the test regions and it didn't seem to have any significant impact on either the simulator or my viewer.   I am sure the raptors make much smaller demands on the simulator than they would do if I tried to replicate the movements -- which I could, were the object broken down into component parts, but nowhere near as smoothly as animesh does it.

To my mind, animesh promises to be an efficient replacement for several quite laggy workarounds.   I don't understand basis of your concerns.

 

Edited by Innula Zenovka
  • Like 3
Link to comment
Share on other sites

6 minutes ago, Innula Zenovka said:

To my mind, animesh promises to be an efficient replacement for several quite laggy workarounds.   I don't understand basis of your concerns.

Animesh is a good thing... but... Comments I'm seeing suggest that the thinking of many of the hopeful fans is still stuck in ancient days of ignorance...

Yeah a wandering anumesh npc will still use the same pathfinding scripts as a prim wanderer...

Yeah, a greeter animesh using a laggy llSensor to detect visitors will still use the same scripts...

And yeah, the 'pseudo-ao' that works the animesh shouldn't be any worse than the clunky prim animator scripts.

What concerns me, is the blatant overlooking of such facts as...

A rigged mesh animesh bot will have pretty much the same RCI as an avatar wearing the same rigged mesh, poly count, shaders, etc.

That the sudden surge to rez one of the new 'fashionable' animesh greeters on your parcel will lead to people replacing a simple contact triggered floor mat, with some appaling 'animesh lag bot' with horrific RCI (that they wont even bother to check, and laggy scripts, because "everyone who is anyone has a shiny new animesh greeter npc lag bot in their store..."

Too many people who show concern for RCI on avatars completely ignore the fact that non worn items also have a renderweight. The kind of idiots who'll moan like hell if you wear an avi with an RCI over 80k, while cheerfully rezzing a couple of dozen MILLION in RCI for their build, and then accuse the visitor with the 81k rci of making their place lag.

It will be like Bento...

The day Bento officially went 'live' there were 64 pages of 'bento items' on the MP, 60 pages of those appeared to be unrigged mesh, or prims, whose only noticable 'Bento' feature was that they had been edited to attach to one of the new bento attachment points.

People with no clue running around telling all their friends how 'kewl' bento was and how it allowed [insert non factual tech illiterate gibberish here], unscrupulous merchants rip[ping off gullible people, store telling people they needed to pay 500-1000 ls a pop for a new 'bento shape'.

If there was a practical way to slap a 500 LI 'surcharge on scripted prim npc's, I'd support that too...

Those 'raptors' you rezzed for testing...

Seriously, can you imagine if  there were hundreds of them all with their pathfinding, sensor and AO scripts, chocking a sim up? Choking your client's rendering systems with their RCI, an RCI you CAN'T jellydoll because, they are NOT 'avatars'.I'd want a safe limit on the things wouldn't you?



 

Link to comment
Share on other sites

53 minutes ago, Klytyna said:

Those 'raptors' you rezzed for testing...

Seriously, can you imagine if  there were hundreds of them all with their pathfinding, sensor and AO scripts, chocking a sim up? Choking your client's rendering systems with their RCI, an RCI you CAN'T jellydoll because, they are NOT 'avatars'.I'd want a safe limit on the things wouldn't you?

In fact, they have only one pretty simple pathfinding script, which uses a sensor to trigger  different types of pathfinding behaviour.    The only difference between them and a regular pathfinding script is that they also have simple one line calls to start and stop appropriate animations when they start and stop different pathfinding behaviours.    It's way, way simpler than trying to achieve a similar effect with llSetLinkPrimitiveParamsFast.

Not that I'm suggesting this is a good idea, but I am certain that a club could make itself significantly less laggy if replaced its avatar dancers with animesh ones.   And no one would notice the difference between animesh strippers and avatars who use canned emotes, so that might actually be a good idea, in that it would encourage people to do stuff to prove they're not simply animated mesh objects....

In general (and as someone involved in running clubs and areas that attract a lot of visitors) i think that any sensible landowner is going to check on the sort of effect animesh items have before going nuts and rezzing loads of them.   Anyone who does rez a hoard of them and make the place too laggy will soon learn the error of their ways -- any successful club owner or landlord is constantly checking on how the regions performs and feels, and looking for ways to make it less laggy.   

So while I agree there need to be limits, I start from the basis that an animated mesh object is almost always going to place far fewer demands on the resources of both the simulator and people's viewers than is a regular avatar, whether mesh or system, so there's no need to be particularly concerned, and I'm sure most landowners will -- in their own interests -- try to find solutions that don't lag the place up.   

If they do, that's their problem not mine, since I can always go to a less laggy club or shop or whatever.

Edited by Innula Zenovka
  • Like 3
Link to comment
Share on other sites

16 hours ago, Qie Niangao said:

(EDIT: Or, wait. Re-reading your post, maybe one could rig a bunch of jellies to different parts of the same skeleton, then play multiple animations simultaneously, the way we can layer them on our avatars -- Animesh supports that, right? -- effectively animating the different jellies separately. Uh... within the constraint of the skeleton topology, I guess.)

Yep, totally possible!

Link to comment
Share on other sites

1 hour ago, Klytyna said:

What concerns me, is the blatant overlooking of such facts as...

A rigged mesh animesh bot will have pretty much the same RCI as an avatar wearing the same rigged mesh, poly count, shaders, etc.

That the sudden surge to rez one of the new 'fashionable' animesh greeters on your parcel will lead to people replacing a simple contact triggered floor mat, with some appaling 'animesh lag bot' with horrific RCI (that they wont even bother to check, and laggy scripts, because "everyone who is anyone has a shiny new animesh greeter npc lag bot in their store..."

Too many people who show concern for RCI on avatars completely ignore the fact that non worn items also have a renderweight. The kind of idiots who'll moan like hell if you wear an avi with an RCI over 80k, while cheerfully rezzing a couple of dozen MILLION in RCI for their build, and then accuse the visitor with the 81k rci of making their place lag.

It will be like Bento...

The day Bento officially went 'live' there were 64 pages of 'bento items' on the MP, 60 pages of those appeared to be unrigged mesh, or prims, whose only noticable 'Bento' feature was that they had been edited to attach to one of the new bento attachment points.

People with no clue running around telling all their friends how 'kewl' bento was and how it allowed [insert non factual tech illiterate gibberish here], unscrupulous merchants rip[ping off gullible people, store telling people they needed to pay 500-1000 ls a pop for a new 'bento shape'.

If there was a practical way to slap a 500 LI 'surcharge on scripted prim npc's, I'd support that too...

Those 'raptors' you rezzed for testing...

Seriously, can you imagine if  there were hundreds of them all with their pathfinding, sensor and AO scripts, chocking a sim up? Choking your client's rendering systems with their RCI, an RCI you CAN'T jellydoll because, they are NOT 'avatars'.I'd want a safe limit on the things wouldn't you?

In the spirit of not having my post deleted, or my avatar banned from the forums, I'll just say that I do not agree or can even relate with any of this. 

No, the RCI of an animesh is guaranteed to be considerably lower than any avatar there is. Why, because there are, and will be triangle limits. Avatars also have another RCI costs that the animesh will not.

Seriously, if every merchant in a mall added 1 animesh to greet people, collectively they would have almost no impact on the experience. 1 stores textures in their little shop would be more data than all the animeshes combined.

Rezzed objects have land impact costs which is meant to restrict them. Animesh will also, so I don't get your point. If people want to rez a 1 million polygon building, who cares. Their region doesn't walk around SL with me. Put those million polygons on an avatar tho, and now there will be issues.

Like Bento! I would assume that is a good thing. lol

Did the conversation switch to the Marketplace? I Don't Care! No relevant!

Bento is awesome! Why do you care if people want to buy someone else's shape? Again, NOT relevant!

There is a way to slap a 500LI surcharge on animesh. LL just did it, but 200LI. Again, for testing tho. Good thing you aren't in charge.

You can rez hundreds of Raptors right now, or close to it. Go try it. Why would animesh need Jellydolls? They have LODs, and a triangle limit. Sounds to me like you just want to be negative.

 

Edited by Medhue Simoni
  • Like 4
Link to comment
Share on other sites

35 minutes ago, Medhue Simoni said:

No, the RCI of an animesh is guaranteed to be considerably lower than any avatar there is. Why, because there are, and will be triangle limits. Avatars also have another RCI costs that the animesh will not.

Seriously, if every merchant in a mall added 1 animesh to greet people, collectively they would have almost no impact on the experience. 1 stores textures in their little shop would be more data than all the animeshes combined.

Oooh, you just gave me an idea: Why not allow 1 animesh object per parcel for 0LI!!!  This would allow every resident/seller to have their pet/salesbot with no land impact - as if it was an avatar. <== My real point (like an avatar).  Or, have it count as "1 avatar!"

Link to comment
Share on other sites

40 minutes ago, Love Zhaoying said:

Why not allow 1 animesh object per parcel for 0LI!!!  This would allow every resident/seller to have their pet/salesbot with no land impact - as if it was an avatar. <== My real point (like an avatar).  Or, have it count as "1 avatar!"

I don't suspect that this will be needed. Of course, we do not know what the final restrictions will be, but I'd be willing to bet that the land impact costs will be relatively similar to products already being sold in the pet market. Yes, there will be restrictions but there are many tricks that we as creators can implement to keep things low.

1 point that has not been talked about yet, is that an animesh can be worn/attached to your avatar. Many of us pleaded with LL to allow this. Again tho, there is a limit to this. Currently the limit is 1 animesh can be attached. Soooooo, in theory, if someone wanted to have their cat with them, most of the time, when they did not have rights to rez, they would simply carry the cat. Where they do have rights to rez, the cat could roam freely. I suspect there is more work to be done with this tho. Like, can you teleport wearing an animesh? I'm not sure yet.

  • Like 1
Link to comment
Share on other sites

5 hours ago, Klytyna said:

can you imagine if  there were hundreds of them all with their pathfinding, sensor and AO scripts, chocking a sim up?

67645c7ad28bd0cd3facdbee33c83291.gif

 

Here I have around 30, all in my field of view. My Frame rate is still around 55 fps. I also see no major issues looking at the region stats.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 10/21/2017 at 4:09 AM, BilliJo Aldrin said:

No, i'm just saying the easiest way to improve your performance especially frame rate is to derender all the moving lights, floors, all that annoying club crap. To me this is just more moving crap that's gonna slow me down.

People are gonna use it, and more power to them but i'm not gonna let it affect my experience at any given place or time.

Oh and I always derender moving animals etc too.

Enjoy your animesh, but don't expect me to enjoy it.

This is true. OR, you could turn your settings down.

When I bring my big Dixie Belle Riverboat past Sirens Isle and someone passive-aggressively shouts about it is a lag-causer, my usual reply is the only lag being seen is by people with POS computers with graphics turned all the way up.

I want to be clear here: I am NOT dissing on you, BillJo - I am speaking in general terms. SIM lag, where the sim itself is choking because way too many scripts is genuine lag. Network latency (coming from SL or one of the 50 black boxes on the internet your connection goes through is genuine lag. But framerate issues is on you; all you. Or, more specifically: your computer's ability to draw the picture at the quality you want it to 30 times a second.

Certainly, derendring things are one way to go about it, but it would be a lot less work and frustration if you just turn your graphics settings down. Use the presets.

As for the OP subject: I can see where this is a great addition to the grid, though the examples are all human "avatar" types, I can see it being used in a lot of other things. For example robots, gadgets, vehicles - for example, A jet with folding or retractable wings, etc. This means the creator can use an animation rather than scripts to achieve these functions, and "genuine" lag will be relieved in that respect.

Though, as with all the new tech LL throws into the grid, it will be quite some time before we really start seeing how this can be used. I think it's a great addition to the grid.

Link to comment
Share on other sites

11 hours ago, Klytyna said:

Seriously, can you imagine if  there were hundreds of them all with their pathfinding, sensor and AO scripts, chocking a sim up? Choking your client's rendering systems with their RCI, an RCI you CAN'T jellydoll because, they are NOT 'avatars'.I'd want a safe limit on the things wouldn't you?

Animesh can jellydoll like agents. They just currently don't impostor even though they count towards impostors. Other nearby agents will impostor instead.

Once impostoring is addressed I think dozens of on screen animesh characters won't be as big a problem as some are thinking it is.

I specifically tested jelly dolls with 60 dancing animesh skeletons within 20m of my camera, each wearing rigged mesh that my own avatar has attached.

During that specific test, turning my max avatar complexity setting down to the minimum 20,000 turned them all into jelly dolls and allowed my 25 fps to increase to 35 fps.

Someone with me said that with their hardware they were getting 50 fps. Without any skeletons applied and just the mesh alone my fps was 35 fps.

This is why I say the low tri count caps are not really necessary as far as rezzed content is concerned. Let land impact be influenced by high LOD tri counts instead.

The unknown to me at this time is what an ideal base land impact should be, but tri count caps are only going to favor those on below standard hardware and hinder product and commerce potential. Like any other content, it won't stop griefers from filling sims with as much of it as they can, plus they would have 1000x better results lagging everyone in the sim with a single 200 land impact, region sized sculpt lagger which would take several hundred on screen Animesh to have the same effect nor would there be anything restricting them from wearing dozens of said laggers wherever they go.

In the end, it comes down to your hardware and your settings. As long as we have settings that can effectively reduce lag to a level that still allows us to enjoy SL, I don't see why Animesh is any different that any other new render based feature. Like any new feature, it is just going to take some time for people to get used to how it looks and how it performs.

Animesh is one of many features SL needs to evolve as well as maintain interest in the platform and inspire newcomers and maybe veterans to build experiences for others to witness and do the same. If done right, Animesh will be a decent revenue generator across many use cases and commerce types.

  • Like 3
Link to comment
Share on other sites

19 hours ago, Qa Boa said:

As for the OP subject: I can see where this is a great addition to the grid, though the examples are all human "avatar" types, I can see it being used in a lot of other things. For example robots, gadgets, vehicles - for example, A jet with folding or retractable wings, etc. This means the creator can use an animation rather than scripts to achieve these functions, and "genuine" lag will be relieved in that respect.

I've been trying to wrap my head around what does and doesn't make sense as Animesh applications. I wouldn't have thought it appropriate for the jellyfish example (beaten to death above) but I now think it might be viable, assuming the LI is comparable to normal scripted mesh (so, for that minimal application, no more than 5 or 6 -- certainly nothing as extravagant as the 15 minimum of a Pathfinding character).

Because Animesh seems commonly used with Pathfinding, I assume it works fine with KFM, but about that "jet with folding or retractable wings" -- does Animesh work as a physical object? (Obviously not with Pathfinding at the same time.) If they behave reasonably when physical, can they actually use the special physical vehicle API to Havok?

That assumes one can sit on them, which was something I asked about for the one meeting I could attend, early on, and I think the answer was yes. (And they can be attached, but I assume not sat on when attached -- which would be more valuable than the animated mesh feature itself.)

(I realize this is all easy to test, but my in-world time is pretty drastically over-committed these days.)

Link to comment
Share on other sites

As someone who plays SL on my atari (it had better FPS than my toaster), I too am deeply upset by this. I'll de-render everything I see that isnt a non "mesh" avatar circa 2010. It might not effect my performance, but it's the point of it! Finding enjoyment in things on a video game is not what I log in for.  /s 

In all seriousness, when I got into the early stages of bento, when it was just a handful of people, I'd been invited to make use of it for pets. But quickly, I saw thats not what it was meant for, and while possible, it couldn't be done without a lot of um, adjustments. This is what I'd brought up though, and what I really pushed for, so I am so happy that some lindens were out there thinking the same thing.

I don't love that its using the SL skeleton, thats just more complication than is necessary, but it's a step int he right direction, assuming they fix the mess of LI. As it is, people will stick to the old way or risk sales. This is coming from talking to other top pet creators, while we don't speak for everyone, I do think its good to put opinions out there so its known that established people are thinking this way. 

Link to comment
Share on other sites

On ‎10‎/‎26‎/‎2017 at 3:10 PM, Qie Niangao said:

That assumes one can sit on them, which was something I asked about for the one meeting I could attend, early on, and I think the answer was yes. (And they can be attached, but I assume not sat on when attached -- which would be more valuable than the animated mesh feature itself.)

Yes, you can sit on them, as long as they have a sit target. Technically, yes you can sit on an attachment, as there is the pelvis attachment point, and the rest is easily done with animation and code.

Edited by Medhue Simoni
Link to comment
Share on other sites

6 hours ago, Medhue Simoni said:

Yes, you can sit on them, as long as they have a sit target. Technically, yes you can sit on an attachment, as there is the pelvis attachment point, and the rest is easily done with animation and code.

Wait -- what? Does "technically" here mean that one can make it appear as if one is seated on one's own attached object? That's certainly not what I meant (and would be nothing new) but if there is the capability to actually sit on an attachment (one avatar is the llAvatarOnSitTarget() of an object in another avatar's llGetAttachedList()), that would be way, way bigger impact than Animesh or any other new feature in years. (But realistically I'd expect it to be a much larger development effort, too, and way beyond the ambitions of current resources.)

Edited by Qie Niangao
  • Like 1
Link to comment
Share on other sites

I read through a lot of this and a big thing people seem to think is that this is going to be JUST AS LAGGY as Prim Animation by changing prim positions, ect. It's not at all. When you animate something right now you have two options. you can update each linked prim every frame of the animation which is INCREDIBLY hard on Script Run, or you can do that REALLY REALLY Bad Alpha Looping thing. I have been on The Test Grid the Better part of 2 days now messing with this. I find the additional 200 Land Impact completely unacceptable and you can tell that whatever team is working on it currently has no association with people that play Second Life.

Additionally someone mentioned that using this for NPC's would cause lag because of the number of Sensors. Any decent scripted would never script an NPC or Turret system using a sensor it is laggy, and in every way inferior to using AgentList for that sort of thing. Currently our Zombies have a Land Impact of 18 an active script time of around 0.112 and A LOT of Script Memory because of how we animate them, they look great compared to say other people's zombies and they are comparable in terms of region impact including their script run. We can drastically reduce this script impact and memory by switching to Animesh Zombies, however the trade off is entirely undesirable right now currently I can get 10 zombies on sim at a cost of 180 Land Impact, If these were Animesh Zombies that would cost me 2180 Land.of Impact. In a full Sim oriented towards combat with 15 or so avatars I can run about 50 zombies currently before we start to notice a performance hit on the Simulator, that performance his is not Render Performance, and it's not related to Physics FPS, it's 100% Script performance, and 100% to do with the way we have to animate them now. If i turn the animation scripts off entirely and let the zombie run static i can have HUNDREDS of them before i get the same problem. 

People making game systems SHOULD NOT have to suffer because of inexperienced users. I will be filing a Feature Request or whatever is necessary to bring this to attention. The Land Impact should be directly related to the complexity of the Mesh, nothing more. 

Currently i am working on a Video and a Document detailing everything I've stated. This is very important for some communities in SL and We outright cannot allow this to take the turn that Pathfinding did due to lack of testers. As it stands preparing a sim for Pathfinding isn't worth the trade off of just scripting navigation using llCastRay to detect obstacles. 

It's a little late for Linden Lab to start caring about performance when you see people walking around in Mesh Bodies layered with alpha 1024x1024 alpha blen textures, 2 Million Tri clothing, ect. I've literally come across avatars with GIGABYTES worth of content on them. IF we want to start caring about performance we need to have things like avatar complexity addressed in community meetings. We need more community meetings, and we need to start calling out content creators that are making the content that's making us lag, so that the rest of us don't have to suffer "fail-safes" like an additional 200 land impact for their mistakes.

I apologize for any typos I am legally blind. If anyone would like examples of things I am talking about feel free to contact me inworld, or add me.

 

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2315 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...