TorqueLab - Revamped Torque3D editor (under development)

  • 1
  • 6
  • 7
  • 8
  • 9
  • 10
92 posts Page 9 of 10
Duion
Posts: 813
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Fri Jan 08, 2016 8:39 pm
Sounds like a better approach. You could start with the regular editor and add each feature individually, then test, if it works, add the next etc this way you ensure everything is working and makes it easier to find bugs, since there is a clear commit for each feature.
I would help testing, especially the environment settings sound interesting, since at the moment I save each weather situation as a new mission file.
JeffR
Steering Committee
Steering Committee
Posts: 750
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jan 11, 2016 4:49 pm
If you're going to be stepping back and approaching the work with a Lite version based on the current editor, it may be a good time to present something I'd been working on as you may have a use for it there.

Basically, rather than needing separate, full, custom gui controls for each editor, we'd approach it from the single world editor that then enables a tool class that intercepts the inputs to operate.

https://github.com/Areloch/Torque3D/tree/BrushEditorToolTesting

So, for example, rather than needing a guiRoadToolEditorCtrl, which acts as a total replacement of the world editor, including replication of all the base editor functionality, you'd have RoadTool like the BrushTool as i've got it in that branch. When active, the world editor continues to operate exactly as usual, but the tool intercepts the input calls and can also render it's own stuff on top of the world editor view.

This keeps the tool code a lot more minimalist and minimizes how much crap can break when trying to switch tools around. Figure you may have some use with it with all your editor work, so I thought I'd mention it ;)

Keep up the excellent work dude!
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Mon Jan 11, 2016 9:37 pm
JeffR wrote:Basically, rather than needing separate, full, custom gui controls for each editor, we'd approach it from the single world editor that then enables a tool class that intercepts the inputs to operate.

This is exactly what I was starting to think about last week (If I understand your suggestion well). So, for example, if you select a DecalRoad object in the scene tree, the DecalRoadEditor would be activated directly and you could edit the road layout without changing editors. Is it what you meant?

About the whole TorqueLab thing, while working on it I have learn a lot of thing about how the editor work and if I was starting again today with what I know, I would have work on it differently. I still enjoy my TorqueLab editor very much for my personnal use but it's not developped much with a public approach, I'm simply adding stuff as I find some needs for my current works. So, I don't think I will just stop working on TorqueLab and move on a "lite" version, I think instead I would just contribute to the existing editor with a GIT branch that people could add/remove simply. I would use TorqueLab work as reference to enhance that branch while trying to keep current editor scripting standard.

That way, I will get back my full freedom on TorqueLab and might start extending it further as I was planning for the after public release phase. My goal is a bit to create something similar than Unity and make it more like a project manager from which you can "edit" multiple projects at same time. Anyway, I'm just saying it quickly and It's not something that would be done in a close future but I would start thinking/experimenting in that direction. If someone have suggestion about how such thing could be done, I'd like to hear about it. Currently, the way I think it could be done is to simply make a project that work with T3D code which would be simply a project manager without any game specific stuff...
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Tue Jan 12, 2016 1:26 am
I started working on a setup for the stock editor enhancements and I'm having some problem with it because the stock editor is not very independant from the game scripts. It cause problem if you change some stuff from the template. For example, if your Hud isn't called PlayGui, the editor won't go back to your Hud when closing because it can't find the PlayGui object.

So now, I'm wondering if the community would prefer a that I make the Lite version completly independant or stick with the the current setup. I'm not talking about making a complete rewritting of the system like TorqueLab but simply fix the things that make it dependant of template scripts. This would make no difference for user using stock templates but it would make it work fine for any kind of project structure or object naming. Ex: For the PlayGui issue, I have simply added a variable that remember what Gui was the Canvas content when launched and when the Editor closing is called, it set back the initial Gui active on launch.

So, would you guys prefer an updated editor which is completly independant? If so, I could simply fix the dependance issue I found and maybe it could be added to the official templates (if accepted for sure). And then, I would start adding some TorqueLab features and the DarkGui.

