Jump to content

Honza Noyes

Resident
  • Content Count

    56
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Honza Noyes

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. Thank you guys very much for pushing BUG-2833 fix to the RC channels. It means a lot to me.
  6. Hello, please check BUG-2833, it seems like that LSL HTTP URL haven't been fully fixed yet.
  7. This would be very useful. Since the JIRA changes, is there any way to file a feature request there?
  8. Oskar, following issue, SCR-382 is still occuring. Along with that the "llAttachToAvatarTemp fixes" mostlikely resulted in SVC-8136 being rolled grid wide.
  9. 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.
  10. For example: Outer Heaven, Second Life RC Magnum 12.07.06.261281
  11. 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?
  12. It's great to hear the the llSetRegionPos is making it to us!
  13. Thanks a lot Oscar, great job on pushing the llTransferLindenDollars to the whole grid. Great job Lindens!
  14. 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
×
×
  • Create New...