elexis

(There were some screenshots visualizing different aura radiuses in D395.)

I'd also favor a general vision range reduction and increase with age 1 and 2 (plus a technology in age 1 to increase the vision range). Hannibal was not decided yet. @mimo had similar plans right? So perhaps we can get Grugnas to create said patch(es) for Alpha 23 and start agreeing on vision ranges based on screenshots and reviewable patches (that don't have any other balance changes)?

Does that map on the screenshot include a createBumps call? Try the numbers from danubius. Might be weird for the cliffs, but I assume those can be avoided (as in cliffs being marked with a tileclass)?

Reminds me of the Ambush or Archipelago map where you often see circles around the CC. By using some random patterns instead of only a single circle or square, that shape could be blended in a bit. The flattening approach doesn't seem so bad after all. An alternative would be very strong smoothing. Notice that besides a single player being cut off, theres also the possibility that two parts of the map are disconnected. Perhaps connectivity could be ensured by creating paths between players, as seen on Caledonian Meadows. Those paths really add a lot of value to the visual appearance as well usually (for example on Danubius). Also I'd recommend a createBumps() call after all mapgen is processed to disrupt any repetitive patterns in the terrain.

I've investigated the stacktrace further and now know less than before. Looking at the revision log of apic.cpp, Janwas was probably the only one who knew what this code does exactly (and N/A). The line calling from the windows code into the unix code was added by r8951 with the commit message " Add some more stuff to hwdetect, because there can never be too much". Maybe we have found an exception to the rule So you could try to delete this one line from the stacktrace that induces the crash (i.e source/ps/GameSetup/HWDetect.cpp 313) and compile the game with a free edition of Visual Studio 2013, see BuildInstructions. scriptInterface.SetProperty(settings, "numa_numnodes", (u32)numa_NumNodes()); I don't see anything using that numa_numnodes property (perhaps the hardware database server won't like that property being missing, but that'd be unrelated). Alternatively, the entire hardware detection code could be cut off by adding a "return;" as the first statement in RunHardwareDetection(). As far as I know, disabling the hardware detection code won't reduce your ability to play (you might have to test which graphics settings work with your graphics card and driver at worst).

Definitely never seen that stacktrace. apic.cpp is part of the arch linux dependencies if I see this correctly. What struggles me is that your OS is windows though. That part was called from the Hardware Detection part according to the crashlog. Machine name and ID might be interesting, but indeed not relevant Can you try previous versions of 0AD and see if that breaks too? We did change some Hardware Detection code in #4561, so maybe it doesn't work for your particular hardware configuration. If a previous works, you can try to bisect which revision introduced the broken change (if X works and Y fails, try (X+Y)/2 next). I'd test for r 19876. If that crashes too, could try Alpha 21 release (see Changelogs for the revision IDs). (Notice that the pyrogenesis.exe had been updated only every now and then, so you won't be able to pin down the exact commit that broke it).

Oh, also getting everything review into the last bit made it about twice as long to get the same code into the game.

