sanderd17

Because '=' sets the reference value. I don't know the GetSmoothedHeightmap function, but since you say the heightmap isn't edited, the GetSmoothedHeightmap function must make a new object in some way. That means the heightmap variable will hold a different address after the assignment. In JS (at least with the SpiderMonkey implementation), every new object causes a new "type" to be made in the background. That type holds the information of the available keys, and the types those keys can store. Creating of modifying such a type can cost some time. The bigger the type, the more time it costs. That's why deleting a key (with the delete keyword) is no good idea. Adding keys goes quite fast. Modifying the type a key can hold is somewhere between the two. So when you can modify the existing heightmap into the smoothed heightmap without changing the type while doing that (so only assigning numbers to the keys that already had numbers assigned), it should go a bit faster. But for smoothing, you probably have to access some neighbours that were already processed. To remember that, you either need to introduce new keys to solve the old value (which isn't good, as those keys become part of the type, while it isn't needed for further processing, and it causes more memory usage than needed), or you need to store it in a separate object, which isn't good either, as you're constantly cloning parts of the heightmap to separate objects. So I think, for smoothing the heightmap, creating a new object would be the best option. If you'd have to f.e. level up the heightmap with 1 meter. Then you don't need the old value of the neighbours, so you don't have to copy values in some way, which means it will be faster to edit the object directly.

Normally, passing around stuff (even if it's big) between JS function doesn't cause performance problems. That's because everything is passed by reference. Iterating over big arrays multiple times, or passing big objects through the Engine to other parts of the code (either C++ code or other scripts) does cause performance problems, as the Engine has to clone the JS values.

First of all, the unit size reported to the engine is not always the visual size. F.e., units are considered round or square (to make calculation easier), which causes long units (like cavalry or ships) to be able to go through each other. If we don't want to cause more lag, this won't be fixable. But what I see here, is probably a result of some formation behaviour. When units are in formation, they are allowed to walk through each other to reach their position in the formation (otherwise it would be impossible to reach certain places in the formation). If you stop them right when they'll walking through each other, they'll stop inside each other. There isn't a lot we can do with the current pathfinder, so we'll just have to wait for the new pathfinder.

Adding more detail can be done by moving the sail texture to a separate file, that frees up a lot of space for the other stuff.

Oil was very common in some regions (there was quite some surface oil in the middle east), and couldn't be used for a lot of purposes (no fuel, no plastics ...), so it was more of a waste product than anything else.

The .cat extension, and saying it's from Barcelona already gave away something

Those are old files and should get replaced some time. The new files are all in png format.

AFAIK, that code was all JS. So there are no types, which means noting something as 2.0 isn't needed. Also, the compiler can do strange things when it comes to optimisation, and you'll notice that none of your replacements will make any difference. Not even in micro benchmarks. And it's not even sure the compiler will kick in. These aren't really optimisations that will make the RM generator faster. Instead, the placement algorithms have to be made better, but that needs template information.

In Linux, I use GDB, I don't know what tools are used for Windows. I guess something is build in VS. This bug is most likely OS-specific (or even driver-specific). So debugging in Linux makes no sense. Can you join #0ad-dev (best in the evening), and try to contact historic_bruno, Philip, or maybe leper?

Also, the report only mentions a null pointer (with an offset of 4). As null pointers cause immediate crashes (and prevent the engine to do any useful logging), they can only be fixed with dedicated tools. Which means we need a way to reproduce it consistently.

It's not in the main game AFAICS, so it's not really a bug report.

It will teach you too much for now. It's more important that you learn various ways to structure your code (like the object-oriented model) than learning about the specific details of different compilers. You'll have to learn those details later to write fast code. But you'll first have to write readable code. If you code something, check it again after a week, and see how much you still understand, even understanding a small program that's badly written will be hard. I suggest you look for an introduction to object oriented programming in your favorite language. You can also look for different methods (procedural, functional, logical...), but object oriented is used most. The language doesn't generally restrict your coding style to a specific method. But some languages are more suited for some methods. Like Haskell is mainly for functional programming, JS can be used for functional and object oriented programming, Java and C# are mainly for object oriented programming...

The scale thing is only a matter of art, it won't be related to the simulation (to affect walking speed f.e.) as that would only complicate stuff. Also, different scales in 3 directions will be hard to do, as the normals will be influenced, so the normal map won't fit anymore. I only plan a scale with a single float (possibly a random float in a range). Though actors (like shields, swords ...) could scale differently then their parent when wanted.

I meant the "we" as in the regular, mortal programmers Enrique was having trouble with unit meshes and scales. So I thought I'd mess a bit with scales. I have a working prototype now, but I still need some input on what's actually wanted. Yes, it's shaping up nicely. Basically triggers will be set by the map maker (AI can't add triggers), but triggers are part of the simulation, so they can be made accessible to the AI via the AIInterface. The triggers are very liberal though. So I don't know if the AI would be able to gather a lot of info from it.