Also, in TorqueLab, I use a lot of my custom helpers function, some of them are very usefull and could help making my Lite TorqueLab port better. Are you okay with it if I used some of them which would be bundled in the tools scripts. I started considering it when found back about the multiple exec() calls needed in the editor script and I tought about using my simple execPattern function which exec() all files that match a pattern.

Here's an example of how it work.
My helper function:

Code: Select all

/// execPattern -- Execute all files found that match a specified pattern
/// %pattern - Pattern for the files to be execed
function execPattern(%pattern) {
   //call exec() on all files found matching the pattern
   for(%file = findFirstFile(%pattern); %file !$= ""; %file = findNextFile(%pattern)) {
      exec( %file );
   }      
}

By using it, this:

Code: Select all

 // Load Scripts.
   exec("./scripts/menus.ed.cs");
   exec("./scripts/menuHandlers.ed.cs");
   exec("./scripts/editor.ed.cs");
   exec("./scripts/editor.bind.ed.cs");
   exec("./scripts/undoManager.ed.cs");
   exec("./scripts/lighting.ed.cs");
   exec("./scripts/EditorGui.ed.cs");
   exec("./scripts/editorPrefs.ed.cs");
   exec("./scripts/editorRender.ed.cs");
   exec("./scripts/editorPlugin.ed.cs");
   exec("./scripts/EditorChooseLevelGui.ed.cs");
   exec("./scripts/visibilityLayer.ed.cs");
   exec("./scripts/cameraBookmarks.ed.cs");
   exec("./scripts/ManageSFXParametersWindow.ed.cs");
   exec("./scripts/AddFMODProjectDlg.ed.cs");
   exec("./scripts/SelectObjectsWindow.ed.cs");
   

Become:

Code: Select all

 execPattern("tools/worldEditor/scripts/*.ed.cs");

--------------------------------------------------------------------
I'm just trying to define a line into how much I should borrow from TorqueLab and since I want to make it great for the community, I'd like to have your opinion about that "line".
JeffR
Steering Committee
Steering Committee
Posts: 750
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Jan 12, 2016 7:22 am
Yeah, that's basically what I was looking at for the EditorTools.

You never leave the world editor(short of something COMPLETELY different, like the shapeEditor), and just do a WorldEditor.setActiveTool(myNewTool);

This makes myNewTool intercept the input events(mouse down, mouse up, input key, etc) and piggybacks the render event. The tools can even be set to filter what inputs they'll intercept. So you could leave the RMB to control the editor camera, for example.

Because of the way it's set up, it'd be easy to implement simplistic tools in pure script, if you wanted. You could easily rig up a simple object painter tool purely in script with this because the intercepted inputs trigger script callbacks.

It'd also go a long way to solve the weirdness that people have encountered with stuff breaking/overlapping when switching between editors, because there'd be fewer moving parts.

As for separating the editor out to be independent, I'm either way. Both integrated and independent have their pros and cons.
It'd be an interesting experiment to rig up a very lightweight editor(just the world editor, for example) as independent to try it out, and if it seems like it'd be workable, it could have all the other stuff layered over top.

Also, I love utility scripts :)
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Tue Jan 12, 2016 7:41 am
JeffR wrote:Yeah, that's basically what I was looking at for the EditorTools.

I still haven't examined what is the EditorTools... It sound like an interesting approach, I will try to learn more about it tomorrow.
JeffR wrote:As for separating the editor out to be independent, I'm either way. Both integrated and independent have their pros and cons.
It'd be an interesting experiment to rig up a very lightweight editor(just the world editor, for example) as independent to try it out, and if it seems like it'd be workable, it could have all the other stuff layered over top.

I like the very lightweight editor experiments idea. I played a bit today with the current editor and I think a "rewritting" might be a good idea. It reminded me why I started changing a lot of the structure when I started working on TorqueLab:
    It's very hard to find function you are looking for. Most functions are all mixep up in a long script file.
    It's almost impossible to modify the main EditorGui GUI without doing it all by hand...
    There's a lot of unused scripts


