Dual Xeon, dual U320 controllers, dual hot-plug U320 10K's, dual PCI Express, dual gigabit ether, dual hot-plug fans, and dual redundant PSU box just arrived.
I know what I'm going to be doing over this dual day weekend ...

These forums are CLOSED. Please visit the new forums HERE
virtual linking for linkmessaging rather than physics |
|
Morgaine Dinova
Active Carbon Unit
![]() Join date: 25 Aug 2004
Posts: 968
|
10-16-2004 04:04
Talking about servers and speed ...
Dual Xeon, dual U320 controllers, dual hot-plug U320 10K's, dual PCI Express, dual gigabit ether, dual hot-plug fans, and dual redundant PSU box just arrived. I know what I'm going to be doing over this dual day weekend ... ![]() _____________________
-- General Mousebutton API, proposal for interactive gaming
-- Mouselook camera continuity, basic UI camera improvements |
Moleculor Satyr
Fireflies!
![]() Join date: 5 Jan 2004
Posts: 2,650
|
10-16-2004 04:44
Unfortunately, no, we can't, because SL objects can't currently initiate outgoing XML-RPC messages, but only respond to incoming ones. Alondra has a perfectly valid point though. The original intent behind XML services was to enable another method of communication for objects. Mostly with the outside world, but Obj<->Obj was promised too. The HARDWARE with the necessary connections IS there. LL just needs to turn on our capability. This would enable Obj<->Obj communication without recoding the entire backend of SL. _____________________
</sarcasm>
|
Strife Onizuka
Moonchild
![]() Join date: 3 Mar 2004
Posts: 5,887
|
10-16-2004 14:26
emails don't trigger the email event is because the email server doesn't know which sim the object is in or which sim to send the event to until the script pops the mailbox.
---- I hear you Eggy You want a simple system for sending messages to objects in the sim. Method 4: (aka Eggy's method) (a) sends message (b) (b) takes message sees if target is in the sim if so sends to object (c) other wise sends to (f) (c) triggers object_message event in relevent scripts CODE
The different methods in breif i've discribed so far. 1: Sends the actual message between the different sims and to the message server, supports message forwarding, requires a central database of objects that are accepting messages. 2: Sends the message to the sim it thinks the message should go to directly, supports message forwarding, requires a central database of objects that are accepting messages. 3: Only sends the message to the sim it thinks the message should go to directly, requires a central database of objects that are accepting messages. 4: Only sends the message to the object only if it is in the sim, otherwise drops the message all to gether. CODE
Method 4 could later be expanded into Methods 1, 2 or 3. If the local flag is preserved as i've writen there will be little need for protocal changes. using the 0 bit might be a better idea. message format { key source; integer local; string subject; list message; } commands void llSetObjectMessageFilters(list filters); list llGetObjectMessageFilters(); key llSendObjectMessage(key target, integer local, string subject, list message); void llTriggerError(key id) the llTriggerError event is used for data requests or for sending data with llSendObjectMessage so that an error message is returned on failure. Not totaly needed but could be nice to have. filter format [source1, subject1 source2, subject2 .... sourceXX, subjectXX]
events object_message(key source, integer local, string subject, list message) error(key id, string about)
------------------- on a side note, could we have added: list llSetListenFilters(list filters); //returns a list of the listen handles. list llGetListenFilters(); list llGetListenHandles(); //returns the same list as llSetListenFilters list format used by llSetListenFilters and returned by llGetListenFilters [channel1, name1, id1, msg1, active1 channel2, name2, id2, msg2, active2 ... channel64, name64, id64, msg64, active64] channel is an integer name is a string xor key id is a string xor key msg is a string xor key active is an integer and use these instead of having to muck around with the listen functions and keeping track of listen handles? llListen llListenRemove llListenControl _____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey |
Eggy Lippmann
Wiktator
![]() Join date: 1 May 2003
Posts: 7,939
|
10-17-2004 13:17
Strife, do us all a favor and apply for a job at LL
![]() _____________________
|
Strife Onizuka
Moonchild
![]() Join date: 3 Mar 2004
Posts: 5,887
|
10-17-2004 20:45
That's a complicated issue. It comes down to the fact i don't have the skills to actually implement it. Knowing how a nuclear reactor works doesn't mean you can build one. I'm a much better architect then builder. What LL needs are builders and testers. To be either you need formal education and work experience in the field. The later being the harder to get. Currently I'm working towards the education part.
And the weather is beautiful in SF, i wish i lived there. Last time I was there it felt like a vacation. _____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey |