Tempate cleanup

[Bloodknight]

Extra files not needed or that overwrite cmake created files.

main.cs overwrites the created one and renames the 'appname' to full if thats the template you use

the cleanup files delete*. are replaced completely by a single cleanup file by the cmake process.

It is also reasonable to assume that with the removal of DX9 nobody will be using the older project generator and older solution files and should be using cmake anyway, this makes the buildfiles folder redundant also.

[ghost]

Why delete the cleanup command files?

[Bloodknight]

Because they are included in a cleanup.bat file that is created by the cmake process. It could be argued that separate cleanup areas are useful but by the same token, it could be argued that the single cleanup file could be modified to create branching paths and command line arguments.
There are more than a couple of ways this could go, I selected one that kept the newer system in place removing the older and potentially superfluous files.

[rextimmy]

I have to say it is kinda handy having the individual ones because ya don't have to fluff about in the command line to say pass in an argument to only clear shader cache etc. Either which way if we run with the cmake generated cleanup.bat (which is from cleanup-win.bat.in) we need a linux/MacOS command equivalent.

[ghost]

I never used any cleanup command file, I just delete the cached shaders folder manually before release and maybe the tools settings.xml thats all I need, but I can see the potential use of individual cleanup files, since you only need certain functions most of the time.
I do not like any of those files created automatically in the game folder, since then you have to cleanup the cleanup files for release as well. So I would just put the isolated cleanup scripts in the projects root folder like it is now.

[ghost]

Also some people may still use project generator I have heard of at least one case from the forum.

[rextimmy]

The old project manager is no longer maintained or supported and hasn't been for some time. It doesn't have support for any of the latest IDE's, doesn't have support for numerous modules. CMake is the only build system that is maintained.

[Shockwave-X769]

Not having a project manager and to rely on CMake only gotta be one of the worst mistakes when it comes to user friendliness. Now surely you got to be aware of how engines like Unity and Unreal 4 has project managers that makes it easy for new comers to click and use the engine right away right? The old Torque 3D Project manager , which I have used with T3D version 3.51 a lot is such a user friendly tool that made it easy for new users to start using and testing T3D. CMake is NOT such a tool and it WILL alienate T3D for all new users. I agree that a project manager should be kept around in order to keep T3D MIT user friendly.

[rextimmy]

@Dwarf-King are you volunteering to maintain the project manager?

[Bloodknight]

Project manager simplicity was to some extent its greatest downfall, to gain simplicity it lost flexibility.
Comparing torque to commercial engines that have at the very least dozens of highly paid developers is also at least slightly disingenuous.
The project manager has also been pretty useless since 3.6, the sheer complexity of the project needs for the engine as it is now would make the manager would make it look pretty much like cmake even if it was fully maintained.

[rextimmy]

It should also be noted that the project manager gui https://github.com/GarageGames/Torque3D-ProjectManager can be modified to call cmake instead of the old project manager backend, the end user wouldn't even know the difference.

[Shockwave-X769]

Got to redo as I used another GitHub account called webTechFreak I had set up... Lol :P

Well my comment was meant as a way to make you understand that IF you wish to get more users of the engine THEN you should make it a lot more easy for people to start the tool up and work with. Hence the project manager was such a tool that DID that. Not that CMake is not a good idea. CMake is a fine tool. If it comes to the situation where people point out a mistake(or what they find to be a mistake) ends up with standard comment "are YOU gonna implement that?" answer I see no reason to provide any suggestions in the future. If I had the time I would fix that Project Manager myself but I am totally running out of time. In fact I should not even be writing in here right now as time is very precious in these days. However, I value this community and the people in here so I write this to make it clear that I am not attacking anyone with my comment. I just try to point out that making a tool more widely used is all about making it more easy to start out with.

I wish you all a good day :)

[Azaezel]

Having used both, I really have to ask... What exactly is complex about cmake that wasn't about the project manager? Wasn't the setup, because I well remember the dependencies breaking on the PM. Wasn't the module setup, because if anything we're at a point that it requires fewer lines to pop in a custom directory or library... Is it frontend presentation? If so, then yeah, I could see, as has been suggested a few times, giving that frontend paintjob. Just brings us back to 'Ok, who has time for that at present'? That is a genuine, non-sarcastic question. Does anyone actually want to step up to the plate on that that isn't going to end up tacking it on to their own mile-long todo lists? If not, then the answer there'll have to remain 'when there's time for it'.

[ghost]

I would suggest in keeping pull requests smaller and not add multiple things into one, so you can more quickly merge the non problematic ones and even if someone wants a feature back he can still undo that certaub PR.

[crabmusket]

Hi folks :). Some history: I did try maintaining and continuing the Project Manager GUI in a previous version. It's written in Qt and not very easy to dev on. I had intended to actually port the whole thing to Torque - since, uh, graphical applications are what Torque is FOR. Thanks to TorqueScript it would be faster and more accessible than modifying the Qt project every time. The idea fell by the wayside when I didn't have time. If anyone really wanted to Make The Project Manager Great Again, I think that'd be the easiest route to doing so.

mile-long todo lists

That was always the problem 😓

[rextimmy]

I did start converting the project manager gui over to cmake at the start of the year, i got it working with QT 5.x branch, modified the projects.xml file to suit the way cmake uses modules, got it compiling on windows,linux and macOS and was about 80% complete but got distracted with real life stuff and haven't gone back to it. Reading some peoples attitudes, not really sure i have enthusiasm to continue it.

[Areloch]

@Dwarf-King You're correct in that having a cleaner frontend like what the Project Manager provided is good, especially for non coder types who may get themselves confused about what all the options mean.

That said, it's been the plan for a while to try and have an updated project manager that wrappers around cmake(because in terms of generation, cmake is far easier to deal with).

As @crabmusket and @rextimmy mention, there've been a few passes at it, so the plan is still there, it's just that cmake works well enough for the moment while core updates to the engine itself are happening, and when we get more on towards the release, supporting elements like a clean and fancy project manager that'll look nice for the non-coders would become more and more the focus.

It's not that no one wants a nice UI wrapper, but that it's not a major priority right now because cmake works for the actual meat, and the core engine progress is where most of the effort should be focused right now.

If you had the opportunity to contribute time to help get a new/updated project manager rolling, no one would complain, for sure. For now though, we're focusing on the core. I get it's a personal bug bear to you especially, but I just wanted to make it clear that it's not an issue of 'whether anyone wants it' and more of a 'prioritization of tasks' issue.

On topic, now: @Bloodknight Yeah, I was kinda surprised to see the individual cleanups removed. I get what you're saying about having the all-in-one to avoid redundancy though. As you said, a few ways we could go about it... so I guess do we keep it cleaner by having one file? Or do we keep 'em separate so you don't have to fuss with command line?

Also, as @rextimmy mentioned, if we went with the cleanup.bat, we'd need linux/mac versions as well(though that could easily be a different PR to get those rolled in).

I'm pretty 50/50 on which way to go with it. Does anyone else have a particular preference one way or the other?