How do you handle console logs?

#1 The best way IMHO to increase sales of TGE and family would be to focus on the art pipeline and get that thing fixed, Constructor would be a great first step, and Show Tool Pro is good as well, however both need to be included in the basic TGE package as part of the default art pipeline, I know I would have been willing to pay 2x the price for TGE if it had at least those tools.

Also settling on a default dev environment would be an excellent idea, eclipse is now almost to the point that it could serve that purpose, it's multiplatform and works well, TBE is a VITAL first step, and should be made multiplatform so it runs the same on Windoze, Mac and Linux.

Better support for Linux would be a nice extra +, when I first tried to get Torque to run on Linux, it took quite awhile and I had to switch distros 4 times before I got the kind of framerate I wanted, now admittedly this is also because I choose to use the notorious ATI 9200 SE Video Card, and some other wierd combinations of hardware, but it was a pain nonetheless.

If I were GG and I wanted to increase sales, here is what I would do and the order in which I would do it.

#1 Fix the art pipeline, perfect the Blender Exporter and possibly write a Blender Importer, then include Blender,Torque Constructor and ShowTool Pro as part of the standard Torque Package.

#2 Fix TBE so it works the same across all supported platforms, there is really no reason not to include the TBE as part of the TGE package, also include #1 as part of the same package.

#3 Come up with a standard set of docs that is regularly maintained, by the community (look at blenders docs for an example of what I mean).

#4 Give us more models, especially player models, salvage some of them from Realm Wars, and make some up on your own. Also more interiors and static shapes. A sampling of melee weapons and a standardized and functional melee system. This way we have more than JUST the crossbow.

#5 Give us access to things like the default player skeleton (the one the orc uses), in ALL of the supported modeling tools, for instance, there is currently no way for me to know what bones are in the Orc model when using blender, since Blender is the ONLY modeling environment that behaves the same on all platforms, I have no desire to use any other tool, even though I DO own most of them.

#6 Change the license for all new purchasers, TGE w/o source should be free and should simply be the Demo with some tools added as per #1 & #2. Then charge the commercial license fee for the source code.

#7 Increase the price of a TGE source code license to around $900, honestly when looking at the current TGE at the time I purchased it, I thought that you must be trying to oversell it because NO ONE sells what you sell, for that cheap. The current price, gives the user a perception of cheapness, and honestly if a person isn't willing to shell out $800-900 for the engine source code, then they really aren't ready to make the type of game that would require the source code.

If I were GG thats what I would feel to be nessecary to boost sales.

On another note...

Seriously, fix the DEMOs all of them, to remove errors about things that are not there, and won't be back such as the error from the above post, and all of it's many cousins.

I honestly get sick of reading those things, and they are a bugger to track down.

On the other hand, no one looking at the demo, is aware of the console, I know I wasn't aware we even had a console until 2 or 3 months after I bought and I hit the wrong key (Yes I AM an IDIOT).

#2 @Dreamer
Is this a mispost or what does this have to do with reducing console spam?

#3 Read the first post, yes it appears that they want to reduce console spam, but the reason for doing it is they are afraid it is costing them sales, ergo I took the opportunity to tell them, what I believe may actually be costing them sales and spent the majority of the post pontificating on what I believe are ways to increase sales.

So my post is really more of a mixed bag. :)

*edit* NM it's a mispost all except the last couple of lines anyways, thats what I get for responding w/o coffee.

#4 As I mentioned in the original thread, I do think that the demos out of the box should not have -any- errors or warnings. The demo's should not have models/requirements that are going to generate warnings, but I fully admit that this is a "nicety"--the demos work and accomplish what they should. It is but a refinement to the demos to get rid of the "console spam" that DD talks about in this specific case.

Now, on to the warnings themselves: It has been mentioned in other threads (and Ben Garney's .plans) that the console reporting system would benefit greatly from having a 'warning level' capability, where you could filter out warnings based on what warning level is assigned, and what is selected in your console filter. This can be implemented by the end users (and in many cases, has been for large, long term projects), but the console itself would benefit greatly from this type of capability.

Now as to how my project personally deals with warnings:

1) Theoretically, we don't allow environments that generate warnings into fully tested internal milestones. Note, I said theoretically...in many cases, the warnings that are generated for the stock code base don't necessarily apply for works in progress (a lot of the "missing stock animation xxx for model yyy" for example, if you don't use stock animations), and we may not have taken the time to get rid of the warnings for these special cases. Also, some of the warnings we leave in place if there are plans in the future to finish an implementation--in this case, the warnings are very important to make sure that everyone is aware in our project of the current status.

2) I am a firm believer that if a warning (not just console, but compiler as well) winds up being "ignored" for a long period of time, it's purpose is worthless...I'm not saying that the warnings should be not generated in the first place--I'm saying that developers should never have "acceptable warnings" in a publically released scenario--as a matter of both robust code, and technical pride, all warnings should be handled, period. A warning system is simply worthless in the long run if you allow things to slip by. In the electronic security field those are called "false positives", and they are the bane of any customer that uses a security monitor--and they are a bane for TGE developers as well.

I do understand all the work involved to "fix" these warnings, both in source code and the console--and I also understand that it's not a very high priority when compared to new tech, fixing "actual" bugs, etc. But I stand by the belief that removing them is important on it's own.

EDIT: With regards to the "spam" aspect, I do think that the specific "missing texture" messages need to be reworked...as Ben mentioned in the previous thread, these are at multiple scope levels and is the "best we can do with the current console logger", and I accept that, but it's something that could be handled much better!

#5 @DD: Just keep in mind that in the big picture, we are probably in the minority when it comes to this belief (why, I'm honestly not sure!)--many developers in many different platforms look at warnings as "you can turn them off if you don't like them!"...compilers even let you do this as a setting.