I'd favor a 4 month release cycle to keep it a bag of positive surprises. We could have probably released 2 months earlier if there hadn't been things to wait for beforehand (something like 8 things to wait one week for each. It hadn't been in our control to change.) I'd prefer 3 releases over 4 per year to keep it a tremendous update (as opposed to having only one major feature). Alpha 22 development started Nov 10th 2016, then feature freeze was on Jun 1st and release was on July 27th. That's just bad. The key to improving that is having more active and qualified contributors if we don't want to release without new features that can be mentioned in a release announcement. Wait, this is the Hyrule Total War thread?

That mod contains only templates and the committed splash damage bugfix. There is no reason why this should crash. Therefore every crash should be reported like a crash without the mod. If there is no bugreport that states how a crash can be reproduced, then there is nothing that we can do. I saw one line about SDL_TextEditing. This is certainly unrelated to the simulation and the mod, but should be a bug in source/gui/ and triggered when someone edits the text in an input field. (Since it occured in a22, I'm glad that my recent commit to the file didn't cause the crash :P) https://trac.wildfiregames.com/wiki/ReportingErrors

You can have the worlds best programmer, if the problem can't be analyzed, then we don't know what to code. However the issue sounds like some graphics cards don't support some shaders that are enabled by GLSL. So the hardware detection code might be improved to catch that (so the analysis could perhaps be done by looking at the specs of graphics cards in the reports). But then again there seems to be a problem with 0ad picking the worse graphics card if we believe that one reporter.

mainlog.html has some warnings about the structure tree not supporting that many units, which only occurs for mods as far as I know. The crashlog.txt says it crashes in the NetClient at DeserializeState. I might suspect that you tried to join a lobby game where the players dont have mods while you had a mod enabled. We don't have mod support in the lobby currently, but with every release, it becomes a little bit more relevant to add it (as in showing a warning that you need the exact same mods as the players in that game).

Patch review: Stan agrees with the patch and the cheating factor is really negligible. The most one could find out is if there is a mountain or not. (The rallypoints allow for more cheating as they indicate the entire path, obstacles on the way and the entire terrain changes on that path.) Patch is correct because that property does by definition what were looking for, its complete because the other non-optional Visibility properties are given in the inherited actor template. Ive tested it and it works as a dvertized and doesnt reveal the marker to enemy players. The alphabetic order of the components is kept too. </review> Thanks for the patch.

Not sure why this would be considered as such. I've stated this in the differential revision proposal as well. If one knows that a command will be executed upon click, then the target marker does in fact not add new information and is just a fancy graphical enhancement and does not provide new information, am I wrong? I have committed that because I like it, so not sure why I'd be considered a critic of the feature. If one does a rightclick, then the units will react to that. But that isn't obvious. If the game is lagging then units don't react to the player command until some considerable amount of time later, so the players might assume the units didn't react to it. So often players reported that they can't play with the lag, while in fact it becomes easier to play with more lag (as one has more realtime per gametime to send all commands).

You mean it gives a new information to the players because the players might not know that their command definitely makes it into the game until the next turn is executed (which might take some seconds with heavy lag?).

gameboy, we need someone that can write code AND experiences the same error before we can write a fix. Other than that, you might want to try the recommendation of one trac user: http://www.techadvisor.co.uk/how-to/pc-components/how-set-default-graphics-card-3612668/

I heard that from a different user too. The hotkey code didn't change at all in Alpha 22, except this one commit rP19624 / D303. It doesn't look like it could cause a bug like that. You could checkout the code, remove the two new lines in that patch and compile the game (see BuildInstructions) to see if it changes the result. With the below patch, you could also display the actual SDL keycode of any pressed key. It should be 49 if you press the "1" key. Perhaps we could also consider whether SDL2 is stupid and assumes your number keys to be keypad keys, but I doubt it. https://wiki.libsdl.org/SDL_Keycode Index: source/ps/Hotkey.cpp =================================================================== --- source/ps/Hotkey.cpp (revision 20095) +++ source/ps/Hotkey.cpp (working copy) @@ -161,6 +161,9 @@ case SDL_KEYDOWN: case SDL_KEYUP: keycode = (int)ev->ev.key.keysym.sym; + LOGWARNING("Pressed SDL keycode is %d", keycode); + LOGWARNING("The button 1 is expected to have the value %d", SDLK_1); + LOGWARNING("The keypad button 1 is %d", SDLK_KP1); break; case SDL_MOUSEBUTTONDOWN:

The bug appeared when the barracks converted to gaia? Could ask one of the participants to upload a replay. If so I'd appreciate the minute in which the bug occurs. But perhaps you can easily reproduce the bug already, given that description? Like building some barracks, researching a tech, deleting the CC, then replaying that game, selecting all barracks and hoping the bug will occur again? It could be that the entity ID of the selected building matters (as in either the first or not the first built, selected barracks having to be the one researching a atech).

That contrast problem is getting more annoying the more often I mention it. FFS, it must be possible to fix it. @stanislas69 no ideas? The purpose isn't an indication of ownership, but to give more immersive feeling (blue is what you are and everything you do is blue) and to make UI colors consistent. Should be relatively easy to make an option to use a fixed color in all these places (except in observermode). (Also the target marker isn't really needed for players because the marker is directly beneath the mouse cursor and has disappeared before the mouse moves somewhere else. It's just there becaue it's fancy afaics).

