CompuServe Thread

Concerning dialog controls which can affect realtime viewports: Sliders are built in, buttons just require custom feel_functions, but editable fields (int/lint/float/lfloat) require mucho work rewriting the edit_feel function? Would this edit_feel function would have to be changed by the Yost Group? If so, I would ask that this be done. One of the many cool things about the SDK3 is the interactiveness which it allows, I think removing this ability from some of the controls severely hampers this. Please put me down for a suggestion to add the ability to update a viewport to editable fields. Ideally, the programmer would add this ability in a manner similar to the ClientSliderAction method of easiness, although you know we'd be happy w/ just about anything. (No-'cause it would be WAY too much work IS a very acceptable answer) 🙂 Reading my new trusty manual I see Exp_Select_Input_Obj and am very happy. Now I must ask the other side of the coin: after reading in the selected object's vert/face info,etc., can the object be written back out to? (put_vlist, and such?) This would allow AXPs which work on all objects encompassed by the bounding box, instead of tagging each and every object. That would truely be awesome. Suggestion: Give AXPs access to the Exp_Extents command/info. New Crusade: The animation start/end frame and render-by-N-frame information can be very important to routines which run at render time. You can write the current field to a state file/variable and then compare each frame to get the render-by-N-frame value. But AXPs are not given access to the start/end frame info like SXPs are. Please put me down for a suggestion that this be changed. Light question of the day: Since 3DE.exe will not be included in the release version, does this mean there will an expanded section on manually building your own Dialog monster union statement? liking this new forum, Don