> 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. > > Boroondas Gupte wrote: > 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.
I don't think rapid clicking as you suggest (even if the time was extremely close to the rezz time of the about to be created sculpt) is an issue -- the packet sent to the server to request the sculpt to be created and rezzed is going to generate a packet coming from the server with the initial object parameters. I don't see how you could "get in front" of this return server packet with additional clicking. I'm assuming the server processes packets coming from the viewer sequentially. - Jonathan ----------------------------------------------------------- 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