.jpg.65ce3f4cab9e96a6a6e9f67463b84b13.jpg)
Ela Talaj
-
Posts
874 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Ela Talaj
-
-
"Has anyone, in fact, sought profession advice from a competent attorney about the likelihood of a court being persuaded to set aside the ToS in this respect? It seems to me rather a specialist area of the law, I have to say."
That is the last thing we need, Innula, and exactly the direction I warned against in my post in this thread. The advice you wish for would costs anywhere from $800 to $1500 per hour and before we know it there would be no Lab and no SL just heaps of legal bills, which their dilapidated red brick building would be hardly able to hold.
As for unprofessional advice I fail to see a substantial difference between L$ and casino tokens (aka chips) issued by a specific establishment for a specific purpose yet convertable on demand to real dollars. To my knowledge there is no precedent declaring them "currency".
-
Darrius, with all due respect, I don't think you understood my post.
-
Ahh... so you are just holding the key. Then I guess I was wrong about the kbrd 100 msec timer and it is much faster. Apparently you are holding an arrow key for the agent keep moving. From a purely prctical point of view I wouldn't worry about the interrupts rate and such.
I've written several scripts which include taking control for a purpose of moving the agent. For as long as I keep the key pressed the agent is walking when I release the key it stops. I'm yet to notice it quits walking while the key is pressed and no customer reported such occurance either. In a very busy sim with many agents present the walk would be lagging of course but no more than when I just move the agent via arrow keys manually. The lag has more to do with the sim rendering avatars (it is a very complex process) than with dropping keystrokes in a script.
-
Please see my reply to Toy. It is also a reply to you, but he's an original poster after all
-
In your original post's statement that "many of the Merchant of SecondLife use their sales of content into SL as a primary source of REAL LIFE INCOME for them and their families". I would've changed the word "many" for the word "some" and the word "primary" for the word "supplemental" to cover more bases but even your wording is essentially correct. It is also true that the Lab derives a part of its income from merchants activities: via the Marketplace commission, via merchants subscriber fees and probably most via exchanging real currencies for L$ which regular users must do to be able to buy merchants' wares.
Premises considered, some kind of a de facto association between the merchants and the Lab is hard to dispute. Perhaps sooner or later someone would come up with a precise term for this kind of association but it is not relevant for us in here. What is relevant is to state with specific particularity that no matter how real and how mutually beneficial this de facto association may be it cannot and must not become de jure.
The reason is obvious: our litigation society. While having superficial control over merchants' wares and business conduct the Lab has much deeper pockets than the merchants have and the cost of defending whatever frivolous lawsuits would be impossible to bear regardless of their outcome. Should the Lab devise a whatever scheme of executing strict control over merchants, most of them would not be able to comply with the terms.
Therefore the current business model of treating the merchants exactly the same as other paying and non-paying customers is the only one reasonable and moreover imperative for continuation of business. Those merchants who wish otherwise are pushing themselves on a very slippery slope.
Having said that, we must also acknowledge that the health of the Marketplace is a matter of concern not only for merchants but also for their customers and therefore for all SL users so merchants being the loudest in expressing this concern is not at all contrary to the above. There is nothing wrong with meeting with Mr. Humble but what a purpose would be? A mea culpa? I have neither desire nor time to listen to such and would not attend. I'm sure there are others feeling the same way and that is why I posited that the meeting request does not represent wishes of all merchants.
I have no inside information of the Lab operations and can only offer a speculation. In fact I have done it before several times in here as well as in the in-world merchants group. The Commerce Team is incompetent. There is nothing derogatory in this word's usage in my content. It simply means that they do not have the expertise. It would appear that at the conception of the Marketplace project its complexity was grossly underestimated. Engineers assigned to the project had no e-commerce experience because there was no one around with such experience. No management whatever brilliant can compensate for people lacking knowledge in what they do.
There are 2 ways to resolve such situation. Hire competent people is the fast one but the cost, considering contract wages of no less than $100 per hour (contractors are hired indirectly via agencies which have a significant markup), would run into hundreds thousands if not millions. I'm not sure the Lab, which only a couple years ago had to lay off 30% of its staff, has sufficient money.
The second way is slow and tedious: let people learn on the job. I believe that this is what is taking place. We cannot speed up this process by emotional complaining. We can speed it up by timely and calmly reporting bugs. Neither can Mr. Humble speed up this process. So once again, what is the purpose to meet?
As for me "not liking you", this is simply preposterous. I have no idea who you are; as far as I'm concerned you are just your posts byline as well as I am from your end. Why would I dislike you? I read you
-
"Item Delivered & No Payment", I had one such occurance on October 6. A customer was charged full price for a quite expensive item, which he received but my account was not credited and the order status stayed "Being Delivered". I use Magic Boxes.
I figured I'd wait a cpl days before filing a ticket and sure enough today (so within 48 hours) my account was credited and the status changed to "Delivered".
I'm writing this info-post to just suggest that maybe in such cases it is worthwhile to wait a day or two before filing a ticket so to not clog the tickets system any more than it is already clogged :)
-
There is no way on earth your fingers no matter how fast can press a key with 40 Hz frequency. So how do you simulate one in 25 msec key press to deliver from your PC to the server? From what I remember your kbrd driver works on a 100 msec timer though I might be wrong...don't recall for sure from the top of my head.
-
If you set your listening filter like this:
llListen(CHANNEL, "", llGetOwner(), "");
why do you need this check:
listen(integer channel, string name, key id, string message) { if( message=="Yes" && id==llGetOwner() ) { . . . } }Who else is it going to listen to except for the owner?
-
Some concerns listed are certainly valid though I could've argued about others but I don't remember voting for you as Merchants representative to issue demands in anyone's name except for in your own. Did I miss the election day?
-
I send to my customers mailing list once a month and sometimes none in two months... lol... cuz I forget about it or too busy to write a newsletter and still some (small percentage though) complain of "spam".
-
Have you ever noticed that in some LSL documentation scripts are called "tasks". That is actually a correct programming term for it. Indeed each one is a little task telling the server how to change the rendering of an object; it has its start, its end, its rest periods when it waits for something to happen, etc. So what starts the start? What happens when it ends? what tells it that what it was waiting for did happen? All that of course comes from the operating system, so each script-task uses some OS resources. The more scripts the more resources used.So generally less scripts is better.
However there are no rules without exceptions. If you are able to write a script performing a certain generic function which can be used in many applications then you are much better off making a specific module and doing application-specific stuff in another module. Would save you a lot of time reusing instead of rewriting even if you lose a few hundred milliseconds of CPU time. This is called "encapsulation" and in the real world where the hardware is cheap but software costs a lot of money it is the king.
-
This line works but it's bad style:
on = (!on); // Flip the boolean value of the integer 'on'.
Don't need any brackets there, they don't do anything. The customary style is
on = !on; // Flip the boolean value of the integer 'on'.
-
An "event" is a system function which differs from a user function only in that that instead of being passed arguments it waits to receive same from the operating system which in turn receives them from the outside world. In stand-alone applications such arguments are called signals while in embedded environment they are called interrupts. How the interrupts ("events" in our terms) are processed depends on a specific system.
Some systems allow what is called "nested interrupts" that is interrupts of different priorities. When an interrupt of a higher priority is received while the previous one of a lower priority i still being processed the OS stops processing a lower priority interrupt and switches to the processing a new higher priority interrupt. The old processing resumes when the new one is complete.
In other systems all interrupts have the same priority and the LSL state machine resides in this group. An event (interrupt) is processed by its event code until completed. If a new event comes during processing the previous one it is queued in FIFO order. On information and believe the LSL queue is limited to 64 events.
-
It is not yet complete. What is going to happen when a second agent collides while the timer is ticking? Let's say it ticked 29 sec. The collision code is going to reset the timer to 30 sec again...so the door traps now after 59 sec... and so on. I believe you would know how to resolve this issue so not going to write code for you
-
Actually switching states when a simple binary flag (TRUE/FALSE) would do is a bad way. From an applications programmer point of view there is not much difference between a state and a user function. User functions add significant overhead in both memory terms and efficiency terms and so do states. In many cases a state machine is of course unavoidable but not in this case.
-
Wow! Good ole Tom Malthus lives... and seems to be carrying on...
-
It appears every time there is Marketplace maintenance, whether scheduled or unscheduled, my MP sales go down very significantly for the next cpl days and then by the 3rd day recover to their regular level. Works like a charm every time.
I don't know what to attrubute it to except perhaps to some temporary shifts in search relevance. But if indeed such shifts occur and my items move back in relevance, someone's items must move forward, so someone ought to notice a temporary sales increase. Anyone noticed such?
-
I made my demo script long before llAttachToAvatarTemp was implemented and I'm too lazy to redo it now
Doesn't matter anyways cuz attachments to demonstrate are scripted and would do nothing on no-scripts parcel. You are right of course that they must be no mod/no copy. -
Most prolly your script calls llListenRemove() after receiving the 1st message.
-
Here's your problem:
startup() //called as necessary from events such as script reset or rezzing{ llCreateCharacter([CHARACTER_MAX_SPEED, 2, CHARACTER_DESIRED_SPEED, 1.0]); //create the character state wander;}A state can be switched only directly from inside an event code not from inside a user function code. The startup() is a user function.
Strangely enough from time to time the compiler lets it thru and a script works as expected but most of the times it returns the compile error you noted.
-
I sent you an IM in-world. By itself, Centova API does not require back-end php/mysql.
-
Yes it can. I wrote it long time ago for wearable attachments demo. Can be worn only once, after it would not reattach.
-
Perhaps an avi could wear something which would start a slow walk animation upon getting into the mud. Then in control event could react only on each second or each third arrow keystroke, which would slow down the actual movement.
-
A constructive suggestion would be stop blaming the Lab for your own screwups.
Facebook
Instagram
Twitter
YouTube
Flickr
Help creating a shopping center
in Merchants
Posted
This low lag multi-feature vendor would enable you to rent shops on commission basis, for a percentage of sales, instead of for a fixed amount. This way of leasing would be beneficial for a new place, which doesn't have high traffic yet.
You would need a special version of the vendor called MPV-SD with hard-coded commission percentage which would work only on your parcel, nowhere else. Then you simply give full perms copy to each renter. they own it, they load their products in it and when they sell you collect percentage. I do not sell MPV-SD version in the Marketplace as it must be customized as to the percentage and the parcel name, so contact me in world.