SRTT User Interface Questions

Yeah that's what I was thinking, but it doesn't seem like it would be too hard to make it load from c:\sr3toolfolder\folder\folder\location instead. [V] Knobby seems to imply it could potentially be impossible.

Nothing is impossible. The issue here are things that we use internally. We have programs running locally that talk to our tools and provide them information about where files live, we have remote reporting for crashes and problems, we have external programs that act as an output window for the tools, source control communication, and other such things. The more of these things that the tool uses and the less knowledge the guys that are volunteering for the modding initiative have about the tool makes it difficult to know how much work/time it might take so we don't want to promise anything.
 
Nothing is impossible. The issue here are things that we use internally. We have programs running locally that talk to our tools and provide them information about where files live, we have remote reporting for crashes and problems, we have external programs that act as an output window for the tools, source control communication, and other such things. The more of these things that the tool uses and the less knowledge the guys that are volunteering for the modding initiative have about the tool makes it difficult to know how much work/time it might take so we don't want to promise anything.

Oh, that makes sense. Thanks. Hope everything ends up working!
 
Yeah that's what I was thinking, but it doesn't seem like it would be too hard to make it load from c:\sr3toolfolder\folder\folder\location instead. [V] Knobby seems to imply it could potentially be impossible.
Impossible is a very strong word. ;)

Many of our tools are integrated deeply to our revision control and other in-house tools and severs that will not and/or can not be released. Removing all references to those systems so that the tool can be run outside of our development environment can be very time consuming and tedious, and may ultimately be deemed not the best use of our limited resources. We will definitely be looking into the possibility of porting this tool and many others.

Making games is all about balancing risk and effort with reward.
 
Impossible is a very strong word. ;)

Many of our tools are integrated deeply to our revision control and other in-house tools and severs that will not and/or can not be released. Removing all references to those systems so that the tool can be run outside of our development environment can be very time consuming and tedious, and may ultimately be deemed not the best use of our limited resources. We will definitely be looking into the possibility of porting this tool and many others.

Making games is all about balancing risk and effort with reward.
And then there's the tools that are based on using source data we don't have and are not likely to get - our workflow consists of unpacking existing content, altering and repacking - whereas Volition's is creating content + packing instead. ;)
 
And then there's the tools that are based on using source data we don't have and are not likely to get - our workflow consists of unpacking existing content, altering and repacking - whereas Volition's is creating content + packing instead. ;)

True, but if we can get you guys creating the same way we are that sounds like a win to me.
 
Are you saying you might release some of that source data? (I assume that means things like the Source engine's VMF files, etc.)

You are able to extract some of the source data now, but yes, we have talked about this. The only issue I see is that the source data is significantly larger than the crunched data. I'm not sure at all if that will happen or to what extent, so I wouldn't expect a massive data drop anytime soon..
 
Back
Top