Object properties script?

[Branan]

A small update. Check out the WIKI Page for the details.

Quite a bit more than a small update. I started adding some documentation as to what all the buttons do. Most of them are self-explanatory to those who have been working with Uru for a while, but to a new person, button descriptions are nice.

Anywho, I'd still like any feedback on stuff that's missing. Specifically, do any of the regions (besides footstep) have settings that can be changed?

[Nadnerb]

the alctype:"collider" is basically what the "visible" button would be. (collider = not visible). so the "collider" button is misleading and redundant in your gui. (collision type is already in there) also, I'm guessing that your new "convert to region" button would set the appropriate settings to make the region and change the buttons for that object. (which I don't see in your images) It would contain a dropdown for region types and such. (essetially controlling alcspecial) but keep in mind that regions would need to have almost all the settings that are available for normal objects. (mass, page, collision type, etc.) or problems will be had when It comes time to write python scripts. And you need spawnpoint controls. (pretty much just a name field, but you want to stop people from adding mass to a spawnpoint or something) And book controls. (you can edit the book and pages) also, once mass has been added, you would want to add the controls for certain kickable only properties. (check out col_flags4)

Edit: oops. missed your "region" control panel pic. but it still needs those settings.

[Branan]

'Collider' turns collision on and off. Something can have collision and be visible. It has nothing to do with the term as it's currently used. 'Visible' toggles the type from 'object' to 'collider'

I had thought that 'regions' were kind of like 'triggers' in most FPS engines. Or, at least, that they'd have pretty standard collision stuff that we wouldn't want to mess with. If regions do need all the collision control, I'll just merge the two pages together into a single "properties" page.

[Nadnerb]

:blink: wow, you reply fast. I was editing my post again...and then you had posted.

so the collider button would set col_flags2 then? that makes sense.

anyway, for convenience I copied my last edit down here:

And you need spawnpoint controls. (pretty much just a name field, but you want to stop people from adding mass to a spawnpoint or something) And book controls. (you can edit the book and pages) also, once mass has been added, you would want to add the controls for certain kickable only properties. (check out col_flags4)

-----

if you're going to go with a single properties page for objects and regions, (which is good. they have too many common settings ) it would still be a good Idea to have a make region button that would set some of the flags properly and enable the region controls (this is plasma for beginners, after all), and also, plain objects (not just regions) need to have a separate swim setting. (you have to have a surface to swim on not just a region to swim in. (yes that is a bit weird)) And also, instead of a seperate region control panel, have seperate controls for the book and it's pages.

[Branan]

Book and Spawnpoint controsl are WIP. The col_flags4 stuff can be added as well, If I can find room.

Does anyone have an opinion about user control of region physics settings? If not, I can just hard-code some defaults, and just have the user choose the type. The point of this is to hide as much as possible, after all.

[Nadnerb]

:blink: :blink: I should really learn not to edit my posts. this is almost like instant chat...

major changes were made to my last post:

if you're going to go with a single properties page for objects and regions, (which is good. they have too many common settings ) it would still be a good Idea to have a make region button that would set some of the flags properly and enable the region controls (this is plasma for beginners, after all), and also, plain objects (not just regions) need to have a separate swim setting. (you have to have a surface to swim on not just a region to swim in. (yes that is a bit weird)) And also, instead of a seperate region control panel, have seperate controls for the book and it's pages.

-----

anyway, I think that the physics controls are pretty self explanatory. my vote is always for the most control possible while keeping it self-explanatory. one thing I might add is a button that would basically zero all the mass rc el settings and call it "disable physics"

If you really want to hide the region physics controls, you could do this:
when user clicks "make region" remove them mass rc and el settings and replace them with a dropdown containing "static", "dynamic", and "advanced" (which would bring them back.) and also lock the "visible" button while adding the "region type" menu. (selecting footstep would add the footstep sound menu, that way, it is only available when neccesary.)
also, setting the "clickable" button in an object would create a "clickfile" field. the button would be removed for regions and replaced with "clickregion"

the way I see it, aside from the books, there would be only one object controls panel and selecting certain settings would enable or disable other settings. so "make region" should really be just "region" (in the green buttons) and it would enable some settings and disable... visible and lights. oh and collider. (no point in having an invisible region without collision, might as well might no exist, but coltype should still be there but with only options 1, 2, and 3)

[Branan]

I think it may be better to just add a few switches to the region properties... I'd like to keep them seperate, since regions are what interact with the engine, and objects/colliders are what interact with the player. That being said, some of the properties can be added to the region panel: Collision type, Mass, Friction, and Elasticity. Those shouldn't have to be adjusted for a region, from what I've read, but I'll enable them anyway, just in case. The controls for books and pages are still in my head, I still haven't gotten the oomph going to get started on those.

My original plan was to have each region type use the defaults set when you add a region of that type using the current PyPRP scripts. I wasn't aware those settings would ever need to be chaged.

A couple of notes on my resasoning:
Clickable: A region shouldn't need to be clickable. A visible object is much better for this role.
Block Camera: Same as above. A region, being invisible, is a poor choice for a camera blocker
No Friction: No friction with the Avatar should probably be set by default for regions, and never turned off.
Colide with (All|Kickables): A region is useless if it only collides with kickables
Save Object State: Used, from what I understand, to save the location and orientation of stuff that moves. Again, not going to be used for a region.

[Nadnerb]

ok. it is true that most of the time one would simply add a region and not change it's properties. what I'm thinking of is two things: that regions don't neccesarily have to be cubes, and that if you want to move them around with python, they're going to have to have mass. so just replace mass rc el with dynamic/static. and if they're dynamic, give the option of kPinned. (or just do it by default)

I don't mean to be overly critical, but I figure feedback is neccesary if this is going to work right

---- last post: (disreagard most of it now)

the way I see it, aside from the books, there would be only one object properties panel and selecting certain settings would enable or disable other settings. so "make region" should really be just "region" (in the green buttons) and it would enable some settings and disable... visible and lights. oh and collider. (no point in having an invisible region without collision, might as well might no exist, but coltype should still be there but with only options 1, 2, and 3)

[Branan]

I don't think you're being overly critical... I was more worried you would think I was being stubborn. I agree that feedback is necessary!

Static/Dynamic is good. Most regions will probably be static, but for things like a switch on an elevator, the click region needs to move around. Coltype with options 1,2,3 would allow for non-cubic regions without any issues. Hiding the exact mass is probably best, since it's irrelevant as far as the script goes (maybe?).

kPinned... does that cause the object to stay where the script puts it, and not have gravity effect it? There's a list of the col_flags4 stuff at ALCUGS and at COBBS, but I can't find descriptions of them at either. Descriptions of those would be nice, so I can add useful tooltips, and maybe better button names. Besides, if anyone knows what those do, they should be documented at ALCUGS, anyway.

[Nadnerb]

yes, kPinned locks the object in position so that the region doesn't just fall out of the age. (only affects objects with mass) that way only the required scripts will be able to move it. And yes, you don't need to know the exact mass. (At least, I can't think of a single reason why you'd have to.)
and yeah, a lot of the flags4 seem to be redundant, or .. weird. (kWarp?) I've been tossing them around in my test age trying to figure out the difference between kSupressed and kDisable. (seems to disable gravity and collision detection) kWeightless doesn't seem to do anything at all. (I would expect something like pinned except collisions would change its velocity)