How to help newbies financially?

It could do that.
It does imply that the LMs have to be fed to it by a remote server.

That process could include a consideration of the (recent?) history of LMs given to a particular avatar. It would be good to try to always send them to new places. If they found themselves at particular places regularly, that could be a killer - unless they were solely interested in the L$.

A lot of people seem to want that.
We seem to be stuck with it though.

I don't know if LL analyse the IPs v. the payment status of avatars.
They might be seeing big chunks of the globe in which the vast majority of users are NPIOF and wondered why.

That can't be done, unless you mean SLURLs that appear in chat. The board idea is pretty much the cones idea with a choice of categories added. Just the shape, the texture, and the way of moving on (click a board vs click a menu button), are different. You can't have stand-alone boards unless they are all fixed at the start, and nothing changes - i.e. new boards and new places can't be added.

It could be done if the LMs were delivered remotely on being triggerd by the cone/board.

I'm not able to grasp most of the techno-lingo about servers. But you're saying that a server will not be able to handle a large load on the system.

What if there were separate loads. Several systems operating....say each system has a maximum of 35 Landmarks. Those are distributed throughout one system. Then another system with another 35. Would that lighten the load?

The store owner could view a list of each system...each 35 LM's, and decide which system you want to enter into. If you get bored with it....simply drop out of it....then choose another group of 35.

Does that make sense? Technologically?

Last night, my alt got a message from one of the cone holders....he was very rude. She had been dropped off to his place 3 different times, and could never find the cone....all she did was ask where the cone was, in case she was dropped off there again....he was a complete jerk. I'm not real thrilled to know that I might be sending him traffic from my store...not real thrilled to be part of a network that includes him....which was an issue I mentioned earlier.

Then it becomes very messy. But we've been through exactly this before and there's no need to go over old ground.

What if each device held 35 LM's. The device owner pops in the LM's they choose. It mixes them up to toss in a random fashion. The device owner would have to network with some other business owners to assure that their LM was getting dropped in....in other words they would have to stay on their toes to offer something attractive.

You could probably cover this angle, just by networking with your business friends. No guarantee that your LM is getting dropped in enough times...you would just have to work at it....with a "you scratch my back, I'll scratch yours" type angle.

My maximum attention span with huge effort was about 10 stops. So you're getting a regular visitor 3 to 4 times from your one network, before they get a repeat. If they start getting repeats...they will probably switch to another network....but that's fine....you had them 3 to 4 times.

It must be somewhere because it's the thing that sends the SLURL to your alt. Some of them were mod so that an LM could be put into them. Did you check for transparent objects?

Or maybe the system was written poorly so that a cone gets its location when it's rezzed but not when it changes position. So an unscrupulous cone owner could rez it and then move a long way away (1000m up, for instance) where nobody can find it. I don't have a cone, so I don't know how the SLURL is generated.

I'm curious though. Can you let me have an LM for the landing spot?

I'll send it to you.

You may not be familiar with the delivery method used by XLStreet - for one.
Strangely enough ....... the 'messy' does not appear to cause problems.
A cone type system is perfectly capable of triggering inventory delivery.


If you genuinely want a discussion rather than provoking a ding-ding, I suggest that you try and refrain for attempting to slap me down as if you were some testy schoolteacher - particularly when your assertion is not well thought out.

Nobody is trying to slap you down. Don't be so sensitive. Requiring all the LMs to be in one place would be too messy and we *have* been through it before in this thread. It's much simpler all round to have the receiving object send an SLURL to the person. I don't know if it could send an LM, but centralising LMs would be too messy.

No.
*You* say something is "too messy".
You appear to be under the entirely mistaken belief that your say so is final.
Something that appears "too messy" to you might not appear so to someone else. It's just technology. All of the components required are available both inworld and hybrid.


If you have a very particular design that you wish to progress to the exclusion of all other ideas, then I suggest you get on with it somewhere. Just stop trying to suppress alternative ideas in a more general thread.

Many ideas discussed here are equally applicable to a fixed or a variable stay. I'm quite happy to suggest ways that might enable a fixed stay system, including some sort of back end. Many of those are also applicable to a variable stay system.

For example, all of the comments regarding the location and accessibility of cones are common.

It's nothing to do with technology. If the LMs are held centrally, they have to be put there, and they can only be put there by the object (cone/board) owners. First they have to rez it, then they have to take an LM, and then they have to go and put it in the central system. That's the first messy bit when compared to just rezzing the obect and leaving the system to do its work.

Then, when an owner decides that the object would be better in a different place, s/he has to remove the current LM from the central system and replace it with another. That's after having made another. That's another messy bit when compared to just relocating the object.

