Historic overview of previous work on PRPGUI

[Branan]

This originally started as a project to create a graphical front-end for the current PRP-related scripts, as well as a graphical method for setting all of the flags necessary to make objects work properly in Uru or Myst 5. However, if those involved in the current scripts agree, it may be best to do a complete re-write of the entire script system, to include the GUI from the ground up. This is a summary of the decisions made so far, and the reasoning behind them. I'll update this post with the latest news every day or so, depending on how much discussion gets done.

The wiki page on ALCUGS for the project is here. Check it out for images of the different panels, and information on what all the little buttons do. Please note that those images are not from the actual interface. They're prototypes created by me using Inkscape.

REGIONS:
Most of the discussion so far has been about the region controls. I think the final layout is just about here. There may be a few more tweaks, but it's mostly set. The final button set is actually pretty small. Region name, page it's on, region type, collision type, and start disabled. kPinned is enabled by default on regions, and disabling it makes them go away. Thus, there is no Pinned toggle for regions. Regions works whether static or dynamic. The current scripts default to Dynamic, so that's what the GUI will default to. There is a "Static" toggle, to allow for regions to be set static if desired.
There is also a box for entering a script name. Works just like the old box in the Blender's logic page did. See the tutorials for details. Mostly because I don't know them

OBJECTS/COLLIDERS:
Not much discussion here. A few missing things were pointed out to me, but the screen isn't finished yet. I still need to add the toggles for all the different kFlags. It's been agreed that they need to go in there, but I'm not sure how I want to set them up. They only apply to dynamic geometry, so if mass is set to zero, they'll be hidden. Other than that, I'm not certain.
Just like the regions, there's a box for a script name.

EXPORT:
Again, not much discussion. There are buttons to enable/disable every option in the alcconfig.py file. There's a file browser, those switches, and an 'export' button. That's all we need, I think

That's what's been discussed so far. When something changes, there'll be a new post in this topic, listing the changes, and this post will be edited to reflect those changes.

Also, if I ever miss anything that was discussed and agreed upon, don't hesitate to reply here, as well

[Branan]

There's been another update.

Changes:
1) Added script boxes for both regions and objects.
2) Added the 'static' toggle to regions.

The main post will be updated with these changes. The WIKI entry is already updated.

[Branan]

I've added the first image of the add page to thw WIKI article. Check it out, leave comments there, here, or in the thread down in the age creation section. There's a link off of the ALCUGS WIKI front page, but for those of you who don't want that extra click, here's the link.

[Branan]

I've had this one done for a little while now. Don't know why I didn't upload it. Anywho, check the WIKI, you know the drill. linky

On another note, I made some adjustments to the layout, moving each image next to the section describing it. This should make the page more compatible with people not running at my screen resolution, or not running a full-screen window.

[Robert The Rebuilder]

Thanks for clarifying (in the Object properties script topic) what this page would do. I think that the plugin will benefit greatly from having a revamped interface.

However, I'm just not convinced that this page would be of any benefit to the age developer. Here's my reasoning:

• The existing interface for adding objects is straightforward enough: it's either a menu option, , or . The existing interface for setting the object/mesh name also seems pretty easy to use. Granted, this page puts all this capability into one spot, but there are consequences (see next point).
• The Add Page interface would be more difficult to use in some cases. For example, when duplicating an object, the current method is just to select the object to duplicate and then hit . The Add page would force you to search through a list of mesh to find the right one; if you don't know the name of the mesh that you need to duplicate, you'd need to go back to the scene anyway to find it and get its name.
• I can't think of why an age developer would want to have multiple objects share the same mesh (i.e. using the method). From the Plasma perspective, each scene object would require its own mesh, right? So, why offer this as an option in the Add page?
• The Add page would need to keep up with Blender/Plugin developments, as items are added to the Blender and URU Script menus.

Again, I may be missing some crucial aspect of the Add page that may be quite important to the end user. Any explanation of the purpose for this page would be appreciated.

[Branan]

1) good comment here. I'll touch on it in my next point (hopefully)

2) The main reason for this is that, hopefully, we'll eventually be moving the data to an easier-to-use format. Moving the entries out of Blender's game logic panel means that they won't be duplicated when duplicating an object. I know this was only mentioned in passing, but I've been doing some research, and it looks like it should be pretty easy, once a nice UI is there.

3) ease of use. If you make a lamp-post, say, and then decide to change it, all the lamp-posts would change, eliminating the need to delete all the old lamp-posts and create new ones. On another note, do the Cyan PRPs have multiple copies of meshes that are used more than once, or has the method of doing that not been figured out yet?

4) Blender's Primatives probably won't ever change. And unless something other than objects and regions is added to the PyPRP implementation, I don't see what needs to be changed there.

All in all, it centralizes things. and are nice, but when you end up with a complicated scene, finding what you want to duplicate can be a pain, at best. This allows control over how the PRP properties are applied to the new object as well, which isn't available when just using the keyboard shortcuts. Also, Blender normally gives very non-descriptive names to objects. This allows descriptive names to be entered from the beginning. You don't have to remember to flip over to the right Panel to change the name. It's right in front of you when you create the object.

Don't get me wrong, I fully endorse having a way to add properties to an object created through Blender's standard object system, for people who prefer to work with that. I'll probably still work with the old system. I just feel that this makes a few things easier, by moving them all to one place. Anything that makes Age Building easier will attract more people.

[Branan]

Unless anyone has any more strong objections to what's on the Export or Properties pages, I think the coding on those pages can be started now .

I think we should stick to the current data format for now, but depending on others' opinions, I may work on fleshing out my idea of using Blender's text buffers to hold data...

Anywho, I'll bring up a 'last call for objections' to these two pages at the meeting tonight, and if nothing gets mentioned, the coding can begin!

Also, if anyone wants to assist in the coding, they're more than welcome to. Fortunately, this isn't going to be too bad, since it's only changing a few values.

[Robert The Rebuilder]

Good luck, Paladin!

Note: you'll have less code to write if you use the existing object properties instead of adding an intermediate text buffer.

[Branan]

yeah. I'd actually like to get rid of that screen entirely. Accessing a text buffer should be faster than going through several properties. Fewer things to access, after all. Plus a non-human-readable format can be used, so there would just be this string of all the information. Short and sweet. The exporter/importer would need to be re-coded, though.

The other advantage of that is that a user could save a custom default, or even several custom defaults, and have a drop box to select them. Right now, dummy objects would have to be created to hold the information.

But I'm getting way off topic here. We can discuss this in the Cavern this evening, with input from others in the community.

[Branan]

Alright. Quick update on what's been done so far:

I've finished the GUI coding for the Export section. At some point, when both he and I are on the Internet at the same time, Paradox and I are going to tie my code to the current export script, hopefully in a way that won't make thing crash, explode, or otherwise do Bad Things.

I've started the coding for the Properties page(s), but I've hit a couple of snags with Blender itself. I just need to figure out how to update the screen when the user changes his selection. Shouldn't be too hard... Just check for right clicks, then check if the current object has changed. I think. If anyone knows of a more efficient way of doing that, let me know. When editing a mesh, there are lots of right clicks, and not everyone has a top-of-the line system to deal with that kind of in-efficiency.