Ceres - a WC3 build tool for Lua maps

[~El]

Following the announcement and release of 1.31 PTR, I almost immediately started work on Ceres - a build tool and script preprocessor for WC3 Lua maps, for working outside WorldEdit.

Right now it doesn't support much, however all the basics for developing WC3 maps outside the editor is there - a module system, a command-line interface, project folders... etc.

In the future I plan to use Ceres as a platform to develop far more interesting features and additions. One possible such feature is the inclusion of a standard suite of lua libraries for WC3, wrapping over the natives, much like Wurst currently has one.

Another feature I'd like to get working is live reload - rebuilding the project and then reloading the new script inside WC3, but that is still some time away.

README, Source code and compiled binaries for Linux and Windows can be found on github:
SamuelMoriarty/ceres-wc3

If you have any questions, suggestions or feedback, feel free to tell me!

 

[Cokemonkey11]

Why don't you just use wurst?

 

[~El]

Why don't you just use wurst?

Because I want to use Lua, not Wurst, and experiment with developing features that I need or want?

Don't get me wrong. I've used Wurst for well over a year and it was great compared to what we had back then. But right now, since Lua is an option, that's all I want, and I need the infrastructure necessary to develop in it. Some other people have also expressed interest in that, so I'm posting the project as public.

 

[Cokemonkey11]

> Because I want to use Lua, not Wurst, and experiment with developing features that I need or want?

Wurst is a compiled language. There are talks of enabling the compiler to emit target code in lua.

What are the features that you need or want, that you don't have?

> But right now, since Lua is an option, that's all I want, and I need the infrastructure necessary to develop in it.

Do you mean that you prefer lua the language, or you want things that lua can give you?

 

[~El]

Wurst is a compiled language. There are talks of enabling the compiler to emit target code in lua.
What are the features that you need or want, that you don't have?

I know there are talks about emitting Lua in Wurst, but what improvements that would bring to the language? Wurst was built around circumventing JASS's limitations and it sometimes shows. The way closures capture primitives only by-copy, but structs by-ref. Half the standard lib depends on LinkedList, which is entirely redundant in Lua. The way generics work in Wurst.

I'm just not sure what, if anything, will change for Wurst with the transition to Lua. It doesn't seem to me like Wurst's model of a typed, static language maps well to an untyped, dynamic language like Lua - which is to say, I'm not sure if it can take advantage of it without significantly redesigning language.

Do you mean that you prefer lua the language, or you want things that lua can give you?

I do have significant experience with Lua so it comes naturally to me, but also the latter. I appreciate Lua's dynamic nature and it opens up the possibility for a lot of neat little tricks which I just don't see Wurst managing to replicate without significant design changes.

TL;DR: I used Wurst because JASS and vJASS were shit. Since I'm comfortable with Lua and it's a really good language, I don't see a reason to use Wurst anymore, personally.

 

[Cokemonkey11]

> I know there are talks about emitting Lua in Wurst, but what improvements that would bring to the language?

Probably optimisation capabilities, but the wurst optimiser is not very exciting, either.

> Wurst was built around circumventing JASS's limitations and it sometimes shows. The way closures capture primitives only by-copy, but structs by-ref. Half the standard lib depends on LinkedList, which is entirely redundant in Lua.

Cool, good to know - thanks

> The way generics work in Wurst.

What is wrong with the way generics work in wurst?

 

[~El]

> The way generics work in Wurst.
What is wrong with the way generics work in wurst?

I feel like they are still very underdeveloped. I.e. no type bounds, primitives have to be coerced into integers via toIndex and fromIndex functions. In practice, this means that generics are only good for usage in collections - if you need to actually do anything with the generic type in the code you have to cast it, which is less than ideal. I understand a lot of that comes from the fact that JASS doesn't exactly make this job easier. Maybe this is one area where Lua support could help improve things significantly.

