> On July 20, 2011, 11:14 a.m., Boroondas Gupte wrote: > > indra/newview/lltoolplacer.cpp, lines 394-404 > > <http://codereview.secondlife.com/r/317/diff/1/?file=2852#file2852line394> > > > > Where are these numbers coming from? Are they used elsewhere in the > > code? > > Jonathan Yap wrote: > These numbers are copied from another place in the code dealing with > converting an object to the sculpt type. In file \newview\llpanelobject.cpp > see the end of getVolumeParams.
If they are used at more than one place, would it make sense to have constants for them? > On July 20, 2011, 11:14 a.m., Boroondas Gupte wrote: > > indra/newview/llviewerobjectlist.cpp, line 96 > > <http://codereview.secondlife.com/r/317/diff/1/?file=2854#file2854line96> > > > > Is a global variable really the way to go here? Also, please add a > > short comment explaining the semantics of this variable. > > Jonathan Yap wrote: > Comment added. Robin Cornelius suggested using a global variable. If > you can think of a better way please let me know. A static class member variable would avoid littering the global namespace. Though an issue I'm more worried about would remain: We might end up converting the wrong object to a sculpty. I think one could trigger a race condition by clicking the new sculpty button, then veeeeery quickly clicking inworld, clicking one of the non-scuplty prim buttons and clicking inworld again. In that case, it might be undefined which of the two new objects become sculpties. Then again, users who do insane clicking like that might not care either way, anyway. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/317/#review895 ----------------------------------------------------------- On Aug. 3, 2011, 11:21 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/317/ > ----------------------------------------------------------- > > (Updated Aug. 3, 2011, 11:21 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > As a Content Creator, I have to select a regular prim type and than choose > sculpt from a drop-down menu in order to create a sculpted prim. > > I have added a new Sculpt icon to the list of available object types that can > be selected on the build menu. You can now rez a sculpt the same way you do > a cube. > > Possible issue: I made up a new Pcode used only by the viewer. > > > This addresses bug STORM-49. > http://jira.secondlife.com/browse/STORM-49 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/llmath/llvolume.h a36a329e77cc > indra/llprimitive/llprimitive.cpp a36a329e77cc > indra/newview/llfloatertools.cpp a36a329e77cc > indra/newview/lltoolplacer.cpp a36a329e77cc > indra/newview/llviewerobjectlist.h a36a329e77cc > indra/newview/llviewerobjectlist.cpp a36a329e77cc > indra/newview/skins/default/textures/build/Object_Sculpt.png a36a329e77cc > indra/newview/skins/default/textures/build/Object_Sculpt_Selected.png > a36a329e77cc > indra/newview/skins/default/textures/textures.xml a36a329e77cc > indra/newview/skins/default/xui/en/floater_tools.xml a36a329e77cc > > Diff: http://codereview.secondlife.com/r/317/diff > > > Testing > ------- > > Rezzed a sculpt both alone and with someone watching. > > Rezzed sculpts as fast as I could click (poor mans load test). > > > Thanks, > > Jonathan > >
_______________________________________________ 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
