Torque 3D Community Edition Discussion Thread

#121 EDIT: Hmm. Post got eaten then regurgitated.

#122 Mac port also sounds fantastic tome - being able to reach more people is always good, especially considering how popular Macs are becoming. But unfortunately, I don't have a Mac either, otherwise I'd be all over this!

I like the idea of a new script project. I actually tend to use the Empty project whenever I'm starting something new - it's so nice to have a project that's 30 megabytes instead of 500! (Once you remove all the massive, redundant skies from the core folder, that is.)

Speaking of branches: should not every major addition or change have its own branch? I thought that was somewhat standard practise when you're making changes that require more than one commit, or have a chance of preventing people from compiling.

EDIT: Kory, would you be able to edit the URLs for Trac and SVN into the first post? Every time I go to find them on a different browser I need to trawl through the Achilles thread :P.

EDIT: It's probably a good idea for people to set up some sort of communication between SVN and trac. Makes the trac project much more interesting when you can link commits to issues and have them appear on the issue page itself.

#123 Alfio would have to decide if we're to have a R&D or testing branch since it's his storage and bandwidth we would be using. It is a good idea, and would likely see more action from those worried about dirtying up the trunk.

@Kory: Daniel brings up a good point about editing your first to post to include the URLs for the trac & svn location, as well as a link for the activation thread -- I think I might have missed a few requests that are scattered around, oops.

#124

Quote:a R&D or testing branch

What I meant was more like branching for each new change. For example, I want to start integrating the Recast resource - I make a branch, commit the base resource, make some changes, integrate it with other peoples' changes, then, if people are happy with the way the branch has turned out, merge it back into the trunk and kill the branch.

IIRC, branching doesn't really use extra storage space, since a branch just starts with a reference to an existing commit. All you're storing in the branch is deltas on top of that, like with regular commits.

#125 Ah, well I never actually use branches much. I'll make changes to my working copy and then commit those after testing and verification. Seems to avoid a tedious step or two that way :)

I say go for it, you've got write access.

#126 True enough. I personally tend to just maintain huge branches for entirely separate features, and merge them all into a trunk as I make updates to make sure they play nicely together. But with a branch, you can make smaller commits more often and not worry about treading on peoples' toes. Though you do then have to merge :P.

Just checked out the entire T3DCE, and realised I can't create any VS solutions. I can create a new project, but when I hit 'edit C++ source' in the Toolbox, I get a popup saying there are no solutions, would I like to create them? I hit yes, and get another popup saying projects were successfully generated. But they weren't.

Doesn't happen in a stock 1.2 install in a near-identical directory. Anyone else run into this? Windows 7 Home Premium, 32 bit.

#127 I recall some employee mentioning issues with multiple installations of T3D when trying to use the Toolbox. I only ever use the Toolbox for initial generation of a new project directory (just because it takes the tediousness out of copy/paste/rename) and use the generateProjects.bat file for the VS solution and project files. I haven't had any issues that way.

#128 Ah. It's not finding the PhysX SDK. Weird that the stock 1.2 install didn't seem to have that problem.

Semi-relatedly: how do we go about adding files to the engine in such a way that they'll appear when someone creates a new project? For example, the Recast resource requires a ton of extra files, especially the Recast library files. These will just go in the Engine/source/whatever directory, but how do we ensure they show up in someone's MyProjectDLL VS project when they create a new project with the toolkit?

#129 You can setup modules (.inc files) for the project Generator, which basically is a list of directories, and modify the project's project.conf to include the new modules. Then regenerate the projects.

The generateProjects.bat batch file is your friend, and should be used when you update from the repo and notice that new files are added to the source... otherwise you have to do it all manually in VS.

#130 Finally i'm back, after a bit of vacation i return on my projects.

I wanted to clarify some basic concepts behind the CE initiative. The CE was not born to have a new engine with new features. It 'was born from the discussion started on this forum, and its goal is to improve the functionality already built into the engine.

I personally do not accept requests for new functionality that has not been developed by myself or by others. So you do not ask new camera systems, or implementation of DirectX 11, etc. etc..

If during my work, will develop something that i think might be useful to the engine, it will share willingly.

#131

Quote:goal is to improve the functionality already built into the engine.

+5 for that.t3d need more optimization rather than any new functionality.without optimizing current code and bug fix,new feature could make it a terrible beast that can be hard to control.
so instead of asking new functionality u all can give some time to improve current functionality.

MAN HAVE UNLIMITED WANTS AND NEEDS
so keep it simple.and work(or pray) for that.no matter if it is small or big.