EDIT: I just saw there was also work to improve generics in Wurst, but since I haven't used Wurst for quite a while, my knowledge of it has been somewhat outdated.

 

[Cokemonkey11]

Thanks for the response!

Lua doesn't have generics at all, but you're right that it could provide some features that make wurst generics more powerful.

Personally, I view JASS as having similarities to C99, and LUA as having similarities to python. I hate all 4 of those languages.

Maybe some day I will try out your project anyway

 

[~El]

Thanks for the response!

Lua doesn't have generics at all, but you're right that it could provide some features that make wurst generics more powerful.

Personally, I view JASS as having similarities to C99, and LUA as having similarities to python. I hate all 4 of those languages.

Maybe some day I will try out your project anyway

You're welcome!

I still really like Wurst and it's great that it was built, but in the end I do have some personal gripes with some of the design choices - and that's fine. Lua has its own shortcomings, too, but it is nonetheless a really great language too, which I just happen to be much more familiar with than most other languages.

One area where Wurst unquestionably wins is static typing, which is something I can't dismiss the benefits of, but something I can live without for a while. In the future there's several possibilities of utilizing other languages that transpile to Lua that do have static typing, so that's something to look forwards to, I guess.

 

[Almia]

> Lua doesn't have generics at all, but you're right that it could provide some features that make wurst generics more powerful.
That's because Lua is a dynamic-typed language. We don't do type inferences here, we assert them.

 

[Cokemonkey11]

> Lua doesn't have generics at all, but you're right that it could provide some features that make wurst generics more powerful.
That's because Lua is a dynamic-typed language. We don't do type inferences here, we assert them.

Laughs in typescript

 

[MindWorX]

I've been using Ceres for a while and followed it as it's been developed. Already works great and a very good way to bridge some of the current shortcomings of making maps with Lua. Definitely keep up the good work!

 

[~El]

I've been using Ceres for a while and followed it as it's been developed. Already works great and a very good way to bridge some of the current shortcomings of making maps with Lua. Definitely keep up the good work!

Thanks, man! <3

 

[Trokkin]

Is there any forums or chats or anything for the community around ceres?

 

[~El]

Is there any forums or chats or anything for the community around ceres?

This made me make one

Join the Ceres Central Discord Server!

 

[yxq1122]

There are two parallel interpreters integrated in wc3 now: Jass and Lua.

So I suggest to provide support for Jass. Any map in whether Jass or Lua type could be built outside WE could be more useful and attractive.

Edit: your project is important and great. Continue your great work please! (★★★★★)

 

[~El]

There are two parallel interpreters integrated in wc3 now: Jass and Lua.

So I suggest to provide support for Jass. Any map in whether Jass or Lua type could be built outside WE could be more useful and attractive.

Edit: your project is important and great. Continue your great work please! (★★★★★)

Thank you for the positive reinforcement!

Regarding JASS...

There's several issues which I feel don't make adding support for it worthwhile. Some are technical, some are preferential, but in combination they make me hesitant to offer any kind of support for JASS.

1) There is already a lot of good and adequate tooling surrounding JASS maps. There is, of course, JassHelper with vJASS and Zinc, which a lot of people use, and which are now integrated into WorldEdit directly. It is also already possible to externalize your project outside of WorldEdit with JassHelper. There is also Wurst, which has an entirely out-of-WE workflow.

If you are talking about pure JASS, then I believe most people using it are already used to WorldEdit and aren't very inclined to switch to something else. It's the workflow that they're used to.

2) JASS by itself, in my opinion, is not a very interesting nor pleasant language to work with. As mentioned above, hardcore enthusiasts already have a workflow figured out for themselves, and they are unlikely to switch to an external tool for that. If you're talking about including some kind of vJASS and/or Zinc support in Ceres, that is further complicated by the fact that I'd have to essentially write a compiler for both of them, and that is simply not something I can do at the moment, virtue of not having a lot of time.

