Jmtcw
by Dave Silvia · in Torque Game Builder · 05/20/2006 (6:26 pm) · 34 replies
1. Have T2D.exe reload .cs files when they're changed and/or a method to produce this behavior. Quitting out and restarting is a little onerous.
2. Ability to delete image maps from right side bar display. Sometimes, (especially if you're following the tutorials which have a lot of "btw" instructions after the fact) you load something incorrectly and need to get rid of it and do it again.
3. Ability to minimize/maximize T2D.exe. At least on the Windows platform this should be relatively straightforward.
4. Horizontal as well as vertical scrolling in right side bar display. Resizing is not always optimal nor possible.
5. Remove exclusive lock on console.log file so that it can be viewed without quitting out of T2D.exe.
6. Make plain and available the .cs code the level builder is generating.
Okay, so it's six cents worth...
thx,
Dave S.
2. Ability to delete image maps from right side bar display. Sometimes, (especially if you're following the tutorials which have a lot of "btw" instructions after the fact) you load something incorrectly and need to get rid of it and do it again.
3. Ability to minimize/maximize T2D.exe. At least on the Windows platform this should be relatively straightforward.
4. Horizontal as well as vertical scrolling in right side bar display. Resizing is not always optimal nor possible.
5. Remove exclusive lock on console.log file so that it can be viewed without quitting out of T2D.exe.
6. Make plain and available the .cs code the level builder is generating.
Okay, so it's six cents worth...
thx,
Dave S.
#22
I can see where you need to be secure re: global access in a distributed game, but a developer should have the freedom of his system.
Again, I can see where this is easier to implement, but is TGB supposed to be easily implemented or a useful, flexible tool for the customer?
Just as only compiled scripts are packaged, only local files could also be. Think about it a bit more to try to see my point. It is doable and, although not a zero effort, it's not prohibitive, just imaginative.
thx,
Dave S.
05/23/2006 (12:23 pm)
Understood, but you're talking about the finished product, not the development environment. I'm talking about the development environment, specifically, the level builder. This is not part of a finished game.I can see where you need to be secure re: global access in a distributed game, but a developer should have the freedom of his system.
Again, I can see where this is easier to implement, but is TGB supposed to be easily implemented or a useful, flexible tool for the customer?
Just as only compiled scripts are packaged, only local files could also be. Think about it a bit more to try to see my point. It is doable and, although not a zero effort, it's not prohibitive, just imaginative.
thx,
Dave S.
#23
Your point is taken, trust me--we've been talking about the issue for quite a while now. The root factor development time wise is that it's a core mechanic of the underlying Torque technology, and even in a development environment the risk level is still there--we forsee (and hope for!) a lot of developer add-ons and script class libraries as TGB becomes more mature and the community starts to develop these types of packages, and regardless of who might actually code in a hack to their pack, we would still have a responsibility.
05/23/2006 (12:28 pm)
Unfortunately, they use the same resource manager to handle the access controls.Your point is taken, trust me--we've been talking about the issue for quite a while now. The root factor development time wise is that it's a core mechanic of the underlying Torque technology, and even in a development environment the risk level is still there--we forsee (and hope for!) a lot of developer add-ons and script class libraries as TGB becomes more mature and the community starts to develop these types of packages, and regardless of who might actually code in a hack to their pack, we would still have a responsibility.
#24
Although I disagree (I've been involved with more "insurmountable" security issues), I bow to GarageGames' decision.
Just out of curiosity, how do you deal with not distributing .cs code? I haven't seen that part of the process yet. But, I understand that only compiled script is allowed to be distributed.
thx,
Dave S.
05/23/2006 (12:35 pm)
So, if I understand correctly, you're saying the chances of anything of the sort happening are slim and none. You view the security issue as insurmountable and so not worth the development effort?Although I disagree (I've been involved with more "insurmountable" security issues), I bow to GarageGames' decision.
Just out of curiosity, how do you deal with not distributing .cs code? I haven't seen that part of the process yet. But, I understand that only compiled script is allowed to be distributed.
thx,
Dave S.
#25
I didn't say insurmountable, I said that we've been talking about it for quite a while, are looking for solutions that meet both the security requirements and useability requirements, and that since it's a core technology being used, it has more implications to change than just TGB.
.cs code is covered by the EULA, as well as the packaging utility (once it's fully feature complete and bug free) automatically develops a distribution file set that you can deliver to your customers.
05/23/2006 (1:02 pm)
@Dave: you are reading more into what I said than I said!I didn't say insurmountable, I said that we've been talking about it for quite a while, are looking for solutions that meet both the security requirements and useability requirements, and that since it's a core technology being used, it has more implications to change than just TGB.
.cs code is covered by the EULA, as well as the packaging utility (once it's fully feature complete and bug free) automatically develops a distribution file set that you can deliver to your customers.
#26
Sorry, didn't mean to read more into it than you said. That's why I posed the question as "if I understand correctly". I guess I don't. Just wanting to understand the problem more clearly and see if the future holds any hope for a more developer friendly environment. Your original answer seemed short and sweet and to the point, but I guess I missed the point.
thx,
Dave S.
05/23/2006 (1:11 pm)
Then, couldn't the links I propose be included in the EULA and the packaging utility? Seems relatively straightfoward to me. But then, when it comes to games and 2d graphics, I'm really a dummy. So, I could easily have my head up my a**!;)Sorry, didn't mean to read more into it than you said. That's why I posed the question as "if I understand correctly". I guess I don't. Just wanting to understand the problem more clearly and see if the future holds any hope for a more developer friendly environment. Your original answer seemed short and sweet and to the point, but I guess I missed the point.
thx,
Dave S.
#28
how hard is a cvs up -d, no copying required, everything is protected under revision control, and you have the flexibility to pickup over pserver to multiple nodes, (sometimes I like to rip in the Gimp).. checkout , manipulate, commit, cvs up -d on my torque machine....
I ranted about a few of the same things my first few weeks playing with TGB, the most important being the TGE data being locked out from TGB people being able to view it.. But I've given up on that, now I just repost a question, it probably makes the TGB boards stronger by having the same solutions reexplained there anyway, for those who will never buy both prouducts...
I'll shutup now...
05/23/2006 (10:47 pm)
Not to throw the conversation back into loop, but if your using proper source control for your projects, There isn't a tedious part to any development projects file management. I have my "graphics" applications that write to a local copy of CVS for saving my important pixel shifting efforts, and then checkout (-d ) into my torque images directory, set CVS directories as ignore, and never look back, just make sure you use your -kb flags if adding binary items. how hard is a cvs up -d, no copying required, everything is protected under revision control, and you have the flexibility to pickup over pserver to multiple nodes, (sometimes I like to rip in the Gimp).. checkout , manipulate, commit, cvs up -d on my torque machine....
I ranted about a few of the same things my first few weeks playing with TGB, the most important being the TGE data being locked out from TGB people being able to view it.. But I've given up on that, now I just repost a question, it probably makes the TGB boards stronger by having the same solutions reexplained there anyway, for those who will never buy both prouducts...
I'll shutup now...
#29
As I said, the resource manager in use is part of core tech. As a design principle (source code management is simply a part of it--you have to consider compatibility, product deviation from core, support, training, etc.), when functionality is dependent on tech that is part of other product lines, we don't simply re-write it to work for just that product.
05/23/2006 (11:56 pm)
@Rodney: I must not be speaking clearly! The problem isn't in isolating or managing the code, the issue is simply a matter of priority vs workload vs product line changes vs security vs future development.As I said, the resource manager in use is part of core tech. As a design principle (source code management is simply a part of it--you have to consider compatibility, product deviation from core, support, training, etc.), when functionality is dependent on tech that is part of other product lines, we don't simply re-write it to work for just that product.
#30
Understand...
I think the issue is that the core tech was written when the product line was more limited. As such (and as is often the case with existing code), it has a narrow field of application. Often what is needed is to rethink the core tech to make it more generic and flexible so that it doesn't have (or has as few as possible) restrictions and limitations it imposes on yet to be developed products. This is a very difficult part of developing any system, but the more successful ones have their core tech as open ended as possible so that it fits as many applications as possible. UNIX kernels are a good example of this. Security issues are more aptly suited to higher level applications than to core tech, since security problems change with time and application. When the core proves to be restrictive, it is frequently time to back up and retrace before things are so far afield that your products require major rewrites in future because the core was too narrowly defined at the outset.
You know, perhaps instead of "Suggestions" this needs its own thread?
'Nuf said...
thx,
Dave S.
05/24/2006 (12:28 am)
Quote: ... when functionality is dependent on tech that is part of other product lines, we don't simply re-write it to work for just that product. ...
Understand...
I think the issue is that the core tech was written when the product line was more limited. As such (and as is often the case with existing code), it has a narrow field of application. Often what is needed is to rethink the core tech to make it more generic and flexible so that it doesn't have (or has as few as possible) restrictions and limitations it imposes on yet to be developed products. This is a very difficult part of developing any system, but the more successful ones have their core tech as open ended as possible so that it fits as many applications as possible. UNIX kernels are a good example of this. Security issues are more aptly suited to higher level applications than to core tech, since security problems change with time and application. When the core proves to be restrictive, it is frequently time to back up and retrace before things are so far afield that your products require major rewrites in future because the core was too narrowly defined at the outset.
You know, perhaps instead of "Suggestions" this needs its own thread?
'Nuf said...
thx,
Dave S.
#31
05/24/2006 (10:41 am)
You are correct! And that's why it's taking longer than just a "ok, recode the resource manager to allow it" solution.
#32
thx,
Dave S.
05/24/2006 (10:46 am)
Bottom line, it's in the works? That'll nip all this discussion in the bud. Then we'll just have to wait to see what we can do to break whatever you come up with and what new gripes we can think of!;)thx,
Dave S.
#33
Sorry, I know you want more than that, but that's all I can say (because that's all their is, not because of "I can't say" type stuff).
05/24/2006 (12:10 pm)
"In the works" implies that it's a guarantee--and it isn't. It's under discussion at various levels (TGB team, Torque Core Tech team, R&D, etc.), and may or may not be a modification in a future release of TGB.Sorry, I know you want more than that, but that's all I can say (because that's all their is, not because of "I can't say" type stuff).
#34
I guess I consider the discussion over. It's up to future tech to say. As Dan Quayle said, "The future will be better tomorrow...";)
thx,
Dave S.
05/24/2006 (3:46 pm)
No guarantees are ever assumed!;) "... in the works...", "... under discussion...", "...on the table...". All say to me that it's recognized as something valid and is being pursued. If possible, it will be done. Possible has a lot of qualifiers, tho', and that I understand.I guess I consider the discussion over. It's up to future tech to say. As Dan Quayle said, "The future will be better tomorrow...";)
thx,
Dave S.
Torque 3D Owner Stephen Zepp