The marker shows up in the fog of war, but not in the shroud of darkness. It was noticed in the review, but we thought it might be ok for it to not show up, because it allows finding out the terrain at that place. But I guess that is totally irrelevant and we were just lazy to find a way to always display it So if the others agree, I will commit your patch. While discussing the thing, I was also wondering if we could make that thing use playercolors. It'd allow showing markers for all players in observermode and would be more in line with the selection, aura, rallypoint and minimap colors. It only runs into that contrast issue again (black playercolor on volcano, green player color on anatolian plateau). Can't we solve that by adding a second color around the playercolor? I guess there is only white available and that's already there. Don't tell me it's impossible, there must be a way to keep the contrast.

TypeError: reqs[Symbol.iterator] is not a function g_SelectionPanels.Research.setupButton@gui/session/selection_panels.js:770:1 g_SelectionPanels.Research = { "setupButton": function(data) ... let tip = template.requirementsTooltip; let reqs = template.reqs; for (let req of reqs) Interesting error. Do you happen to recall what your selection was at the time? Got a replay? Recall when that error occured? Sure everyone was using the same mod (as in no mod or everyone delenda est?) Sure you don't have unrevisioned files (simulation/data/) around? My best guess would be either broken requirements in a technology JSON file (we should have noticed long ago though), or a strange bug in the requirements parsing, or the building that was selected being destroyed or converted to gaia perhaps.

Code looks ok. 440 lines of code sounds like a lot, but the file is really small in comparison. Pass by at our Coding_Conventions page and compare with our codebase: use ++i where possible remove braces if in if-statements and loops if they contain only one statement a space after if and while open a scope with { on a separate line space after a comma stick to JS doc defined syntax (i.e. dash after @param variable, http://usejsdoc.org/) less indentation for these = function() statements few unneeded braces (a && b || c && d) (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence) Also might want to checkout FeXoRs heightmap library that is used for Caledonian Meadows and Wild Lake. It distributes the resources depending on height. (Argh, those ugly 3 black tiles at the map border and incomplete skyset again. Had this issue in the trailer and release screenshots. They only make sense when playing in a top-down perspective, so perhaps we should switch to a complete skyset and enlightened map border if the horizon is within the camera view) Make sure to end up with a map that we can commit for alpha 23

@Itms

Nice work Pyrophorus! I'd advise to create one or more random map scripts for multiple reasons. Foremost, lobby players almost exsclusively play random map scripts (because they can change the number of players and any other setting arbitrarily). Secondly because it is very rare that someone actually proposes a polished map for 0ad that was done with the map editor. With regards to your code, you should take care that the generated map is round (thats the convention, looked better with the minimap. Is also better for gameplay as noone can hide in a corner and all players have the same distance to the center of the map. Also square maps have 4/pi times more area on the same mapsize, i.e. 27% more which often causes unintended performance-lag). Put some players there, straggler trees and details and try to make the resoures balanced (as in guaranteeing 40 starting trees for each player). It'll be important that there aren't wide areas void of entities. There can be open space, but the eye should always have something to look at. I saw water can be generated as well, so you might have to paint terrain below players (like archipelago random map script does) or ensure that there is sufficient space for each player. Most of the maps generated with your script have very steep terrain. That's fine for some map generations, but not for every. Would be great to include a map that encompasses all these considerations in alpha 23!

Can you test that patch?

Index: source/lobby/XmppClient.h =================================================================== --- source/lobby/XmppClient.h (revision 20067) +++ source/lobby/XmppClient.h (working copy) @@ -154,7 +154,7 @@ const std::string& property1_value = "", const std::string& property2_name = "", const std::string& property2_value = "", - const std::time_t time = std::time_t(nullptr)); + const std::time_t time = std::time(nullptr)); private: /// Map of players