leper

Nah, making it easy would be linking to the Getting Started Programmers wiki page too.

(Well if people want to make games lag by doing that during the game they will have to either stop doing that or speed up those computations.) For the Atlas issue only one possibility would be to only recompute all that sim-state once modifications are done (or at least most of them that don't change what is displayed). So the slider would work nicely, but we'd have to tell the simulation to stop recomputing once the slider starts moving, and stop when it stops moving. The same could (should) be done for terrain modifications, where the start/stop points are a lot easier to define than the moving part.

If the line is in local.cfg or user.cfg remove it instead of changing it.

Or set the XDG variables to whatever you want (though that applies to all applications, but you can set it for one program only if you use an alias or a script or possibly some desktop file).

That's what the dmp file is for (which as one could guess is a dump file of the program state), but for debugging those one needs a Windows development environment.

Since the translations are updated all the time, it would be better to use the SVN version of the game (else you will not see most translations at all). Also one can place the files in the corresponding mod folder in the user modifiable path (or in the user mod if one is especially lazy and can deal with the breakage later). Also just placing the files next to the zip, but with the correct folder structure also works (take care that the file timestamps are more recent than those in the zip). This is however slightly uglier than just using the user writeable mod folder.

Getting support from VS2015 merged first (which depends on merging premake5).

Done.

The number of serious 3D game engines written in anything but C or C++ is not very large. Both of these languages can be quite close to the hardware, which is sometimes needed to make things performant (yes, we aren't there yet, but that is just lots of work). With Java you'd either be trying to work around the garbage collector by keeping memory buffers yourself, or having to deal with those GC pauses. Python still has that global interpreter lock (which is just as bad as it sounds), and we do already have another scripting language with quite some code written in it, and it works well enough that nobody really considers porting it to something else that will just have different drawbacks a worthwhile effort. Mostly C++ is one of the very few choices for a game engine that makes sense (mostly due to being close to the hardware if needed, and being able to use libraries). Java might be a fine choice for business applications where you can just throw bigger servers at it and tune the GC until it works good enough, but for a 3D game (engine) it might not be the best choice. For Python vs JS the former might be nicer from a language standpoint, but that doesn't change the issue of existing code that works, also we do benefit from JS engine optimization efforts.

Thanks for both following up on the report and keeping us updated!

Might I suggest reading through your questions a bit more before posting them? That should result in better questions that could even result in actual answers. Right now most of these just seem like a random bunch of words from which one could maybe derive some question if one spends more time than you did while asking it. Also caring about questions by people on a platform where the average attention span makes a Higgs boson's lifetime seem long is nice, but if you are only investing about as much time into relaying such questions you aren't going to get anything that resembles an answer. (Slightly unrelated, but you might also want to keep that pointless thread bumping and necro posting down. Actually adhering to the first part of your signature might do wonders.) That said 3D RTS engines tend to look similar, especially if the art style is similar. Also the Age of Empires series is one of the bigger influences, so some similarity should be expected. But then comparing a few screenshots from a few historical 3D RTS games (more specifically buildings) will show quite some similarities. One of the reasons for that is having game entities look familiar to players new to that specific game, but not to the genre itself (compare barracks layouts which do tend to be U shaped). But anyone spending some time thinking about the whole issue should be able to deduce that those similarites are caused by the type of game being made, quite similar to FPS games really.

Useless use of cat. You could just specify the file grep should use. (See http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html.) Or since you are already using pipes, just use commands.txt as the input. That said this looks very much like a perfect use case for sed, which has the stunning ability to delete lines (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html), and quite a few common implementations provide a parameter to do that replacement in-place (-i). Happy shell golfing.

Does anyone actually read more than the first half of the second sentence when seeing those messages?

No. The code or data files should be fixed so that those errors do not occur. Hiding them or adding the ability to hide them will just result in nobody reporting them (as they are hidden) and nothing will get fixed.

Nice to see this! I'll repeat something I said in an internal discussion related to possible campaigns. You neither need to necessarily have the player defeat the enemy to "win" (or rather end) a scenario in a campaign, nor are we limited to telling the story from only one side. Switching sides might be a lot more relevant for a possible Second Punic War campaign though.

Units only switch targets if tasked to do so, or the current target dies. Adding direction/rotation to the simulation is most likely a lot harder than wraitii assumes.

Let me be the first to say TL;DR. I did notice a part about directionality, do note that the simulation has no concept of unit rotation (or rather rotation speed, so a huge ship can and will rotate instantly). About provinces instead of territories I suspect this will be just as bad as it was in EE2 (not that that game didn't have any other weak points).

There is #2649.

That's just one more reason to get the gamesetup rewrite done.

It's more an example of how not to do a mod. The actual difference between whatever version of the public mod they ended up using (I haven't found enough time to look at the most recent release) consists of a few templates, some textures, a few maps, and some gui files that are mostly badly edited copies of other files. I suspect someone with a clue how to actually create a mod, some motivation, and a bit of time could create a working (and relatively tiny) mod out of that "full game" easily.

Try disabling the persistent match settings option, I suspect that code is causing breakage again (someone should just rip that out given that it just doesn't work).

Run `make clean` as noted in the build instructions.

We don't need iteration speed, look at all the uses of that cache, it's only inserting once, and tons of lookups, and iterating when shutting down (or running a simulation test).

There is a very simple improvement we can make there, use std::unordered_map.

For easier installation there is #4027. I'm opposed to reinventing more of a package manager than we already do. Also allowing downloading and installing of mods (which contain code that will be executed, and I'm not certain that all the code paths that can be called are safe) requires at least signing them so nobody injects malicious code. Then we'd have to verify that mods don't do any obviously malicious things (which is most likely some work, depending on the mod; if there isn't a lot of JS that is easier). Something I'd like us to do would be providing hosting for mods (.pyromod files) split according to the version of the game they depend on. (That still requires us to at least check the mods, but most of the mods above are small enough (amount of included JS) and pretty much all of them are produced by trusted people (there is some intersection between the wfg team and those modders ;-) ).