Rider Linden
-
Posts
221 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Rider Linden
-
-
Be sure that you are not trying to follow an excessively long chain of redirects. LSL HTTP does automatically follow redirects, but the number of redirections is limited.
-
2
-
-
I have not personally used this method of doing what you are describing but it might be worth giving it a try.
Consider treating your texture atlas as an animation and use llSetTextureAnim to display the cell/frame you want.
You could rewrite your ShowNumber() function as follows:
QuoteShowNumber(integer num, integer face)
{llSetTextureAnimation( ANIM_ON, face, 8, 8, num, 1, 0.1 );
}
Note, that this turns the animation on for the indicated face, divides the texture into an 8x8 grid. It then starts a single frame non-looping animation and should display your number.
Your mileage may vary.
-
12 hours ago, Wulfie Reanimator said:
Besides, it's an impossible request in its current form because changing or adding a string to on_rez would (almost, if adding) definitely be a breaking change.
Changing parameters on an already published API is not really a possibility. It would absolutely be a breaking change.
-
20 minutes ago, Wulfie Reanimator said:
Can you go into any specific details about those changes? (Talk techy to me, LL.)
Or at least, what can we as scripters expect that is different from before, or is this just a performance increase?
Why did content break, or was it only because of those already existing race-conditions?
I'm not going to go into details about what changed beyond saying that some events (notably chat listens) were being collected and distributed once every script execution for every script. They are now queued immediately to the subscribed script(s) removing some work from the scheduler.
The window between the object_rez event and on_rez() has become more variable and the delivery of chat messages to a channel has become faster. So, scripters that already use a handshake as recommended in the blog post will not notice any difference and their scripts will continue to work. However if the rezzers are relying on a timeout to determine when their rezzed object is ready, those scripts may break.
on_rez() in multiple scripts should all occur within a server frame or two of each other (depending on the script load of the server), however the order in which they occur remains arbitrary.
-
7
-
-
5 hours ago, WolfBaginski Bearsfoot said:
Is this bug likely to be on the Beta Grid?
Only on selected regions. What regions and sever version did you encounter the issues on?
-
1
-
-
Little Things
Little drops of water,
Little grains of sand,
Make the mighty ocean
And the pleasant land.Thus the little minutes,
Humble though they be,
Make the mighty ages
Of eternity.
-- Julia Abigail Fletcher Carney-
4
-
1
-
-
On 9/27/2019 at 3:45 PM, Rolig Loon said:
Texture animation is a prim property. It can only be started or stopped with a script, but it does not require a script to continue running. Therefore, you can delete the script once it has started the animation. There's not really much benefit to doing that, but it appeals to some people's sense of tidiness.
If the script's sole purpose was to start an animation on a prim there is benefit to deleting the script once it has done that. Even scripts that contain no events currently consume some resources on the server and must be checked every frame to ensure that they do not have any events pending.
-
2
-
-
The download for the current EEP viewer is https://releasenotes.secondlife.com/viewer/6.4.0.530150.html
You can check which viewer you are running by opening Help>About. For EEP the first line should read: "Second Life Release 6.4.0.530150"
Windlight XML files are still included with the EEP viewer but it does not use them. You can find all of the old Linden Lab Windlight files (and many of the Firestorm Windlights) in your inventory under Library>Environments. You can use these directly on your land or copy them into "My Inventory" and edit them to create your own environments.
-
2
-
1
-
-
@skylarmalone. That appears to be a non EEP viewer. That floater was removed in the the EEP viewer.
For the legacy Windlight viewers the windlight XML files are located in the Second Life install directory under: ./SecondLifeRelease/app_settings/windlight
-
1
-
-
At some point in the future (EEP2) we will be implementing density profiles which will give better control over things like haze, distance fog, god rays and ambient colors.
This isn't until some unspecified future though so you should be fine with using SETTING_LEGACY_HAZE for the time being. Again, just be aware that they are considered legacy at this point and may be missing from future versions of the a settings asset. (At which time you'll have to infer what the values of distance_haze, distance_multiplier and ambient_color should be.)
-
1
-
3
-
-
The viewer's corresponding conversion code has been there for some time (It was put in place so that an EEP viewer could still update the environment on a Windlight simulator, and has never been removed, even after the whole grid switched.)
You can find it in llsettingsvo.cpp. (found at the link). Search the file for methods named convertToLegacy( ), there should be three of them. The viewer conversions do not have the issue that impacted the simulator.
Be warned. The legacy Windlight format does not include a number features such as customization for clouds and heavenly bodies, independent moon position, and several others. These improvements are stripped in the conversion.
-
2
-
-
28 minutes ago, Henri Beauchamp said:
Would LL be so kind as to publish the relevant code, so that it could be integrated without having to reinvent the wheel into viewers that keep the Windlight renderer (this way, the viewers that support EEP settings but don't use the EEP renderer could render Windlight settings corresponding to EEP ones, even when the EEP settings do not come from the region itself) ?
As I mentioned above. This is a simulator, not a viewer, issue so there is no code to publish.
All simulators on the grid at this point maintain EEP settings internally and do a translation to the legacy windlight when a viewer requests the environment through the old cap. It was this translation that was applying the improper scaling on our end.
Conversely, if a viewer changes the environment using the legacy caps and sends Windlight to a simulator, we do the translation on our end into an EEP setting.
-
2
-
-
There was an issue on the servers that was scaling down the fog values when translating from the simulator EEP settings into legacy Windlight. (Scaling them down so that they were practically 0.)
We have a fix for this and are rolling it out to an RC today as in simulator version 2019-09-24T17:23:00.531200.
-
1
-
3
-
-
Just now, Profaitchikenz Haiku said:
Unless you put up several dozen prims and then start cycling the textures on them several times a minute? (My way of saying that although the scripts themselves are serverside, their outcome is most definitely clientside)
DON'T DO THAT! You'll make me cry. 😭
But you are correct, scripts can cause effects that will be reflected in the viewer and potentially degrade performance... I will hazard a guess that virtual crops are not committing this particular sin however.
-
1
-
-
Scripting is handled entirely on the simulator. It would not impact your GPU in any way.
-
3
-
-
"Milotic"
-
3
-
-
Don't blink!
-
5
-
1
-
-
15 hours ago, NiranV Dean said:
B: EEP is still far away from being usable, i could bet that if i were to test the latest release my master list of bugs would still be untouched (best case) or in worst case would be even bigger now.
Have you filed bugs in JIRA for your master list?
-
1
-
2
-
-
In seriousness... the minimum distance between two frames in a day cycle is 2.5%. This works out to 6 minutes for a 4 hour day cycle.
You could move the moon to near the zenith with a small scale factor and have it move to somewhere near the nadir with a large scale factor. This would give the appearance of a large rock(s) hurtling to the earth (it would cross the horizon at roughly the 3 minute mark.) If you had the sun and moon alternating positions (making the heavenly body unnoticeable when it reset to the zenith) you would certainly be able to simulate your own personal Perseids Meteor Shower.
-
3
-
2
-
1
-
-
34 minutes ago, Love Zhaoying said:
I bet one of the moons could look like a giant asteroid, and move fast!
Ok... but you're on your own for craters and an impact blast 😉
-
2
-
1
-
-
1 hour ago, Love Zhaoying said:
I would be afraid it is a trick, and they will send a giant asteroid while I’m a Dinosaur.
Giant asteroids are out of scope for the EEP project. I'll add Dinosaurs to the EEP two list.
-
2
-
3
-
-
On 6/15/2019 at 4:44 PM, Wulfie Reanimator said:
The real difference between these functions is that one uses an EEP asset, the other uses a list of parameters. But notice how llSetAgentEnvironment does not have the two big caveats on it. I wanted to know whether this is a case of incomplete documentation, or those big caveats don't affect llSetAgentEnvironment.
I have corrected this oversight on the wiki.
-
5
-
-
In all cases, the Linden Lab EEP viewer allows the agent to override any simulator applied environment setting. This includes environments applied to the region, the parcel, and through scripts functions such as llSetAgentEnvironment and llReplaceAgentEnvironment. The simulator is unaware of any such override and can not track it through llGetEnvironment. This function works only to report on the state of the parcel or region settings.
-
5
-
-
Does this mean I'll need to a new LSL call?
llAdministerDramamine( key agent_id );
This will, of course, require experience permissions.
-
4
-
Facebook
Instagram
Twitter
YouTube
Flickr
LSL HTTP requests don't redirect automatically
in LSL Scripting
Posted
Animats, if you can open a feature request JIRA for following redirects on methods other than GET or HEAD so that it stays on our radar and we can take a bit of time to weigh the implications.