Torque 3D Community Edition Discussion Thread

#141 @Michael, zip file sounds good (along with the MD5 sum of the resulting file if possible), I can throw it up onto my download manager overnight to get it. (the reason for the MD5 sum is simply so the download manager knows it's got the right file once its finished downloading.).

My email is steven@rearmed.org if you need it.

#142 @Kory,
Do you have an aptitude for programming? Do you want to get better? Then read on.

I have learned the most by diving in and doing. I guarantee that if you dive into and try to make sense of the tickets you started you will learn a lot. When I program I end up trying to find out exactly what I want to accomplish. Then I look at existing code and start trying to understand what is going on with the code. From there I use Google constantly to determine ways to approach the code and find information on syntax.

By doing the above I have learned a ton about programming in general. I also have found Stack Overflow and the sister sites to be a wealth of programming knowledge. 9 out of 10 when I do a Google search I end up at Stack Overflow. This is how I learned to extend Python with T3D. At times it was painful as the examples could not always answer the questions I had. But I stuck with it. Now I have a very robust interface to Python from T3D.

It may be hard at first, but 2 to 3 months down the road you will look back and be amazed at where you were and where you are then. Then imagine what will happen in 2 to 3 years! You could very well be an expert on C++ and on T3D!

So if you are game, then the basic task it to go forth and pick a ticket and figure it out. That is how the rest of us do it. We just might have been doing it longer. ;)

#143 @Frank, love the honesty. If I wasn't working on so many different projects I would take your advice. I guess the next time I have some free time and whatever feature or enhancement that hasn't been added that I feel T3D needs then I try my hand at it.
I guess if there is a feature I need bad enough then I can always have it freelanced.

#144 See, I agree that we shouldn't just be making tickets for others to implement.
My 2 tickets(dealing with player class stuff) I made firstly to discuss if anyone else thinks they'd be worthwhile to implement(since there's another ticket about a forums that it was decided the ticket system would work just as well for this purpose) before I go dumping files around or making whatever changes.

Perhaps there should be a new ticket type, 'Idea' or 'Discussion', which aren't(at least at the time of creation) intended to be treated as an actual implementation task, but a point of discussion for if the idea is worth implementing, or how to implement it. Once a concensus is more or less reached, the type can be edited to an actual task ticket, or a new one can be opened up for the task itself.

#145 .

#146 I understand the main task is improvements to the existing codebase, but what about resources that have been implemented and proven to work with the code like the Recast NAVmesh? I know T3D hasn't had AI but that resource is the best free resource that adds AI. Plus anyone can make uses of the AI. Maybe someone else would be willing to create a editor or some thing. Just an idea, but I honestly feel adding it would help.

#147

Quote:I wanted to clarify some basic concepts behind the CE initiative. The CE was not born to have a new engine with new features.

I was waiting for you to weigh in, Alfio! So, to clarify: you're not against adding new features to the CE, but you'd like people to be implementing features themselves, rather than just requesting them?

#148 @ Daniel, If that is the case then maybe there should be an special area to get to get those feature from. So the CEV doesn't get bum bared with request for new features and what not.
I guess my understand for the CEV was wrong. The community (pre CEV) I thought was bug fixing, and improving functionality. I figured the CEV would do all the above and adding of new features (just as long as it didn't break the current codebase), maybe I'm wrong!
So I wouldn't see anything wrong with opening up a ticket, so the feature or whatever can be discussed. Maybe, within the discussion it may can out that majority of the people would want to keep the current feature but maybe expand on the current codebase.
That what I thought the CEV purpose was, if requesting features is a major problem then I can always freelance what I need; can't do or don't have the time to implement myself.
When suggesting feature/opening tickets I request things I think everyone could benefit from, and leave it open for discussion. That way it can be discussed and something everyone would be happy with would be the result. If my intent is wrong let me know and I can close the tickets. I just thought I'd get conversation started, I figured if I wouldn't have maybe no one else would have.

#149 I've had no time to give to Torque this week, but I have paid attention to the discussion(s) going on here.

Anything already implemented, or any existing feature, is welcome to be improved upon as improvement is the overall purpose of the CE. Improvement means bug-fixing, enhancement, and additional usability features (in general this would be Tools). New usability features should not be game or genre specific.

There have been some Resource requests that have been made that go about doing something that Torque already does, but in a slightly different manner and in some cases with little to no actual improvement. This type of request will not see any action from me other than discussion. Not because I oppose the resource or request, but because I would rather see the stock implementation of feature X be improved upon, than to duplicate existing functionality under a different name.

A Resource request that adds to or improves upon any of the Tools, features, etc., can be approved after consideration of it's impact, usefulness, and possibility of improvement - which is where these types of discussions can be quite useful so that the best person for the task can be found.

I'll be adding a new ticket type, Discussion, after leaving here. The purpose of Discussion should be self-evident and will have the lowest priority. This ticket type can then be upgraded. Requests that have not been closed after a period of time are open to those willing to take ownership of it.

AI is one of those shady areas of the engine that not everyone will be able to reach a consensus upon. The Recast implementation has already proven to be one of the better navigation Resources available, and I see it being worth including -- as I think Daniel is planning to do -- since navigation is something everyone can use with little to no alteration of the basic implementation. However, thinking and game logic for bots should not be included into the CE as those are very game-specific and would only have to be stripped out if we tried to include a generic implementation of AI thought as an example.

It looks like Steven Saric is going to be the go-to guy for the Mac port. I also saw that Bank has a working Linux port, but is troubled by an issue with Bullet in regards to it. So it looks like the CE may be adding the "multiplatform" back into Torque :)

