Ela Talaj

https://marketplace.secondlife.com/p/Commercial-Vendor-MPV-SR/593120

Calculate new position (vector pos) and before actually attempting to move there call llGetParcelDetails(pos, [PARCEL_DETAILS_ID]) to see if still the same parcel. If it is, you are ok to move. If it is not, call llGetParcelFlags(pos) to see if entry is allowed.

This is not a trivial task. There are however many hand evaluators already written in a real world programming languages. Perhaps you could study one and port to LSL. May start here: http://www.suffecool.net/poker/evaluator.html

Toy, for the hundredth time, my only relation to the LL is exactly the same as yours, that is being their customer. I've no access to their code, never had and have no idea how it works. Yet, I fail to see a relation between such issues as for instance "Order confirmation email failures" and "L$ balance not updating automatically inworld". To my experience, these would be totally different subsystems. Even assuming they get the data from the same generic queue (I sincerely hope it's not the case), the balances update just fine on the dashboards so wouldn't be the queueing problem.

Actually the term "freeze" usually means something totally different. A freeze period is a time period between testing completion and release to customer. During this period the release build is "frozen", that is no more makes are done for this version; developers still can make changes in their source code but it will not be submitted to source control for this version. But this all is a matter of terminology. The matter of substance is that the bugs introduced in the latest marketplace upgrade appear unrelated to the upgrade itself and to each other. This may indicate that the overall design did not properly encapsulate processes, that is they are not kept sufficiently separate from each other but affect each other in somewhat unpredictable manner. Data and methods that should be private are probably public so any developer can access and inadvertedly damage. In other words, basic principles of OOD/OOP may be violated in the design. This considered, the question becomes whether or not the design or at least sufficient portions of it are inherited from the old XSL street. Delivery relying on magic boxes seem to indicate so. If indeed true, we should look forward to the new direct delivery release as it may replace the flawed design elements with correct ones.

While duplicate listings themselves have indeed disappeared, the total items still shows the previous large number that included duplicate listings. Resyncing with the box does not restore the correct number of items.

You have state online and list online. You cannot have both.That's the reason for your double declaration error. list online you don't even need, but if cannot live without it rename the state from online to Online. This will correct your compile error. Why make a one-product vendor when you can get a full features vendor here https://marketplace.secondlife.com/p/Commercial-Vendor-MPV-SR/593120

That could be for 2 reasons No one else has this problem or no one sells anything

however the SL dashboard account balance updates just fine. This problem was not observed prior to today. If the problem is not localized for some reason to just myself but is widespread, this should be a showstopper. However I found no JIRA on it.

however the SL dashboard account balance updates just fine. This problem was not observed prior to today. If the problem is not localized for some reason to just myself but is widespread, this should be a showstopper. However I found no JIRA on it.

The Texture Color Changer (TCC) would prolly do better than anything else for textures and colors. It does not however supports resizing. https://marketplace.secondlife.com/p/TextureColor-Control-API-Professional-Edition/2065789

If you detail what "magic HUD" is and what it does, I'm sure I'd be able to make it

Entirely possible but you'll have to put a rezzing code in your main prim because the temp prim must be re-rezzed about every min. This is all easy but you must remember that the temp prims lifespan is not fixed... it depends on lag and other factors. On the other hand, your re-rez rate is fixed, so at time you'll end up with 2 temps existing together (and therefore 2 floating texts) and sometimes with none at all for a few sec). Why not put the text in your main prim? Or get MPV-SR one prim vendor which will do floating text for you and many other things.

You might be able to turn your no- modify script on and off from another script, via llSetScriptState() method. Look it up in the Wiki.

Sorry, I've no idea what you're trying to say. A conditional statement (comparison) evaluates to a boolean variable in any language; there is nothing else for it to evaluate to. The operators precedence in LSL is exactly the same as in ANSI C.

Basically what you wrote is a total nonsense Assuming it compiles (a big question) llGetOwner() && llGetObjectDesc() always evaluates to TRUE so your condition becomes: if(llDetectedKey(0) != TRUE) which in turn always evaluates to FALSE and whatever is in the brackets underneath it will never execute. (We must remember that TRUE is anything that is not 0, not necessarily 1) What you probably wanted to write would look like this: if(llDetectedKey(0) != llGetOwner() && llDetectedKey(0) != (key)llGetObjectDesc())

I would support my products regardless if a user bought it from me or got it as a gift or obtained elsewhere. I don't need a transaction record to recognize what I've made so rezzing would be quite sufficient. I hope this would apply to most makers. As for resellers... all bets are off.