Torque 3D Community Edition Discussion Thread

#161 i vote for 2nd way.that is the standard way to add external libraries.

#162 Do you mean the whole resource? Sounds good! One thing before you commit - I'm just a Daniel Buckmaster, not the Daniel Buckmaster ;P. Did you set up Recast as a library, or is the source just included with the rest of the engine/gameplay code?

#163

Quote:Do you mean the whole resource? Sounds good!

Yes, the whole resource.

Quote:Did you set up Recast as a library, or is the source just included with the rest of the engine/gameplay code?

As all the code i add, is all included in a control of the compiler preprocessor. And with a #define, the relevant code is compiled or not, leaving intact the original code of the engine. For this case:

// Include the Daniel Buckmaster's Recast integration - http://www.garagegames.com/community/resource/view/21392 ->
#ifndef TORQUE_NAVMESH
#define VERTEX_BOUNDS_CHECK() AssertFatal( mCurVertIndex < mMaxVerts, "PrimBuilder encountered an out of bounds vertex! Break and debug!" );
#else
#define VERTEX_BOUNDS_CHECK() CheckVertexBounds()
#endif

#164 Good - I would have done that ;P. I meant to ask about where you put the recast library code. For example, the source code for Bullet is in lib/bullet, but in the Recast resource, the recast code is in source/T3D/nav/recast.

#165 Are inside the T3D folder

the module definition:

<?php
beginModule( 'navmesh' );

	addProjectDefine('TORQUE_NAVMESH');

	addEngineSrcDir( 'nav' );
	addEngineSrcDir( 'nav/recast' );

	addIncludePath( 'nav' );
	addEngineSrcDir( 'nav/recast' );

endModule();
?>

#166 Is it just me or are you including nav/recast twice?

#167 One question and status update:
Would it be feasible to create a diff of the CE project against stock 1.2? I know I can do diffs on entire directory structures using gnudiff.

Status on optimizing the TS VM:

1. I have converted all the opcodes to discrete functions.
2. I am currently testing the operation of the VM. I am stuck on a recursion issue with a recursive call in the game/main.cs. It won't stop recursing. I am thinking this is a stack issue of some sort or a variable storage issue.

#168 I have a request that might help the CE keep going strong and stay focused.

Please provide status of the things you are working on. It could be a simple update that you fixed 20 S32/U32 issues in one file. It could be an inclusion of a library. It could be an art file updated or TS file tweaked. The point is any progress will help build cohesion and excitement within the CE project.

I really like seeing the efforts going into the solution rebuild tools. I really have no clue as to how that stuff works so seeing it being improved and automated is a good thing from my perspective. I also like the effort in including the nav/recast work, the AI discussions, the Mac port efforts, the simplification of the templates, etc, etc, etc. This really gets me excited and makes me want to contribute to this excellent effort.

Also, not just the effort of including fixes, features, optimizations. I would also enjoy seeing where it is being used and what problems it is solving. That also gets me excited and wanting to contribute more.

Hopefully this perspective will help other people that might be sitting on the sidelines or are very focused somewhere else. Which is okay, sometimes the game doesn't look very exciting so it can be hard to stay excited. This request is to hopefully liven up the game a bit. So get out those jerseys and take the field if you can!

#169 I agree I can say I'll be using the CVE for my project: www.facebook.com/pages/Nightmare-Origins/363444293726737
I've submit an over-the-shoulder camera for a possible camera system in the future.

#170 @Kory,
Awesome, I may need that over the shoulder camera soon. Thanks.

#171 I agree with Mike, with one addendum: if you've fixed 20 U32/S32 issues in one file, commit it! Don't wait until you've fixed every single mismatch you can find to commit one massive changeset. I remember reading, and taking to heart, this rule: whenever you've made enough changes that you'd be irritated to lose them, commit! That would, by itself, generate more activity around the repository, and allow everyone else to see progress you're making.

