Play nice rules with products.
by foribiteu · in Torque 3D Professional · 03/09/2012 (10:17 am) · 9 replies
Like most people I have bought a lot of packages for Torque3d. The first one I installed was the AFX package. Cool I thought this is going to be easy. Then I went to install the UAISK and everything broke. Then they came out with a quick install that would make both of them work with out issues. Now lets fast forward a few months down the road and we decided to install MACK and FACK, with AFX and UAISK. O BOY what fun, once more every thing broke. This got me thinking, I am also planning on installing more packs after this, and I understand that GG has little control over 3rd parties plugins but it would be nice if they had some sort of play nice standards that if a package met these standards GG would give them may be an approved buy GG for T3 logo, so as a client when we bought them we would know when we installed them our code would not come crashing down on our heads, unless it was our fault.
This could also go for models, so when we loaded them in game we would know that they would be facing the right way, not holding the gun back words, had all the texture files.
Even go one step farther and standardize the install of these models and packages. So we know that the models will all ways be in format X, and we take this folder and drop it here, and had these few lines of code in this file. I know I know what your going to say, too many people want to do X, Y and Z with our product that there is no way to stream line it that way. How ever as a user and I decide that I am going to move all the modles to another directory for example, at least I know that when I get something new that had the Approved by GG logo that I would know what to expect.
I also understand that this would take time, work and testing but I for one would be willing to pay a little extra knowing that when I got the product that I would not have to spend hours trying to figure out what they did and how to import it in to my project.
What I was wondering is how many other users would like to see this? Also if GG considered doing something like this?
This could also go for models, so when we loaded them in game we would know that they would be facing the right way, not holding the gun back words, had all the texture files.
Even go one step farther and standardize the install of these models and packages. So we know that the models will all ways be in format X, and we take this folder and drop it here, and had these few lines of code in this file. I know I know what your going to say, too many people want to do X, Y and Z with our product that there is no way to stream line it that way. How ever as a user and I decide that I am going to move all the modles to another directory for example, at least I know that when I get something new that had the Approved by GG logo that I would know what to expect.
I also understand that this would take time, work and testing but I for one would be willing to pay a little extra knowing that when I got the product that I would not have to spend hours trying to figure out what they did and how to import it in to my project.
What I was wondering is how many other users would like to see this? Also if GG considered doing something like this?
About the author
This is our current game -> tectuma.com
#2
03/09/2012 (12:33 pm)
When we evaluate a product for the store it's tested against a clean stock install of the engine it's for. Unfortunately we just don't have the resources for anything more than that currently. 
#3
With such one, we could all have improved upon it through time and it could by now have been a very usefull 'Engine Expansion Thome'.
Instead it have been pro's and selftaught indies shooting from the hip, without any directional suggestions as to make a seamless expeerience.
So, how about makeing such one?
03/09/2012 (1:41 pm)
One thing that could have been done ages ago, could have been a 'code convention' that people could have been leaning against.With such one, we could all have improved upon it through time and it could by now have been a very usefull 'Engine Expansion Thome'.
Instead it have been pro's and selftaught indies shooting from the hip, without any directional suggestions as to make a seamless expeerience.
So, how about makeing such one?
#4
But it is a great idea.
03/09/2012 (2:02 pm)
That is definitely not a bad idea. It would require that all of the existing codebase be converted to it since there have been a lot of code styles implemented over the years.But it is a great idea.
#5
I am assuming that that GG has access to the 3rd party apps in its store. Take a look for yourself, most of the installs are: 1) drop folder here, 2) bunch of files here you go hope you know what to do with them fyi you may need files from other folders in the pack good luck finding them all, 3) here is a show case program with your art pack dig it out yourself 4) I know you bought the package for these 10 things but I mixed them together with 20,000 un-fished or broke things and the file naming key is hidden under my bed, and my personal favorite and number 1 on my list 5) add these lines of code to file xyz.abc (and then never tell you where the heck that file is, where to put the code in the file and if it does 1/2 the time what they say to look for is not there).
Or look in the forum and see how many times you see "I have Torque 3D with package X and package Y installed, how do you get package Z to work?"
If there was a set standard where everything was required to be documented, and everything in a set format it would make it a lot better to trouble shoot when you did have an issue. I know this is an over simplified example and has nothing to do with source code. But let say two packages set the same key binding different things. I drop the seconded package in and all heck breaks loose. I can look at the doc and see WoW this package does change XY and Z. With the source code it would be the same, it failed to compile with this error. Look in docs O I see their code changes this in that file and that why it spit out 115 errors.
I am not talking about changing anyone's code style, people are going to code how they code. At least document what they changed and why. Otherwise we are left to reverse engineer the changes trying to make it fit in our project wasting time that we could be getting things done.
Why would they have all this useful information in the documentation that would save us hours and hours of digging thru lines after lines of code to find out what changed what? Easy GG would require it in order to get there Approved by Logo.
GG could even use this to make some extra $. Charge for 3rd party models and programs to summit their product for testing and approval for the logo. 3rd parties could charge a little extra $ for aps and models that been approved. GG makes $, 3rd parties make $, and us the users save loads of $ on time, and replacing the hair we pulled out. Everyone is happy, world peace, rainbows and unicorns, ok maybe not but I would not be wondering why my coder was trying to cut his wrist when I show him the video for pure light...
03/09/2012 (5:05 pm)
Yes this is a good point and is understandable. However if there is changes in the source code have it documented in a set format what was added, removed or changed. Instead of the install saying just drop folder here and hit yes if it ask to overwrite and pray. Even if their where major code changes having GG at least look over them to make sure that nothing major was wrong that would toss a monkey wrench into any project that was not stock would be a huge step in the right direction.I am assuming that that GG has access to the 3rd party apps in its store. Take a look for yourself, most of the installs are: 1) drop folder here, 2) bunch of files here you go hope you know what to do with them fyi you may need files from other folders in the pack good luck finding them all, 3) here is a show case program with your art pack dig it out yourself 4) I know you bought the package for these 10 things but I mixed them together with 20,000 un-fished or broke things and the file naming key is hidden under my bed, and my personal favorite and number 1 on my list 5) add these lines of code to file xyz.abc (and then never tell you where the heck that file is, where to put the code in the file and if it does 1/2 the time what they say to look for is not there).
Or look in the forum and see how many times you see "I have Torque 3D with package X and package Y installed, how do you get package Z to work?"
If there was a set standard where everything was required to be documented, and everything in a set format it would make it a lot better to trouble shoot when you did have an issue. I know this is an over simplified example and has nothing to do with source code. But let say two packages set the same key binding different things. I drop the seconded package in and all heck breaks loose. I can look at the doc and see WoW this package does change XY and Z. With the source code it would be the same, it failed to compile with this error. Look in docs O I see their code changes this in that file and that why it spit out 115 errors.
I am not talking about changing anyone's code style, people are going to code how they code. At least document what they changed and why. Otherwise we are left to reverse engineer the changes trying to make it fit in our project wasting time that we could be getting things done.
Why would they have all this useful information in the documentation that would save us hours and hours of digging thru lines after lines of code to find out what changed what? Easy GG would require it in order to get there Approved by Logo.
GG could even use this to make some extra $. Charge for 3rd party models and programs to summit their product for testing and approval for the logo. 3rd parties could charge a little extra $ for aps and models that been approved. GG makes $, 3rd parties make $, and us the users save loads of $ on time, and replacing the hair we pulled out. Everyone is happy, world peace, rainbows and unicorns, ok maybe not but I would not be wondering why my coder was trying to cut his wrist when I show him the video for pure light...
#6
I reckon having some sort of standard is a good idea, but we'll just never get rid of different packs wanting to modify the same file, especially if they contain code. In these cases, it would certainly help for pack creators to keep unrelated modifications to a minimum, work around existing systems instead of replacing them, etcetera.
03/10/2012 (8:53 pm)
Quote:Instead of the install saying just drop folder here and hit yes if it ask to overwrite and pray.If this is a source of a lot of problems, there's an easy fix. I'm not blaming you - it's pack creators who should take responsibility for providing better installation instructions. Even some sort of hint that existing files are modified would be helpful, and providing some sort of commenting as to what and where has changed.
I reckon having some sort of standard is a good idea, but we'll just never get rid of different packs wanting to modify the same file, especially if they contain code. In these cases, it would certainly help for pack creators to keep unrelated modifications to a minimum, work around existing systems instead of replacing them, etcetera.
#7
03/11/2012 (12:27 pm)
I personally don't see much of an issue if you hand merge a pack's code into your codebase. Sure, it may be time consuming and requires more skill than drag and drop, but I want to know what my code says - especially if I'm adding someone else's, professional or otherwise! I've always seen the stock scripts as an example or suggestion at best and am not afraid to modify or rewrite entire systems, yet have had no issue adding any add-on to it.
#8
Though personally I raise an eyebrow at people who drag'n'drop rather than port manually using the old mark1 eyeball.
03/11/2012 (12:36 pm)
Tell your coder to chill ... pureLight is an external app :PThough personally I raise an eyebrow at people who drag'n'drop rather than port manually using the old mark1 eyeball.
#9
03/11/2012 (6:35 pm)
I agree that drag and drop is a bad idea... but so is having code with out docs... or packages that change everything under the sun when they do not need to... If we had some set standards you have to admit it would make things easier for every one including the ones that make packages in the first place. 
Associate David Montgomery-Blake
David MontgomeryBlake