elexis
-
Posts
3.644 -
Joined
-
Days Won
59
Posts posted by elexis
-
-
Case 3: When chasing a unit that is running
-
Can you tell us when that error occurred?
Since it's in the "Serialize" function, it might be at the time when you created a savegame?
Did you use any mods or try to load an old savegame?
-
1
-
-
Not only to hide units from the enemy, but the main advantage is that the units aren't killed by the arrows of the defender while approaching the fortification. Garrisoned units also increase the capture regeneration rate of any capturable unit or structure (not relevant for rams as they arent capturable currently).
-
1
-
-
The https connection error messages should be shown, rather than that it failed to parse the response as JSON. We run into this problem several ways already.
-
2
-
-
On 7/30/2018 at 2:25 AM, Ulfilas said:
Battles could be won by attacking a supply chain
7 hours ago, wowgetoffyourcellphone said:You could just make the lack of food effect a global effect on your units
If it's a global effect, it can't implement the effect of broken supply lines and scorched earth tactics (in case that was the actual aim).
It's rare that players create an army, delete the entire economy and then win with that, at least if there are more than 2 players. Players very rarely have no economy, because their units die too in a battle and have to be reproduced continuously, replaced with more expensive units. It's also very rare that one has exhausted all benefitial upgrades. Not stating that reoccurring food cost is a bad idea.
54 minutes ago, macemen said:So some degree of snowballing effect is absolutely fine.
Consider that snowball effect is also the method how the one that is outnumbered can win if the opponent doesn't group all units.
-
7 hours ago, Ulfilas said:
Any major army had to worry about supply lines. If you have an army of 1,000 people and you pass through a village with 30 people, chances are they do not have enough food to feed you
That. Celts employed scorched earth tactics to have romans starve. It's also a reason why the nomading mongols were so successful - their supply line moved with the war effort.
However it's never easy to implement such things, especially with the mapsizes that we currently have. Food would have to be a local resource, not a global anymore. For example units would lose health unless they go back to a storehouse and take some resource of that storehouse. Might be a can of worms (the problem, not the food).
-
1
-
-
150 population * 8 players * normal mapsize is recommended for multiplayer.
AIs have a signficantly noticeable performance impact. It needs some love (lots of love actually).
-
1
-
-
Dunno in specific, but there are a number of variations of stone and metal mines. You can see them in the Actor Viewer of the Atlas editor.
-
Check the first error, not the last one. interestinglog.html should contain all error messages, mainlog.html even more, the replay of that match should reproduce the error. https://trac.wildfiregames.com/wiki/GameDataPaths
-
1
-
-
GPL and Steam:
In order to test what GPL-licensed games are available on Steam Store and how it is implemented, I've installed Steam and installed Blender and Battle for Wesnoth.
In these two examples (most likely dosbox too), It seems there are literally zero functions of Steam in use except the application running inside Linux SteamOS, the auto-updating, possibly usage-stats generation, for which the software possibly wasn't modified.
supertuxkart intended to implement some of the multiplayer services and possibly drivers, so time will tell if they succeed in using the Steam API.
I wonder about Steam having to comply with GPL however. As far as I know if one distributes a binary, one is obliged to also distribute the source, possibly against a fee. That should be easy for them as they can just mirror the sourcce code and charge a fee. But perhaps they also modified the source code of Blender, Wesnoth or DOSbox in order to have the app compatible with or improved for Steam? If they distribute the binary, they'd have to distribute these modifications as well (if they exist) or ask all copyrightholders to relicense for Steam use, unless I got GPL wrong.
Battle For Wesnoth on Steam:
- May 2018 Version 1.14 entered Steam Greenlight:
QuoteProbably most notable of all, this is also the first release to be published on the Steam Store, where it is available for free on Windows, macOS, and Linux platforms! We would like to extend a huge thank you to everyone who supported this effort over the past two years. Wesnoth made it through Steam Greenlight in record time, and your continued interest on our forums and social media has been extremely encouraging. We look forward to seeing new faces in our community!
- Wesnoth developers considered Steam logins, but currently the software uses only wesnoth forum account for multiplayer lobby logins.
-
1
-
Authentication failed sounds rather like the wrong user/password than being banned.
The registering of the one new account might however have triggered someone to ban, what was your username?
To protect from spam and trolls, when an IP registered one account, the same IP has to wait some time to be able to register again, which were the last issues you must have encountered.
-
2 hours ago, Sundiata said:
So there's no (near) absolute figures? What do you think was the minimum amount of times alpha 22 and alpha 23 have been downloaded so far?
I don't have more data than is in those two links either. The number of lobby accounts can be considered.
Order of magnitude being 100k per year and 1mio total seems to be covered by these conservative numbers . (So might be 2x as much now but most likely not 10x as much)
-
1
-
1
-
-
http://releases.wildfiregames.com/stats.php is incomplete IIRC, doesn't contain sourceforge, torrents and some downloads werent captured at all IIRC, also linux distributions
-
2
-
-
So either
- the described TurnManager error was irrelevant to the game not progressing and a different bug made the game stop, or
- there is a different callstack than the previously reproducible one that might somehow break the NetServerTurnManager cleaning up (and thus not waiting anymore for the next turn of that client).
For 1: the game only progresses as long as all clients are ready for the next turn. But one client might still be connected to the game, but it's network connection is so bad that it stalls the entire game without being notified (could probably only happen under extreme conditions).
For 2: We have old logfiles in the ticket, but it's too much data without a specific indication as to what caused the error. With good knowledge of the turnmanager code one might be able to discover unreported bugs that may coincide with the bug described here.
-
1
-
Careful, if you start 0ad some of the vial logfiles will be overwritten. I guess you already did that to find the directory of the replay.
https://trac.wildfiregames.com/wiki/GameDataPaths
It's important to know the exact error message, in case of out-of-sync also which player exactly was out of sync (and then ideally the logfiles of that one too).
Reading your recollected error message, it however seems that it wasn't an out-of-sync error, but a TurnManager error.
Especially since you said that the units froze, it sounds a lot like this bug, there will never be a new Turn executed.
QuoteLOGERROR("NotifyFinishedClientCommands: Client %d (%s) is ready for turn %d, but expected %d",
LOGERROR("NotifyFinishedClientUpdate: Client %d (%s) is ready for turn %d, but expected %d",
I expect the game to not progress until the client was disconnected, was that observed?
If the rejoining player was disconnected and the game still didn't progress, then there is something unknown here.
If the rejoining player never disconnected or if he disconnected and the game then progressed,
-> tolduso (or rather toldthemso), was just fixed before the release (and should have been fixed in previous ones): #3643
-
warn("hello world"), not message box
-
The program might need a certain amount of consecutive free memory, but the memory might be fragmented. (For exampel if 8GB of 16GB are free, but it's 1MB free and 1MB allocated, one can't allocate one chunk of 2 MB).
One could find out at which place the OOM occurs in bahrain.js (by adding a warn("hello world")) after every statement and thus see which memory allocation fails (probably some array creation).
-
1
-
-
Oh I missed the "Out Of Memory". That can explain any sort of error that comes afterwards, especially if you set a maparea 4 times as large as the largest one officially supported.
It's possible to that alternative mapgeneration algorithms would not get Out-Of-Memory errors by being more efficient with memory (or even writing temporary files).
But even then it's questionable whether there won't be many other algorithms that get Out-Of-Memory issues during the game (especially the AI)
-
Alt+D -> disable camera restrictions. The skybox isnt too beautiful though.
-
I mean which buttons did you press to get the error? Does the same error occur again when you press the same buttons? If we have the recipe to produce a bug, we can solve it most likely
-
Look at the error messages, it seems like it's a gamesettings bug (there are several in atlas). Even better than a logfile would be knowing how to reproduce the error.
31 minutes ago, OPEJ said:Thanks for explain.I really hope it can use mutiple core for mapgen. I don't want my others core just wait and see...
As mentioned they have to for large portions of the program and secondly doing better algorithms without implementing threading might still make the loading screen much faster without spending the additional time to implement threading. We want to spend our time efficiently too, so either the most effective measures first or the ones that are really quick to implement but still efficient.
-
Random map generation uses a single thread, so it can only utilize one core. Since the operations are sequential, only certain tasks could be outsourced to a secondary thread.
For instance when testing a Constraint against an area. If the area contains 1024 points, there could be 4 threads each testing the 256 points against the Constraint and then the map generation pauses until all 4 threads finished. Testing the constraint would have to be a read-only process, otherwise you get undeterministic behavior, race conditions and players would generate different maps ir they didn't segfault. We can probably achieve better results with smarter algorithms in random map generation and the later simulation.
-
The first screenshot shows an "out of memory" error in openGL. So it seems like you set the graphics settings too high for your graphics card (possibly very high shadows)
-
1
-
-
(Also, if you decide to go for these shallows and paths, one could have a really narrow one near enemies and a broader one near allies usig the areAllies(p1, p2) function)
-
1
-
battering ram garrisoning
in Gameplay Discussion
Posted
Armor only relates to attack types. Garrisoning entities influences the capturing regeneration rate. That number is not displayed anywhere currently. The effective capture rate is also proportional to the building / unit health as well. Since rams can't be captured, it's irrelevant for rams. But for siege towers and buildings it's relevant. A CC or Fort can be captured with like 30 units faily quickly. You can see in the tooltip of the building whether it only shoots 3 arrows and thus is easy to capture. If the building has 100% health and is garrisoned, no chance without siege engines reducing the HP to < 25%. I guess there a capturing tutorial might be useful to teach these aspects.