historic_bruno

It is a top priority.

Did you build the game yourself or are you using a package? If you built it yourself, you could try building with SDL2 instead of the default SDL 1.2 on Linux. There should be many improvements in SDL2's handling of multiple monitors, but as Sander says, I don't have such a setup to test.

It's coming, check out trompetin17's work on Atlas: http://wildfiregames.com/forum/index.php?showtopic=19722 and #118

Welcome! Check out the Art Development forum and you could try getting in touch with our art lead, Enrique.

The same argument could be made for other gameplay behaviors, like ejecting garrisoned units on damage, but we do have to choose arbitrary cutoffs. I haven't heard of garrison ejection being especially confusing, though it's a behavior carried over from AoK and capturing is not, maybe we're used to it. I like that less, but it's a possible solution. My concern is purely that players can't avoid capturing by destroying a structure without risk, because it's going to be a very important part of gameplay. What I mean by risk: if it's going to be captured in 2 seconds, there is zero risk in destroying it now in fact there is only a benefit to the defender. If it's going to reach 50% loyalty in 2 seconds, there is still much risk in destroying it, because you lose production, territory and a defensible structure while you have time to sway the loyalty back above 50% with reinforcements. This goes not only for the initial defender, but the attacker upon capturing will essentially become a defender themselves, because it's possible to win the structure back if they don't have enough units to hold it. With your proposal, the building may not be in the process of being captured by the enemy for a time, yet with a low amount of loyalty, the new owner could destroy it and I'm not sure I like that for the above reasons. See Enrique's comments, garrisoned units might be ejected when loyalty drops below a certain point, or they may take damage.

I don't see your concern, the ability to destroy your own building wouldn't be based on it's damage. We are talking a new concept of loyalty/capture points. If you aren't in control of a building, how can you sabotage or destroy it effectively? So you would need to anticipate losing that control, and act quickly, which I think is even more realistic than not. It's a difference between having a burned out shell of a building that you control vs. having a pristine new fort that is being captured - one you can easily destroy, the other not so much. And just because a building is damaged, that doesn't mean it is actively being captured, if you defeat all the attackers or they are mostly siege, you are fine from this perspective, no matter how damaged it is.

That could be for reasons of efficiency, that it's more efficient to have an effect applied to the whole screen, instead of per-geometry. I suspect it was easier to implement this way, too, and perhaps myconid just wanted to do a bunch of screen based shaders to begin with (that's how it seems here).

This and similar things have been proposed many times before. The problem is you are now using doubles, which aren't safe in the simulation, it must have identical behavior on all platforms. Fixed and sqrts only appear to be a bottleneck in profilers because the overall algorithm is quite flawed. (As far as using sqrt, I can't remember off the top of my head, but I seem to recall there is a good reason for it, you should discuss it with Philip on IRC, or maybe it's buried in a forum topic around here)

I'm not sure if your proposal includes this or not, but I think loyalty (capture points) should also be rebuilt after a capture, so there is a while where a building will have low loyalty after "ownership" changes. I like how capturing cities worked in RoN and while I haven't looked at the mechanics in detail, I recall that recently captured cities are difficult to hold. Then after some time passes, they become more firmly under your control. IMO it makes sense from both gameplay and historical/realism perspectives. It may be time to consider fixing territories to work better with diplomacy, unless we really want allies to be able to capture each other's buildings even by accident, by surrounding their territory, and not allowing allies to build in each other's territory. I agree, and it should work the other way, too, you can't just destroy a recently captured building if you haven't built up enough loyalty. That could be simplified with a single color to show "loyalty" (this is perhaps a better term than capture points), maybe purple. There are a few concerns with using player color, the color won't necessarily be visible or look good there, and it might get confused with other bars. E.g. what if the opposing players are red and green, is that properly distinguished from the health bar. For showing which players are involved, what about using territory borders or selection rings? In RoN, I remember floating text that gave hints of what was going on, but it was ugly. I agree and that was always the plan, health decay only exists to make territories relevant until we have capturing.

That's the session UI minimap, which isn't terrible if it's fixed for Atlas, but the ticket is about a separate widget, like the new dockable floating panels. I think the advantage of a separate widget would be resizing and repositioning it. It wouldn't be trivial to add as another GL canvas, unless it could be a texture generated by the engine and displayed in a simpler wxWidgets control.

Here is a ticket about a minimap in Atlas: #571 I think it describes the function well.

Fixed in r16461.

It's "normal" but not desired Someone even volunteered to work on it, but I don't know what the status is.

Thanks, that is the correct log. I am going to update to a newer version of SDL2 in SVN, it would help to have as many people testing it as possible, once that happens

IIRC, for the hotkeys to be listed, standard wxWidgets IDs have to be used in Atlas UI instead of custom ones. There should be a ticket to fix that.

Hi, can you try this DLL and see if it also works? It's OpenAL Soft 1.16 built with VS 2013. OpenAL32.zip

For sound effects, see this topic: http://wildfiregames.com/forum/index.php?showtopic=17915 I would say there is much more work needed here than on music. For music, you should try getting in touch with Omri Lahav who composed the game's music and performed a good bit of it too.

I guess they could be added to the map settings during init.

This is a known bug and #3119 basically covers it, normal and parallax are broken.

It doesn't all need to happen at once though, there is probably enough work for Atlas to last a year, but it should make it to SVN too One idea is to preview the heightmap textures before applying them. Not to preview the actual terrain, only the texture, to know which one is being selected if the names aren't clear.

I'm referring to the riverbanks being at different heights. Possible solutions would be to restrict bridge placement or terrain flattening. I'm guessing the main structure of the bridge would be built like walls, but unlike walls, it should be a single finished structure.

Looks like API differences from a very old version of MiniUpnpc. You will need a newer version to build the game (unless we add support for that old API, but it's not there now)

Technically, they are and they do, with planes and other flying things The answer is simply to have a separate "pathfinder" for such cases (walking on entities, be they bridges, walls, or other things). The hardest part would be combining them so units can transition between the different pathfinders, but it would be extremely cool. On a related note, I think we'll end up with multiple pathfinders anyway, I'm quite skeptical that one alone can handle infantry, cavalry, vehicles, and boats in a reasonable manner, but we'll see. Building bridges would be tough as well, making them adjust to different heights and lengths.

Nice work I think the heightmap texture should be selected in the main "new map" dialog, not after you select "Apply". Apply should be consistent in simply creating the new map. Also, are the player settings necessary for empty and heightmap? (I can't think of why someone would set them there) These are just UI issues, I have ideas for other features and changes, but I don't think we should try to do everything at once.

Contrary to Michael's view, I think they actually look better than our current farms, not worse.