Why does not unity provide us with a hot-update jitter? like lua or whatever.....

I am curious…why not…one jitter integrated with unity…

Your question is very ill formed.

Are you referring to Max/MSP?

And what do you mean by why? Why could be as simple as, they didn’t want to.

If you’re attempting to accomplish something that can easily be done via some library you’re used to using in Lua… well, what are you attempting to accomplish? Maybe we can direct you towards a method of accomplishing it.

1 Like

it is not simply the library, but some code could be executed just in time…you know without compiling.
here in china, many people try to find a way to do that in unity like lua jitter, which is now pretty good.
but that is not so good in integrating with unity… no inspector, no way to reference variables and no way to debug…

Are you talking about interpreted languages? I am wondering where the word “jitter” comes in.

.net is a JIT (just in time) compiled language. So I’m not sure what you mean by ‘just in time’ in this context.

If you mean interpreted, well sorry… .net isn’t interpreted. Though you could use ‘eval’ to interpret strings of javascript (with certain limitations).

You still haven’t answered the question though. What are you trying to do?

yes…

Interpreter, I am sorry my major was not computer, so I dont know the exact term…
It not I am trying to do it ,but many developers do it…without it your game will not be favoured by the consumers

are you talking about mod support? i.e. users creating script files to be handled by your core game etc.?

Why would you need an interpreter to be favoured by the consumer?

If you want mod support, Mono/.net can load in .net dll’s dynamically at runtime and access them. So really, yes, you can support mods created by the consumer.

It is not the Interpreter that the consumers favour, it is the Process brought by an interpreter…
If you release a new version of your game, the consumer have to download it and reinstall it. but if your code is running in an interpreter, the client could download only the text - code. it saves net data and does not need a new new package or reinstall the whole client which could be a bother for the consumers…
what the consumer want is : open you app, play - open and play , open and play…
they dont want to see a pop up doalog telling them to reinstall.

Yes, but interpreters are slow.

You’re talking about patching. You can patch code that isn’t interpreted.

The built version of your game is still just a collection of binary asset packs, mono/.net dll’s, the unity game engine, etc. You can replace just the files that are necessary to update it to the latest version. The dll’s being the ‘code’ part of your game.

I know how to update assets, but How to update dll or code? apple won’t allow you to do it…

First off, Apple is a special case, because they don’t allow code that isn’t compiled directly for their machine. This is what Xamarin is for with Mono. Instead of running JIT code on iOS, you have to compile the code ahead of time (hence the name AOT, ahead of time).

Here’s the thing, the same goes for interpreted code. From Apple’s developer guidelines:

As for updating dll’s on Windows, Linux, OSX, etc… you just overwrite the old dll with the new.

well, thx, I thought unity would provide a built - in interpreter for us…

For AOT architectures (iOS) it’s not allowed to support them.

For JIT architectures (Windows, Mac, Linux, etc), Mono/.Net directly supports JIT code, dynamic loading of libraries (.dll) at runtime, as well as any interpreter written in .net/mono.

For example here is a javascript interpreter written for .net called Jint:
https://jint.codeplex.com/

There are also Lua interpeters out there for mono/.net (as opposed to compilers that compile lua to CIL which can be ran directly in mono/.net).

One of the benefits of Unity using Mono is that it gives you access to anything out there that can be ran in the version of Mono that unity runs (note, it is a little out dated, most everything .net 3.5 or earlier will run).

Unity doesn’t directly supply these things because they already exist. They supply a game engine, and the API into the game engine, and an architecture to allow novices to get off the ground. For the more complicated stuff like you’re asking, Mono gives you the freedom to tackle that problem in your own manner. Instead of locking everyone into the same thing, that most of us won’t need.

1 Like

each time you release a new version in the mobile platform(fix bugs or whatever),
you force and bother consumers to reinstall it, that could make you lose some consumers.

  1. mobile games are usually small anyways, the user doesn’t necessarily have to be told they’re ‘reinstalling’. All they know is an update is being installed… may that update overwrite everything, or some of, the original install isn’t here nor there, as the average consumer doesn’t know the difference.

  2. mobile versions of your build STILL have the code and the binary assets in different files. This means you can download JUST the code file if that’s all that needs to be updated. An interpreter IS NOT needed to support this. Rather an interpreter would impede your ability to support that as it would NOT be allowed on iOS in the first place.

I’ve pointed out repeatedly that what you want is ALREADY AVAILABLE with out the need for interpreted code.

You seem to be of the opinion that to update code it needs to be interpreted, or JIT. But it does not. The code is just a file like any other… update the files that changed, and that’s it.

3 Likes

I think there are some games on the Apple store that try to fly under the radar and patch their games without Apple knowing by writing large parts of it in Lua and sneaking in a Lua interpreter, and then sending the updates as text files, sort of disguised as content file updates, from the web. I think Apple frowns upon that, and I don’t think customers actually like it very much. Anyone who turns off automatic updates on their iPhone probably wants to see when things are updating and be able to say no, otherwise they wouldn’t have turned it off. I think devs do it more to allow patching bugs constantly without players noticing that you’re updating the game like fifty times a day because that looks really bad.

1 Like

OK, thx…

I don’t think that’s the primary reason. Apple takes its sweet time (10 to 14 days) to review store submissions, which is way too long if you need to push a bug fix.