And there's the question of how the system knows which LM to send when it wants to send a person to a specific object. Perhaps a naming convention will work, but that would rely on the object owners getting it right.

The whole thing is just too messy when compared with the practical simplicity of the cone system. It's much better to have the receiving object send the LM but even that needs the owner of it to remember to change the LM after relocating the object. The fewer necessary actions there are, the better it is.

As Einstein said, "Make everything as simple as possible, but not simpler." And as everyone else says, "KISS".

Landowner has a device rezzed.
They can drop a LM into it.
The device gives inventory to a bot.
The bot drops it into a server device.
The server device can be trigged to deliver inventory to a named avatar on demand.

If something take a bit more tech than something else, it doesn't meant that it's "too messy".
"To messy" is just your perception of it. "Too messy" is not a level of technology.



There is no absolute need for the LM to be a LM for the precise location of the device.
What matters is that the device be easily locatable. That's a matter of signage and/or local teleports in a large or multi-level parcel- all very run-of-the-mill stuff.
There is actually an advantage in separating the two in that even in a variable stay system, the visitor would have to move through content to get to the cone.
One would hope that a landowner would not sek to make the location of the cone ultra difficult. In that case, complaints should result in them being removed from the network.



The practical simplicity of a cone system in which landowners drop in LMs for local delivery only may be all very well for a small circle of parcels, but it doesn't scale up.

If we are looking something with extensive reach, it might be done simply via the existence of a large number of independent small simple systems.
However issues arise in getting people to move from system to system when they have exhausted the possibilities of one system.
Issues arise for landowners in that they can only get the benefit of visitors from one or a small number of systems with separate cones.


The premise for this thread is that we face a situation in which a large reach is required.
That does not exclude the possibility of a large number of independent systems. However, your preference for a small simple system should not be allowed to exclude the discussion of a more complex system.

So now a 24/7 bot is needed. Sorry, but it's just too messy for my liking. I don't see anything wrong with the simple method. If an object can give an LM to an avatar on the grid, then the cone/board can do it just fine. I don't see any reason to make it any more complicated than that.

I don't have a preference for a small system - exactly the opposite. But I do have a preference for keeping it as simple as possible, and a definite aversion for unnecessary complications - especially when they gain nothing over the simple method.

You have posted that you disliked running your traffic-bots 24/7 because of concerns about leaving PCs plugged in while you slept.

Others do not suffer from the same concerns.
Others get on with it and/or use data centres.
Others are not as intimidated by complexity as you appear to be.

Your preference for a simple system is not a valid reason to attempt to suppress discussion of more complex systems.


Quite apart from large scale considerations,we are facing in an SL in which script memory is going to be limited. That may effect even relatively small-scale systems.
That will tend to make the complexity of moving logic off-world a more common situation.

I don't think you are understanding it, Sling. We are talking about which object sends the LM. If you can provide any reason why an LM is better to be sent from a center than from the receiving cone/board, let's hear it. As far as I can see, the only difference is that a central system for doing it is necessarily more complex.

It has nothing whatsoever to do with scalability. If you think it has, let's hear your reasoning.

The difference is in the scale of the system.
If the device is to hand out LMs from a pool of possible LMs in its own inventory, then there is a management and coordination issue in having each individual landowner in the system drop LM's into their devices.
The more people involved in the system, the more prone to problems it becomes.

We are not limiting ourselves to small-scale systems.

That's one the things that I said a couple of posts back - the fewer the actions, the better. It's for that very reason why it's better that the object sends the LM (or SLURL, which needs even fewer actions) than a central system that needs to be supplied with the LMs. Either way, the owner has to drop the LM somewhere, so nothing is saved by taking it to a central store, and it's easier to just drop it into the object. It's easier still if an SLURL is used instead, because the owner doesn't have to do anything.

As far as scalability is concerned, it's much easier to scale a system where each object deals with its own LM itself, than to have all the LMs contained in a central system. Scalability isn't an issue here - not in the handing out of LMs, anyway.

I can see where sending a LM to a central location, or plugging LMs into a device won't work....as I've moved the cone around over and over again. You would be stuck with keeping it in one location.

Exactly. I made that point a few posts back. It's so much easier that way than requiring the owner to redo LMs and either drop it in the object and remove the old LM, or go to a central store object and do the same there (I think a 24/7 bot was a bit far fetched).

I'm curious though. When you moved a cone, did you take it into your inv and rez it again in another spot, or did you move it by editing it?

If you moved it by editing, do people arrive next to it, or do they still land at the old spot?

I moved it on the floor, without taking it back into inventory - I need to test that.

And what happened? Do people arrive where it is now, or at the old spot?

Hey Phil - have you received your paycheck yet, for all this market research and advertising.....mine seems to be lost in the mail.