[opensource-dev] Review Request: STORM-1793 Viewer needs to treat all mini-map altitudes above 1020 m as the same height
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/534/ --- Review request for Viewer. Description --- The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. The code for the mini-map, in drawing the agent locations for equal, above or below needs to take this into account. It currently does not. LLNetMap::globalPosToView() computes a relative position: LLVector3d relative_pos_global = global_pos - gAgentCamera.getCameraPositionGlobal(); The Z value needs to take the global camera pos, and slam anything above 1020 to be 1020, and all our problems will be solved. Also, new artwork, an X, needs to be displayed for the case of avatar B and your camera position being at or above 1020m, where the relative height positions are unknown. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs - doc/contributions.txt 4982ab91ef6a indra/newview/llnetmap.cpp 4982ab91ef6a indra/newview/llworldmapview.h 4982ab91ef6a indra/newview/llworldmapview.cpp 4982ab91ef6a indra/newview/skins/default/textures/map_avatar_unknown_32.tga 4982ab91ef6a Diff: http://codereview.secondlife.com/r/534/diff/diff Testing --- See test plan in jira Thanks, Jonathan Yap ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-17587: Added "Fly/Land on holding up/down" option under Move preferences
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/523/#review1139 --- Ship it! tested with 3.2.5, works as expected. - Lance Corrimal On Dec. 5, 2011, 3:01 p.m., Kadah Coba wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/523/ > --- > > (Updated Dec. 5, 2011, 3:01 p.m.) > > > Review request for Viewer. > > > Description > --- > > Quick patch to add back the long missing AutomaticFly aka "Fly/Land on > holding up/down". The setting still existed but only has a debug setting with > no exposure under preferences. This change only added a check box for it > under Move preferences. > > Repo: https://bitbucket.org/Kadah_Coba/vwr-17587 > Changeset: https://bitbucket.org/Kadah_Coba/vwr-17587/changeset/2e717f07efbe > > > This addresses bug VWR-17587. > http://jira.secondlife.com/browse/VWR-17587 > > > Diffs > - > > indra/newview/skins/default/xui/en/panel_preferences_move.xml a984f7ffeb4b > > Diff: http://codereview.secondlife.com/r/523/diff/diff > > > Testing > --- > > Patch was tested on Second Life 3.2.4.245931 and is diff against 3.2.5. > > > Thanks, > > Kadah Coba > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: STORM-1799 Object doesn't appear in Block list if trying to block from Remote object inspector
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/535/ --- Review request for Viewer. Description --- 1. Create an object and add default script 2. Click this object 3. Open plain text log and click on object name 4. Click 'Block' button ==> Actual: Block List is opened in the sidebar, but object is NOT added to your Blocked List Expected: Object is added to your Block List This addresses bug STORM-1799. http://jira.secondlife.com/browse/STORM-1799 Diffs - doc/contributions.txt 4982ab91ef6a indra/newview/llinspectremoteobject.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/535/diff/diff Testing --- Performed steps per Description, object is blocked. Thanks, Jonathan Yap ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me"
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/536/ --- Review request for Viewer. Description --- With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me Get together with: Avatar B (not a friend of A) Avatar C (a friend of A) Using avatar B establish an ad-hoc chat with A and C and write a message Observed result: Avatar A and C receive the message Expected result: Only avatar C receives the message This addresses bug STORM-1795. http://jira.secondlife.com/browse/STORM-1795 Diffs - doc/contributions.txt 4982ab91ef6a indra/newview/llimview.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/536/diff/diff Testing --- Created a 3-way ad-hoc session per Description. Avatar C does not receive the message, but does get an ad-hoc session icon, even when B initiates the ad-hoc session. I think this is correct behavior because C may change their preferences to allow messages from everyone. You do not want to reject the session (that was handled by a different jira recently for blocked residents), only suppress messages. Thanks, Jonathan Yap ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1793 Viewer needs to treat all mini-map altitudes above 1020 m as the same height
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/534/#review1141 --- In a number of ways this change is a step backwards and should be rejected / revisited. 1) Ambiguity. Previously, when an agent was "out of resolution" they were reported as 0m. This has the advantage of being an improbable edge value and easy for the viewer to detect and interpret as "out of resolution". However, this new proposed change would mark a user in the "out of resolution" state as 255, which translates to much more plausible value of ~1020m altitude. Agents are much more likely to be naturally at this altitude! Because of this change, it's much harder for the viewer to correctly determine that the reported value is out of resolution, or if the detected agent is actually at ~1020m. 2) Efficiency. I am not sure how aware LL is of the tremendous inefficiency the limited z axis range causes gridwide. More than 2/3rds of ALL SL GRID USERS are now using LSL-based "radar" systems to either feed viewers correct z heights or display the correct heights directly via a HUD. Not only is the overhead associated with transmitting this information every scan interval via LSL staggering, but it means that the original 8bit z axis field is largely being largely wasted. By increasing the resolution of the z-axis field provided directly to the viewer, LL would be saving enormous amounts of overhead and bandwidth by obsoleting LSL-based systems. Continuing to ignore this is penny wise, pound foolish. - Arrehn Oberlander On Jan. 16, 2012, 5:12 a.m., Jonathan Yap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/534/ > --- > > (Updated Jan. 16, 2012, 5:12 a.m.) > > > Review request for Viewer. > > > Description > --- > > The SL simulator has recently been fixed so that the CoarseLocationUpdate > message properly returns 255 for all altitudes above 1020 meters. > > The code for the mini-map, in drawing the agent locations for equal, above or > below needs to take this into account. It currently does not. > > LLNetMap::globalPosToView() computes a relative position: > > LLVector3d relative_pos_global = global_pos - > gAgentCamera.getCameraPositionGlobal(); > > The Z value needs to take the global camera pos, and slam anything above 1020 > to be 1020, and all our problems will be solved. > > Also, new artwork, an X, needs to be displayed for the case of avatar B and > your camera position being at or above 1020m, where the relative height > positions are unknown. > > > This addresses bug STORM-1793. > http://jira.secondlife.com/browse/STORM-1793 > > > Diffs > - > > doc/contributions.txt 4982ab91ef6a > indra/newview/llnetmap.cpp 4982ab91ef6a > indra/newview/llworldmapview.h 4982ab91ef6a > indra/newview/llworldmapview.cpp 4982ab91ef6a > indra/newview/skins/default/textures/map_avatar_unknown_32.tga 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/534/diff/diff > > > Testing > --- > > See test plan in jira > > > Thanks, > > Jonathan Yap > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] A CALL TO MAC DEVELOPERS!
Subject: https://jira.secondlife.com/browse/STORM-1797 Need help verifying if this is affecting those that use Mac OS. Please test against viewer-development tip. Reply here or post a comment in the above mentioned issue. There is a test plan in the issue. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Anim format files upload
Hello,
Is it possible to add the following patch :
In indra/newview/llviewermenufile.cpp. Locate the function
upload_new_resource, and circa line 800 (search for
DoNotSupportBulkAnimationUpload ) after the following code:
else if (exten == "bvh")
{
error_message = llformat("We do not currently support bulk
upload of animation files\n");
upload_error(error_message, "DoNotSupportBulkAnimationUpload",
filename, args);
return;
}
add the following:
else if (exten == "anim")
{
asset_type = LLAssetType::AT_ANIMATION;
filename = src_filename;
}
as seen on this web page :
http://blog.machinimatrix.org/avastar/avastar-anim-format/
Should I open a Jira as feature request for this ?
Thank you
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Anim format files upload
> Is it possible to add the following patch : To add my support. Using BVH to upload files has serious drawbacks. Being able to upload a raw anim file natively in the official SL viewer opens all sorts of wonderful avenues, such as a Maya or Blender plugin that exports directly into the anim format. This allows us to have more accurate animations with less waste, and to put the details where we want them, instead of having them automatically assigned. Laurent, let me know if you find/create a Jira. It would have my support. Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Anim format files upload
Here we go : https://jira.secondlife.com/browse/VWR-28143 Le 17 janv. 2012 à 02:59, Stickman a écrit : >> Is it possible to add the following patch : > > To add my support. Using BVH to upload files has serious drawbacks. > Being able to upload a raw anim file natively in the official SL > viewer opens all sorts of wonderful avenues, such as a Maya or Blender > plugin that exports directly into the anim format. This allows us to > have more accurate animations with less waste, and to put the details > where we want them, instead of having them automatically assigned. > > Laurent, let me know if you find/create a Jira. It would have my support. > > Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
