Ykkrosh

Short version: Please complain if the game no longer compiles properly. Long version: I've updated the code and build system so that it uses a new version of SpiderMonkey (the JavaScript engine used by Firefox). We used to use version 1.6, from 2006; now it's a version that's about a day old (picked at random from the mozilla-central repository, plus a patch that's not been committed there yet). SpiderMonkey's build system has been redesigned since 1.6, and I've rewritten the way we compile and link it, so it's all somewhat different. Hopefully things will work automatically. On Windows, there's nothing to do. On Linux, when you first run update-workspaces.sh it will try to build SpiderMonkey and ought to work and then carry on as normal, but errors are possible. OS X theoretically should work like Linux but I haven't tested it at all. One simplification is that we no longer use a threadsafe version of SpiderMonkey (we do use it in multiple threads but each individual JS runtime is only used in one, and the patch mentioned earlier makes it safe to do that), so there's no need for NSPR when compiling. The other main benefits are that the interpreter is faster, it has a JIT to make things much faster (though it's disabled for now), it has better debugging tools, and it supports new language features (these and these). It'd probably be good to update to a newer version at some point in the future, particularly when the JägerMonkey JIT is integrated and stable, but this should do for now.

Ah - I think SVN's 'import' is importing from your local machine into the online repository, which doesn't work because the online one is intentionally read-only . The checkout command should work better.

Minor correction: It's Pyrogenesis, not Prometheus

"Server busy" would be a different error number, so I don't think it's that. As far as I can see, MKACTIVITY should only be used by the SVN client when trying to modify the repository, so it's odd that you get that when just trying to download. I've not seen a similar problem before. Looks like you're using TortoiseSVN - what are the exact steps you perform (what menu commands, what values in the URL/directory fields, etc) when getting this error?

For gameplay scripts (like these) and GUI scripts (like these). (It's quite different to the JS used in web pages - the language is the same but there's no DOM and it's running in a completely different environment.)

I think that issue is just caused by an incomplete checkout (though I'm not sure what causes that), and solved by running "svn up" (in the SVN checkout directory) until it no longer has any more files to download.

It still could be done, and it'll become a bit easier over time because people are writing more of these WebKit-embedding libraries, but it'd still be rather a lot of work (I expect it'd take me at least a few weeks of work to get all the bits integrated and ported) and it's not really critical since we already have a mostly functional system, and I'm not even certain it'll technically work well enough for what we want (particularly in terms of rendering performance) so we'd need to spend time experimenting first. Some of the testing benefits are mitigated by our GUI now supporting hotloading, so you only have to start the game once and then it'll dynamically load and display any changes, which makes development substantially faster and less painful than before. I still think WebKit would be more cool than the current system, but I still don't think I can justify spending my own time on it when there's so many other things to be doing (and I don't know who else would be willing and able to try it) (On a vaguely related note, the new Steam beta client "swapped out the Internet Explorer rendering engine with WebKit, which gives us a bunch of size, stability and performance benefits" (and also gives them OS X compatibility, which it seems they're going to start supporting) - WebKit seems to be becoming pretty popular.)

You should probably run it without --with-spidermonkey-tip (If you do use --with-spidermonkey-tip, then first you have to go into libraries/spidermonkey-tip/ and run build.sh before it'll work.)

Hmm, if you're using the snapshot that's listed on the BuildInstructions page then that's very old - you need to either run "svn up" after extracting it, or do a normal SVN checkout, to get the latest versions of all the code.

You should just run "make", not "sudo make" - sudo is unnecessary and dangerous (it could let us delete all your files and repartition your disk, and you probably shouldn't trust random code on the internet like that) and the output files will be owned by root which'll make it hard to do anything with them as a normal user. Does the file libraries/spidermonkey/include/js/jsapi.h exist (relative to the SVN root)? That's the one it ought to be finding here.

Is there any chance an optimised memcpy will ever be necessary on any platform? Sounds like that's probably unlikely, in which case we'll never need to revert the change, so it seems like a simplification and therefore a good idea. I suppose WPO might inline it, but otherwise simple cases like int main() { int a = 1, b; cpu_memcpy(&b, &a, sizeof(a)); return a+b; }are a function call with cpu_memcpy but get optimised into "return 2" with memcpy (in g++ -O1), which probably isn't going to make a huge difference overall but seems handy nonetheless.

No. To do that well would need the engine to be designed from the ground up to support multithreading, and we haven't done that (since we started writing it long before multicore processors existed), so it would take a lot of effort to redesign everything for that and to make it work reliably. It would also require the gameplay system to be redesigned for parallelism - e.g. the player AI can trigger pathfinding which can affect player AI, but if those parts are running in parallel then it needs to be changed so that neither has to wait for the other. So it's technically challenging and we already have enough challenges simply making the game work at all, so it's not something we're planning.

Indeed, welcome . C++ is weird in lots of special ways, but not really fundamentally different to other languages, so I think it just takes some practice and experience. It's probably not my favourite language, but I can't really imagine writing a game like this in anything else. Anyway, if you want to get involved with the programming then it may be best to start with some small things to explore the code and see if it's a project you're still interested in working on - there's a few listed here, and there might be others we can think of if there's a specific area you'd prefer to focus on. Interesting/Boring fact: Firefox still supports <script type="text/mocha"> and <script type="text/livescript"> (as synonyms for text/javascript), which were the original names before Netscape's marketing people thought it'd be a great idea to confuse everybody by putting "Java" in the name (which is trademarked by Sun and so Microsoft had to call it "JScript" instead and the standards body had to call it "ECMAScript", making it even more confusing).

I noticed r7339 removed ia32_memcpy, so now it's calling the standard memcpy via cpu_memcpy. Since compilers do various optimisations and specialisations of memcpy given the context where it's used, it'd probably be better for performance to avoid the indirection, and just do a "#define cpu_memcpy memcpy" instead. (Should do the same for the amd64 version too). Any objections to doing so?

Hmm, that seems likely to cause minor pain and confusion for people who currently expect it to load the internal mod by default. A quicker workaround is to simply create mods/internal/ so it always exists with the right permissions - it's a bit of a pain to make that happen via SVN (need to fiddle with the authorization files), but anyone packaging the game for distribution can make the directory manually, as a workaround until we fix it properly.

There is no affiliation or relationship at all - we're completely separate groups that just happen to have slightly similar names. (We also have no affiliation with Wolfire Games, or with the Sonic Wild Fire game, and do not support or condone the lighting of forest fires for entertainment.)

That sounds accurate to me . I don't think any of those features are fundamentally incompatible with our engine. With the things that we're not planning to have in our game, our code makes various assumptions (like all units are fixed to the terrain/water and can't move up and down relative to it, and AI and pathfinding can be entirely 2D, etc), so it'd take some work to avoid those assumptions in the C++ code, and there's likely to be more work changing the gameplay scripts. It's certainly not trivial, but it's easier than programming everything from scratch We do have alpha maps (for trees etc) - every mesh just has a single RGB/RGBA diffuse texture. I don't think there's anything in the renderer architecture that would prevent more complex rendering with specular/normal, we just haven't considered it worthwhile yet. Lighting and shadows are all dynamic so I don't see anything that would prevent the light direction/colour being modified to follow some cycle.

Now filed as #458, #459.

The rough plan (#247) was to get rid of all that category stuff, since I've never ever needed that functionality and it's a waste of time. (I thought it was a good idea when adding it...) That was partly done, but all the old log statements throughout the code need to be fixed (hopefully just a simple regexp replace to make it use LOGERROR("msg") etc) and the LOG_CATEGORYs removed. If anyone wants to make a patch for this, please feel free (As mentioned on IRC) This should be improved at some point by removing the old simulation code (which is currently all in "engine"; the new code is in "simulation2" instead), so there's probably no need to try splitting engine up before then. I don't think I've ever seen errors like that (on Linux). What's the error? (Mahaf is Windows-only and it looks like it's getting used in acpi.cpp even on non-Windows, which is probably not good, but it hasn't caused me any problems.)

Sounds good to me There's also some customisations for running CxxTest as a custom build step, which might be doable with more generic functionality in new Premakes. There's also various tweaks to compiler options, Intel C++ Compiler support on Linux, linker command line orders, and others I forget, which are required for certain build environments (but not all, so it's hard to test). Some of these might already be fixed upstream, others ought to be fixed upstream, others might stay local patches. In any case, it'll be important to compare the generated Makefiles in various modes (Linux, Linux+ICC, OS X) with the old ones to make sure we don't introduce any unintentional changes. Simon (olsner) has been working on this a bit ("now everything compiles! but it only almost links...") so it'll be worth checking with him before doing any work on this. That requires an SVN account so most people can't see it. (It's not secret (anyone can join the IRC channel) but I don't really want it publicly indexed.)

Hmm, it should only rotate if you use left+right+drag, or ctrl+middle+drag, I believe - I'm not sure how that would happen when simply left+dragging. Sounds like something in the code may be getting a bit confused, but I don't know what without having a more specific way to reproduce the problem. You can reset the camera with "H". (The camera movement system ought to be fixed to prevent you from getting it into really bad angles, though.)

(Oops, forgot to reply) Do you mean in the new simulation system, not the old one? I think at that point there was no animation support, hence a lack of visible attacking, and it ought to work better now.

As I've been redesigning the game's simulation system, and it sort of works now, I need to sort out exactly what gameplay features need to be added. So I've got an initial attempt at a list on the wiki. Currently the focus is on pretty basic features (since they need reimplementing in the new system) - I'd like to finish the minimal amount so that we could put together some kind of initial alpha release. It needs to be stable and decent quality, and enough of a game that people can run it and work out what's going on and understand what incremental improvements it needs (and I need to write some more documentation so people can work out how to add incremental improvements themselves), but it's only the first release out of what would hopefully become a semi-frequent progression of releases, so it doesn't need anything fancy and should be done fairly quickly. Any thoughts on whether that page has things that are missing or bogus or misprioritised etc?

That's an inherent difficulty with A* - if it can't reach a destination node, it doesn't know it can't reach it, because as far as it's concerned there could be a wormhole from the other side of the map directly into that seemingly unreachable location, so it wants to explore the entire map before it can be sure there's no valid path. I've currently got an arbitrary search limit of 5000 tiles so it won't actually explore the whole map, but it's still a performance concern.I expect part of the proper solution is to not compute paths to unreachable locations - if you're attacking a building or harvesting a tree etc, it ought to compute a path to the edge of the object rather than the center. Currently it sort of does that, by setting the goal to a circular range rather than a point, but not very well. Since we have a grid, there might be other ways to avoid the problem in special cases: if the pathfinder has explored tiles in a ring around the goal, but hasn't been able to reach the goal, it should give up immediately because there's no point searching further outside that ring. Haven't thought about this much, but it seems like a simple matter of detecting topological holes - when a tile is added to the 'closed' set that will fill in a gap (it's closed on at least two sides and unexplored on at least two sides), the algorithm could walk around each edge of the closed tile set and if it finds one is the outline of a hole (if you walk with closed tiles on your left and when you get back to the start you've turned 360 degrees rightwards, then it's a hole), and the goal is in the hole, then don't bother searching further outside the hole. Or something like that.

On a related topic, this article is interesting and slightly depressing. ("it's not uncommon for tool improvement to be viewed as "bad" or at least a problem". "You cannot often argue with people who are sufficiently confused about technical matters; they think you are the one who doesn't get it. They also tend to get emotional. Arguing reliably kills sales.")