My personal belief is that if the compiler complains about it, it should be fixed, but not everyone feels this way.

#6 I have to agree with Stephen on this one

#7 So, who's going to make sure all the floating point constants in TGE are suffixed with f so we don't get the double to float truncations warnings anymore ? ;)

Being a little facetious, but I do like to use a higher level of warning than what TGE is set for by default, if not outright treat warnings from a compiler and linker as errors...
Some of those warnings can sometimes be really be the source of nasty, hard to find bugs :)

Definitely in the camp of warnings as errors camp myself

#8 @Nicolas: One of my team's dev's...that's who!

Seriously, he finally took the reigns and started "clamping" (pun intended) down on all of the type conversion warnings and other problems in stock, and it is -really- nice! Can't wait until we get the rest of them nailed down.

#9 I think having the warnings, etc in the demos is a little ridiculous myself. My first thought upon reading them all was "if the guys who sell the engine can't even use it well, how am I supposed to?"

Obviously I bought TGE anyway, glad I did, and I just went ahead and didn't even use the starter.fps or starter.racing codebases. I took common, went through every file and gutted what I wanted, then build a whole new codebase up that has no warnings or errors unless I'm testing something new. I don't like warnings, script OR C++. First thing I will think of a supposedly stable codebase that throws warnings is that the programmers are lazy or incompetant. :)

#10 I would say Ben's authority is based on his being the Torque Technology Director...in other words: the guy who's job it is to make that decision.

#11 Experience with the code base, which is only gained by actually researching each and every warning, and understanding why it is being generated.

From my personal perspective, the only valid reason to accept a console warning as being "benign" is because you, as a developer, know it is benign...and that's because you have researched it completely, and can explain why it is being generated, and what it would take to fix it.

#12 But if they understand what it would take to fix them, why not just do it?
That way it'd be easier for people like me to spot when I made a boo boo and an error/warning suddenly shows up. Right now compiling the engine I get so many errors/warnings I don't even bother to read them.. I just execute the thing and see if it runs instead. Which is NOT good quality control imho...

#13 Becomes bugs and new features come with priorities and levels of criticality, and GG only has so many devs they can put against not only bugs/feature enhancements, but new tech as well.

And when it comes down to it, the source code is in your hands--if you don't like the console reporting, go make it the way you like it!

And to re-iterate, warnings are just that--warnings. Even if they come as part of the demo out of the box, you should still go in and find out why they are being generated, and learn to resolve them--because you will see even the ones that are in the stock demo in your own projects, and if you don't fix them then you'll be shooting yourself in the foot in the long run!

#14

Quote:As far as model sanity checking, do you feel that it would be better to distinguish between errors and warnings more distinctly within the engine?

...yes, as an artist primarily; I utilize the tools available[sorry, I'm not yet capable of 'just doin' it myself'], and if those tools are producing content that will grind the engine to a halt; heck yes, I'd like to know a lot more about what is and what isn't 'stable' art for the engine provided 'out of box'. For example, my collision meshes; when generated thru GameSpace and Dark Industries exporter, produce a warning about a non-existant texture, since I applied none to the object in the modeling package[ahem, it's afterall a collison mesh]. Now I understand this may be more of an issue with the pipeline, rather than a fault of the engine; but if the engine can't/won't tell me about it, I'm rather lost, aren't I? And conversely; if a non-existant texture hunt is a non-issue, I'd also like to know about it, more...ahem, or have a way to stop the engine from a futile search.

Quote:Should the export process be provided hints about what sort of use a model will be put to, and do sanity checking there?

...yes, would probably clean the process up and might even decrease flow of FAQ's to the website...?

Quote:Or should "bad" models cause an assert, forcing them to be fixed?

...yes, well[if quote2= false], with at least some direct failure pointers, for example the default crossbow's ammoClip warning about the collision mesh, which when I view the shape in Max; clearly looks like to me the collsion mesh exceeds the bounds in the lower corners. I just went back and recompiled the shape in GameSpace to produce a nice replacement, except for my 'unnamed' texture on the collsion. I'll probably nail it today with Milkfarm. In ShowToolPRO, the collsion's Node orientation also appears to be outside the meshes boundries. It's these things that are definitely a 'needed' feature, if a non-programming artist is utilizing the product, and professionals alike, I imagine.

Quote:Do you think a more complex interface to console logs would be useful? For instance, providing means to filter the visible error/status messages?

...not necessarilily 'complex' but perhaps a Gui that delt with collecting them all in one place and allowed a means of analysing the trends[that would be more complex than the current Console.gui!...not sure, since I'm not up on how important the output line to console should follow the bugtracking, ie...if you don't know where it failed is that important??

...my few thoughts.

#15 @Stephen, are you able to release a patch with the type conversion warnings damped?

#16 @kenneth: It's a possibility we may submit it to GG, but honestly it's only being done for our project, and tested within our project--there is enough possible logic modifications that a full testing of all of the starter kits would be needed, and I don't think anyone has TAP setup to do automated regression testing (yet!), so this would be an issue...

#17 While on the subject of annoying warnings, can you put newlines at the ends of files? gcc spews a warning when the newline is missing, and I'm sure other tools are less than happy about that.

#18 Another warning is "taking address of temporary". This typically happens when an API returns an object (not a pointer or reference) and the result is immediately passed to an API that takes a pointer or reference. The risk is that the receiving API might cache the pointer inside an object or static variable for later use. I'm not sure if the base GG code has this issue; I just looked into it today with my project's code to try to understand the basis for the warning.

Here's a typical example, from engine/game/player.cc:

alxSourceMatrixF(mWaterBreathHandle, &getTransform(), &getVelocity());

In this case the usage is safe, but the compiler can't know that without analyzing the called function.