Where is the buglist page?
by James Brad Barnette · in Torque Game Engine · 02/01/2006 (9:51 pm) · 11 replies
There used to be a list of known issues and bugs. on the site that was easy to find does anyone know where that is now?
A link would be great.
and anyone from GG I applaude all of the great work you guys have done. and there is sooo much new information. Thanx for all of the hard work.
A link would be great.
and anyone from GG I applaude all of the great work you guys have done. and there is sooo much new information. Thanx for all of the hard work.
About the author
#2
I 'm currently having a issue that I have found posts going back 3 years about and it has basicly just been ignored? "waterblock holes with terrain squareSize anything other than 8"
I mean this problem has my project at a complete stand still. With no ETA on when it would even become a priority. You can see how this can be frustrating from the licensee's perspective can't you?
02/02/2006 (9:08 am)
Ok well then how is the community supposed to know what is being worked on? What the priorities are?I 'm currently having a issue that I have found posts going back 3 years about and it has basicly just been ignored? "waterblock holes with terrain squareSize anything other than 8"
I mean this problem has my project at a complete stand still. With no ETA on when it would even become a priority. You can see how this can be frustrating from the licensee's perspective can't you?
#3
I have to comment.
that since your project is at a complete stand still.
you now have the motivation to fix it!!
woot!
and the time too!! Hooah!
02/02/2006 (10:50 am)
Heh,I have to comment.
that since your project is at a complete stand still.
you now have the motivation to fix it!!
woot!
and the time too!! Hooah!
#4
02/02/2006 (7:29 pm)
Way above my skill level I'm afraid 
#5
02/02/2006 (8:13 pm)
I seem to remember there was a resource somewhere that fixed this. Basically changing all the hardcoded "1024"'s in waterblock.cc to the correct value (and changing the position of the terrain block so it was centered also).
#6
www.garagegames.com/mg/forums/result.thread.php?qt=3166
but it didn't work. last post about it was early DEC 2005
I don't want to hard code it I need it to be adjustable to the squaresize of the waterblock. I need to be able to change this from mission to mission. I can't be locked into one set squaresize.
02/03/2006 (8:12 am)
Yeah that thread is herewww.garagegames.com/mg/forums/result.thread.php?qt=3166
but it didn't work. last post about it was early DEC 2005
I don't want to hard code it I need it to be adjustable to the squaresize of the waterblock. I need to be able to change this from mission to mission. I can't be locked into one set squaresize.
#7
So, in the spirit of not offering a problem but a solution, can we not do the following?
1) Treat problems as a new category of/folder-in resources.
After a bug is agreed to be a bug in a particular thread, a bump is made to GG requesting that a Problem Resource be created. GG, if they agree it is a bug and NDA is not an issue, create a problem resource with the next problem number, ie. TGEPR0099 - Bug Title goes here. (TSEPRxxxx could be used for TSE).
This resource is ultimately owned/made updateable (by GG) by the team leader/chief volunteer.
2) Create a template as follows and include it in the body of the resource created by GG. (It is intended to be maintained by the solution Team Lead (TL)).
a) Solution No. - assigned by GG.
b) Solution Title - as suggested by the original problem thread.
c) Solution Description - as suggested by the original problem thread.
d) Solution Priority (vote dependent using standard resource post voting).
e) Originating thread - included by GG when they create resource.
f) Status. (Unassigned, WIP, Testing, Completed, Approved). Default Unassigned. Only Approved if GG merges to HEAD.
g) Team, be that Team GG or community volunteers.
h) ETA.
i) Version.
j) Modified Date. Whether that be status 'WIP", 'Completed' or 'Approved'.
k) Changelog.
3) We post to the problem resource to vote on priority, volunteer, help test etc.
4) We bump to GG when ownership is assigned (or they volunteer) so they can assign the resource to Team Lead.
5) Status, ETA, version, date and changelog are maintained by TL.
6) The solution is either merged to head or left as a resource. GG decides.
I may be missing something but the above seems virtually hands free and no new wheels required.
Or am I mistaken?
Edit: Spelling.
02/05/2006 (4:41 am)
I admit to some frustration regarding this since I first got TGE in October 2003. It is not difficult to keep the NDA issues separate and to focus on problem management. And since many problems are solved by the community, I cannot understand why there isn't a community oriented problem management solution in place.So, in the spirit of not offering a problem but a solution, can we not do the following?
1) Treat problems as a new category of/folder-in resources.
After a bug is agreed to be a bug in a particular thread, a bump is made to GG requesting that a Problem Resource be created. GG, if they agree it is a bug and NDA is not an issue, create a problem resource with the next problem number, ie. TGEPR0099 - Bug Title goes here. (TSEPRxxxx could be used for TSE).
This resource is ultimately owned/made updateable (by GG) by the team leader/chief volunteer.
2) Create a template as follows and include it in the body of the resource created by GG. (It is intended to be maintained by the solution Team Lead (TL)).
a) Solution No. - assigned by GG.
b) Solution Title - as suggested by the original problem thread.
c) Solution Description - as suggested by the original problem thread.
d) Solution Priority (vote dependent using standard resource post voting).
e) Originating thread - included by GG when they create resource.
f) Status. (Unassigned, WIP, Testing, Completed, Approved). Default Unassigned. Only Approved if GG merges to HEAD.
g) Team, be that Team GG or community volunteers.
h) ETA.
i) Version.
j) Modified Date. Whether that be status 'WIP", 'Completed' or 'Approved'.
k) Changelog.
3) We post to the problem resource to vote on priority, volunteer, help test etc.
4) We bump to GG when ownership is assigned (or they volunteer) so they can assign the resource to Team Lead.
5) Status, ETA, version, date and changelog are maintained by TL.
6) The solution is either merged to head or left as a resource. GG decides.
I may be missing something but the above seems virtually hands free and no new wheels required.
Or am I mistaken?
Edit: Spelling.
#8
02/05/2006 (10:26 am)
Brilliant!!! I'm a sorry programer but I'm up for it I think it is a wonderful plan!!!
#9
02/05/2006 (4:10 pm)
Sounds lovely
#10
There's really two issues coming up here - what is GG doing to move TGE/TSE/whatever forward, and what is GG doing to keep track of various issues?
For the first - well, we have a team of developers doing TGE work. We just launched 1.4.0, and a point release is coming soon. We work hard on fixing all the mainline usability issues - like crashing editors, bugs in script, etc. - and less hard on weirder cases, like how collision is kinda funky with scaled shapes. If you need a shape to always be a significantly different size just re-export it after scaling it in Maya or whatever. :)
For the second, we note specific bugs as issues and note the issue #s in the threads. For large, complex bugs with poorly defined "fixed" states, like "make script work better", we don't assign issue #s and instead just note them in todo lists or on whiteboards. There are few enough of these that we don't need fancier tracking systems.
I don't see that opening the tracker is going to address either of those issues. We don't post ETAs on the bugtracker or elsewhere, so you're not going to get any extra information than you already are, so... it seems like the only thing making it public will do is make it easier to accidentally mislead the community, which is something none of us want. :)
We might find, after some more experience with our own internal dev processes, that opening the tracker won't end up being a pain for anyone, but at the moment the more prudent course as it appears to us is to post in the forums about what we're doing, and keep our private notes private.
And meanwhile the community is free to post bugfixes and enhancements, all of which are reviewed for inclusion in HEAD by us, and apply them to their own codebases if needed. We reject a lot of stuff because it needs to work essentially 100% in all cases, but for any given game, there are often only a few situations that people care about... meaning it's much easier to make Torque work for your specific game on your own than for us to make Torque work for everyone's games for you. We are definitely committed to making Torque super solid and awesome to use, but that means that we often have to invest more time in fixing problems than it takes to make it good enough for a single game.
If you need something fixed to ship your game, don't wait on us - fix it yourself. You have the code and the knowledge to do it. That's the whole reason we've made the source for TGE available - so you don't have to block on us for every little fix, and if you need to change something for the needs of your game... you can!
As for Cisor's plan, it sounds nice enough but we're already maxed out managing our internal project tracking & doing forums - an additional bug tracking/co-ordination task is more than we can do. :(
02/05/2006 (7:55 pm)
A note as a long-time community member - I think it's hilarious that when the bug tracker was public you couldn't pay people to use it... and now that it's private, people are beating down the door to see it. :)There's really two issues coming up here - what is GG doing to move TGE/TSE/whatever forward, and what is GG doing to keep track of various issues?
For the first - well, we have a team of developers doing TGE work. We just launched 1.4.0, and a point release is coming soon. We work hard on fixing all the mainline usability issues - like crashing editors, bugs in script, etc. - and less hard on weirder cases, like how collision is kinda funky with scaled shapes. If you need a shape to always be a significantly different size just re-export it after scaling it in Maya or whatever. :)
For the second, we note specific bugs as issues and note the issue #s in the threads. For large, complex bugs with poorly defined "fixed" states, like "make script work better", we don't assign issue #s and instead just note them in todo lists or on whiteboards. There are few enough of these that we don't need fancier tracking systems.
I don't see that opening the tracker is going to address either of those issues. We don't post ETAs on the bugtracker or elsewhere, so you're not going to get any extra information than you already are, so... it seems like the only thing making it public will do is make it easier to accidentally mislead the community, which is something none of us want. :)
We might find, after some more experience with our own internal dev processes, that opening the tracker won't end up being a pain for anyone, but at the moment the more prudent course as it appears to us is to post in the forums about what we're doing, and keep our private notes private.
And meanwhile the community is free to post bugfixes and enhancements, all of which are reviewed for inclusion in HEAD by us, and apply them to their own codebases if needed. We reject a lot of stuff because it needs to work essentially 100% in all cases, but for any given game, there are often only a few situations that people care about... meaning it's much easier to make Torque work for your specific game on your own than for us to make Torque work for everyone's games for you. We are definitely committed to making Torque super solid and awesome to use, but that means that we often have to invest more time in fixing problems than it takes to make it good enough for a single game.
If you need something fixed to ship your game, don't wait on us - fix it yourself. You have the code and the knowledge to do it. That's the whole reason we've made the source for TGE available - so you don't have to block on us for every little fix, and if you need to change something for the needs of your game... you can!
As for Cisor's plan, it sounds nice enough but we're already maxed out managing our internal project tracking & doing forums - an additional bug tracking/co-ordination task is more than we can do. :(
#11
Also, I see the suggestion not as a tracker, but a community bug coordinator and history mechanism. The official tracker, as you imply, was not really used and served no real purpose to the community other than to see if a problem was reported. It is not the droid we are looking for.
1) What is GG doing to move TGE/TSE forward?
Make no mistake, I am not criticising GG for not fixing bugs or taking TGE/TSE forward. As a longish time member I know GG is at it 24/7. The suggestion above is mainly to help us help GG solve bugs.
2) What is GG doing to track various issues and bugs?
I know you have an internal tracking system. My suggestion was/is not to replace or circumvent that. More to enhance that with a system where we, the community, can co-ordinate and track our own efforts to solve the bugs we see as a priority. (Although the suggestion above allows for GG volunteering to fix a problem, if the ETA is not feasible for you guys, then so be it).
It seems apparent to me (and I have managed distributed PC and Mainframe Production Support Departments for over 15 years) that there are many holes in the current/and previous systems. Perhaps not for GG solutions, but for community priorities and solutions.
1) It is difficult to know if a problem has been reported, is being worked on, and who to liaise with if it is. GG has it's own priorities (and rightly so), but since we solve a lot of the bugs ourselves, a manageable, accessible community oriented system would be a great help.
Currently bugfixes are buried within multiple threads and finding that someone has posted a fix is a thankless hit/miss task.
2) There is no accessible history of problems and solutions. Many times the solution to a problem is a good learning opportunity and can be the starting point for the resolution to other problems. Since the system above has an inbuilt mechanism to keep the code implemented for the change, we can all learn from it.
3) Solutions sometimes create more problems than they fix. Having the solution code available enables us to track which bugfix broke what.
4) The number assigned to the PR can be the internal number GG uses (it has no relevance to us other than uniqueness).
5) The only GG involvement is the following:
a) Read an official structured 'bump' for the problem thread and if you agree it is a bug and NDA is no issue, open the PR with your internal bugno. (You are doing most of this anyway since you track the bug internally).
b) Assign the resource to the Team Lead when you get an official structured 'bump' on the PR.
c) Decide whether to merge fix to HEAD when problem is resolved. (You are doing this anyway for bugfixes posted in threads).
There is only a little GG coordination required.
Although I hear you regarding your current workload, and the results are apparent to us all in TGE and TSE, I think my suggestion will end up reducing your workload. The more problems we can fix the less you have to do.
I believe the pragmatics can be worked out, streamlined and managed so the onus is on us, rather than on GG. (This approach is already apparent in the suggestion I made).
All I can do is ask GG, as a team, to reconsider.
We want to help fix bugs, and it would be nice to have a system to help us do so.
02/06/2006 (1:34 am)
Ben: Thanks for the reply. My proposal is not aimed at the bugs GG are, or soon will be, working on. It is aimed at the bugs that have a low GG priority, but a high priority for the cummunity, and/or sectors of the community.Also, I see the suggestion not as a tracker, but a community bug coordinator and history mechanism. The official tracker, as you imply, was not really used and served no real purpose to the community other than to see if a problem was reported. It is not the droid we are looking for.
1) What is GG doing to move TGE/TSE forward?
Make no mistake, I am not criticising GG for not fixing bugs or taking TGE/TSE forward. As a longish time member I know GG is at it 24/7. The suggestion above is mainly to help us help GG solve bugs.
2) What is GG doing to track various issues and bugs?
I know you have an internal tracking system. My suggestion was/is not to replace or circumvent that. More to enhance that with a system where we, the community, can co-ordinate and track our own efforts to solve the bugs we see as a priority. (Although the suggestion above allows for GG volunteering to fix a problem, if the ETA is not feasible for you guys, then so be it).
It seems apparent to me (and I have managed distributed PC and Mainframe Production Support Departments for over 15 years) that there are many holes in the current/and previous systems. Perhaps not for GG solutions, but for community priorities and solutions.
1) It is difficult to know if a problem has been reported, is being worked on, and who to liaise with if it is. GG has it's own priorities (and rightly so), but since we solve a lot of the bugs ourselves, a manageable, accessible community oriented system would be a great help.
Currently bugfixes are buried within multiple threads and finding that someone has posted a fix is a thankless hit/miss task.
2) There is no accessible history of problems and solutions. Many times the solution to a problem is a good learning opportunity and can be the starting point for the resolution to other problems. Since the system above has an inbuilt mechanism to keep the code implemented for the change, we can all learn from it.
3) Solutions sometimes create more problems than they fix. Having the solution code available enables us to track which bugfix broke what.
4) The number assigned to the PR can be the internal number GG uses (it has no relevance to us other than uniqueness).
5) The only GG involvement is the following:
a) Read an official structured 'bump' for the problem thread and if you agree it is a bug and NDA is no issue, open the PR with your internal bugno. (You are doing most of this anyway since you track the bug internally).
b) Assign the resource to the Team Lead when you get an official structured 'bump' on the PR.
c) Decide whether to merge fix to HEAD when problem is resolved. (You are doing this anyway for bugfixes posted in threads).
There is only a little GG coordination required.
Although I hear you regarding your current workload, and the results are apparent to us all in TGE and TSE, I think my suggestion will end up reducing your workload. The more problems we can fix the less you have to do.
I believe the pragmatics can be worked out, streamlined and managed so the onus is on us, rather than on GG. (This approach is already apparent in the suggestion I made).
All I can do is ask GG, as a team, to reconsider.
We want to help fix bugs, and it would be nice to have a system to help us do so.
Associate Ben Garney
It might go public again someday. :)