nice
Re: Client Update for 0.4 Released (2017-05-24)
« Reply #15, on May 24th, 2017, 07:05 PM »
There's just one question about that. How are we (excluding me since I can hijack the VM and perform an indirect save of the compiled closures) going to save the byte-code? Because I believe you have to be able to do that from the client itself. Probably an example is worth a thousand words:Quote from Stormeus on May 24th, 2017, 05:42 PM
- Added support for loading precompiled client-side scripts (i.e. .cnut files). These must be compiled on a 32-bit Squirrel instance.
Code: [Select] Hud.AddFlags(HUD_FLAG_CASH)
In this case, `HUD_FLAG_CASH` is a constant. That means it must be available at compile time. And the way you describe the process is that we can compile scripts with the regular Squirrel compiler and simply instruct it to save the byte-code.
The issue here is that any other application that embeds the Squirrel language will be missing the these constants and the client API. So you'll be getting a bunch of "index XYZ doesn't exist" when you try to compile it on anything other than the client.
In this case there are two choices that I foresee. First, implement a function like the `Include()` one (or add an optional boolean parameter) that after compiling and loading a certain script, it'll save the resulted byte-code into a similarly named file, except with the letter `c` prefixed to whatever extension the initial script name had. Would avoid hard-coding the extension as .cnut in case some people (don't underestimate some people!) use the extension .cnut on the actual script.
The second one. Is to create a standalone compiler that mimics the client API. Which to be honest, seems like an undesired overhead on further development and an easy way to introduce bugs and outdated/mismatching API.
hashtag @Stormeus :P
__ __ _ _ ___ ___ ____ _ __ ___ __ __
\ \ ___ / / | | | |/ _ \ / _ \| _ \ / \\ \ / / | \ \ ___ / /
\ \ / _ \ / / | |_| | | | | | | | |_) | / _ \\ V /| | \ \ / _ \ / /
\ \ (_) / / | _ | |_| | |_| | _ < / ___ \| | |_| \ \ (_) / /
\_\___/_/ |_| |_|\___/ \___/|_| \_\/_/ \_\_| (_) \_\___/_/
print the string, it'll be saved in the server logs :D
:edit: Oh, I guess VCMP won't recognize those characters and won't save it :P
The other way is to somehow save it to the debuglog file, which might store those characters. But, then,. TXT, notepad might remove it :P
Code: [Select]
__ __ _ _ ___ ___ ____ _ __ ___ __ __
\ \ ___ / / | | | |/ _ \ / _ \| _ \ / \\ \ / / | \ \ ___ / /
\ \ / _ \ / / | |_| | | | | | | | |_) | / _ \\ V /| | \ \ / _ \ / /
\ \ (_) / / | _ | |_| | |_| | _ < / ___ \| | |_| \ \ (_) / /
\_\___/_/ |_| |_|\___/ \___/|_| \_\/_/ \_\_| (_) \_\___/_/
if( !sucess ) tryAgain();
cool and mind fixing ghost shots so they're able to be made as they were back in the older versions? :D
There's just one question about that. How are we (excluding me since I can hijack the VM and perform an indirect save of the compiled closures) going to save the byte-code? Because I believe you have to be able to do that from the client itself. Probably an example is worth a thousand words:Quote from Stormeus on May 24th, 2017, 05:42 PM
- Added support for loading precompiled client-side scripts (i.e. .cnut files). These must be compiled on a 32-bit Squirrel instance.
<snip>
Prepared to fix vehicle locking. This fix requires a companion server update which will be released in the coming days.
BUT I'm totally ok with it ! :D
Welcome back, and thanks for the update !
I have some wonders though: will setting custom vehicles' handling be posible with this next server update ?