Script porting to Javascript

[Per]

I thought it was about time to announce it here, since the relevant code has already been merged. I am currently in the process of converting the Warzone scripting system to Javascript, using Qt. So what happened to Lua? The Lua porting ran into some difficulties that have been avoided this time around: First, the old and new scripting systems can run side by side, so there is no need to port everything at once now. Second, the backend code to run it is much simpler. Third, Javascript should be more similar to people used to Wzscript already than Lua. Fourth, and finally, we are no longer trying to convert existing code with a conversion script, since this resulted in rather ugly looking end results. The approach now is to rewrite things by hand, one script at a time. In my experience, the new code is half as long as the old code, even though it does exactly the same, and it looks much better.

In current master (sorry, no new snapshots with this yet), the scavenger script has already been converted and runs with the new script engine. I am working on fleshing out the API, so that the multiplayer game rules can be ported next. In theory, it already possible to write AIs in Javascript, but most important API calls are still missing their Javascript equivalent. Some help getting them ported over would be appreciated.

Once I have ported the rules, I will be starting on the campaign scripts. While I am at it, I intend to make some further changes. For starters, I intend to make it easier to add additional campaigns to the game, which will be especially important since I will be doing this conversion piecemeal as a new campaign, and I intend to make some long needed changes to parts of it. More on that later.

I will start to write some about the new API soon, and it is far from too late to make changes to it yet. As a small taste, I have attached the new scavenger script.

[Goth Zagog-Thou]

Ahh, very good Per. Any idea how long this will take to get fleshed out, and should we hold development on Campaign 4 until it's all converted over? No reason to do unneccessary work.

[Per]

It will take time. I have no idea how long. There is no need to hold development of anything else, though, since porting over to the new framework will not be hard. In fact, since I am doing this step by step, it should be possible to gradually phase in elements of it over time, as pieces get finished. I will keep you updated as things progress. For now, I recommend working against 2.3.

[Goth Zagog-Thou]

Not a problem. I've been building on 2.3 anyway.

[macuser]

YAY I love javascript!!! thank you thank you

[milo christiansen]

Time to start learning a new language I see....

After a little thought, This Is Great!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Lots of people know JavaScript so the number of potential scripters has just gone up

[milo christiansen]

One thing to keep in mind...

Tile coords are MUCH MUCH simpler for scripters to use compared to world coords, and for some functions there is no obvious reason to use world coords.

Most of the time I find my self just doing tile coords * 128 but if the functions were made to use tile coords....

For some thing this would obviously not work, for example anything that takes a x axis.

[Per]

Tile coords are MUCH MUCH simpler for scripters to use compared to world coords, and for some functions there is no obvious reason to use world coords.

Most of the time I find my self just doing tile coords * 128 but if the functions were made to use tile coords....

Interesting. Anyone of a different opinion?

The good thing about the current script coordinate system is that you only have one of them, whereas in the C++ code, you have two, and you never really know which one is expected before you look it up. I think a requirement for switching is that all javascript functions can use tile based coordinates, to avoid a mixture of coordinate systems.

[Zarel]

As far as I know, all numeric values in JavaScript are floats anyway, and floats can represent multiples of 1/128 with perfect accuracy, so I don't think using tile coords will be a problem precision-wise.

[Buginator]

Tile coords are MUCH MUCH simpler for scripters to use compared to world coords, and for some functions there is no obvious reason to use world coords.

Most of the time I find my self just doing tile coords * 128 but if the functions were made to use tile coords....

Interesting. Anyone of a different opinion?

The good thing about the current script coordinate system is that you only have one of them, whereas in the C++ code, you have two, and you never really know which one is expected before you look it up. I think a requirement for switching is that all javascript functions can use tile based coordinates, to avoid a mixture of coordinate systems.

That would break everything, so all scripts would need to be rewritten, and that isn't a small task.
Lots of functions in WZ itself would need fixing as well.

We could put this on the 10 mile long TODO list though.

[cybersphinx]

We could put this on the 10 mile long TODO list though.

We have a short version of the todo list?

[Per]

That would break everything, so all scripts would need to be rewritten, and that isn't a small task.

Note that this thread is about javascripts... in which case you'd have to rewrite stuff anyway.

[Zarel]

We had a script converter from WZScript to Lua... I assume a similar one would be made for JavaScript? Unless we intend to rewrite all the campaign scripts?

Oh, you're saying we might as well do the unit conversion with the script conversion. That makes sense to me.

[Per]

Unless we intend to rewrite all the campaign scripts?

... we are no longer trying to convert existing code with a conversion script, since this resulted in rather ugly looking end results. The approach now is to rewrite things by hand, one script at a time. In my experience, the new code is half as long as the old code, even though it does exactly the same, and it looks much better ...

Please re-read the first post above. It has all the details.

[Buginator]

That would break everything, so all scripts would need to be rewritten, and that isn't a small task.

Note that this thread is about javascripts... in which case you'd have to rewrite stuff anyway.

But that approach requires us to rewrite *everything*, not just a few scripts.

I rather port stuff 'as is' for the most part, so we can at least be sure that works as well as it did in the past, before we go throwing more wrenches in the way.