Friendlyskies AoI Forum

Hi Troy,

A commendable undertaking. Just a few points which may be of help:

1. The AOI Scripts and Plugins project (AOISP) on Sourceforge was created to help with exactly this issue. We keep source code for (most of) the current plugins there. The SF source download system can manage multiple versions of source for each plugin.

2. The AOISP project also has a subversion SCCS. Personally I am very much against subversion (it seems to be the opposite of what we want for a distributed development effort), but it is a centralised repo for source code. And it is globally accessible.

2a So what would be useful would be for us to arrange some way to regularly update the AOISP subversion repo from your GIT repo.
Speaking of this, I should arrange a similar update process from my Darcs repo of my plugins... (Francois asked me to do this years ago, and it is in fact quite possible - I just haven't got around to it...)

3. Now is a good time we got all the plugin developers to discuss this. I don't know enough about Github, but what we really need is a central place for source code and the binaries for the SPManager to download from. We currently have all of this with AOISP. We don't really get great value from AOISP in terms of source code management, so if we decide to move elsewhere I am ok with that. But I would not want to separate the 2 functions - it's hard enough keeping the 2 parts of the single project we have up to date. Having 2 separate projects to update would be even worse. :-)

Cheers!
Nik

The other thing I have considered is hosting a public Darcs repo on the AOISP project. This is actually quite easy to do, and offers a better environment for distributed development.

Whichever way we go, I am planning on achieving the following:

1. Single global website with scalable download mirroring that supports both versioned sourcecode and versioned binary distributions;
2. Web-based access to the source repository;
3. Web-based access to the versioned binary repository;

I can achieve all of the above through SourceForge and SVN. I am still looking into whether the result would be better or worse if I used Darcs instead. In amongst all of that, I should consider GIT. It is possibly a better solution for a global repository such as this, but in other respects it may be more difficult to set up on SourceForge.

However, that does raise the interesting prospect that perhaps GITHub might be a good solution for both source and binary repos...

Cheers!
Nik

Well, that would be great, I guess. Didn't know that either. Looks like git is really gaining popularity ...


Just to report some updates. The snapshots are up to date, so you can obtain these plugins / scripts from there.

External Script Editor:

Allows you to edit scripted objects in an external editor such as vim, geany or whatever. Just select your script(s) and choose "Tools" -> "External Script-Editor". You can configure that plugin under "Edit" -> "Plugin Preferences".

Note that there's a button to create a hotkey. You only have to do this *once*, even if you change the editor command. That hotkey can be adjusted using "Edit" -> "Preferences" -> "Shortcuts".


Regex-Tools: (all of the following are tool scripts)

RegexSelect and RegexTextureWipe provide simple utilities to select objects and delete textures whose names match the given pattern. For example, selecting "Sphere.*" would select every "Sphere 1", "Sphere 2", ... in the scene. Please note that there's no undo record being created when using RegexTextureWipe - so you can't recover any deleted textures.

RenameByFindAndReplace is a little bit more complex. It allows you to batch rename objects. For example:

- Select nothing and start the script. To replace every "PolyMesh" in object names with "Bomb", just enter "PolyMesh" as the pattern and "Bomb" as the replacement.

- To restrict this process to *some* objects, you have to select them before you start.

- There's a "counter" feature: A %c in the replacement-string will be replaced with a growing number. So, to rename all objects like "Sphere red", "green Sphere" ... with "Ball 1", "Ball 2", you'd have to enter ".*Sphere.*" as the pattern and "Ball %c" as the replacement-string. Note that in this case you'd have to disable the "Regex: Word boundaries" option.


Feel free to poke me if that short description was just too confusing.

Hey,

I'm sorry, I should have put the DOF autofocus scripts in this thread, too. Sorry for the slight chaos.

Anyway, here's another tool script: MoveObjectsToLocation

Download via github, just throw it in your "Scripts/Tools" directory.

This is pretty self-explanatory. You select a bunch of objects and launch the script. Now you pick one of the selected objects and all other objects will get moved to the location of the target object. An undo record will be created.

Hey,

grouping and categorizing scripts is another "battlefield". (I suppose that sentence was proper denglisch).

I totally agree that it's hard to find one particular script in such a long list. Categories (preferably editable by the user) would be very nice. However, this has been discussed on SourceForge a while back and as far as I can recall there were no proposals yet on how to solve this issue...

Translating my tutorials? That's nice! I have to admit that I haven't followed your "Editable Manual" project in detail. Seems like I should take a closer look. Anyway, let me know if you need any help in translating those tut's.

mayid wrote:

Would you merge the scripts in a single menu item, and put it in a menu? (outside the Scripts submenu).

Hm, well, I'm thinking of something like this (click for full view):



Of course, in any case, grouping poses the question of "how to group?" You may want to group scripts in a different way that I would group them. Hence, the best way would be to have some kind of "default grouping" (maybe non at all) and if the user wants to, he may group his scripts in any way he likes. This results in user-editable-menus (at least for the scripts).

I do have some ideas of how this could be implemented. However, most of the code would be GUI code (--> create a menu editor) and that's cumbersome. The underlying logic wouldn't be that hard to code, I guess -- but writing GUI code is very time-consuming.

Francois explained me why the scripted objects cannot have a GUi. But how about converting it into a Tool?. Would you guide me to do it?

I would if I could.

The nature of tool scripts is that their output is immutable. Once a tool script has done it's job, nothing can be changed. You may create a wireframe with a tool script -- but you can't change it programmatically afterwards.

Object scripts can do that. They don't really "create" objects but they "describe" them. An object script says: "Put a sphere at this location and it shall have radius x." At any point in time, the user may change the value for "x" -- so we can animate them or make them dependant on other objects. But they will never have a proper GUI and they will never be equivalent to tool scripts. Hence, both types can't be converted into each other.

If you really need to combine the advantages of both tool scripts and object scripts, you need to make a plugin that defines a new object type. Just like the polymesh editor or the fluids plugin. Then, you can create a very nice GUI and programmatically change the objects at any time.

* The search function would allow users to put in keywords, and find whatever they were looking for
(The search panel would be dockable, so users could dock it when they are using it a lot)

Dockable searcher for scripts would be nice. It would be a editable combobox, right?
http://java.sun.com/docs/books/tutorial … bobox.html

The nature of tool scripts is that their output is immutable.

I meant a tool plugin. It would be the same than for tool scripts? Immutability? (there's already a lattice tool script, btw)

I think that having an object on scene, and pressing an icon in the tool bar, would generate the wireframe. Moving and posing the primitive object and pressing the tool again would generate another wireframe object. See, I'm thinking in terms of photos not in animations.

Double clicking the icon would let you set the thickness parameter. (And the texture from a list maybe?) It likes me this way because it's simple.

TroY: The picture about grouping did what i was thinking about. But i consider these tools should be in Object menu instead of there. The scripts are too far from the workflow (and other things are too, making the modeling process quite slow). I miss the mnemonics in AoI. More predefined keystrokes would make thinks flow. By example, one for opening the script panel. But the docks would make it better.

Is nice to speak about this.

Mayid.

Last edited by mayid (May 29, 2010, 8:28 am)