#132 I understand what you mean, but at the same time I feel it'd be rather remiss to ignore some of the other discussions and ideas.
From what I'd seen most of the 'new features' emphasize workflow and development efficiency. While I like the idea of the primary development being optimization of the engine code, I think another perfectly valid idea(as long as it's handled reasonably) is to optimize the actual usability of the engine as well.

I don't think it's sensible to just cram new features and ideas into the engine, no. But I do think it's worth looking into about improving workflow or efficiency in actually USING all that fancy new optimized code.

#133 after thinking some more,it seems there is only 2 active working person in CE.
alfio and michael.
they are giving large amount of time into it.and other memebers are giving only what they can afford.so may be more discussion on new request could be a problem for those two.only they have to answer and deal with those present and feature request.
may be i am wrong but that is what i think is happening there.
not much active response considering total tickets.

#134 Well, I'd planned on posting up stuff for the tickets I made pertaining to updates to the player code. I don't know that I have write access to the svn, so I was just going to attach the files on the ticket and let it be integrated in. If people working on this is part of the problem, I'd be willing to implement those changes myself if there are no complaints.

#135 Remember that there is always the resources section for sharing new or improved functionality.

#136 Just got my Mac setup again on OS X Lion, with latest updates, newest version of xcode, etc. So I can probably attempt a merge with the community edition over the next week, make sure everything works on both windows and mac before I do a commit.

@Michael Perry: How would I be able to download it? Would it be a svn/git repo? zip archive? etc? Whats the rough file size of the resulting file? What other components would I need to download and install to get it compiling under OS X (other than xcode and its tools, and possibly the physx sdk)?

#137 @steven, that's great news! Everyone else, I agree with the improving functionality, and as mentioned there should still be room for adding of new features and what not, if developed in a way that won't break the engine. If the CEV is just for code changes and bug fixing, then what is the difference in what the community is doing now?
I really hate using other engines but other engines are really exploding with new features. In my opinion T3D is still in their league but quickly falling behind with some outdated stuff. If those issues can be addressed along with the bug fixing and improving.
The particle system currently in the CEV is a new feature. It would also fall into an improvement too. My point was it was done in a way that would not break the current codebase.
Some of the things I suggested aren't just for one game or any specific genre. They are things I honestly feel would help with the process of creating games in torque. Rather than turning to a 3rd party plug-in (no offensive to anyone). Unity exploded a little after 3.0 was released and if i remember right they had a summer were the community created alot of resources, and enhancements. T3D in my opinion is a much easier and better engine. If we come together and do both the bug fixing and adding of the new features, what the engine would become.

#138 @Steven - It's all inclusive, so you shouldn't need anything else other than Xcode. I can either send you a single zip file or put in a request to give you git access. Which would you prefer? It is basically a full copy of T3D repo, so a couple of gigs.

#139 @Kory,
The issue is not the new features themselves. The issue is new features are being requested without code input from the people making the requests. At least that is how I am seeing this issue.

If you want a new feature, and implement that feature, there will be no resistance to it being considered for inclusion in the head. Until it plays nicely with the engine it should be in a branch.

Another item to consider is the engine does need to have a more solid foundation. One issue U32 vs S32 is just one example of an issue that has been lingering for a long time. It seems harmless on the surface, but over time issues creep in and it breaks the engine. That is why there is such a focus on rooting out fundamental issues like this. This needs to be done, now.

To help you understand the primary issue here is an example of what I think the founders of CE want to see. I have asked for one feature/improvement. So I submitted a ticket and I have taken ownership of that ticket. I am (hopefully) optimizing a piece of the Torque Script virtual machine (VM). I don't expect anyone else to write this code for me. That is what the community edition is looking for. Find something either in the existing tickets that needs fixed, or find something that you think you can improve. It can be code, artwork, script, directory structure, a bug fix, etc.

Once we get the CE to a point where the majority of the issues we can find are resolved then we can consider more broad feature inclusions. So bear with the process and get involved. Focusing on this initial task is important. If everyone shotguns and fragments efforts, nothing will be accomplished.

#140 @Frank, I agree. That's why I never said let's focus on one thing versus the other. I know having a solid codebase is he first and fore most the most important thing. If I were a stronger programmer, I would be all over it but I'm not so I can only give suggestions. Give me a basic task and I can do it.
Btw, I start the ticket for the ai, camera, and etc because it was brought up in the forum and I though I'd start one. It's open for anyone to add to. Granted there should be a full discussion before any of those are added. That way whatever is developed would be something most people would be happy with. Well the issues that were bought up in the Achilles thread, I hope are being addressed or the whole point of the CEV would for nothing. So far the work being done is great!