virtual linking for linkmessaging rather than physics

So, the reason why we can't link objects further than 30m apart is because of the physics engine.
Well, I don't care about the physics engine, but I would like to have speedy comms between any part of the world, or at least between any part of a simulator.
Can't we have "virtual linking" to enable link messages to propagate between physically distant objects? Or between more than 250 objects?
I don't care if the prims have to remain phantom, I think this would be very handy.

Hehe.

That damn physics engine is giving rise to too many excuses and restrictions.

Maybe they should just chuck it out, and use void phys(){} instead.

I was thinking about this same issue. It would be great to be able to open a data link between two objects at great distance. And it would at least need to work into the next sim.

There are some things that need to be worked out though. For one, what happens when you bring out a second instance of the thing? Does the data link work like a normal link in the respect that taking a copy one object in the link set picks up the rest too? If so, what happens if they're really far away from each other? If there's a distance limit, what happens if they get too far apart?

It's something that could really make the game a lot better, for me especially. It's just that it's a little difficult for me to figure out how exactly the thing would work.

I think they should simply provide arbitrary-distance messaging based on UUID and be done with, as many people have requested. It's a much cleaner and more generic approach to communications, and we can easily implement our own inner-object comms based on it, with or without the help of link messages.

And I bet that most people wouldn't mind at all if cross-sim messaging were significantly slower than within a sim. Like everything else, it's a tradeoff, and I'd certainly be happy with the extra functionality regardless of speed.

For once Morgaine is coherent enough that I can agree with her. Special non-link links is just a wonky way of doing what we've been asking for for ages. Get UUID messaging, or inter-XML support between objects, and have done with it.

For me, speed is a major concern. Until we have a UI toolkit I will be developing the 2D games I want to do with screens made of primitives. In order for me to do the kinds of things I've dreamed about, it would sometimes be necessary to link more than 255 prims together, or be able to communicate through linkmessages over a distance larger than 30 meters, etc...

BTW the reason why i suggested this hack is because unlike some people I am aware of the technical and entrepreneurial constraints on what we can expect to see done to SL, and I try to make evolutionary suggestions that I think will be easy to implement with the current system

You confuse "coherent" with "matching my worldview".

Amen!

If a system were extremely fast, one could put up with all manner of ridiculous and restrictive features just by virtue of applying sledghammers to work around them. But restrictive AND slow becomes effectively unusable for games. I agree.

No, coherent. Often times you obfuscate enough to where you seem like you're doing it on purpose, just to sound smart. (And sometimes you end up screwing yourself over, like saying "Caching isn't working right, because while caching IS working right, I'm still sending data" or other such contradictions.)

You could achieve the faster, llListen-less comms between objects if LSL added support for object-to-object llInstantMessage(). This feature has been requested many times.

All it really requires (at least as far as the language semantics are concerned) is the addition of a new 'instant_message( key id, string msg)' event.

- Ace

If that could be made as fast as regular link messages, I would settle for that. I don't care if it has to be kept in the same sim or something. I don't even need to communicate over a very large distance at all. I'm more concerned with the prim limit per linked set, actually.
Not even XyText can give you a standard 80x25 resolution.
The distance thing would be handy for multiplayer versions of my games, i.e., linking two screens together, on opposite corners of the sim, so that people could not peek at each other's screen.
Fast worldwide object to object comms would be ideal of course. I dont know why they can't simply add a raw socket wrapper hardcoded to 127.0.0.1, or restricted to local network adress ranges or something.

I never said those words, so you'd better quote something that I did say before trying to find a flaw in it. Setting up what was never said only to knock it down is commonly known as a straw man. Don't do it.

What you see as obfuscation is merely length I'm afraid.

My sentences are often long because it takes more than a few words to state an argument with precision. If you don't like that, I can't help it. If there is ever a specific line where you think that either the premise, the logic or the conclusion isn't working then I'll be more than happy to reconsider it. In many cases I am certain that your observation will be correct and that I will have to ammend it. That's what logical discussion is all about.

As long as you are open to discussion in the first place though, and contradict the arguments instead of attacking the person who is giving them, then the discussion should end up being very constructive instead of nasty and personal as other people have often complained that you make them.

I wrote this post, then thought better about posting it.

I should PM it instead, right?

Oh. Wait. Turns out Morgaine has her PMs off.

So rather than stand by and get called a liar by someone, I'll just post this anyway. After all, it would look bad to let someone call me a liar and get away with it without standing up for myself, right?