I think a fresh start using the system you are talking about might be the best idea on long term, making the editor flexible and modular. TorqueLab became a script monster mostly because I tried to keep most of originals editor scripts intact so it's easy to update when a tool from the stock editor get updated... Anyway, thanks for your inputs, I'm still thinking about what should be that "lite" ports of TorqueLab.
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Tue Jan 12, 2016 10:39 pm
So I took some time to think about the latest discussion and I think I will forget about the "Lite" version of TorqueLab running on current editor. It's to much work to figure how to update the stock editor without modifying a lot.
Instead, I will start working on a completly new editor from scratch but I will do it step by step so there's always a stable/bug free release for testing. I will work on it based on Jeff suggestions and see how it goes. For sure, once the basic features are implemented and stable, I will consider adding some feature borrowed from TorqueLab.
About TorqueLab, yesterday, I played a lot with it and realized it's quite stable and a stable public version could be done without much works. I would simply remove the "Under Development" features and keep those on a development branch that anyone would be able to try at their own risk... About the documentation, I will try to work on something for the features that needs a documentation. Most of basic feature works like they do in stock editor so no need to explain. I will simply document what need instruction to use, for example,the AmbientGroup system I added, it would need some instruction about how to add the game scripts in your game files.
I will try to get a fresh release on GitHub for Thursday but no guarantee about 100% bugfree yet...
JeffR
Steering Committee
Steering Committee
Posts: 750
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Wed Jan 13, 2016 1:57 am
Sounds like an interesting idea!

If you're starting from scratch, then it may be worth you looking into the proceduralized UI I was messing around with a few months back, in this branch: https://github.com/Areloch/Torque3D/tree/NodeGraphUIs

Specifically, the gui/controls/guiMainEditorCtrl files.

If you don't remember, it was the one that was set up like this:

http://ghc-games.com/public/hmm.png
http://ghc-games.com/public/hmm2.png
http://ghc-games.com/public/hmm3.png
http://ghc-games.com/public/hmm4.png
http://ghc-games.com/public/hmm5.png

It was intended to have the flexible docking/floating windows that more modern editors use for their interface. The window/docking stuff is procedural, but you'd nest regular gui controls inside them as needed, was the plan.

Not an obligation, but may be useful. Feel free to grab it, poke it, and/or ask questions about it. I'd be glad to help :)
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Wed Jan 13, 2016 3:13 am
JeffR wrote:If you're starting from scratch, then it may be worth you looking into the proceduralized UI I was messing around with a few months back, in this branch: https://github.com/Areloch/Torque3D/tree/NodeGraphUIs

Specifically, the gui/controls/guiMainEditorCtrl files.

If you don't remember, it was the one that was set up like this:

http://ghc-games.com/public/hmm.png
http://ghc-games.com/public/hmm2.png
http://ghc-games.com/public/hmm3.png
http://ghc-games.com/public/hmm4.png
http://ghc-games.com/public/hmm5.png

It was intended to have the flexible docking/floating windows that more modern editors use for their interface. The window/docking stuff is procedural, but you'd nest regular gui controls inside them as needed, was the plan.

Not an obligation, but may be useful. Feel free to grab it, poke it, and/or ask questions about it. I'd be glad to help :)

Yeah I remember about those, It's hard to forgot when they are still present in my TestGui but without the code. Get some nice red console errors. 8-)

I will give it another try but last time, I couldn't figured how they work... Can you explain briefly how to setup those Gui Controls together?
That's another area that I'd like to contribute, enhancing the GuiControls. I already use some basic enhanced Gui for my personnal project and I should clean them up and share it with others. I guess I could also submit PullRequest for the basic enhancements that I'm confident about (Some have a newbie coding style...) but I don't know how to do PullRequest professionaly, is there a tutorial/guide about it somewhere?

Also, I'm not sure about what your NodeGraph GUI works, do you have an example video of a tools that use similar Gui than what you have in mind?
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Wed Jan 13, 2016 3:30 am
Just found the Pull Request Guide on the torque3D website: http://torque3d.org/contribute/#pull-request-guide
  • 1
  • 6
  • 7
  • 8
  • 9
  • 10
92 posts Page 9 of 10

Who is online

Users browsing this forum: No registered users and 1 guest