Ideas culled from Cyan's Plugin

[The.Modificator]

I agree with D'Lanor. Even though AlcScript is far from perfect, easy, well-documented, or user-friendly it is quite usable once you understood how it works. Having to rely on a GUI without alternatives scares me off a bit.

What do you think about a new XML based script language that could replace AlcScript? I can think of some advantages for something like this:

• Easy-to-use end-user GUI plugins could be created quite simply
  Some yet-to-be-created PyPRP2 plugin GUIs could parse, modify and write back the script code which would enable a modeller to make easily use of the functions provided by that GUI.
  
  
• Hard-core users could still modify the inner workings
  Not all Plasma features can (and should) be made alterable through GUIs IMO.* Relying on some human-readable form of code could make it possible for the "programmers" forum section to do what they can do best.
  
  
• Seperation of GUI from Plasma and Blender functions
  To ensure that the PyPRP2 code stays easy to maintain, this would be one approach to seperate the various parts of PyPRP2. What I'm also thinking about is a work flow like this: One developer adds new features to the script code. Another devloper then turns these features into some GUI elements later on. Advantage: The new features can already be used even though there is no GUI yet.
  
  
• Other external tools could be made possible
  Having already read about some problems with the Blender GUI API it might be possible that some Blender-external editors could deal with some tasks better than Blender-internal GUIs. Using some custom script language (instead of relying on Blender's inner structure) would make sense here. And especially XML would be a good choice in this case as there would be no need for yet another Plasma-specific library/toolkit/whatever. XML can be parsed and modified by pretty much every modern programming language.
  
  
• PRC files also use XML
  Since PRC files also use some XML format, it should be pretty simple to "import" PRC objects into an XML-based script language if necessary.
  
  
• Converting AlcScript to the new format should be easier
  Even though I don't consider this point as being one of the higher priority ones, I'm pretty sure that converting AlcScript to a new language would be easier than converting it to some internal Blender structures.

I won't fight for XML specifically (actually I detest most incarnations of it a lot), but on the other hand the GUI-only approach would scare me off mainly for two reasons:
From a plug-in programmer's perspective, I'd have to create a GUI for every feature I implement... and let's put it this way: I hate GUI programming.
From an age designer's perspective, I really like the current seperation of "what it looks like" as in 3D models etc. from "how it behaves like" as in detectors or responders.


It's after 2am here and I'm pretty tired, so I hope this stuff makes at least some sense.


Cheers,
The.Modificator


* I think, Cyan would be on my side here... *cough*unleash satan function*cough*

[Lontahv]

I know what you're saying about GUIs. A good text interface is much better than a bad GUI, however, Alcscript is a bad scripting language. It doesn't exactly line up with the way Plasma does things (so those who know Plasma's ways don't already know how to use it), it gets grumpy about tabs/spaces, and it has odd things like "-" indents and " " indents. XML a better language but it has many problems, for instance, having to type "<" and ">" about ten zillion times to do anything interesting.

I think, Cyan would be on my side here... *cough*unleash satan function*cough*

I'm not sure everyone (who was) at Cyan would be. Of course the hard-core engine coders would say they want C code and the logic scripters would want Python code, but what about the artists? Since we don't have a production pipeline for most projects here, usually the artist has to do some coding (which is many times like mixing water with oil).

Also, from what I've seen from the plugin most of everything is in a GUI (even things that are strange to have graphical).

We could include a small PRC pane in the plugin so you're able to use every feature of libHSPlasma even if it doesn't have a GUI or you don't want to use the GUI.

[I.Brattin]

I wouldn't mind a GUI. It might have simplified my problems with the linking book/journal issues I am having with Chamassa, instead of D'Lanor having to search through an elf log to see what alcscript or python code I messed up.

[Tayrtahn]

We could include a small PRC pane in the plugin so you're able to use every feature of libHSPlasma even if it doesn't have a GUI or you don't want to use the GUI.

As in, we could edit the PRC XML stuff right there in Blender? 'Cause that would be totally awesome!


As for linking objects together, would it be too horribly hacky to loop through all of the objects and make a (terrifyingly huge) dropdown list or such of the relevant ones?

[Lontahv]

As for linking objects together, would it be too horribly hacky to loop through all of the objects and make a (terrifyingly huge) dropdown list or such of the relevant ones?

Take a look at how the new Blender (2.5) does references. It'd either be a system like that or the name of the object.

[Trylon]

I agree with D'Lanor. Even though AlcScript is far from perfect, easy, well-documented, or user-friendly it is quite usable once you understood how it works. Having to rely on a GUI without alternatives scares me off a bit.

What do you think about a new XML based script language that could replace AlcScript? I can think of some advantages for something like this:

Actually, alcscript isn't too different from XML after interpretation in PyPRP. . YAML was chosen for alcscript instead of XML, because it's easier to read and write than XML. You don't have to write all those start and and brackets for example.
Most of the things you thought of can be done with current alcscript just as well.

Your idea of separatge GUIs that modify the scripts are actually pretty sound by the way.
My main problem with Alcscript is that it is in a central file, whereas object-specific scripts should be stored with the object. Right now, alcscripted properties don't copy with the object.

Perhaps with Blender 2.5/2.6 we'll be able to fix that, or do it a lot better

[diafero]

I really like the idea of PyPRP2 in it's core only knowing some yet-to-be-chosen scripting language, and the GUI being an independent project (or at least an independent set of files). It reminds me of how Unix works - small powerful CLI tools doing one task, and doing it well, with the GUI being a separate project using either the external binary or a library for the actual functionality.

I agree that XML is a pain to type, but while alcscript is much more readable, the indents problems are a pain to debug. Basically you have to post a screenshot or send the blend file to someone to be sure that the one trying to help you can check indents. I would prefer some CSS-like syntax, but more cascading (so sub-blocks are possible), a language which is both easy to type and read and white-space agnostic (yes, I do hate how Python uses white-spaces for block nesting )

[Tayrtahn]

I hear you on the whitespace issue - it looks messy, it's hard to share, and it restricts formatting style. I definitely prefer the commonly-used curly-brace { } method of denoting blocks.

It would also be nice if we could avoid requiring users to install multiple Python libraries. Though I suppose we'd still need YAML support for back-compatibility.

[diafero]

Backwards compatibility will affect much more modules than just alcscript. The transition from 1.5 to 1.6 already required a lot of planning and some wizards, but from talking with some age builders I got the impression that it worked really well. But for this re-write, that's a totally different story.
However, instead of leaving YAML as requirement and supporting alcscript like forever, an alternative would be for the new plugin to no longer understand alcsript, but a wizard (requiring YAML only if that wizard is run) converting alcscript to whatever new system stores the settings. The same of course also applies to all other settings and setups that could be changed in a way breaking backwards compatibility - each time, one has to decide whether the new plugin works the same way as the old one, or whether it's better to break compatibility to get a sane code base, and provide some way to convert.

[The.Modificator]

I think, Cyan would be on my side here... *cough*unleash satan function*cough*

I'm not sure everyone (who was) at Cyan would be. Of course the hard-core engine coders would say they want C code and the logic scripters would want Python code, but what about the artists? Since we don't have a production pipeline for most projects here, usually the artist has to do some coding (which is many times like mixing water with oil).

I totally agree. I'm definitely not against a well thought-out GUI... but I'd like to have an alternative too. I think, having both a GUI *and* the possibility to do the same (or even more) things in code would make life easier for everyone: The artists can prepare everthing they can in the GUI and the programmers could take over from that point and implement the rest of the coding.

We could include a small PRC pane in the plugin so you're able to use every feature of libHSPlasma even if it doesn't have a GUI or you don't want to use the GUI.

Well - this on the other hand would be like having to write an Office application suite in assembler. The script language I'm thinking about should be able to simplify common tasks for age writers (like creating a pushable button which then triggers some animation). Having to code something like this in PRC only would be very time-consuming and hardly maintainable.

Most of the things you thought of can be done with current alcscript just as well.

Yes, my point was that relying on a GUI-only approach would make most things on my list a lot more difficult, if not impossible.

My main problem with Alcscript is that it is in a central file, whereas object-specific scripts should be stored with the object. Right now, alcscripted properties don't copy with the object.

That is true. While writing this, some solutions came to my mind:

Alternative 1: Associate code with objects, i.e. the code for an object would be stored in a custom Blender object attribute. Advantage: Code can be duplicated when the object is duplicated (though this could also be a disadvantage in some cases). Disadvantage: Object referencing is harder to control. (When having to reference another object in code it wouldn't make much sense to use the name of the object that should be referenced... objects can be renamed or deleted - and having to find a reference to such an object in every single object source code can become a big pain I think.)

Alternative 2: Give objects an own name for the code, i.e. the code will still be stored at some central file but when refering to objects in the code, only the code name can be used. Advantage: When duplicating an object the code name will be duplicated as well, allowing some way of attribute duplication in script. BIG disadvantage: This works ONLY for attributes (responders and modifiers would make the whole thing go crash otherwise) and is not very flexible (if you want to duplicate an object and change only some properties in the duplicated version, you'd end up having rename the object and to copy the code for that object once again).

Alternative 3: Still store the code seperated from the objects but introduce Blender GUI hook functions. Example: when the user tells Blender to duplicate an object, the hook would be called which would then ask the user if he/she wants to copy some Plasma-related properties as well. This could be a selection like "physics", "rendering", "modifiers" etc. where the user could select the property groups he/she wants to have copied as well. The plug-in would then copy the relevant parts of the underlying Plasma-related code. Another hook could be created for renaming objects (I'm thinking about a dialog like "Do you want to update all existing Plasma references to this object as well?").

It reminds me of how Unix works - small powerful CLI tools doing one task, and doing it well, with the GUI being a separate project using either the external binary or a library for the actual functionality.

That's pretty much what I'm thinking about. I would be one of the persons who would put their focus mainly on the PyPRP-equivalent of the CLI tools - the script language.

I would prefer some CSS-like syntax, but more cascading (so sub-blocks are possible), a language which is both easy to type and read and white-space agnostic (yes, I do hate how Python uses white-spaces for block nesting )

What do you think about JSON?

However, instead of leaving YAML as requirement and supporting alcscript like forever, an alternative would be for the new plugin to no longer understand alcsript, but a wizard (requiring YAML only if that wizard is run) converting alcscript to whatever new system stores the settings.

I'm completely on your side with this.



Just to make sure you don't get me wrong: I'm definitely not against a GUI. The fear I have about writing a plug-in that integrates very tightly with Blender without offering any alternatives is just that it might scare off developers who only want to work at one specific part of PyPRP2. (Take me as an example: I don't like working with GUIs, I've never worked with the Blender Python API before, but I worked with PRP-related stuff *a lot* - and I'd really like to contribute there. However, having to get to used with the other two things would not fit into my time schedule.)



Cheers,

The.Modificator