Jump to content

TorqueLab - Revamped Torque3D editor (under development)


Mud-H

Recommended Posts

  • Replies 91
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I'm planning to do a few changes on the Torque editor myself, but this looks great Mud-H! Keep it up :)

 

Thanks for your good words! Always appreciated.



Also, I have been thinking about my never ending TorqueLab project and I think it could be a good idea to make a Lite version by simply adding TorqueLab major features to the Stock Editor with fewest modifications possible. I would port the Dark UI and also some features to the stock editor so the community can use them. I think it would be much more simple than working on a full features TorqueLab release.

TorqueLab also became more than a simple editor and have some features that work in relation with the game scripts which make it even harder to make a release. For example, last month I created an Ambient Group Manager which allow to store different environment objects settings into a file beside the mission files, then you can quickly change ambient in your level( SunnyDay, CloudyDay, RainyDay, Dawn, Night,etc). But most of the scripts is outside TorqueLab as it need to be accessible from the game itself...


Let me know what you think about the TorqueLab Lite which would simply be the stock editor with some enhancements borrowed from my TorqueLab project. My plan would be to start with the UI and the SideBar component(FileBrowser, the VIS Settings and the Creator(which might be removed since mostly same as Stock Editor Creator). It's mostly what I was planning at start but I was facing many issue that make it hard to tweak the Stock editor but now that I know everything about it, I know some workaround to adapt it.


I will start investigating the idea today and you are welcome to list some feature from TorqueLab you'd like to see in the Lite version.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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:

/// 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:

 // 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:

 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".

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 3 weeks later...
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

I did some experiments with your BrushEditorTool and I'm not sure how it's meant to be used... If I understand it right, it's not meant to do anything as is it now, right? It's just the base for a better editor system but the existing tools need to be adapted, right?

So this would allow to call existing tools function from within a single WorldEditorGui instead of having to switch the EditorGui just so it can receive the brush call. It sound like a good idea but I would need more informations about how they should be use before I can do anything with it. Anyway, I don't want to put pressure on you about that, I just want to clarify how the BrushTool should be used.

I'm currently giving another development rush on TorqueLab and tought it might be used to unify the MeshRoadEditor and DecalRoadEditor. I will work on something by simply switch the EditorGui depending of what type of road is selected and later I might just switch to the BrushTool once I figured how it work.

Link to comment
Share on other sites

  • 7 months later...
  • 2 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...