Too bad this is going to get the thread locked. Hell, maybe posting this insane drama over here will get them to actually IMPLIMENT the bloody llObjectMessage thing.



No, not the exact words, but your post was so INCREDIBLY long I couldn't quote you from memory if my life depended on it. So I paraphrased. The meaning was the same though.



FINE! I'll quote your goddamn post, and even link to it. Eat your own words, Morgaine!



As you can see, you make the entirely erroneous conclusion that because you're downloading information (of what, you have no clue, but you know you're downloading SOMETHING), your cache isn't working. You even ADMIT that things DO load faster due to caching, but insist that caching is not working anyway, because your bandwidth meter is twitching.



Funny, that's precisely what I did in that thread I just quoted from, and you ignored it completely there. So are you lying here? Or are you deciding that NOW would be a good time to address the issue?



No, your posts are nothing but half-formed arguments attempting to nag LL into making changes it CAN'T make or simply doesn't have the time to at the moment. Your posts are also long winded, either in an attempt to camouflage the fact that you have no clue what you're talking about, or you have a serious communications problem involving the complete LACK of ability of knowing when to shut the hell up!

Lets take your arbitrary mesh "idea" for a second. The average 1000 polygon model these days apparently takes approximately 150KB to store the information regarding it.

I dunno 'bout you, but I can't have SIX user created models of that size being streamed to me, much LESS have a thousand. But you completely ignored this FUNDAMENTAL FACT and kept arguing and arguing, burying your arguments in massive posts, that few people actually care to read.

===========

To be perfectly honest, I'm sick of hearing you ramble incoherently, long-windedly, and complain that LL is being lazy. And as I KNOW you've read on here, I'm not the only one who's sick of it.

Learn to shorten your posts so that your point comes across CLEARLY. If you have to sacrifice a smidgen of accuracy, so be it. At least your posts will be short enough to where we can actually see the important parts then.

===========

Damn, I am SO hearing from LL about this. *sigh*

You should hear from LL...

This thread was interesting and informative before you chose to preface your first post with "For once Morgaine is coherent enough that I can agree with her".

It's just ugly.

Instant Message to objects would be great. I personally would prefer it was global and not just in a single sim.

Also the ability for a script to respond to an IM from player or script.

if you two are going to do this get your own thread to do it in.

(while some folks have qualms about telling other people what to do, i have none)

now back to the topic:

Eggy i understand why you would want to patch this into the linked message system but i think the solution would be better object-object communications not based on something so simple as linked messages.

First lets examin obect email:
LL probably is running something like a pop3 server and when your object calls llGetNextEmail it's just poping the accont on the server. And when a script has an email event and llGetNextEmail somewhere in it; it then calls for the creation of the mailbox on the server.

object sends email
   |
  sim
   |
email server

object requests next email
   |
  sim
   |
email server _______
      \     /       \
       \   /      message forwarding
        sim       (not sure if this
       /   \      is currently done)
    object  \_______/

the way it's setup the email server doesn't need to know where the object is.

what we want is a system like this

object sends message
    \
    sim
   /   \
object  \
         \
   message server _______
           \     /       \
            \   /      message
             sim     forwarding
            /   \         |
         object  \_______/

multiple scripts should be able to recieve the same message. scripts should be able to filter the messages, by source and subject. local is an integer the user can pass local>=0 (if the negative bit is set it will be ignored). If the message came from another sim then the negative bit will be set.

message format
key source
integer local
string subject
list message

if (local < 0)
{
    llSay("message from other sim");
    local = local & 2147483647;
}
else
{
    llSay("message is local");
}

this would require a server that would keep a list of object locations.

once a min a sim would send a list of objects that had a message-recieving-script to the central server. An object with a message-recieving-script would have to exist for 90 seconds before it can be added to the central server. If an object moved out of the sim the sim would then be responcible for forwarding any requests to that object. When an object enters a new sim it's 90 second timer isn't reset. The 90 second wait period is to eliminate load from temp_on_rez objects flooding the central message server. The 90 second timer would not restrict an object from receiving messages, just keep it from being registered. when an ojbect is deleted it is added to a list that is sent to the central server of deleted objects.

OR

every time an object enters a sim or is rezzed with a message-recieving-script a message is sent to the central server initializing the location for the object. message forwarding between sims would allow from an object to cross a sim boundry and not have any messages be lost.