#150 @Kory: there is nothing wrong with making the Requests or Tickets. Some may see action upon, others may not. After discussion someone may actually say "hey I can work on that and make it better!", and this I would rather see than a copy/paste inclusion of any Resource.

Discussion is definitely worth having as it may give some direction to more long-range goals. It's only been about a month, so we are still in the early days of the CE as of yet.

#151

Quote:I also saw that Bank has a working Linux port, but is troubled by an issue with Bullet in regards to it. So it looks like the CE may be adding the "multiplatform" back into Torque :)

after starting to learn t3d,that sounds most sweetest things to me.i always have craziness for multiplatform support.and i was planning to work for that.but i am still too far away to have that kind of working ability.
a working port will be a grate help to learn it and to improve it more.
i will eagerly wait for that.thanks bank and others who have worked on it.

#152 Might seem strange for me to request this, but I would like to join. I might be able to help and me being involved might facilitate things in the future.

Note: Ah...just found this thread for requesting access:
http://www.garagegames.com/community/forums/viewthread/130717

#153 @Michael, the discussion ticket is a great idea. I have one question though, regarding the AI. Would giving the option for the developer to create different brain types, similar to guidebot and GMK by considered game or genre specific?

#154 @Eric: not strange at all. Would love to have some input if you think we might be doing something wrong.

@Kory: I'm not familiar with the workings of either of those, but in my mind a "brain" would control all logic and reactions of ai objects that subscribed to the brain, so therefor the logic would be game specific. Even if you tried to create a generic FPS bot behavior there would be too many possible parameters if we tried to cover all of the bases, some of which would be unsuitable for all FPS games.

#155 My opinion on how any sort of AI work would be to add any legitimately generic additional functionality(bigfixes, adding something like recast), and then setting up a simple brain object hook.
This would let you set up all the gameplay-specific logic in the brain, which the AI player object would defer to for whatever brain it's assigned. This keeps the core AI code clean and lightweight, and defers any gameplay-specific stuff to whatever you add into the brain.
Anything past that is probably getting too specific.

#156 Okay, so I'm finally getting around to implementing the recast resource. Question: would people prefer I do it the way the resource does it - by adding all the Recast source files to T3D/nav/recast - or should I go the full-on external library route, using a librecast.conf file and adding the source to Engine/lib/recast? I ask because the first is easier, but the second strikes me as better design. I just don't know how to do it ;P.

#157 @ Daniel
And what happens when you want to add, edit, fix, update the *.conf file with the second method?

#158 @Jeff, You described what I've been trying to say. To have a brain hook. To set up the behaviors and what not. A developer can create other behaviors (bots) with different action if they want to add to their own build/projects. That way it wouldn't be game specific it would just be a basic AI.

@Daniel, I'm glad you are adding this. I would say go with the easier one but if the second one will make things look cleaner than go for it.

#159 Steve: Not sure I follow you. The second method would require maintaining the *.inc and *.conf files, you're right, but comparable changes would need to be made to similar files in any case, so that the project generator knows about the recast code and additional files.

#160 Daniel, i have already the changes ready to. If you like, i do commit and then you make the changes if something goes wrong or needs to be changed. I always use the module system of the projectGenerator.

On my project.conf:

// --------------------------------------------------------------
	// Include the Daniel Buckmaster's Recast integration
	// http://www.garagegames.com/community/resource/view/21392
	// --------------------------------------------------------------
	includeModule( 'navmesh' );