3) I personally believe that if you are starting from scratch, it is best to use Lua anyway. It has better performance, less quirks, is more stable, and overall far more flexible than JASS, and there is little reason to use JASS, other than, maybe, familiarity.

Overall, I don't think this is a time investment that would justify itself. Adding support for pure JASS doesn't feel like a very worthwhile endeavour to me, and support for vJASS/Zinc is too complicated. Either way, it would basically have to be an entirely different project from Ceres.

With all that said...

I think adding some kind of support for JASS code would be super-cool, however, it would be still compiled to Lua, and the primary benefit of that would be the ability to gradually migrate a project from JASS to Lua. This is something I want to look into in the future, but no promises yet.

As it stands, I have very little time on my hands at the moment, and adding native JASS support simply isn't on my radar because of that.

 

[Bribe]

I'm going to add my 2 cents here: the only reason JASS is supported by the editor is because of legacy support. Lua is a stronger language and can do things that modders often wished JASS could do.

 

[Trokkin]

There are two parallel interpreters integrated in wc3 now: Jass and Lua.

So I suggest to provide support for Jass. Any map in whether Jass or Lua type could be built outside WE could be more useful and attractive.

Edit: your project is important and great. Continue your great work please! (★★★★★)

Why do that, when JassHelper can already do what Ceres do with Lua? I mean, replace 'require' with 'import' and run JH from console?
Worked for me several years before I switched for a better language.

 

[Wrda]

I'm going to add my 2 cents here: the only reason JASS is supported by the editor is because of legacy support. Lua is a stronger language and can do things that modders often wished JASS could do.

Like what? Please give me examples.
Most people wont even bother moving to lua since they don't care about if it's more performance wise or if it is just better and not "garbage" like JASS. Nor they have the time for that, nor that will actually make the map better. The people who would be totally interested in lua are professional coders/game developers and of course people who code for fun and like coding in general.
I don't think (v)JASS would ever deprecate.

 

[~El]

Like what? Please give me examples.
Most people wont even bother moving to lua since they don't care about if it's more performance wise or if it is just better and not "garbage" like JASS. Nor they have the time for that, nor that will actually make the map better. The people who would be totally interested in lua are professional coders/game developers and of course people who code for fun and like coding in general.
I don't think (v)JASS would ever deprecate.

Even for people who don't want to go through the trouble of rewriting their maps in Lua or even learning it, there's still some benefit to be had from the fact that Lua exists in the first place.

Since JASS is such a relatively simple language, it is possible to transpile from JASS to Lua and attain a significant performance boost just from that. Blizzard already does that, somewhat, but there's some subtle bugs that make the conversion process prone to introducing weird and transient issues.

Theoretically, a separate tool could be made to automate this process and to fix those bugs in Blizzard's current implementation.

This isn't really relevant to the point being discussed at hand, but I think everyone can benefit from the addition of Lua, even people who don't use it directly

 

[Trokkin]

Like what? Please give me examples.

1. Less chunky syntax
2. Execute code directly
3. Callbacks with arguments, including vararg
4. Native lambdas with by-reference variable capturing
5. Code arrays
6. Dynamic memory
7. Classes and objects without non-unique ID referencing extra-large static arrays
8. No strict typing
9. Modifying environment at will
10. Dynamic code load

That's only the first things coming to my mind after two weeks working on my standart library for Lua. Yes, most of this is not useful to simple users, but not having interest is better than not having possibilities.

 

[Bribe]

Like what? Please give me examples.
Most people wont even bother moving to lua since they don't care about if it's more performance wise or if it is just better and not "garbage" like JASS. Nor they have the time for that, nor that will actually make the map better. The people who would be totally interested in lua are professional coders/game developers and of course people who code for fun and like coding in general.
I don't think (v)JASS would ever deprecate.

I mean the ability to call functions dynamically has huge implications for extending off of Damage Engine, systems like Timer32 and missile or knockback onLoop behavior.

Lua also allowing the overriding of natives and BJs which allows GUI people benefit incredibly while maintaining simple code.

