As announced in this blog post we are planning to deprecate support for UnityScript and, in order to make this process as smooth as possible, we want to provide help for developers to convert their existing UnityScripts to C#. After evaluating some existing AS solutions we decided to implement a converter ourselves, which you can download (including source) from this github repository.
Keep in mind that we will probably never have 100% syntax coverage; our goal is to make sure that the most commonly used (UnityScript) features are supported.
If you have a project that relies on UnityScript it would be nice if you could give it a try and help us iron out potential issues.
Iām glad youāre releasing this tool and I will give it a try. But I think it would be helpful for non-coders like me (who are probably the biggest UnityScript users anyways) if the converter could be downloaded as a simple app for Mac / PC. I know many people are used to GitHub and Mono, but not everyone is as comfortable with that process (iām one of them:)
I agree, Iāve never used mono but just looking at the site makes me think, yeah Iām gonna stuff some part of this up before I even get to the convert process.
Hopefully they will make a converter thatās more accessible to non coders. Iām an artist who codes by necessity to realize my visions, and I have a few engineering friends who are very comfortable with GitHub and the like. But for me itās a big barrier and not something that comes naturally. I kind of feel like its a sign of things to come when it comes to non coders and Unity in general. After all, it was the accessibility of Unity that drew me to it in the first place.
Iām starting to plan how to deal with this and I have a few questions
Lets say i convert the scripts successfully. I have maybe a few thousand instances of various scripts attached to hundreds of game objects in my open world. Each script might reference another script elsewhere and have various settings and variables set, like in the attached image.
Using the attached image as an example, Lets say i convert my DayManager.js script to DayManager.cs. What is the next step to replace the current script
Can i add the new CS script to the same game object as the original JS, and then copy and paste the vales between the JS and CS components?
Will I need to manually type in all variable values between scripts? Is there a way to automate copying the data between CS and JS components?
Can JS and CS scripts with the same name exist with the same project directory? ie there wont be any conflict?
Do i have to change all my JS scripts to CS at the same time? Or will I be able to say change one to CS and still reference it froma JS script that hasnāt been converted yet? i seem to remember something about an issue accessing CS fro JS and vice versa. This way i can start converting scripts one by one now before its too late.
Iām using over 100 Asset Store assets in the game. If some devs do not or cannot update their assets to C#, will I still be able to use them in the game? Or after a certain time will JS files not work at all in a project?
Do you have a roadmap for how long before our JS based projects stop working? 6 months? 2 years? even a rough guesstimate will help planning
A suggestion: if there isnāt one already, how about a dedicated Forum for UnityScript to C# conversion where everyone could ask questions and find answers specific to this? I could port all my questions there and you could pin a link to the conversion tool
Sorry to ask all of this, but Ive invested many thousands of dollars in unity, assets and this game, and I want to try and get the worst possible scenarios out of the way so thereās no surprises when I attempt this:)
If anybody else can think of any potential issues I havenāt thought of, please let me know. Nimian Legends BrightRidge is a very complex game and I want to attempt to do it as efficiently as possible.
I think the best bet here is actually going to be to have the CS component āassume the identity ofā the JS component, by having it remove/rename the JS component and then hijack the ID of the JS component from the .meta file. I believe this isnāt something the tool does today, though it sounds like something that it probably should. When this is done successfully, you will not need to recreate any components or copy/paste any values around - Unity will simply start using the C# definitions of your components instead of your UnityScript ones.
Unity wonāt have a problem with it, but your own code might - if you have both MyBehaviour.cs and MyBehaviour.js, then there will technically be two different āMyBehaviourā classes in your project, and this can cause problems such as GetComponent not returning what you expect. Iād say it is probably fine for scripts that youāre not actually referencing from elsewhere in code, but otherwise I would recommend against it.
Yes, hereās the relevant manual page. In effect, because C# and UnityScript code is compiled in separate assemblies, it means you cannot freely reference back-and-forth between the two languages. So, converting files one-at-a-time might not work well, depending on how much they refer to other scripts. Itās not something I would really recommend as an approach.
That said, there is a new feature in Unity 2017.2 called āAssembly Definition Filesā that can make life easier; it allows you to group scripts together into assemblies, above and beyond the special folders mentioned on that manual page. If you break your scripts up into assemblies using Assembly Definition Files, then you could convert your project one assembly at a time, and that should be OK. Note that you also get other benefits from using Assembly Definition Files, such as improved compile times.
At some point, we will release a version of Unity in which .js files do not work at all - it wonāt matter whether they were authored by you or downloaded from the Asset Store.
Roadmap-wise, we will probably not release that version for at least 6 months. Bear in mind that when we do, you will still be able to keep using older versions of Unity just fine - weāre not removing support retroactively. The UnityScript compiler is also open source, so it should also be possible to find a way to manually compile your scripts with it even after we drop support.
If we get a lot of questions, weāll consider it, but for now this thread is fine.
I wholeheartedly endorse this
Provided your project is backed up / committed to source control, you can try running the converter ASAP and then just throw away the results - thatād be the best way to find out how good of a job itās doing, and give us the feedback. Iām not sure if we will ever reach a point where it ājust worksā for everyoneās projects, but if thereās obvious things we can do to improve the tool and make the transition easier for you, we are interested in doing them.
Good to see, Unity is investigating in such a conversion-tool. But the current version / solution isnĀ“t easy to use. First, its a command-line method. Second, its outside unity. I hope the direction of this conversion-tool will be like all other assets integrated with unity, via *.unitypackage. Its simple to install. And It has a gui. And it should have something like a list function, where you can put as many *.js files into as you want and they all will be converted at the same time.
Thank you for the feedback. And I agree with sledgeman and your meta file suggestion. I dont know what meta files are although i have seen them in the project file, but it points to the notion that for a casual coder many of us dont use command lines,github etc. They are foreign concepts to me just like the use of composition and color theory may be forign to some professional coders (not all of course because some lucky people have a grasp on both skillsets). If The converter could eventually in Unity just convert in situ the scripts and preserve the settings, or at least the variables if not the script references to other scripts because i understand that these change one at a time, that would go a long way to making this change a positive thing and not a disaster for people who have already invested years in JS development - i hope you guys can make that work.
This is also beyond me but it sounds like it makes sense. Iām actually still using Unity 5.2 because it has great performance on mobile (which is where my games are released) so I couldnt use this, but its good to know there might be a solution when new versions of Unity are mobile steady.
This is my current backup plan. Ill stay on Unity 5 and it should be great - the only 2 drawbackas are 1) apple,xcode, ios etc change a lot so eventually Unity 5 might not be able to deliver an IOS 12+ compatible archive and 2) It locks us out of a lot of asset store purchases, although until know i am just buying incompatible ones because many of them still work undocumented in earlier versions of Unity
Anyways now that I know this is coming I will start experimenting with converting very carefully single files and porting in the values for some of my less critical files. I have some JS that communicate with CS and the link you sent will help. one thing I just want to put out there. i think most people at Unity are engineer minded, and its good to remember some of us dont have pro coder experience, use command lines, etc. I actually brought up my fear that this was going to happen a while back in this post: https://forum.unity3d.com/threads/will-javascript-become-deprecated.410416/#post-2877105 and I just want people to acknowledge that for many learning C# is a big deal. Some of the feedback ive been hearing is that its dead simple, but by not acknowledging how difficult it will be for us it feels like those concerns are not taken seriously or that somehow as an artists and casual coders we are not up to snuff. Unity was so accessible that even a javascript web designer like me was able to make a 120,000 selling open world rpg on mobile - i cant overstate how sometimes accessibility can be a large selling point for use of a software program, especially when it makes it inviting for web people who already work and will continue to work with JavaScript on the web. Im very happy that you answered everything so thoroughly and are honest about what is coming and although i would rather see UnityScript kept as a deprecated option and not removed to ease this transition, i know it is happening and at least by keeping us informed we can better prepare ourselves to try and solve this in our JS based games.
Iām one of 3.6% Already left my thoughts on the UnityScript deprecation on the blog post itself, but as for the conversion tool, I agree that it needs to be bundled under a standalone application instead of a command lineāthis should be pretty simple to do, and itās something that will make the process easier for all of us. Also, the tool should at least keep comments and as much formatting as possible.
Protopop brought up some good points on staying on Unity 5, iOS compatibility changes constantly, and the Asset Store has weird Unity version requirements as well. Luckily for me, I donāt build for iOS and I donāt use the Asset Store frequently, but other people arenāt as lucky. After my current project, I will be making the switch to C# and keeping up to date with newer Unity versions (As stated on the blog post Iām fluent in C# already, so switching will be easier for me). Iām just hoping that this transition is made as smooth as possible, this is a huge change for us UnityScript users.
I think it does this already? Otherwise only does half the job and would leave your project in a mess.
Currently it fails (stops converting) when it finds a class with a js Function pointer (not surprising but needs message). Then leaves the project in an uncompilable state since the new cs files need to be in plugins while there are still js files left that access those classes!
(error is āInternal compiler error: Object reference not set to an instance of an objectā¦ā)
Is there a built-in way to do this? Possibly an internal method we could reflect into? Currently the solution I have for changing the GUID of a file is pretty ugly:
public static void SetGUIDForAssetAtPath(string assetsFolderRelativePath, string GUID) {
var absolutePath = RelativeToAbsolutePath(assetsFolderRelativePath);
if (!File.Exists(absolutePath)) {
throw new FileNotFoundException("Not file at " + absolutePath);
}
var metaFile = absolutePath + ".meta";
if (!File.Exists(metaFile)) {
throw new UnityException("The file at " + assetsFolderRelativePath + " has no .meta file. If it has been recently generated, " +
"please use AssetDatabase.ImportAsset first to generate the .meta file. Can't set the GUID if there's" +
"no existing file already, sadly.");
}
var allLines = File.ReadAllLines(metaFile);
var newGUIDData = "guid: " + GUID;
allLines[1] = newGUIDData;
File.WriteAllLines(metaFile, allLines);
}
Could we get a preview for that? Iāve been wanting something like that for a very long time.
This happens because UnistyScript parser does not pass these comments along with the AST (sorry for the jargon) so the converter never see them. Weāll investigate some approaches to try to preserve comments.
Already left my thoughts on the UnityScript deprecation on the blog post itself, but as for the conversion tool, I agree that it needs to be bundled under a standalone application instead of a command lineāthis should be pretty simple to do, and itās something that will make the process easier for all of us. Also, the tool should at least keep comments and as much formatting as possible.