T3D1.0 New Project Scripts Structure Reverted
by Steve Acaster · in Torque 3D Professional · 09/29/2009 (12:07 pm) · 17 replies
I see you've reverted the scripts hierarchy/structure to something akin to TGE/A and FPSkit (eg: all dumped in one scripts/server folder), after previously having the files split between art and server folders for all 5 of the betas.
More tea will be required before porting custom Beta5 project to Release.
More tea will be required before porting custom Beta5 project to Release.
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#3
The Empty Template is a barebones setup that many people have expressed a desire for.
But it really didn't change that much in setup... or so it seemed to me. Datablocks are separated out into the "art" directory and scripts are still client/server as always.
09/29/2009 (1:07 pm)
The Full Template did change, some, but it was certainly cleaned up with many long-lived script errors fixed, and is more akin to a stripped down version of what the FPS kit was.The Empty Template is a barebones setup that many people have expressed a desire for.
But it really didn't change that much in setup... or so it seemed to me. Datablocks are separated out into the "art" directory and scripts are still client/server as always.
#4
Is core/~~~/spawn.cs redundant now? I just saw the same spawn functions and player kitting out in server/gamecore.cs, and it appears to override spawn.cs.
09/29/2009 (6:16 pm)
@MichaelIs core/~~~/spawn.cs redundant now? I just saw the same spawn functions and player kitting out in server/gamecore.cs, and it appears to override spawn.cs.
#5
That totally slipped my mind... hmmm, and since the Template was redone that probably should have been taken care of differently. The Empty Template will still depend upon the core methods in spawn.cs though, so it's not quiet redundant since all projects make use of the core package.
Truthfully, I never thought that spawning should have been stuck in the core to begin with -- but that's just my opinion.
09/29/2009 (6:39 pm)
Yeah, it overrides it... There was a problem with re-spawning introduced in one of the betas and that's how I fixed it then. That totally slipped my mind... hmmm, and since the Template was redone that probably should have been taken care of differently. The Empty Template will still depend upon the core methods in spawn.cs though, so it's not quiet redundant since all projects make use of the core package.
Truthfully, I never thought that spawning should have been stuck in the core to begin with -- but that's just my opinion.
#6
09/29/2009 (6:43 pm)
I was a bit baffled that a few things have ended up in /core - it's not really your first port of call when looking for things ... like audio descriptions are now in there and water and special, and some other stuff
#7
But taking a page from the MGStarterKit, everything going into my game is actually being put into core/common with mod functionality going on top of that.
09/29/2009 (6:51 pm)
I think it was intended to simplify things since a lot of those audio descriptions (and other specials) are used everywhere across many projects.But taking a page from the MGStarterKit, everything going into my game is actually being put into core/common with mod functionality going on top of that.
#8
After a bit of looking around, yes, the file structure didn't change that much - just momentarily horrifying when opening something up for the first time and it's devoid of the regular sub folders that I've come acustommed to seeing over 5 betas. and they're back now cos I've reorganised it that way!.
09/29/2009 (7:24 pm)
Hmmm, sticking everything in core/common for shipping ... makes sense when your shipped game will be the core.After a bit of looking around, yes, the file structure didn't change that much - just momentarily horrifying when opening something up for the first time and it's devoid of the regular sub folders that I've come acustommed to seeing over 5 betas. and they're back now cos I've reorganised it that way!.
#9
09/29/2009 (7:41 pm)
It is great that you can reorganize these things in Torque 3D much more easily than you could in TGE/TGEa :D
#10
09/29/2009 (7:43 pm)
Infinitely superior to TGE/A for ease of use. 
#11
My goal was to get down to a largely empty art folder and to have the minimum amount of project specific scripts needed to accomplish my goals. Anything that I found in art or scripts that was required to get Empty up and running and was used in the same way in all of our other projects got moved to core with the exception of some of the level loading script code (that was riskier to change than I had time to deal with) and some scripts that I deemed should stay project specific (like MainMenu).
You can see that working now really well in Empty and having spun up a couple new demos based off of it, I am pretty happy with its layout.
The artwork (water, special, skies) and the datablocks (audio descriptions) that got moved into core were driven for the most part by the World Editor. A number of the objects that you can create in the World Editor expect certain textures, Material's, or datablock definitions to exist in your project. I thought it odd that if you delete your "art" folder then you can no longer create a number of the objects in the World Editor...especially when most of those were stuff that existed in every single project/demo/example we had shipped unchanged so far (some as far back as TGE).
Ideally, I would like for a lot of the artwork required for object creation to exist in the "tools" folder and to get copied into your project's art folder only when needed but that is a lot larger of a task (any takers?).
09/30/2009 (9:38 pm)
Basically for Empty I targeted having a game/project that allowed you to load a level and fly around as a free Camera. I stripped out everything that I could till things started breaking and then I looked at why they broke.My goal was to get down to a largely empty art folder and to have the minimum amount of project specific scripts needed to accomplish my goals. Anything that I found in art or scripts that was required to get Empty up and running and was used in the same way in all of our other projects got moved to core with the exception of some of the level loading script code (that was riskier to change than I had time to deal with) and some scripts that I deemed should stay project specific (like MainMenu).
You can see that working now really well in Empty and having spun up a couple new demos based off of it, I am pretty happy with its layout.
The artwork (water, special, skies) and the datablocks (audio descriptions) that got moved into core were driven for the most part by the World Editor. A number of the objects that you can create in the World Editor expect certain textures, Material's, or datablock definitions to exist in your project. I thought it odd that if you delete your "art" folder then you can no longer create a number of the objects in the World Editor...especially when most of those were stuff that existed in every single project/demo/example we had shipped unchanged so far (some as far back as TGE).
Ideally, I would like for a lot of the artwork required for object creation to exist in the "tools" folder and to get copied into your project's art folder only when needed but that is a lot larger of a task (any takers?).
#12
The other reason that I reworked the spawn code is that I wanted to allow spawning to be a lot more editor driven and a lot less script driven. It has always struck me as silly that if an artist or designer wanted to change the type of Player that spawns, we have had to point them at the 300th+ line of scripts\server\games.cs and have had to guide them to a single line of code that is buried in a lot of other intimidating code.
Now, they just select the SpawnSphere in the World Editor and choose a new Player datablock and they are on their way without having to know anything about TorqueScript or ClientConnection's.
The spawn code isn't 100% of the way to allowing them to control all of the spawning options but it is a lot closer and if we can get it all of the way there then almost no one will ever need to edit the spawning scripts every again...which makes them a logical candidate for "core" scripts (code that very few people should ever need to touch).
The nice thing about TorqueScript is that it is ridiculously easy to override functions and do your over version of them. No need to go stripping out or messing with core unless you trying to save on a small amount of hard drive/download size.
One thing I would like to do with core in the future is split it up into better "modules" so that you could strip out the scripts directly related to an "fps" project if you don't need them while preserving the other parts of core that you care about. However, I am not sure when we will get to that point =)
09/30/2009 (9:46 pm)
Reworking the spawn logic into core was largely my doing. The intent there was two-fold. I wanted to make sure that it was possible to always spawn a "player" in your world, even if you didn't know how to implement the script code for that. Getting a "player" (be it a Camera or a Vehicle or a Player) spawned correctly requires a fairly in-depth understanding of Torque's systems and no small amount of code. Additionally, this code pretty much has been duplicated in very similar states in every Torque project back to the beginning of time and very few people have had reasons or knowledge enough to change them.The other reason that I reworked the spawn code is that I wanted to allow spawning to be a lot more editor driven and a lot less script driven. It has always struck me as silly that if an artist or designer wanted to change the type of Player that spawns, we have had to point them at the 300th+ line of scripts\server\games.cs and have had to guide them to a single line of code that is buried in a lot of other intimidating code.
Now, they just select the SpawnSphere in the World Editor and choose a new Player datablock and they are on their way without having to know anything about TorqueScript or ClientConnection's.
The spawn code isn't 100% of the way to allowing them to control all of the spawning options but it is a lot closer and if we can get it all of the way there then almost no one will ever need to edit the spawning scripts every again...which makes them a logical candidate for "core" scripts (code that very few people should ever need to touch).
The nice thing about TorqueScript is that it is ridiculously easy to override functions and do your over version of them. No need to go stripping out or messing with core unless you trying to save on a small amount of hard drive/download size.
One thing I would like to do with core in the future is split it up into better "modules" so that you could strip out the scripts directly related to an "fps" project if you don't need them while preserving the other parts of core that you care about. However, I am not sure when we will get to that point =)
#13
Could you list for me exactly what stuff got rearranged that surprised you? And what you did to rearrange back?
Aside from some stuff moving to core and a few things getting properly split between scripts and art, it should be a pretty similar layout as before.
I'm just curious what threw you for a loop?
09/30/2009 (9:49 pm)
Hey Steve,Could you list for me exactly what stuff got rearranged that surprised you? And what you did to rearrange back?
Aside from some stuff moving to core and a few things getting properly split between scripts and art, it should be a pretty similar layout as before.
I'm just curious what threw you for a loop?
#14
My initial wtf was most likely exaggerated from rolling out of bed with my first cuppa.
I hadn't really bothered leafing through the FPSkit files during the beta, just a quick glance at the start and it seemed fairly consistant with the TGE/A structure - while New Project was arranged otherwise with art/datablocks and scripts/server dividing various player/weapon functions which previously had been all been in server. So I was probably gripped by an initial fear that things had regressed to the unergonomic-TGE/A-throw-all-the-script-files-into-a-folder-together.
Also spawn.cs being overridden by gamecore.cs, hadn't looked in any game.cs type file since the start of the betas. Of course some of us do know how to use "find in files" when we're hunting a function, which helps greatly.
And just to note, staticshape.cs is missing from the New Project build, it'd be handy to have it returned so that those who are unfamiliar with Torque in general know that there is such a thing.
So, no fire, and probably not smoke either. Maybe a cloud of dust ... I do need to clear this place up.
edit: Also could you put it to the "powers that be" to rename staticshape to scriptshape or dynamicshape or something. Staticshape is just too confusing to those unfamiliar with the engine, what with statics of TsStatic. The name just seems to be an oxymoron (I hope that's the right word). eg: Radiant calls dynamic brushes, scriptbrushes, because they work with a script - static just gives teh impression it doesn't do anything. I know, I know, semantics ...
Anyhow, teh drahma is over, all my stuff ported. And with the engine in a period of relative stability I'll get round to assaulting the fearsome C++ - of which I know practically nothing - and sort out some pathfinding and vaguely intelligent AI.
09/30/2009 (10:11 pm)
Quote:I'm just curious what threw you for a loop?Lack of folders for player scripts - that was about it ...
My initial wtf was most likely exaggerated from rolling out of bed with my first cuppa.
I hadn't really bothered leafing through the FPSkit files during the beta, just a quick glance at the start and it seemed fairly consistant with the TGE/A structure - while New Project was arranged otherwise with art/datablocks and scripts/server dividing various player/weapon functions which previously had been all been in server. So I was probably gripped by an initial fear that things had regressed to the unergonomic-TGE/A-throw-all-the-script-files-into-a-folder-together.
Also spawn.cs being overridden by gamecore.cs, hadn't looked in any game.cs type file since the start of the betas. Of course some of us do know how to use "find in files" when we're hunting a function, which helps greatly.
And just to note, staticshape.cs is missing from the New Project build, it'd be handy to have it returned so that those who are unfamiliar with Torque in general know that there is such a thing.
So, no fire, and probably not smoke either. Maybe a cloud of dust ... I do need to clear this place up.
edit: Also could you put it to the "powers that be" to rename staticshape to scriptshape or dynamicshape or something. Staticshape is just too confusing to those unfamiliar with the engine, what with statics of TsStatic. The name just seems to be an oxymoron (I hope that's the right word). eg: Radiant calls dynamic brushes, scriptbrushes, because they work with a script - static just gives teh impression it doesn't do anything. I know, I know, semantics ...
Anyhow, teh drahma is over, all my stuff ported. And with the engine in a period of relative stability I'll get round to assaulting the fearsome C++ - of which I know practically nothing - and sort out some pathfinding and vaguely intelligent AI.
#15
Moving forward it is going to be easier to create a new StaticShape datablock in the Datablock Editor and let it handle saving it out rather than tracking it down to a specific file in the server\scripts.
"StaticShape" is a terrible name but I am a bit worried that renaming it could break some projects' backwards compatibility pretty badly.
At some point in the distant future we are going to have the opportunity to break all backwards compatibility with existing "mission" files and gameplay objects and I will happily kill the name "StaticShape"!
09/30/2009 (10:23 pm)
I believe "staticshape.cs" primarily just held the datablock "create" function that is used by the World Editor. That has been moved over into the tools scripts where it belongs (so that you can create static shapes even if you don't have that script in your project).Moving forward it is going to be easier to create a new StaticShape datablock in the Datablock Editor and let it handle saving it out rather than tracking it down to a specific file in the server\scripts.
"StaticShape" is a terrible name but I am a bit worried that renaming it could break some projects' backwards compatibility pretty badly.
At some point in the distant future we are going to have the opportunity to break all backwards compatibility with existing "mission" files and gameplay objects and I will happily kill the name "StaticShape"!
#16
09/30/2009 (10:26 pm)
Tools folder ... there's another thing I've glanced into only once during beta1.
#17
Yeah, I can understand the reasoning behind moving stuff into the core, it just doesn't always agree with me ;) It's a good thing you didn't hear all of my grumbling the first time I found that re-spawning didn't work. But on the other hand I think it could possibly make it easier for newcomers to pick up on the simplicity and ease of use of the package/mod functionality -- and I've actually been moving more towards that sort of thing on my own anyway.
@Steve:
re: No player script/datablock directory -- you can blame me for that confusion ;) Back when we had several player models to choose from it made sense to me, but it just didn't feel right to have a folder with only one script file in it (in this case it was just the one file in the datablocks directory) -- if were up to me I could have gotten carried away re-organizing things ;)
staticshape.cs
The staticshape.cs file in the FPS Genre Kit actually had some damage handling methods thrown into it -- I like blowing things up! But I guess those just hadn't been carried over to the FPS Example or the Template. I didn't notice until you mentioned it that the file was gone. If you need/want some hints on setting the datablocks up for damage/destruction just send me an email. Those methods will also work with other ShapeBase derived classes too.
But yeah that whole static bit in StaticShape certainly is a bit of a misnomer :D
10/01/2009 (1:07 am)
@Matt: Yeah, I can understand the reasoning behind moving stuff into the core, it just doesn't always agree with me ;) It's a good thing you didn't hear all of my grumbling the first time I found that re-spawning didn't work. But on the other hand I think it could possibly make it easier for newcomers to pick up on the simplicity and ease of use of the package/mod functionality -- and I've actually been moving more towards that sort of thing on my own anyway.
@Steve:
re: No player script/datablock directory -- you can blame me for that confusion ;) Back when we had several player models to choose from it made sense to me, but it just didn't feel right to have a folder with only one script file in it (in this case it was just the one file in the datablocks directory) -- if were up to me I could have gotten carried away re-organizing things ;)
staticshape.cs
The staticshape.cs file in the FPS Genre Kit actually had some damage handling methods thrown into it -- I like blowing things up! But I guess those just hadn't been carried over to the FPS Example or the Template. I didn't notice until you mentioned it that the file was gone. If you need/want some hints on setting the datablocks up for damage/destruction just send me an email. Those methods will also work with other ShapeBase derived classes too.
But yeah that whole static bit in StaticShape certainly is a bit of a misnomer :D
Torque Owner deepscratch
DeepScratchStudios