Topics created by Cernel

While testing on WWII revised I saw a similar problem rarely and it seemed to maybe have gone away after a 'blind fix'. Basically a fix where you can't confirm you are fixing something but you think you see where the problem could be. Usually those are non-fixes and the problem still remains. Having a way to reproduce this problem is critical. The location of this bug is in a bad place of the code where it could be many things, there are some very subtle timing issues. I could imagine someone spending a couple weeks tracking just this down. I don't think anyone will have the 80 hours to dedicate to that, as an open source project that time investment could span several months. This is probably going to be the biggest bug in the 2.0 release, if we need a few months to track this down, 2.0 will be majorly delayed or we'll have to tell every user all about this and how they can bypass it until fixed (not ideal).

@Cernel Yes I believe the sorting of units based on either attack or defense of the units whether they are the attacker/defender.

@Cernel It's from the perspective of the code, all maps are downloaded one way or another. That maps can be developed locally is perhaps a good nuance to point out. Some of the file collections can be empty, I suppose only the XML collection must be non-empty. 'Map' vs 'game' is one of the more painful examples of poor domain terminology as the two are virtually flipped compared to common usage.

@LaFayette All fixed (2.0.15631) (except maybe the report thing, that I don't know).

So, since I want it both production based and to be achieved any time, rather than at end round only, and much prefer it showing clearly in the customizable settings, I'll use this hack of having multiple endrounds, as it doesn't appear causing any troubles (and the game is not meant to ever have any triggers). But I'm open to refactor it if it would be possible to achieve the same result with victory triggers/conditions, eventually. I guess since we assume multiple endrounds is not intentionally supported, no reasons to document it. Still, I have to say that personally doesn't like the fact that this endround step manages both hardcoded victories and sets uses for triggers, as they seem unrelated matters, and, in my mind, it should have rather been called "victory" step, doing only that (traditionally as the last step in the sequence).

non - Triple A I played a cruel rpg game called Eternal Lands and I started and I wanted my character to not kill animals so it only killed monsters at low levels (never saw anyone else do that) and I stayed awake 70 hours to finally level and kill my first goblin.... but for Triple A yous got me cuz I don't think I ever had a match longer than 15 hours but cool this game rocks for cool matches

@redrum said in Domination 1914 No Mans Land fails to start [FIXED]: @Cernel Right. Which I'm sure inconsistent naming exists. I agree that would seem better and I'm not sure why the double folder was done. Either way we are getting off topic and better to open a separate thread if you want to discuss it further. Since we have verified that at least the file name in main folder must be the same as the "mapName" in the xml, that should be right for all old maps (otherwise they would not have started in the past) and also right for all or most new maps, as otherwise the mapmaker would have failed testing his own map before getting it to download list. So, I don't think there is anything to worry about this, as currently either a map has the same main folder name as the one spelled in the xml of the games themselves (they can be more than one per map), or it is already not working anyways. Inconsistent naming should really not exist, since in the first folder (from the download list naming) it would currently cause the map to fail to start and in the second folder it would have already done that when the mapmaker was testing it (likely in its simplest and unzipped format), before getting it to download list. So, I think it would be better at least picking one of download list and repository names (I'd definitely say the repository name), instead of, as I understand it, the current process of having first download list name, then repository name, then the actual "map" folder, that I don't think anybody is going to dream it's working this way, or at least this thing should be documented somewhere, that the mapmakers must be sure to have both equal to the xml "mapName", or issues like this one I'm pretty sure will keep happening overtime, and they are a bit problematic, especially since they would leave wrongly named maps inside users' folders, still adding games to that users' selection lists (either calling another folder or failing to find any, like it was the case here, depending whether you already downloaded this map in the past or not), that most users will fail to get around tracking and deleting manually, since they are not going to be overwritten by the correctly named ones (once available).

@ubernaut The old lobby is generally kept running for a few weeks to a month or two so peeps can finish old games when we release a new non-compatible stable. It's all good

@Cernel Thanks for catching that. Updated at The Hub. Yea I try to stay consistent with upper and lower. Doesn't always work though : )