[Azaezel]

And how much polish is required ?
What functionalities you think need to be polished ?

Well, folks seemed rather enamored of the notion of making classes a bit more flexible, judging by the responses to the component system proposal, so there's one.
For me, the big one once the platform agonstic and general tech update ends are considered as-given would be per-map editing. Little things, like having visually oriented tools for linking triggers to lights, or object animations and the like would speed things up for mappers. Looking forward to where @ Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

[Chelaru]

And how much polish is required ?
What functionalities you think need to be polished ?

Well, folks seemed rather enamored of the notion of making classes a bit more flexible, judging by the responses to the component system proposal, so there's one.
For me, the big one once the platform agonstic and general tech update ends are considered as-given would be per-map editing. Little things, like having visually oriented tools for linking triggers to lights, or object animations and the like would speed things up for mappers. Looking forward to where @ Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

Yes, that editor seems nice. I wonder how is he doing ? He did not add any updates for a long time.


Would ArcaneFx be a part of the main line of t3d?

[Azaezel]

Would ArcaneFx be a part of the main line of t3d?

I know I'd like to see it make it in. Or at least the lions share. It's certainly something I incorporate for my own projects.

[Chelaru]

Would ArcaneFx be a part of the main line of t3d?

I know I'd like to see it make it in. Or at least the lions share. It's certainly something I incorporate for my own projects.

Why is so hard to do it? Is not like they changed so much in the core of the engine that is not possible to merge it .

[Azaezel]

Why is so hard to do it? Is not like they changed so much in the core of the engine that is not possible to merge it .

It's not a question of technological effort. In my case at least, it's one of respect. Till http://forums.torque3d.org/viewtopic.ph ... t=30#p1792 gets answered from the guy that busted his hump to make it, not comfortable making that call for him.

[Skipper]

Do we have a 3.8 release candidate ready for testing yet?

[Mud-H]

Looking forward to where @ Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

Yes, that editor seems nice. I wonder how is he doing ? He did not add any updates for a long time.

Thanks for your comments, I never expected to be mentioned in a T3D releases discussion thread
Sorry for the lacks of updates, I decided to cut on updates time and focus on making TorqueLab stable and clean. Also, I got back into game development and I keep updating TorqueLab to fit my game dev needs. I will try to make a new progress update soon.

It's getting quite stable and features completed (in reference of default T3D editor). What I need to do now is to cleanup and optimized my scripts. There's a lot of scripts in there...
So, since there's some interest, I will try to make a new update with reviewed installation process. Also, I started working on a pre-compiled demo using full template + UeberPack levels.

Since we are in a release discussion thread, you think some of the T3D code that cause issues with TorqueLab could be fixed? Mostly about the GuiSwatchButtonCtrl bad mGridBitmap integration which store the bitmap wrong on saving and make the engine crash on next loading. Here's a link to the code changes I made: https://github.com/NordikLab/Torque3D/c ... ead72c0633

Also I have some problem with the GuiMenuBar, I can't get SubMenu items to works with stock codes. Not sure if I miss a concept about it but I made a basic hack for now, but it still need more changes. I'm thinking about making a new GuiMenu class which would work more like the MenuBar code. (Is there a simple way to expose the MenuBar class to scripts? Not familiar with that stuff...). Here's the hack I did for now: https://github.com/NordikLab/Torque3D/c ... a28c277b30

[Azaezel]

... you think some of the T3D code that cause issues ... could be fixed?

Particularly if if you've got fixes you can PR for verification, the answer is almost always yes. (Assuming it's not a big clump of spiderwebbed mess touching 15 unrelated spots at once instead of targetting a specific issue to verify. They never seem to take those. Can't say I blame em either.)

[JeffR]

Looking forward to where @ Mud-H's project (http://forums.torque3d.org/viewtopic.php?t=266) ends up, for instance in that regard.

Yes, that editor seems nice. I wonder how is he doing ? He did not add any updates for a long time.

Thanks for your comments, I never expected to be mentioned in a T3D releases discussion thread
Sorry for the lacks of updates, I decided to cut on updates time and focus on making TorqueLab stable and clean. Also, I got back into game development and I keep updating TorqueLab to fit my game dev needs. I will try to make a new progress update soon.

It's getting quite stable and features completed (in reference of default T3D editor). What I need to do now is to cleanup and optimized my scripts. There's a lot of scripts in there...
So, since there's some interest, I will try to make a new update with reviewed installation process. Also, I started working on a pre-compiled demo using full template + UeberPack levels.

Since we are in a release discussion thread, you think some of the T3D code that cause issues with TorqueLab could be fixed? Mostly about the GuiSwatchButtonCtrl bad mGridBitmap integration which store the bitmap wrong on saving and make the engine crash on next loading. Here's a link to the code changes I made: https://github.com/NordikLab/Torque3D/c ... ead72c0633

Also I have some problem with the GuiMenuBar, I can't get SubMenu items to works with stock codes. Not sure if I miss a concept about it but I made a basic hack for now, but it still need more changes. I'm thinking about making a new GuiMenu class which would work more like the MenuBar code. (Is there a simple way to expose the MenuBar class to scripts? Not familiar with that stuff...). Here's the hack I did for now: https://github.com/NordikLab/Torque3D/c ... a28c277b30

You do good work, so I'm all for fixing stuff you're having problems with

But yeah, if you have an issue with something, then by all means, put up an issue on github if it's not already there, or mention it here on the forums. A problem no one knows exists can't be fixed

Like Az pointed out, if you've got contributions or fixes or whatnot, they'll definitely be considered, and if you form the PR yourself with a fix, it's even easier to check and integrate. Looks like you've got a decent start with those changes already.

While several of us do a lot of the work, we definitely can't do everything, so If you think what you've got in those changes is good enough to integrate into stock, or CLOSE, but needs a bit more work*(you called the submenu changes a hack, for example), I'd say make them a PR and just notate if you think they need a bit of feedback/tweaking/discussion before integration.

It's a good way to prevent the issues from being lost, and it's easier to iterate and test to move it from 'hack' to 'ready to roll in'