Mud-H wrote: Azaezel wrote:
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'