I have been thinking very hard about how to make it so the developers can be as lazy as possible, and the answer is compartmentalized encapsulated tools.
have ‘tips’ and have ‘effectors’
picking a ‘tip’ parents a tool to the cursor, left clicking while aiming at the viewport activates the script contained inside the tool tip,
aiming at a effector and clicking instantly triggers the code inside the effector, be it to manipulate a selection set, or effect a global change etc.
tips and effectors both have properties that are linked to how the tool operates, (brush scale, opacity ?? anything)
then the whole ui can be objects, nested in folders, that can be collapsed or expanded.
ALL commands use python to call C/C++ code, this way the C/C++ functions can be used by the community to produce unintended new tools.
people think python is slow, but they don’t understand a script is not supposed to do the hard work, a scripts design is to pass information to fast compiled native code.
So if the developers created functionality that allowed them to be more productive, you would rather they become lazier instead!?
Following your advice in that case would only ensure that Blender never catches up to the big commercial applications (because you don’t see that happening with commercial app. development).
Is this the reason why Wrectified is not printing money for you yet (so as to hire developers to work on the BGE), because you’re busy creating systems with the intent to do less and less on a daily basis?
the idea is to encapsulate user interaction in a flexible reuasable api, that you keep adding functions to as you need them. This way since the interaction is socketed, you can interact with a new tool without adding any code to support it.
I did the same thing in my wrectifed code container,
and I remade wrectified from scratch, using everything I learned from chaos emergency and past work in a few hours.
you can watch the tutorial series if you want, its 11 parts.
python merely passes data sets and parameters to the C++ code assosiated with the called functions,
Could it be just bad word choice on your end then, because it doesn’t make sense to me that a lazy person would actually be more productive in a development environment than someone who is really focused on the same task (that is assuming that both people have access to the same components and architectures).
Also, one thing I haven’t brought up, just because something works for you in the BGE doesn’t mean it will no doubt work for a program like Blender itself. You keep mentioning how you want to replace Blender proper UI with a hack involving screen-aligned planes with textures, I get the idea that you propose things like that because you don’t seem to have much knowledge as to how development works outside of making BGE games (for instance, the reason why BGE users use planes and 3D objects for a UI is because of the engine’s complete lack of a proper 2D drawing system).
the work plane, is to be used as a desk, that can retract into a 2d dimensional drawer, the idea is to place 3d tools in collapsible ui, that is customizable,
touching the drawer icon, slides the drawer out / workplane full of tool tips and effectors.
this way adding a new tool, means placing a tip in a drawer,
tips have attriubes that are exposed when selecting them for tips, and when mousing over for effectors.
When I read the original non-edited messages here I immediately thought that this is definitely how being at the initial crest of the Dunning-Kruger line must look like.
As Hjalti said in his talk “the joys of animation”, when you are in this condition you should try to be a bit humble. When you make claims that you can “code X in a few hours”, you make people, who apparently cannot do the same look like fools. Then those people can simply say “OK, teach us master”. Then after a month you have nothing and it’s you who looks like a fool. Bad for you. Don’t do this.
Generally the complexity in coding is usually not about the idea. It’s about the scaffolding required to place that idea in the software - and the complexities that pop up from this procedure.
@BPR : You are free to do what you like (writing continuously on the same subject) but for your expectations to bear fruit I tell this sincerely. Instead of writing about it go and learn C, and execute your ideas.
You seem a capable person, with couple of books and experimentation I’m sure you can over come obstacles. Just writing about it or creating ideas won’t produce results anytime soon. There are a lot of resources available now, libraries, game engines, physics engines, just try it. Besides people will be more responsive when you actually build something and ask their help.
You seem to have no problem boasting about your BGE, skills and how you can (almost literally) do anything in a few hours. Surely you have the ability to learn and use the general API without the need for others to hold your hand (since it’s the exact same language with the only difference being what they operate on).
Besides, it will be liberating for you since you can actually turn your ideas into proof-of-concept addons for others to use (which will show just how your ideas are able to work in practice).
I need guidence, I need to chat with someone while I code for a bit, also, the systems I built allow ANYONE to add content fast, it’s not about how good I code, it’s the backbones I have made*
about the mentor -
it’s like landing in a new world, where people live their already.
I could explore the world until I know it, until I find a bathroom…
or I could ask someone where the bathroom is.
also, I know the ‘tips’ idea works, because I already use it in wrectified*
The only thing though is that Wrectified is not a general purpose 3D program, it’s not a general productivity app. You know very well that you’re making it as a game and all of the systems within are designed specifically for the way it is meant to be played. Wrectified does not have modeling tools, Wrectified does not do rendering, Wrectified does not create textures, shaders, armatures, and UVmaps.
Another point is that you can’t say that your Wrectified concepts will definitely work when used in other contexts such as what I mentioned above. I can tell from your posts that you haven’t really exposed yourself to how programming and workflow concepts work outside of the BGE and outside of your own game, the issue is that the BGE way seems to be only way you have really known when it comes to programming and productivity in the 3D space (and the BGE way is neither the only way nor the best way).
objects = user placeable icons, chosen with 2d mouse(UI) , or 3d mouse in 3d space.
in wrectified, you can hold ctrl to bring open a proper UI (inventory) and mouse cursor,
when a code container is in idle, it’s not running any python.
you could setup a system to run a code container for X frames, etc, but it requires a triggering system that runs on BPY.
I will try and make an example, but any mentoring would be handy.
(the idea basically makes icons that are links to python scripts unifying the ui and the function) you could add a new icon, add code to it, and place it into a collapsable UI drawer, targeting a tool and clicking changes the mouse icon to something ideal for that tool, and displays tool properties/attributes in a collapsable menu system with user defined hierarchies.)
you could choose how much complexity to expose, but not limit it either.
edit: check out Moguri’s python component architecture
Check out the templates included with the text editor.
Check out the BPY API
Check out the blender stack exchange
Check out http://blenderscripting.blogspot.com
There are arguably more resources available for BPY coding than there are for BGE coding. Trust me, if you could figure out how to code for the BGE it will be much easier to learn to code for BPY.