iNcog

Exactly, a small nerf such as this one is just the way to go, at least in my opinion. Rush strategies in general aren't difficult to hold off, especially if you take the time to scout. This is especially true since early game your harvesters can fend for themselves. However this only works if you can make the counter to whatever unit your opponent decided to make. So an Archer rush can be dealt with melee cav for example, however a skirmcav rush are much more difficult to hold off given that no unit hard counters them, you only have skirms which soft-counter them. Even then, it's difficult to catch skirm cav. There's no need for a cease-fire aspect in the game, all you need to do is make sure one unit isn't problematic.

Yeah I've heard of this feature in AoM and I think opinions about it were mixed. I personally don't like the idea however it's not for me to decide which features get implemented and which don't. Let's just say that everyone has his opinions: you think this would be good, I think it would be superfluous. Let's just leave it at that. ^^ I agree with your other points.

I disagree with point 3. It doesn't add anything to the game, it would be annoying to code and there's no reason to queue the exact same unit constantly, it's often better to mix up the units you're making anyway. Otherwise, yeah, hotkeys need to be added but there are solid ways to work around the hotkey limiations atm.

Oh that means the game is set up to be well threaded. That's actually great

Well I can confirm what borg says and i'm uploading a video of it. i'll pm the link to ya

Phalanx apparently also have this bug. I just played in utter disbelief as 30 phalanx units (I was monstrously ahead of my opponent) just destroyed everything I had. hehe I have the VOD if you want to see it in action, though it would annoy me to upload it. Basically, ranged units can't attack phalanx, they just run in and die when they get in close range. These things have 12 hack attack btw. I had phalanx attack my CC and all the villagers that were around it, repairing it, were killed at range. The same thing happened to my skirmishers, they died at range. The military camps I had built were destroyed in 5 seconds, my CC in 10 seconds. Should I upload the VOD? It would take hours to do so but I have everything on tape. Fix please.

I wish I could help you guys... I genuinely feel kind of bad posting here knowing that I don't have the slightest knowledge in coding that would allow me to be of any help.

Getting computer parts depends on your budget and what you're going to do with the computer. Nvidia vs AMD, AMD vs Intel, memory to get, everything actually depends. 0 A.D. doesn't strike me as a well-threaded game (given that I get this: http://i.imgur.com/jPWqnAs.png when I play a 2v2 with 3 AI), so I don't see how an AMD CPU would do better than intel, to be perfectly frank. It depends on clock speed and architecture as well. An FX 4300 today with a good overclock (gigabyte's boards indeed have the reputation to be good overclocking boards for their money) might give a slow i5 at stock speeds a run of its money, especially if the i5 is of older architecture. AMD is better bang for buck, Nvidia has some very good features though that make paying just a bit more worth it (shadowplay, g-sync, CPU-friendly drivers atm). Well, it's all that sort of thing. You can't prefer any brand blindly, it's important to do the actual research.

Where are you from? It's better to build desktops yourself.

I don't like doing that for villagers since I want to get them out asap. I think villagers trained one at a time is better than in batches of 5, even if the train time is slightly reduced, you get more resources since you have 1, 2, 3 and then 4 villagers gathering during the time it would take for 5 villagers to be created. For military units, you're probably right, however I have yet to be comfortable with macro in this game. I've already found view time. Very useful. I understand what you mean about hunting with the starting cav unit, it does indeed get you a lot of resources fast. However, it also means you can't scout your opponent. I've had my opponent make 4 skirmcav right off the bat and attack me with that. I couldn't do anything since I was opening with a full-eco build (the starting cav was hunting indeed). So if I had scouted I could have maybe adapted, but not scouting with the starting skirm cav is, imo, a risk, since you don't know what your opponent is up to. I don't know yet anyway, I'll be playing online more to see what's best. ^^

I just did so very interesting indeed it's definitely the short range pathfinder which atm isn't working efficiently. hmm it seems to calculate another path every time the unit hits an obstacle (ie unit). so ideally you'd want the unit to calculate ONE path only and then follow that to the end. however given the random nature of things, the obstacles will move around as well. formations do poorly it seems, when it comes to the short range pathfinder, since a unit in the formation will hit an static obstacle food for thought. not sure what to think

I see, it's much easier to use only squares than it is to use a triangle which rotates. OK, so this set up of mine would in fact garner terrible performance. The way I would cope with a row of units blocking my unit is to repeat the "move to the side" command until my unit finally goes around the row of units. However that might mean that you get stuck vs a static obstruction first. So I don't think that using preset commands is the way to go, after all. How does the current short-range pathfinder currently work? I take it the short range pathfinder doesn't take the long range (blue path) into account as of right now? I think that the best compromise would be to have the short-range pathfinder work so that the unit remains on the blue path. So it would have to calculate the shortest possible path that brings it back to the blue path. Edit: OK so I took some time to think about it. Basically two big improvements are in store: 1. Long range and short range pathfinding become more compatible thanks to smaller nav-cells (so short range pathfinder can base its work on long range path). 2. Short range pathfinding calculations can be simplified thanks to point 1. This results in performance improvement. How does that sound? lol i keep re-reading that pdf, understanding just a little more each time

hehe, i'm also waiting for uni to finish to start playing 0 AD a lot. fix path finding first though

Aren't you describing the short-range pathfinder in that quote? Would it make more sense to have the short range pathfinder simply guide the unit so that it sticks to the long range path? Normally the long range path would take big obstacles like walls into account, no? So if you make it so that the short range pathfinder works to follow the path laid by the long range pathfinder, the short range pathfinder would only work in the presence of obstacles, I guess. Also, doesn't giving the long-range pathfinder higher resolution cells cause lag when lots of units are asked to move over long distances? There must surely be some drawback to having resolution cells? Would this work out? Imagine this: In blue you have the path set out by the long range unit. In red, you have a unit which isn't taken into account by the long range pathfinder. It's a unit on our unit's long range path. What the short range pathfinder does, very simply, is simply issue a series of preset commands when it detects the red unit which is blocking our unit's path. Command 1: go left just a bit Command 2: continue going parallel to the blue path over a small distance Command 3: go right just a bit to continue following the blue path the commands are preset so no calculation is required. the unit just moves when the short range pathfinder sees the obstacle. You could change the geometry of the red unit's "collision shape" (or however it's called). Basically, when I say "collision shape" I mean what the short-range pathfinder detects when it detects a unit. You could something like this: So it's simple. The triangle is in the direction of the units movement. If our unit's SRP (short range pathfinder) detects the brown line, it will use the yellow adjustment instead of the green one. i.e. : Command a: go right just a bit Command b: continue going parallel to the blue path over a small distance Command c: go left just a bit to continue following the blue path The idea is that the SRP tells the unit to turn into a direction based on whether the brown line is detected (in which case our unit moves to the right) or whether the purple line is detected (in which case our unit moves to the left). Faster units (cavalry) would have a taller triangle. Slower but bigger units, like siege engines, would have big fat triangle. A unit that isn't moving would have no triangle at all, its "collision shape" would be a circle instead. All triangles would be preset. So when the unit is moving, the collision shape changes from one preset to another. With this set-up, all the triangles are presets. All the green and yellow paths are also presets. The short-range pathfinder doesn't have to calculate anything at all. It just has to tell the unit to move to one side, continue, then get back on track. Everything being preset means that the only thing going on is commands being issued. Only the long range pathfinder does any actual calculations. I'm not sure how unit movement would end up though. I'm just throwing this out there, as food for thought and in the hope that when it gets debunked I'll know a little more about pathfinding. I'm guessing such a set up might be efficient but also ugly? or something?

