alpha123

Definitely. And the animal noises too. lol

I miss development reports too. They were an excellent way to communicate what the recent developments have been and engage the community. I really enjoyed reading them before I got involved in the development of the project. Nope. I think k776 has tried to contact him, but nobody's heard from him for a while. Too bad, he was one of the most awesome contributors. @Lion: alkazar hangs out on the IRC channel a lot, and he's still very active (and probably the best 0 A.D. player currently). I still see idanwin around a lot too.

See #657. I've tried that patch and it actually works fairly well (needs to be updated a bit for the latest SVN), although there's a lot of duplicated code between that and rally points. IIRC we decided on IRC formations should just have one line.

Accept bitcoins as donations Tell Philip to finish the pathfinder Hire an assassin if he doesn't ??? profit

I actually thought of bringing this up after noticing just how important terrain is in Starcraft II. I say go for it. I was also considering not allowing units to shoot too far up. So if some archers are on very high ground they would not be able to be shot by units on regular ground level. I'm not sure if that's going too far however.

It actually does apply to easy, but in reverse: easy gathers 33% fewer resources than it otherwise would (in addition to some other things; I think it builds fewer military units than medium, but you'd have to ask wraitii to be sure).

1) Players can't be overpowered. I'm going to assume you mean "The AI is too good". 2) Mostly likely you're new to the game? Most experience players find even AegisBot on Very Hard a very easy opponent. I suggest AegisBot on the Easy setting, and also playing the "Starting Economy Walkthrough" tutorial under Demo Maps.

What parallel are you trying to draw here? UnitAI isn't related to maps in any way, shape, or form, while sounds are definitely part of them. Sound effects have nothing to do with gameplay, while UnitAI is a big part of it. You're comparing apples to trucks. Anyway, zoot, Mythos is the guy who made most of the scenarios. I think he knows what he wants when it comes to map design tools.

As far as I know, your server is not endorsed by Wildfire Games in any way, so I recommend removing the "official" part.

I think because it never actually reaches the second market, according to the pathfinder. It just gets stuck really close, even though the model is at the second market the pathfinder thinks it isn't quite there yet.

The elephants really need new sound, they sort of roar weirdly and often. Ideally the Mauryan worker elephant would have different sounds from fighting elephants. At that point I think it's easier and more flexible to just allow the map designer to place a sound emitter.

I don't think that's actually a big problem, as long as the stat change takes effect when they go stationary. I doubt it will be particularly noticable, and none of the tech files would have to change once a proper solution is implemented, so it could wait a little bit.

Very cool. This is the type of thing that makes me think we could just add triggers and the community would create all sorts of awesome things.

See also this topic. Currently there are a few problems like crashing on Windows sometimes and having issues with TLS on some Linux distributions. Otherwise it is (mostly) complete and just needs a lot of testing to get in to Alpha 14.

Ask historicbruno about this on IRC; he actually tried this (IIRC) but ran into some odd problems.