So you are wrong. vJass is only useful for backwards compatibility. The options are much better in Lua.

 

[Boar]

Is this still being supported? It looks just perfect because I'm sick and tired of copy pasting script changes across.

 

[~El]

Is this still being supported? It looks just perfect because I'm sick and tired of copy pasting script changes across.

Sort of. I'm trying to work on it when I can, but seeing as the current version works 'okay', and I'm taking the time needed for the next release, which is going to bring some big changes.

Unfortunately right now I don't have a lot of time to focus on the project, so the progress is slow, but it's there!

 

[WaterKnight]

Like what? Please give me examples.
Most people wont even bother moving to lua since they don't care about if it's more performance wise or if it is just better and not "garbage" like JASS. Nor they have the time for that, nor that will actually make the map better. The people who would be totally interested in lua are professional coders/game developers and of course people who code for fun and like coding in general.
I don't think (v)JASS would ever deprecate.

It accelerates development at first. You don't need as much boilerplate code and integration of libraries/frameworks should be easier as the authors have more power, have to make less assumptions and require less action from the consumer. GUI users can benefit greatly from this. See [Lua]Obliterate all GUI leaks with 1 trigger!, for instance. Fast dynamic invocation of functions had not been feasible before, causing a toll on design. Writing less boilerplates and quirky code to cope with the shortcomings of JASS raises scalability and readability.

I still like typed languages (contracts) for the maintainability and analyzability benefits. Practically, in Lua, you would have to validate all the input parameters of at least public functions to not run into trouble or make the preconditions prominently visible, otherwise.

 

[iNfraNe]

I'm liking this thing a lot. Although I must say I don't even know if there are alternative ways of using lua in the editor for the time being. That said: for the time being, this seems to be a life-saver.

Now, there are some issues with bugreporting. Sometimes the code will compile just fine to a combined lua file, but end of not loading the map giving a blank error ingame (I guess the lua code checking is minimal / absent in ceres?). Of course, this will make bughunting impossible, and should somehow be fixed. Perhaps a way to 'save' in the editor, so you would get a bugreport through there? I'm not sure.

I hope the community here stops devaluing work because "you can just use old stuff we've had for 15 years" instead of using the brand-new implemented things blizzard are doing specifically to help us overcome some of the boundaries of those old things. I love that you're leading the way ahead (again, unless I'm missing other projects out there doing similar things that I've so-far neglected due to inactivity )

Cheers,

 

[~El]

I'm liking this thing a lot. Although I must say I don't even know if there are alternative ways of using lua in the editor for the time being. That said: for the time being, this seems to be a life-saver.

Now, there are some issues with bugreporting. Sometimes the code will compile just fine to a combined lua file, but end of not loading the map giving a blank error ingame (I guess the lua code checking is minimal / absent in ceres?). Of course, this will make bughunting impossible, and should somehow be fixed. Perhaps a way to 'save' in the editor, so you would get a bugreport through there? I'm not sure.

I hope the community here stops devaluing work because "you can just use old stuff we've had for 15 years" instead of using the brand-new implemented things blizzard are doing specifically to help us overcome some of the boundaries of those old things. I love that you're leading the way ahead (again, unless I'm missing other projects out there doing similar things that I've so-far neglected due to inactivity )

Cheers,

Hi, and thanks for the feedback!

There are other projects that are floating around, though I personally have not really looked into them.

Regarding the error checking and other things - there's definitely some things that can be improved. At the moment I'm trying to build the "foundation", which has been somewhat challenging with my limited time availability. I recently returned from a prolonged business trip and will be pouring more time into Ceres again. If you can provide test samples that compile fine, but fail to load in-game, that would be very helpful. There's probably additional analysis that I can perform on the emitted code, and having a "broken" example would help a lot.

Once again, thank you for your patronage

 

[iNfraNe]