That's insightful, and I've never heard it mentioned here before. Not needing to know the location of a communicating party is one important part of decoupliing, which provides numerous benefits. So, very good observation.

I need to understand this a bit better. The change from email server to message server is clear, and represents the proxy for the object-to-object communication system that has been requested so often. It's the other change that I'm uncertain about.

On the face of it, your two diagrams are topologically identical except for the fact that both reading and writing objects appear on the second diagram together and linked to the same sim, whereas on the first diagram they might be connected to two different sims. Is your second diagram then meant to imply that the sim is required to recognize that the reader and writer object are somehow related, beyond the fact that they may be currently on the same sim?

The reason I ask that is because you mention that "multiple scripts should be able to recieve the same message" which makes me think that you want the sim to somehow recognize that both objects are part of a multicast group or something similar, although that doesn't appear in the description. (Or am I simply reading too much into the change of connections in the top left corner of the diagram?)

I get the feeling that you've analysed this extensively, but only presented some of the details. More would be appreciated!

Ah, now I know why we can IM agents but not objects. It's because we are all hooked up to the user server, whereas objects are tracked by each individual simulator, and do not have a client running on them with a uniquely assigned IP address.

... and, continuing your train of thought Eggy, the user server doesn't have any means of querying anybody for a UUID->sim mapping to tell it where to forward the IM even if it could?

I dont think that kind of global UUID->region mapping exists anywhere.
Think of the asset server as one big download site... and the simulators as people's computers. You can make your simulator download something from the asset server, and cache it, by rezzing it. But no one else is aware of what you downloaded.
You would probably need to send a broadcast to the whole network, asking if a given sim had already downloaded that UUID.
*shrugs*

your comments paraphrazed: (no insult intended by my phrazing)
1. The diagram is confusing, the objects appear on the same sim.
2. How would multiple scripts get the event?

1) i'll explain the route.

sorry for the updated chart i realized is was a tiny bit inacurate. here is a simpler version.

object sends message - (a)
 |    ________________________
 |   /  _______               \
 |  /  /       \               \
 | /  /      message         message
sim (b)    forwarding         server 
|\  \  \        (d)            (e)
| \  \  \_______/             /  /
|  \  \______________________/  /
|   \__________                /
|              \              /
|               bit bucket (f)
|
object destination (c)

Method 1:

(a)
the message is passed from the object to the sim (b)
(b)
if the object has been deleted then the message is sent to the bit bucket (f)if the object is in the same sim it is sent onto the destination object (c)
if the sim has a forwarding address for the object the message is forwarded (d)
if the message hasn't already passed through the message server and no data is known about where to send it then it is sent to the message server
(d) a message is forwarded to the sim in question. It is sent to another sim (b).

if the object is not in the database then the message is sent to the bit bucket (f)
if the object is in the database it is forwarded to the sim it is in. (b)

(c) the object recieves the message. All scripts in the object that have the message reciever event are added to the script stack and are given pointers to the associated data of the message.
(f)if message is sent here then an error message is sent back to the source? (not sure)

(a) is the object that sent the message.
(b) is any and all sims but one at a time.
(c) is the target object
(d) is the message forwarding, an inter sim comunication.
is the message server finds the sim for which the target key is registered to and sends the message to that sim.
(f) the mythical place where all deleted data goes.

the message transport format should use an 8 bit bit field. the first bit should denote that it has been through the message server. 2 or 3 bits should be used to count how many sims the message has been through, the originating sim counts as zero; on rollover the message is sent to the bit bucket (f). No idea as to what the other bits should be used for.

the reason for using a list instead of a string for the message is because most times we want to move lists of data and not strings. Will make all our lives easier.

Method 2:

