All Activity

Overall a 2x faster scripting language wouldn't really "fix" the game - some of it is overhead, but most of the time is spent in C++. WASM is interesting, but unfortunately not actually super easy to use. I'd rather not do assembly script but write in some other compiled language for it tbh.

Hmm strange I thought I linked the POC by wraitii for WASM. The problem is while it would speed up some of the code the bottleneck is the interrop between JS and C++ and WASM takes the same time. https://code.wildfiregames.com/D4653 I've also heard packagers complaining about LUA being a pain, not sure why (probably not worse than spidermonkey) maybe @vv221 would know.

This issue could happen with LuaJIT as well no? It uses a garbage collector too. Although it is right there is a limitation per process. LuaJIT also had issues with memory limitations and 64bit adresses in the past. It became mature only recently. I know web-browsers and a few web apps are putting a lot of energy into WebAssembly. Is there any consideration for AssemblyScript to speed up a few calculations without removing the whole easy-to-mod philosophy?

Great idea, leitoso. Luanti is a good example of a c++ engine with Lua modding interface. https://docs.luanti.org/for-engine-devs/script-engine/

Indeed, luajit did not exist at the time. Might have some more info here too There are some gains to be had with better datastructures https://code.wildfiregames.com/D1739 and more threading => https://gitea.wildfiregames.com/0ad/0ad/issues/5874 There are about 100k loc of JS and rewriting them would be a huge undertaking (Source I tried) But there is no silver bullet the reason js is slow is that there is a lot of computations happening at the same time, iirc gathering and the attack logic were the worst offenders. You can probably find some recent js profiling in gitea. And you can run the game under perf to see hotpath, IIRC one of the thing we spend the most time is rbtree_increment which is just a std::map code. There is also the ISQRT function, which performs fixed point square root computations. (That can't be replaced easily, else the game will quickly go out of sync on many platforms) EDIT: One of the big advantages I see about JS is that a lot of people know it. Whereas lua is a niche language unless you're a gamedev. There are many JS crash courses. Lua not so much.

thanks for this reference @Genava55, I think I have read in the past, looking now I see the same stuff, correct me if am I wrong, but it was basically a developers preference of language, which I agree in part, but the simplicity of Lua is so good that we can build our own conventions, and the scripting part of a game should be simpler, not a bloated object language like JS, and now TS which build complexity over the top of things. I like the remark of @Stan` and I believe he is talking about vanilla Lua, luajit I believe could be more closer to c/c++ performance once optimized and jit enabled. as you were talking about bottleneck, I cant see any with proof in hands but I see a lot of issues with 0ad open for hours and you start to see a lot of memory issues and warnings popping out in the logs, idk for sure if it is related to JS integration and leaking stuff but I think in the long run Lua could be more lighter and well rounded with memory and stuff - ffs Lua source and documentation is a little over 1 mb hehehe but I think I will finish my remarks about language wars here, I was much more interested in push a support for Lua in the "core" and these others things we can discuss in the future when we have more material proof to discuss. thanks @Seleucidsfor the tips, I will start there and put remarks and failures here so we can proceed with development thanks !

DE has player colored hero icons IIRC.

The incident is now fixed. Thank you for your understanding.

Yes it works, it copies a mesh of a house to get the dimensions and made a house on top. I made a primitive axe and a primitive spear and I was able to put them in the game without any problems, now I can't get this house.

I know nothing about these things, but if you take an existing thing, rename and import it: does that work?

Can I somehow load the mesh without texture into the program to test?

Stan, I don't know if the problem is with the texture or the object because it doesn't even open in the program. I've tried removing some textures and leaving only the base texture and it still doesn't open.

Idk if you know about it, but triple clicking the hero portrait on the top left will select the hero and take your screen to it. Usually I do a decent job keeping track of my hero and if I notice the portrait blinking when I don't expect it I go and correct my mistake. That being said this is still an amazing mod, a very good quality of life feature.

@SeleucidsWorks great! Thank you very much - extremely useful!

Hello please look at Sorry for the inconvenience.

Error de instalacion, la pagina de mods ni siquiera carga la respuesta del servidor; HTTP 401 Unauthorized

Also depends on how many more you expect them to make. Some players will make 12 or even less and then stop there and some will continue to make them. If you don't have enough cav to stop them or deter them you may still be able to look at their base and spot stables or extra hunts they may yet take. Another option not previously mentioned is to make a new wood storehouse behind your barracks, so that the camels need to approach your barracks to range your woodline. If the camel player ever has to look at his eco, then you may have a chance to jump through the barracks and kill some camels. Iberians are pretty limited vs camel rush but one of the few nice aspects is that if you have wood against the edge of the map there's only 2 approaches for camels to hit the woodline, so this makes a big difference for iberians' case.

There is currently no distinction between your own hero and enemy hero in terms of icon and colour. All visible heroes are shown as a yellow star.

This simple mod gives all heroes a star icon on the minimap, so that you will never loose track of your hero! It also has a positive side effect of showing if your farms are getting raided by an enemy hero. antiherorush.zip

A bunch of interesting issues closed on gitea, showing all the work behind the curtain: Stuttering and low FPS with Alpha 27 #7589 https://gitea.wildfiregames.com/0ad/0ad/issues/7589 Add workaround to turn off nursery size heuristic #7736 https://gitea.wildfiregames.com/0ad/0ad/pulls/7736 Incredible investigation by @Langbart: https://gitea.wildfiregames.com/0ad/0ad/issues/7714 I'm sharing this just to give a little visibility to the work and problem-solving done by the team.

This is great, I love it. We really are lacking technical explanations of 0ad despite me trying to go through bits of it in my channel. I clicked like and subscribed You can just paste the url link directly into here and it should embed automatically in 1 second, like this: This is my new video btw, where I rushed and boomed at the same time (maintaining highest pop and eco), then punished the champ cav spammer despite 1v2 situation.

The issue is really to do with hiding behind ally woodlines. But I am tempted to try these ideas now! Thanks for the replies !

In my experience in games vs the AI, I don't think it is. On medium and above difficulties, the AI is strong if left unchecked. That said, I'm mostly playing 1vs1 games. Not sure how performant would team games be.

Is JavaScript really the bottleneck? Are there specific cases where JavaScript is the definite cause of a lack of performance in a mod?