I see, perhaps someone should make an overview thread (or does this exist? Again, I haven't really looked xD) of early development so we can all learn from eachothers successes/failures (or is that against the competitive nature of wc3 modding xD)

An example which gives an error would be requiring a file with a case mismatch.

hello.lua:

Hello = {}

main.lua:
require("hello")

I should note I didn't test this specific example. If it does work, I'm sorry, I'll give another example later

 

[Wrda]

Lua syntax sucks though, you see

function DomyStuff()
    --blabla
    if MyCondition then
        for i = 0, 10, 1
        do
            --other stuff
        end
    end
end

Now imagine this piece of code multiplied inside more times and you'll get confused with the keyword "end". "end" what? endfunction? endloop? endif? Seriously that just stinks.
Another thing is the dynamic types are lame.
I won't be able to code in lua because I would like to code it alternating with vjass/jass, I hope they manage for us to be able to do that, and no, I don't want to keep another old version of wc3 1.26 and use some other program for that. That's a complete regression for me.

 

[Bribe]

Lua syntax sucks though, you see

function DomyStuff()
    --blabla
    if MyCondition then
        for i = 0, 10, 1
        do
            --other stuff
        end
    end
end

Now imagine this piece of code multiplied inside more times and you'll get confused with the keyword "end". "end" what? endfunction? endloop? endif? Seriously that just stinks.
Another thing is the dynamic types are lame.
I won't be able to code in lua because I would like to code it alternating with vjass/jass, I hope they manage for us to be able to do that, and no, I don't want to keep another old version of wc3 1.26 and use some other program for that. That's a complete regression for me.

Dynamic types are fantastic at simplifying data attachment. Also, C-based syntax uses semicolons which is even less verbose than "end".

 

[~El]

Lua syntax sucks though, you see

function DomyStuff()
    --blabla
    if MyCondition then
        for i = 0, 10, 1
        do
            --other stuff
        end
    end
end

Now imagine this piece of code multiplied inside more times and you'll get confused with the keyword "end". "end" what? endfunction? endloop? endif? Seriously that just stinks.
Another thing is the dynamic types are lame.
I won't be able to code in lua because I would like to code it alternating with vjass/jass, I hope they manage for us to be able to do that, and no, I don't want to keep another old version of wc3 1.26 and use some other program for that. That's a complete regression for me.

Can we please keep discussions of lua syntax out of this thread? I would really appreciate it if this thread didn't devolve into another long-winded argument about the merits and downsides of Lua.

Nobody is forcing you to use it. You can keep using JASS if you want to. You can also use C# to Lua or TypeScript to Lua, and have the luxury of a statically-typed language with a familiar syntax, if you are so inclined. There's also about a half-dozen other languages that can be compiled down to Lua, so your choices are very diverse.

I will admit I am not a huge fan of Lua myself, and one of the things I want to do with Ceres is to build a minimal, typed language with C-like syntax on top of it for the reasons you described. With that said, I don't think that it is actually really that bad. I wrote a lot of Lua code in my time, and lots of other people I know did too, and we managed just fine. While Lua has its own problems, the issue of locating nested blocks by eye and stuff like that has never been an issue. That's what we have indentation in our code for. Python manages completely fine without any block delimeters at all, and it's a very popular language.

EDIT: If you want to be able to mix JASS code with Lua, I think that can also be accomplished with Ceres. Would you be interested in a feature like that?

 

[MyPad]

Now, there are some issues with bugreporting. Sometimes the code will compile just fine to a combined lua file, but end of not loading the map giving a blank error ingame (I guess the lua code checking is minimal / absent in ceres?). Of course, this will make bughunting impossible, and should somehow be fixed. Perhaps a way to 'save' in the editor, so you would get a bugreport through there? I'm not sure.

As far as I've tested in Ceres, trying to access an index of a nil value will cause the map to not load properly when compiled. This is one thing ignored in the compiler, as far as I've tested it (writing up UnitEvent, World, and DamageEvent)

UnitEvent

if UnitEvent.registerflag then
    ceres.addHook("main::before", function()
        print("Something went wrong. Try again")
    end)
end

 

[~El]

As far as I've tested in Ceres, trying to access an index of a nil value will cause the map to not load properly when compiled. This is one thing ignored in the compiler, as far as I've tested it (writing up UnitEvent, World, and DamageEvent)

UnitEvent

if UnitEvent.registerflag then
    ceres.addHook("main::before", function()
        print("Something went wrong. Try again")
    end)
end

My guess it that if a runtime error occurs when WC3 is trying to load the map script, it will abort loading the map with a cryptic error box. IMO this isn't really an issue in Ceres itself as it is an issue with WC3 not properly reporting error messages. It should be really trivial to just print out the lua error when that happens, and display it. In order to check for these kinds of things in Ceres I would have to actually do a test run of the map script after compiling it... Which might not be a terrible idea in general.

 

[Wrda]

Dynamic types are fantastic at simplifying data attachment.

Well, I would like to see an example of that. The only thing that comes to my mind is functions.

Also, C-based syntax uses semicolons which is even less verbose than "end".

Actually it uses { }, semicolons are for a new line. You don't see in jass typing "end" at the end of every line, that would be insane lol

Can we please keep discussions of lua syntax out of this thread? I would really appreciate it if this thread didn't devolve into another long-winded argument about the merits and downsides of Lua.

Nobody is forcing you to use it. You can keep using JASS if you want to. You can also use C# to Lua or TypeScript to Lua, and have the luxury of a statically-typed language with a familiar syntax, if you are so inclined. There's also about a half-dozen other languages that can be compiled down to Lua, so your choices are very diverse.

I will admit I am not a huge fan of Lua myself, and one of the things I want to do with Ceres is to build a minimal, typed language with C-like syntax on top of it for the reasons you described. With that said, I don't think that it is actually really that bad. I wrote a lot of Lua code in my time, and lots of other people I know did too, and we managed just fine. While Lua has its own problems, the issue of locating nested blocks by eye and stuff like that has never been an issue. That's what we have indentation in our code for. Python manages completely fine without any block delimeters at all, and it's a very popular language.

EDIT: If you want to be able to mix JASS code with Lua, I think that can also be accomplished with Ceres. Would you be interested in a feature like that?

I never said I didn't like lua, I just made my personal rant about some things I don't like about it, rest of it is pretty great. That's the reason I would like to use it with vjass/jass. Usually I'm not a guy who likes to use 3rd party stuff, unless I really have no other choice, but there are also people besides me who would also like to use lua mixed with vjass/jass. I think that would be pretty useful and powerful.

 

[Trokkin]

Well, I would like to see an example of that. The only thing that comes to my mind is functions.

SetUnitUserData(u, {whatever, i, would, like, to, put, in, here})

I doubt it would work though, since natives still (seem to) expect correct types. But if you write your own, it would be only one function to do the attachment and only one to get it.
Hashtable (now useless) has a set of HasX, SaveX, LoadX for each type X, and jass would require you to repeat that for any data attachment you'd like to have.

that would be insane

Still you type call/set keywords before every line, insane

 

[Drake53]

But if you write your own, it would be only one function to do the attachment and only one to get it.
Hashtable (now useless) has a set of HasX, SaveX, LoadX for each type X, and jass would require you to repeat that for any data attachment you'd like to have.

I think it's a bit unfair to compare this use-case to how it needs to be done in jass, since we all know jass sucks compared to modern languages.
That said, if I had to do this in for example C#, I could simply use either generics, or objects and then cast the types. Is there any benefit of having dynamic types here, or could you maybe provide a different example where dynamic types are a solution, but the two I mentioned wouldn't work?

 

[~El]

I think it's a bit unfair to compare this use-case to how it needs to be done in jass, since we all know jass sucks compared to modern languages.
That said, if I had to do this in for example C#, I could simply use either generics, or objects and then cast the types. Is there any benefit of having dynamic types here, or could you maybe provide a different example where dynamic types are a solution, but the two I mentioned wouldn't work?

Dynamic typing is generally considered to be an aid in rapid prototyping. Languages which have dynamic structures like Lua's tables (think JS, TS, etc.) do not force you to think about your types ahead of time, which can be useful when prototyping and experimenting with something, and it can be a legitimate time saver. It creates less friction during development as a result, which means you can do the same thing you'd do in a typed language like C# or C++ but way faster. Of course, that also means that you pay the price of not having a proper type system down the road, which can really hurt you if your codebase starts to grow big.

I think the best of both worlds are languages that have good type inference but which are still statically typed. A lot of modern languages are starting to introduce better and better type inference, and I think that has diminished a lot of the benefits of dynamic languages. Still, sometimes dynamic languages are more convenient because the barrier of mental friction is simply lower than their static alternatives.

 

[Jilaer]

Following the announcement and release of 1.31 PTR, I almost immediately started work on Ceres - a build tool and script preprocessor for WC3 Lua maps, for working outside WorldEdit.

Right now it doesn't support much, however all the basics for developing WC3 maps outside the editor is there - a module system, a command-line interface, project folders... etc.

In the future I plan to use Ceres as a platform to develop far more interesting features and additions. One possible such feature is the inclusion of a standard suite of lua libraries for WC3, wrapping over the natives, much like Wurst currently has one.

Another feature I'd like to get working is live reload - rebuilding the project and then reloading the new script inside WC3, but that is still some time away.

README, Source code and compiled binaries for Linux and Windows can be found on github:
SamuelMoriarty/ceres-wc3

If you have any questions, suggestions or feedback, feel free to tell me!

I can not "ceres build mymap.w3x"

 

[~El]

I can not "ceres build mymap.w3x"

Okay. Do you have more information?

 

[Jilaer]

I answered you before, but I don't know why I was rejected by the website. Now I have a new question. "Runconfig is nil"

 

[iNfraNe]

Hi Jilaer,

You need to have a ceres.toml file in the directory, containing something like this:

[run]
wc3_start_command = "C:/Program Files (x86)/Warcraft III/x86_64/Warcraft III.exe"
window_mode = "fullscreen" # other possible values: fullscreen, windowed, windowedfullscreen

Cheers,

 

[GetLocalPlayer]

 

[~El]

Is the map under `maps/map.w3x` ? Are you using the latest released version?

 

[GetLocalPlayer]

`maps/map.w3x`

Are you using the latest released version?

Yes.

 

[~El]

I've published a big update for Ceres. Here's a summary:

The theme of this update is refinement and stability. It focuses on documentation and usability, as well as fixes for minor issues. Ceres can now be declared more-or-less stable, both in terms of bugs and in terms of API changes. I do not expect significant changes to existing APIs starting from this release.

All repositories have been moved to the ceres-wc3 organization on GitHub.

Documentation for Ceres itself has been updated. In addition, Ceres now provides a TypeScript declaration file documenting its entire API surface: ceres-wc3/ceres-decl

Template repositories have been created for Lua and TypeScript:
ceres-wc3/ceres-ts-template
ceres-wc3/ceres-lua-template

And last, but not least, I'm very glad to announce the first release of Cerrie, a WC3/TypeScript library which aims to provide an idiomatic set of APIs and wrappers over JASS types and natives. Cerrie also provides other utilities such as File I/O, object id generation, and Live Reload! Cerrie should be used as an NPM dependency in TypeScript projects, finally bringing the benefits of dependency management to WC3 TypeScript projects.
ceres-wc3/cerrie

On instructions for how to setup Cerrie, check out the cerrie branch of ceres-ts-template:
ceres-wc3/ceres-ts-template

The full changelog and release binaries can be found in the Ceres repository: ceres-wc3/ceres