historic_bruno
-
Posts
2.755 -
Joined
-
Last visited
-
Days Won
47
Posts posted by historic_bruno
-
-
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 #118This should be good enough until real variation feature add to Atlas.
-
1
-
-
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 think it would be pretty confusing not to be able to delete a structure just because another player had more loyalty points. It's possible that they could be so close that the bar could look evenly split among multiple players. At what point would a player get control? At greater than 50% loyalty? at two-thirds? I assume that defense arrows would still be fired until the conversion was complete.
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.guys keep simple.
Just dont let owner delete when in process of being captyired by enemy.
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.Well if a unit is garisonned in it seems logical that it is able to sabotage it
-
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.Should probably still be able to destroy a structure you own even if it is damaged; happened in war all the time where the defenders would sabotage any resources they had to keep them out of enemy hands. Also, repair shouldn't be required just to destroy it afterwards. Just bringing this up since it was mentioned that damaged bulldings should be easier to capture. I think a way to handle it would be to increase the capture rate based on the current health, so the lower the health, the faster the loyalty points drain. This would apply to territory loyalty decay also.
-
1
-
-
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.Some thoughts about capturing
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.Destroying buildings should still be possible (f.e. you reached the tower limit, and you want to build more towers towards the enemy). However, it shouldn't be possible to destroy a building right before it's captured. So I propose only if the owner of the building also holds the majority of capture points, he would be able to destroy the building
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?For the GUI, I see it similar to the health bar, but instead of using a green-red bar, the bar should be divided in a number of parts, showing the playercolour partitions instead.
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.Reaction from leper:
The health decay should be replaced with a capture points decay instead. This would indeed make more sense IMO
-
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.Must of this function is implementent, but maybe this "in one of the current UI panels? in a separate draggable window?" cant implement it right now
-
Here is a ticket about a minimap in Atlas: #571 I think it describes the function well.
-
-
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.
-
1
-
-
Hi, can you try this DLL and see if it also works? It's OpenAL Soft 1.16 built with VS 2013.
-
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.While we're at it:
- It would be nice to remove all hardcoded unit parameters from RMGEN and have the engine give those parameters to RMGEN at start - namely:
CELL_SIZE (4, size of a terrain tile in meters)
HEIGHT_UNITS_PER_METRE (732, How many height units fit into a meter)
MAX_HEIGHT_RANGE (0xFFFF / HEIGHT_UNITS_PER_METRE ~= 90, maximum heigt values in meters - used in RMGEN - supported by the engine - using the range 0 to 0xFFFF). Better just to take the 0xFFFF IMO.
All to be found in binaries/data/mods/public/maps/random/rmgen/library.js
-
This is a known bug and #3119 basically covers it, normal and parallax are broken.
-
1
-
-
So let me know your ideas, we are in the time to break some stuff and improve atlas.
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.
-
2
-
-
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.Hmm, I don't see problem with the height thing, maybe clarify? Length--Just have min and max length. About boats, ancient bridge were not the big bridge of today. Only small watercraft would fit beneath them, certainly not warships! So, the bridge could block boat movement and be perfect realistic.
-
1
-
-
here I come not trough :
../../../source/network/NetServer.cpp: In static member function ‘static void* CNetServerWorker::SetupUPnP(void*)’:
../../../source/network/NetServer.cpp:239:55: error: too many arguments to function ‘UPNPDev* upnpDiscover(int, const char*, const char*, int)’
In file included from ../../../source/network/NetServer.cpp:37:0:
/usr/include/miniupnpc/miniupnpc.h:45:26: note: declared here
../../../source/network/NetServer.cpp:279:67: error: too many arguments to function ‘int UPNP_AddPortMapping(const char*, const char*, const char*, const char*, const char*, const char*, const char*, const char*)’
In file included from ../../../source/network/NetServer.cpp:38:0:
/usr/include/miniupnpc/upnpcommands.h:123:1: note: declared here
../../../source/network/NetServer.cpp:295:36: error: too many arguments to function ‘int UPNP_GetSpecificPortMappingEntry(const char*, const char*, const char*, const char*, char*, char*)’
In file included from ../../../source/network/NetServer.cpp:38:0:
/usr/include/miniupnpc/upnpcommands.h:159:1: note: declared here
Linking mongoose
==== Building mocks_test (release) ====
Creating obj/mocks_test_Release
mocks_test.cpp
make[1]: *** [obj/network_Release/NetServer.o] Fehler 1
make: *** [network] Fehler 2
make: *** Warte auf noch nicht beendete Prozesse...
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 thingsUnits going over each other will never be supported. The pathfinder is 2D, and the position component doesn't store the height, but calculates it based on the terrain. So if you place a bridge over the water, you must be sure that no boats can pass under it, or that no other entities (like fish) are at that place.
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.
-
3
-
-
Nice worknew map video added
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.
-
1
-
-
Contrary to Michael's view, I think they actually look better than our current farms, not worse.They look great, I'm still not sure why they weren't commited. Barley and wheat, and use them as a randomization of farms. Or make them civ-specific if historically accurate... I'm not good with that.
-
4
-
Lost gold in the hands!
in Bug reports
Posted
It is a top priority.