OK so this topic of pathfinding really interests me. The way I understand it, the way things currently are, pathfinding is bad in this game, but it also takes up huge chunks of CPU resources. So if you fix pathfinding you can fix two issues at once, right? If I understand correctly, there are several things that make pathfinding bad and resource-hungry in the game: - The long-range pathfinder and the short-range one have some compatibility issues, in that sometimes the long-range pathfinder says "ok do this" and the short-range one says "ok do that" and the unit just doesn't know which one it should listen to. So the proposed fix to this (very simplified), is to have both long and short ranged pathfinders use the same cell to work with, correct? - The short-range pathfinder calculates too much when trying to find a new path, which means lag when lots of units move at the same time. What is the proposed work around for this? Would it be possible to implement something like "if a moving obstacle is found, then go left, up and continue, then after a certain distance, go down and right and continue on original path" ? What stuff should I read if I were to have look at the pathfinding code myself? Where and how can I access to this code? I feel pathfinding is one of the most important things to look at as of right now.

Would it be difficult to adopt such a pathfinder? Reading that report about Terrain Analysis from the ex-ES employee made me think that AoK pathfinding is quite decent. I'm going to continue the pathfinding discussion in the pathfinding thread though

OK, so ideally you'd want to reduce the amount of pathfinding calculations it would take to move a unit from A to B, correct? That makes sense to me. I'm guessing you also want to limit the amount of actual calculations the engine has to do during a pathfinding calculation, correct? That would bring a calculation from 20 ms to 10 ms for example, and pathing in general would be that much more responsive. This also makes sense to me, thanks. I'm going to read that pdf as well.brb E: Are you guys still working on the new pathfinder which is composed of a good long range pathfinder and a newer, more efficient short range pathfinder? these ones: http://trac.wildfiregames.com/ticket/1756 http://trac.wildfiregames.com/ticket/1942

I would like sheep to be able to man fortresses and watch towers.

this is very interesting to me would it be possible to code units so they recalculate their path every 0.5 seconds? instead of having them calculate their path only when they hit an obstacle, have them calculate a path every 0.5 seconds or even every 0.1 seconds and have them treat other units as immobile obstacles. would that be too demanding? what do you think? would this be more demanding than calculating a path taking mobile objects into account? i feel as if calculating paths is easier to do with immobile objects than moving objects, is this correct?

i have an i5 4670 and it doesn't particularly struggle to run the game, if at all. i'd definitely recommend a 4670 (or rather a 4690 these days) as a bare minimum for most gaming rigs

hahah this made me laugh

OK, makes sense to me. thanks for answering ^^

That's good to hear. ^^ Have you guys ever considered going small hotfixes though? Like Alpha 16.1 or something? Before alpha 17

That doesn't get you map control though. Also if the other civ has stronger skirm cav than you do, you're in somewhat of a pickle.

Which unit do you use to counter skirmcav in the later game? Skirms?