Also, there are many features still needed in this game, but the most important ones require a thorough knowledge of big part of the codebase, as well as a very good knowledge of all related algorithms and solutions. So that's not something to start with. The most important thing is that you get acquainted with the code first.

That's something reserved for approved team members (or donators). Since I guess the CoM will be open for everyone (without approval), I don't think it will be possible to set that image. We also have no rights to change the image, only the forum maintainers can.

Windows doesn't limit you in your ability to code, but it does somehow limit you in what apps you can use to code. Like for compiling the game, we only support MS Visual Studio. And since you need visual studio anyway, you can start with C# too. It's like Java (strongly typed with automated memory management), but this way you'll also get to know the development environment you can use for C++ (and getting to know all sorts of debug tools is important too). In any case, all languages we mention: C++, C#, Java and JavaScript all have syntax that's based on C syntax. This means that their basic features all look very alike. int fac = 1;for (int i = 1; i <= n; i++){ fac *= i;}The example above is a (quite naive) method to calculate the factorial of 'n'. And it will work in all mentioned languages (except in JS, where you have to drop the 'int' types, as JS has no types).

Git is designed so the repo is always in a stable state. This means, when an operation fails, git automatically reverts itself. That's the problem causing the difficult first checkout. If you pull the changes regularly, it's very rare a single pull will take more than an hour. So then you shouldn't have problems.

You don't need to make an application as programmer. You can just start with a ticket you like (our any feature/bug, even if it's not part of a ticket), send in a patch for it, and we'll review it. All our tickets (also a small list with beginner tickets) and some guidance to get started can be found on trac.wildfiregames.com. If you have questions or you just want to discuss something related, you can normally find some of the devs on the 0ad-dev irc channel on quakenet.

I had to try 3 or 4 times (every time it failed after downloading over 1GB), only to see it fail. If the internet just drops every now and then, it can't be resumed via git. I also had to try a few times with svn, but the resume was very handy.

There was a fundraiser some months ago, and one of the perks was a t-shirt. We won't just start to do merchandising, as it costs way too much management time.

Basically, learning to program just requires a lot of time. Writing code that doesn't work, and then trying to understand why it doesn't work. Because of that, you need to pick something that really interests you. When you have chosen a task, you can always ask for help (and you should).

Well, there's not that much. And the references there are mostly related to the orignal civs (celts, hellenes and rome). It doesn't get used a lot to share references now. Most references come from Lion I think.

References that aren't historical (I.e. impressions by other artists) are always copyrighted. So they can be used as inspiration, but can't be distributed publicly (there's no problem with sharing it with a select circle of friends though, most countries have such an exception in their copyright law).

Right, we have an art repo, but it's not public due to copyrighted material in it. There were plans to make a new, public repo, and maybe even move old stuff from the private repo to the public one. But I guess we need to get this started again.