Not quite - only AI serialization is broken. The AI works great in single player (although has trouble with saved games - this is the same bug that causes out-of-sync in multiplayer, IIRC). Multiplayer works very well (better than single player actually) with no AIs. Well, I think the number of people who play multiplayer with AIs is fairly low, but it would be a good idea to make this more known (since it also affects saved single player games). There are a number of topics on the forums about it; the most recent is here. Walls are still useful to create chokepoints. The fact that walls are almost never used in competetive multiplayer games is a bit telling however. ...Yet. There will be one sooner or later. (It's pretty easy to add.) And away from the sides of lakes, and small mountain passes.... >_< Large units such as siege and ships are kinda broken movement-wise right now. The pathfinder currently in the game does not use JPS (the new one will). The problem is that it is a fairly naive A* implementation (just plain A* with a priority queue, AFAIK), which makes it fairly slow. Mainly this affects path quality by the terrain cells being pretty large, although there are some other things that contribute. The current one could be a lot better. The new pathfinder is very good, it uses terrain cells 4x as small which leads to much better pathfinding. That's only the long-range pathfinder though; the short-range one is still pretty bad. I for one would not like sub-optimal pathfinding (HPA* or similar). I think we can do just fine with JPS and/or A* with a quadtree and some other tricks. Unfortunately Philip hasn't had the time to work on the new pathfinder for a while. It already does a single long-range path for formations. This actually contributes to the slowness though: often a formation is too big to fit through a gap, and A* ends up searching the whole map.

Seems like a decent idea. How would it handle wallsets? Would it upgrade just the selected wall or all walls connected to the selected one? I lean toward the former, but that would look sort of weird if you just upgrade part of a wall.

That's a good point. I personally feel like every building would be a little excessive. Walls strike a good balance between not being annoying and adding new tactical possibilities. It would also make walls quite a bit more useful (currently they aren't very good). Also it would be sort of weird since structures currently have their own LOS, so if we did that your own structures would block your LOS and add to it at the same time. I think it would be expected for walls to block both friendly and enemy LOS, so it would be inconsistent if we blocked LOS for only enemy structures, but strange if we blocked LOS for friendly structures. I agree with Yves on this one, but it would still be fairly interesting to experiment with. It would add an interesting dimension to the game's currently somewhat limited micro tactics.

You have good points. I really, really wish the SpiderMonkey docs/support/community was better. The library itself is excellent though. (Well, at least performace/feature wise.) You can't really polyfill this: [n * n for each (n in [1, 2, 3, 4, 5])].map(function n + 1) // [2, 5, 10, 17, 26] contrived example, but demonstrates some (but not nearly all) of the SpiderMonkey-specific syntax. SpiderMonkey doesn't use a tracing JIT anymore, they use a method JIT (like V8) combined with a powerful type inference and optimization engine. I wish they had put more effort into TraceMonkey personally; IMO tracing JITs are superior to method JITs. Just look at LuaJIT (an insanely fast tracing JIT compiler).

For just that case I suppose you can sort of get away with regular expressions. It's still ugly and incorrect though.

IMO that's going a bit too far. Trees aren't particularly big or important in this game, and I'm not sure what we'd gain by not allowing units to see through them. Additionally it would make gathering wood a bit unnecessarily harder.

That would be much harder than simply upgrading SpiderMonkey. It would be a ton of work for no performance gain - SpiderMonkey is at least comparable with V8's performance these days, sometimes it is even faster. The code contains quite a lot of SpiderMonkey-specific synax (short lambdas, destructuring assignments, array comprehensions, etc). V8 does have far better docs though.

This is, um, a really bad idea. GLSL is a Chomsky type-2 grammar, while regexes can only parse type-3 grammars. In other words, you can't do this correctly, for the same reason you can't parse HTML with regexes. You might, maybe, get something that looks like it works, sometimes, but it's just fundamentally a bad idea. I'm not necessarily adverse to parsing GLSL with a real GLSL parser, but I don't think that would be worth the trouble.

Yes, it would assume walls have an infinite height. Someone was already going to implement a quadtree for the RangeManager, we could use it for this as well and get away with decent performance. What I'd really prefer, however, is units not being able to see through walls (and by extension not able to shoot through them).

Let me guess, you were playing with AIs? If you weren't, the host and client were on different versions; the game never out-of-syncs with the same version and no AIs. We should probably add the AIs in multiplayer breaking thing to the known problems list. Sigh I'm still not sure what the best way to handle this is. We might want to add this one to the known problems list as well. (I haven't actually checked if either of these are already on there, but IIRC they are not.) Formations are broken. Deal with it. Until formations are properly designed/implemented there will probably be a "no formation" formation where soldiers just behave like women; i.e. they won't actually be in formation and the order will be given to all units individually. That would be caused by the extremely bad pathfinder. A new one is sort of being worked on (it exists and actually works, but it has some edge cases that don't quite work and AIs break it or something like that). Haha, I like your outlook about it being a feature though. =P