Another way to do this protocal would be to have the sim instead of sending the message blindly to the next sim or to message server, have it request where to send the message. Which is a better idea. (I don't always have the best idea right away ~_~)

So...

(a) sends message to sim
(b)
checks if the object is in sim if so sends to (c)
checks if it knows where to forward it (d) if it does it asks that sim if it has the object or if it knows where to forward it. track down the forwards till it finds the sim it is in, send to sim (b)
check message server if it knows where the object is, treats this as a forward (d) and repeats the forwarding checking.
if forward checks fail then it is sent to the bit bucket (f)
if a sim receives a message for an object it just moved to another sim the message is sent to that sim.
(f)if message is sent here then an error message is sent back to the source? (not sure)


----------

For both methods sims would need to keep forward info along with a list of objects that were deleted (that includes: taken, returned, offworld, and deleted) for no less then 3 min and on average about 5 min after an object was deleted. This could be simplfied with the removal of message forwarding (but would result in rare? data loss).

A simplified system would need not keep a list of deleted objects or of objects that have moved to another sim the table would look like... with all forwarding code being ignored.

object sends message - (a)
 |
 |     _____
 |    /     \
 |   /      message
sim (b)     server 
| \  \       (e)
|  \  \_____/ /
|   \        /
|  bit bucket (f)
|
object destination (c)

Method 3:

(a) sends message to sim
(b)
checks if the object is in sim if so sends to (c)
check message server if it knows where the object is, asks the if the object is there, if not then it sends it is sent to the bit bucket (f)
if a sim receives a message (not a request for if the object is there) for an object that doesn't exist in it then it sends a request to the message server to find the location of the object, if it doesn't find it, then it sends it to the bit bucket (f); if it does it sends the message to that sim (b)
if the message has been sent through 4? sims and not found it's object it is sent to the bit bucket.
(f)if message is sent here then an error message is sent back to the source? (not sure)


--------------------------------------------------

2.

Have the event be sent to all scripts (read: added to the event stack) in the destination object (like a link message is sent to all scripts) that have the recieving event in them.

--------------------------------------------------



exactly it would have to be coded.

I believe Method 2 and 3 are the best of the three methods and wouldn't result in heavy load on any sim. It would require minimal bandwidth and would do the equivilant of running llKey2Name for a forward/exist check.


The message should be a list.

sorry for the bad spelling, grammer and confusing presentation.

Can't we basically already do obj<->obj communication similar to Strife's concept? Actually, I know we can, since I have done it. All that is required is that you make this backend server that handles relaying to message. Basically:
1) Client objects open RPC channels.
2) Client emails backend server their uuid and rpc uuid.
3) When other object wants to send message to another object, it is simply just a matter of passing onto the backend server the object's uuid (or rpc uuid) to transport the message. This would be superior to the current objemail<->objemail since it does not have to constantly check for email (thus saving sim power) but rather calls an event (which god knows why LL does not have the email() event called when an email is recieved....
4) If the to_object has a response, it is simply a matter of sending the response back over it's RPC channel to theback end server, which then relays it to the from_object.

[While we are on the topic, you can also solve another frequently requested item llWriteNotecard() by storing the written code on this same backend server. Once the RPC channel is open, the stream of datalines is basically at comprable speed to SL's dataserver]

Major complaints I have heard is 1) price (Web hosts are _CHEAP_, cheaper than 512m2 of land) 2) Complexity to code (Chances are if you are savvy enough to worry about wide spread obj<->obj communication, you know, or can easily learn, on of the slew of possible programming languages. 3) Speed (To this, I just say shop around... I went through about 7 hosts before I found one I was happy with overall, server speed and even more importantly communication to SL speed being one of the major criteria. )

------------------------
BUT:
Ideally I agree, LL should provide these functions. My point of the rant above was just to express that these are doable now, while some things are not. Direct 2D texture manipulation with text mapping, arrays, increased memory allocation, etc.

Unfortunately, no, we can't, because SL objects can't currently initiate outgoing XML-RPC messages, but only respond to incoming ones. You can implement your own outgoing service of course by polling the objects from your external machine, and some people do that right now. However, it's very inefficient to poll at a significant rate when there are no messages needing to go upstream, and if a lot of people were to do it then one could reasonably expect problems ahead.

Plus, as Eggy said, efficiency is quite possibly the most important requirement of the lot. The XML-RPC route has a lot of good things going for it, but it's not going to win any speed races when you consider that direct inter-sim RTTs are sub-millisecond.

Strife's proposal avoids any polling and has a couple of highly efficient extra features too. I haven't finished analysing it yet, Friday night intruded.

Basically what I want is IPC with the lowest possible latency. That would probably mean that it wouldnt and shouldnt work across sim boundaries, but I dont really care
I just want to be able to set a copy of a game down in one place and have it work fast.
The need for this IPC is mostly derived to the castrating lack of memory, so if you guys want to raise that, it would also be acceptable.
When you've spent half of your second life trying and failing to port interesting RL games to it, you become painfully aware of how much messaging and list access you have to do, and how much of LSL's potential performance you are forced to lose.