What Happens if I Stop Paying My Subscription Temporarily?

I have LOTS of older projects going back as far as Unity 4 and 5, most of which were done in JavaScript (UnityScript). The latest version of Unity I can open these projects in is 2018.2, which is the last version to offer JS support. I'm in the process of updating many of the older apps, so I haven't been getting the latest Unity releases, since I can't use anything more recent. But I'm still paying on the subscription.

I hate to be paying for updates I'm not using. What happens if I stop paying for a while, until I get caught up and can once again use newer versions of Unity? Unity will keep running, but will I lose my "Plus" [not Pro] status? Will I have to use a Unity splash screen? Does this sound like a bad idea?

BTW, dropping UnityScript is the WORST thing to ever happen to Unity, IMO. JS support is one of the features that initially attracted me to Unity. I used it almost exclusively for many years, since Unity 3. I don't have a problem with using C#, it's what to do with ALL those projects with ALL that JS code, many of which I'm still keeping current.

 

You will lose all the services and special features that are granted to you with your subscription and the next build will be without them, ie. splash screen will be shown. However since you plan to pause it sounds like you are not even affected by the financial threshold requirements and it raises the question that why are you even paying for the pro version? Plus version also removes splash screen and offers variety of services.

Unity offered conversion tools for UnityScript users so did you try them?

 

I misspoke. I currently have Unity Plus (used to be Pro under the old license). Still, it sounds like I would lose the benefits and go back to the Personal version.

I did experiment with a few C# converters a while back on some individual scripts. But I have not tried the one that Unity now provides. Converting a single script is a LOT different than converting an entire project. If all the Inspector settings are lost, that would make a big job even bigger. It's something I've been putting off as long as possible.

 

Yea, if you are not required to by revenue, and you are past your year commitment, stopping will just add the splash and remove your access to those other features. Which may not be a big deal if you are just updating projects and not releasing them at this point.

 

You could use Unity Hub. Use the current version of Unity for current projects, and an older compatible version for the JS projects.

I was using Unity JS for years, but then had to convert a project to C# for a game I was licensing out. As I had learnt C# for that, I converted my other projects as it was easier for working with C# focused SDKs.

Because of this I developed an efficient workflow for converting.

1. Create C# files identically named to the JS and copy-paste the JS code in.
2. The C# files would have loads and loads of errors, but most were just reordering syntax, or being slightly more verbose.
3. Add the C# file to each object where the JS file was and move so the components are adjacent. It is easy to look at the JS component and change the C# values to match, or drag in the same object into a field. Then delete the JS component.

It worked well by the third game, which had 14,000 lines of code. I converted the project in just over a day.

It make time if you have lots of projects, but Unity Hub does give you the freedom to have multiple versions of Unity installed and have projects automatically opened by the version you want that particular game associated with, so you can mix old and new projects using appropriate Unity versions.

 

I’ve come to love c#, but I agree that removing JavaScript makes the engine less accessible. I think in general unity is moving away from accessibility, and more towards performance. It’s a double edged sword because JS was what attracted me to unity too. I was a web designer and JS made the transition really simple.

I used the paid app Csharpatron to convert all the js in Nimian Legends. It was a huge project with hundreds of deeply interrelated scripts. But it helped me do it in a few days. You might want to check it out - I don’t think I could have updated such a large project without it.

@Ostwind makes a good point about plus. I use it and unless you need something pro specific, plus is a really comprehensive package and much less expensive.

Btw I remember unity 3. That island palm tree island demo really blew me away at the time

 

I understand it requires resources to maintain and update both JavaScript and C#. So why not just continue supporting JS at its current level without trying to make it keep up with C#? If there are additional capabilities not supported by JS, then C# would be an option. But, more importantly, JS would also still be an option.

Does it preserve Inspector settings and connections? I'm not too worried about translating scripts, it's setting everything back up in the Inspector that is most daunting to me. Is it the converter that Unity now provides?

 

I already have several past versions installed. I've found that updating older projects incrementally works best, too big a version jump, and the project gets scrambled. And since updating to Mojave, I have to use someone else's pre-Mojave machine for opening any projects saved pre-2017.

 

Everyone touched on what will happen if you cancel your subscription, but no one pointed out that when you restart it again you will have to go through the whole twelve month commitment process once more.

It's more complicated than that. Unity's JavaScript implementation wasn't written in C++ or C#. It was written in Boo which meant that maintaining JavaScript required them to maintain Boo too. Plus it's not like they were updating them as new features became available to C#. Like you're suggesting they were just maintaining them and that alone was too expensive.

https://github.com/bamboo/unityscript - original source code for UnityScript

To be honest though JavaScript is not that much easier than C#. Below is a very simple example taken from the official tutorials on scripting. The two main differences are the boilerplate code at the top of the C# script that is automatically generated for you and the fact that you need to specify return types for your functions.

https://unity3d.com/learn/tutorials...bling-and-disabling-components?playlist=17117

Spoiler: JavaScript Code

Code (csharp):

1. #pragma strict
2.  
3. private var myLight : Light;
4.  
5. function Start ()
6. {
7.    myLight = GetComponent(Light);
8. }
9.  
10. function Update ()
11. {
12.    if(Input.GetKeyUp(KeyCode.Space))
13.    {
14.        myLight.enabled = !myLight.enabled;
15.    }
16. }

Spoiler: C# Code

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class EnableComponents : MonoBehaviour
5. {
6.    private Light myLight;
7.  
8.    void Start ()
9.    {
10.        myLight = GetComponent<Light>();
11.    }
12.  
13.    void Update ()
14.    {
15.        if(Input.GetKeyUp(KeyCode.Space))
16.        {
17.            myLight.enabled = !myLight.enabled;
18.        }
19.    }
20. }

That said I'm a programmer so the reason why it's difficult is probably just sailing over my head.

 

The revenue problem can be solved with
subsidiaries

 

So do you run the subsidiaries at less than $100k a year or do you run the subsidiary company at less than $100k a year? What kinda games do you expect to put out in either of those situations?

 

I just found out the asset was removed from the store, the author talks about it here: https://forum.unity.com/threads/csh...ipt-to-c-converter.259847/page-2#post-4289425 and you may be able to get a copy from him. It was the right soulution for me because it has something called shadow mode. Im still foggy on ow it works, but it replaces all the scripts and most importantly preserves all of the variables and connections to other scripts.

I undertand why unity removed js too. I mean, i get it that its easier not to support it, so i dont begrudge them doing that. But it also created a big problem as you know for games made with javascript. Its one of those things where things change and there are some real benefits, and some real consequences.

 

If you make alot of money on your none game related business but not on your game related business that's a good model

 

So basically this only makes sense if you're running two unrelated businesses.

 

Or if you have several IP's which on their own do not make up to 200k but together do it.

 

Great, so then you're dealing with that much more management overhead, which itself costs more, which itself adds to those operating costs to get out of paying for a Unity license.

 

Yeah, that last example might not be that realstic. But there are probably many like me that have a blooming none related business and a IP that make below 200k

 

It's not that using C# is any more difficult than using JavaScript. All things being equal, either language is fine with me. It's a problem of inertia, and extra work. That's in addition to converting the older projects from pre-UGUI to UGUI.

I've been doing these conversions for a long time. Some of the oldest projects started out as HyperCard stacks in the early 1990s. They've been programmed in HyperTalk, Pascal, and Lingo before being moved to Unity/Javascript. So I'm not too happy about doing yet another major conversion. Hopefully I'll be retired before it's time for the next one.