EDIT: I've decided to accept Steve's terrain Y-axis import bug. From the comments on the trac ticket, it seems that some people do not regard this as a bug that needs fixing. We should probably come to some consensus on this :P.

EDIT: Okay, so it's fixed. Just pending everyone's approval!

#172

• If real life will quit being so busy I'll finish up the new Template and get it in place... most of the work for it had actually already been done within my own personal projects -- it's just a matter of culling out and minimizing less than necessary code. That and minimizing the impact of required source code edits for hardcoded filepaths. Right now that's at one required edit (which technically could be optional), and I was looking at 2-3 others. I went ahead and decided to accept the need for modifying filepaths within the tools... mostly GUI related.
• The terrain Y-axis import should definitely be modified to work like one would expect.
• When it comes to commiting, I tend to prefer goal-oriented commits, the "atomic commit" paradigm. Simply because it makes things far easier if you need to revert a specific set of changes. Fox example, modifying a bunch of physics related stuff and then sticking something unrelated, like sound, in the mix is something that should be frowned upon -- it's bad practice, don't do it! Now if anyone has the need of breaking a large commit into several pieces, that's ok but try to arrange the commits so that no one of them would break the build. I know that's not always possible so at least give fair warning.
• I think I'm missing something about the whole over-the-shoulder camera thing... isn't that as simple as placing your player shape's camera node at the wanted location and using the stock 3rd person camera?
• Last week Konrad gave me a list of problem locations in the code that he has found as a result of using code analyzers on his Xenocell project. When time permits he is still interested in moving his relevant fixes for these over to the CE. But for the time being there are other eyes on these issues.

#173 @Mike, I not for sure if the over-the-shoulder camera work that way. I was never successful at achieving it in a stock 1.2 (maybe someone has). I had the work done by a programmer and this code involves engine changes. At least, adding to the existing codebase. Similar to old fluid camera resource in TGE and TGEA.

#174 Do we have any guidelines for commenting engine changes? Would be good if we could standardise things.

#175 Usually, i comment the code with:

// CHANGE DESCRIPTION - FORUM URL IF EXIST ->

....

// <- CHANGE DESCRIPTION

And if possible, i always use the control of the pre-processor to choose to use the new code or not.

So, i set the definition for the pre-processor in the configuration file of the project ( AS HERE ):

addProjectDefine( 'AS_OPTIMIZATIONS_STAGE1' );

and in the source the check ( AS HERE ):

#ifndef AS_OPTIMIZATIONS_STAGE1 
	   if( index < 0 || index >= object->size() ) 
	#else 
	   if( index >= object->size() ) 
	#endif

#176 OK, good, I'll follow your lead.

#177 Usually the only time I'll comment a specific change is if it's a block of code. I personally find the "begin code change here" and the "end code change here" tags that some people love so much to be annoying, and cluttering, especially for 1-2 line edits. We're using version control, which has diff capability, and we all should have file comparison programs... so I'm not going to get bogged down in the triviality of a commenting paradigm just to say "hey, I changed something here!!"

The use of per project defines I do like and encourage as it allows a greater degree of flexibility and control of new code usage.

EDIT: with that said, I'll not oppose any individual's desire to mark every single one-line edit if they desire....

#178 Is the same as what i wrote.

begin:

// .. ->

ende:

// <- ..

With a search, can u find all changes.

The use of comments in a project such as the CE, where the base code has been written by others, in my opinion is essential. Especially when you take the code from the forum. It is important to have information about the changes made​​. the use of tools for the versioning (diff, path, winmerge and others) is great, but in these cases is much faster to have the comments with references to the original post on the forum where you can find many more details.

#179 Easier if only the comment tags are consistently used by everyone. Which I guess is technically the point of Guy's question. However, I had asked you well over a month ago about the nomenclature of CE specific comment tags, and your reply was to not worry about it.... so I haven't ;)

#180 Well it sure, nobody is obliged to follow any method. I just exposed my method :)