IDEA: Change TorqueScript Extension
by James Urquhart · in Torque 3D Professional · 05/20/2014 (6:18 am) · 28 replies
Since its inception, TorqueScript has used the "cs" extension (short for either C Script or Console Script). Unfortunately when CSharp appeared in 2000, Microsoft commandeered the "cs" extension.
As a consequence, every major text editor now assumes a cs file is a CSharp file, meaning you often get horribly formatted highlighting in practically every editor. Making your own syntax highlighting configuration is difficult since they often go by file extension and of course cs is taken. Even worse when you want to open a script, you may find that software such as Visual C# decides to open it.
On code sharing websites such as github, it's also hard to search for TorqueScript code as if for example you search for "cs" files you'll get CSharp code.
In light of these problems, I propose the default extension be changed to something more sensible, such as "ts" for "Torque Script".
As a consequence, every major text editor now assumes a cs file is a CSharp file, meaning you often get horribly formatted highlighting in practically every editor. Making your own syntax highlighting configuration is difficult since they often go by file extension and of course cs is taken. Even worse when you want to open a script, you may find that software such as Visual C# decides to open it.
On code sharing websites such as github, it's also hard to search for TorqueScript code as if for example you search for "cs" files you'll get CSharp code.
In light of these problems, I propose the default extension be changed to something more sensible, such as "ts" for "Torque Script".
About the author
#22
Mich: having more inter-committee discussions would be great. I'm glad we're all in the same forum, at least!
05/20/2014 (8:27 pm)
It's not really retooling so much as optimising what's there. There'll be no changes required to anyone's project except maybe in extreme edge cases, so we don't count it as requiring a major version bump.Mich: having more inter-committee discussions would be great. I'm glad we're all in the same forum, at least!
#23
In fact writing this script first that can go both ways would make renaming everything easier.
05/21/2014 (5:06 am)
I know something you could do to ease the pain. Add a Define to change from new extension to cs and a script file to rename all the files back to cs. Make sure to let people know that it is deprecated. So then if someone with an existing project wants to merge new changes, they can use those two things to stay on .cs for now. Choose a version (5.0? 6.0?) that .cs is gone forever and make sure people know this. This is something larger companies do and apple is a good example. They deprecate APIs and give lots of warning each release until they are finally gone forever.In fact writing this script first that can go both ways would make renaming everything easier.
#24
Problems do arise however if someone updates their engine and finds they have to rename their script files before merging new script changes, making it probably more sensible to do a switchover in a major release.
05/21/2014 (5:46 am)
@Tim there's not really much of a reason why .cs and .newextension couldn't be used interchangeably. For instance we already have ".gui" files which are just TorqueScript files.Problems do arise however if someone updates their engine and finds they have to rename their script files before merging new script changes, making it probably more sensible to do a switchover in a major release.
#25
So maybe a project converter script is a better way of looking at it.
05/21/2014 (5:50 am)
My suggestion for the script was more of a selfish reason :) When we want to update our custom code base with new changes, itll be a nightmare to winmerge two different extensions without renaming them. But if you guys dont think its a good idea i can write the script for myself locally when it changes :) Then i can convert our custom code base over to use the new extension and wont have to worry about it on future releases.So maybe a project converter script is a better way of looking at it.
#26
Question: do we make .mis and .gui files use the new extension as well? I'd be in favour.
05/21/2014 (2:48 pm)
I think, since rewriting the script templates from the bottom up is on the committee's agenda anyway, that we will simply start writing the new templates with this new file extension. The old templates will remain untouched for everyone using them.Question: do we make .mis and .gui files use the new extension as well? I'd be in favour.
#27
What James is saying ( I think ) is that there's really no reason to remove the ability to use .cs at the moment, just add support for .tcs and convert all the template scripts, etc. For instance the initial launch could be changed to run main.cs and/or main.tcs depending on which one it finds. It would then work fine for an existing project but any new project based off the templates would be all .tcs
@ Dan
I'm on board for that but we'd have to alter the GUI editor and mission loader. Not entirely sure how deep it runs but I know they populate their lists based on the extensions. We'll have to find a new method to handle that.
05/21/2014 (3:10 pm)
@ Tim What James is saying ( I think ) is that there's really no reason to remove the ability to use .cs at the moment, just add support for .tcs and convert all the template scripts, etc. For instance the initial launch could be changed to run main.cs and/or main.tcs depending on which one it finds. It would then work fine for an existing project but any new project based off the templates would be all .tcs
@ Dan
I'm on board for that but we'd have to alter the GUI editor and mission loader. Not entirely sure how deep it runs but I know they populate their lists based on the extensions. We'll have to find a new method to handle that.
#28
Main.cs might be a problem since the engine is hardcoded to look for it. But nothing a #define won't fix.
05/21/2014 (7:33 pm)
Well if we rewrite the templates we'll be doing that anyway. And I am highly in favour of building them from the ground-up to be more similar to T2D's modular system. In whish case the existing template structure (which is janky in a few places) won't be affected. (EDIT: Oh, GUI editor. Yeah that may be a pain. I don't necessarily advocate scrapping the existing editors entirely.)Main.cs might be a problem since the engine is hardcoded to look for it. But nothing a #define won't fix.
Azaezel