Honza Noyes

Uh, I can't quote things here, that statement: if( ! $result = curl_exec($ch)) is correct. What it does is that it assigns value of the HTTP request to $result variable. And then checks for the response being empty. Maybe LL changed the structure or URLs of transaction history, I am going to check later today. Edit: Also, I believe it would be better to grab the transaction history from the HTML instead of using the XML files, as they get cached and you would have to play with the date ranges to get the latest transaction history log, where with the HTML page, you will always get the latest one.

I managed to get something like that working in PHP, I also believe it is available somewhere on the Internets. I can probably help with getting it set up, I don't know NodeJS much, but I can provide general knowledge about this. Feel free to contact me in-world.

Well, I submitted a JIRA, few hours later, everything returned to normal. This was really weird behavior. It might have restarted/crashed or so, but the most important thing is that it works correctly now.

Hello, after today's update region "Lionetz" appears to be experiencing trouble. I can teleport in, but can't teleport out (end up crashing and relogging into the last known location). Also scripts are not saving. Also meshes are not rezzing at all. Also, llRequestURL returns invalid URL format: http://sim10429:12046/... JIRA: https://jira.secondlife.com/browse/BUG-3663

Thank you guys very much for pushing BUG-2833 fix to the RC channels. It means a lot to me.

Hello, please check BUG-2833, it seems like that LSL HTTP URL haven't been fully fixed yet.

Thanks for the fix BUG-2564 going onto the Main Channel.

This would be very useful. Since the JIRA changes, is there any way to file a feature request there?

Oskar, following issue, SCR-382 is still occuring. Along with that the "llAttachToAvatarTemp fixes" mostlikely resulted in SVC-8136 being rolled grid wide.

Hello, I am unable to figure out how to properly detect the position where the object hit the avatar, situation is following: Avatar is wearing a HUD, a bullet (for example 5m long one) collides with him, meter gets the llDetectedPos from collision_start event, however the llDetectedPos returns the bullet center, not the actual point where it collided with the avatar's hitbox. Shooting straight would work, but when shooting the projectile from different angles makes the reading wrong, since the center returned is no longer in the same height like where the collision happened. I can quite safely detect the position by llCastRay function, but I would like to avoid that way. Thank you.

For example: Outer Heaven, Second Life RC Magnum 12.07.06.261281

Good day, I was writing a script today, and I ran into a very obvious behavior, the following script looks like this: float rof_time; integer rof_count; Fire() { rof_count++; llSleep(0.1 * llGetRegionTimeDilation()); } default { state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS); } run_time_permissions(integer perm) { if(perm) { llTakeControls(CONTROL_ML_LBUTTON, TRUE, FALSE); } } control(key id, integer level, integer edge) { if((level & edge) & CONTROL_ML_LBUTTON) { rof_time = llGetTime(); rof_count = 0; Fire(); } else if(level & CONTROL_ML_LBUTTON) { Fire(); } else if((~level & CONTROL_ML_LBUTTON) && (edge & CONTROL_ML_LBUTTON)) { llSay(0, "ROF:" + (string)(rof_count/(llGetTime() - rof_time)) + "BPS"); } } }Now the following script after being dropped into an object and worn, holding CONTROL_ML_LBUTTON and than releasing it should say 'ROF:10BPS' which it does in a regular sim (homestead or full, doesn't matter at all), but in a little lag, it reuturns 'ROF:<10BPS'. Now here comes the thing, when you standing the returned ROF is lower than 10 in lag, but when you press CONTROL_FWD or any other button and start moving, than hold the CONTROL_ML_LBUTTON and than release it, the script returns 'ROF:10BPS' which is correct. So here is the question, is this a bug or expected behavior since I am not taking control of CONTROL_FWD or other movement buttons, however they affect the script?

It's great to hear the the llSetRegionPos is making it to us!

Thanks a lot Oscar, great job on pushing the llTransferLindenDollars to the whole grid. Great job Lindens!

Hey, from what I understand, both the llTransferLindenDollars and the transaction_result could be released during this week's deploy to the whole grid. It also is pretty much backed by this article. Also from the article of llTransferLindenDollars announcement: The RC channel LeTigre is scheduled for promotion next week. After the Wednesday rolls this feature will be available in all regions on the main grid. __Oskar

Wow, this looks like we could get the llTransferLindenDollars before Christmas. Great job Lindens!

Oh great work! Thank you Kelly!!!!

Great idea, completely agree with that, but the status would have to be returned all the time with data because if they in future make the string data return more stuff, it would break back-compatibility. Would be just enough to have the success return 1,2,3,4... and have those values stand for certain error, just like PRIM_POSITION or so.. But it would be great to have the function return the agent and amount all the time.

Yes, this indeed exists, it basically downloads the XML file from transaction history, but there is a problem that the XML gets cached for 15 minutes, so for up-to-date checks during those 15 minutes, you need to toggle between the past 30 days... I am using similar system for my vendor system in-world (also uses web server - PHP - to grab the XML and parse it into CSV), it is quite efficient, but the llTransferLindenDollars will be the best solution. There were some links on the SL Forums and a sample, it's too late now, but I could possibly find those and send them to you tomorrow. Or if you skilled enough with PHP, you could possibly grabb the data directly from http://secondlife.com which would be way more efficient than grabbing the XML.

TRANSFERS_DISABLED - L$ transfers are disabled in the regionDoes this mean that you can disable Linden$ transactions in certain regions? Or generally, how can this error occur?

I think that this is rather more complicated... You can just simply do llCSV2List and done.. And I am also sure it has some purpose for future features like making our own transaction descriptions or something like that...

Kelly, is there any ETA of this feature to the main grid?

Since it is going to have same limitations as llGiveMoney, I suppose it means: "Use is limited to 30 payments in a 30 second interval for all scripts owned by that resident on a region. Sustained overage will produce a script error and halt payments while the rate remains excessive. Historically, faster payments have failed intermittently."

So far it works flawlessly.

Thanks for the info Kelly.