elexis

When you click on "save", you get the savegame. The replay still doesnt know which savegame relates to which replay file - with the patch above you can load them by hand. When you rejoin a multiplayer game, the server sends you a savegame which is loaded into memory and forgotton.

Because the savegame of that point is not saved to the disk and hence can't be loaded before the replay starts.

Is it intended and are translators informed prior that their email addresses are published forever in the *.po files in svn/git repositories?

Replays only contain command sent by human players. The commands AI players order are determined at runtime and are not present in the replayfile. The Pyrogenesis engine is deterministic, which means in theory the replay should always compute the same state and serializing/deserializing (=rejoining a multiplayergame or saving+loading a game) should too. If it computes a different state sometimes, it's an "Out-of-sync" error, which is one of the worst errors that can happen and a release-blocker bug as it breaks multiplayer games and replays. In order to verify that there is no such error, the simulation state is hashed (you can see the hash in multiplayer replay files commands.txt). I'm wondering if we shouldn't add hashing for singleplayer replays too for that purpose (replay integrity). AI bots are not deterministic, they are Out-of-sync, because they create new plans upon each deserialization (savegame loading, multiplayer rejoin), rather than serializing and deserializing their plans. Fixing that is important as we can't play multiplayer games with AIs currently - players will drift into parallel universes when playing with AI currently if one of the players rejoins the match. (Also performance of AI is tough) Replays starting from savegames will probably work with my patch hack linked above. If you're not familiar with patching and reading code, lobby to have me commit this replay+load commandline option, otherwise wait (possibly some years, or put a high enough price on the feature for devs to prioritize finding some solution). Notice that savegames can be 2-10MB or something each, so there can be an accumulation problem if its stored for every replay starting from a savegame and every replay of a match starting from a rejoin. Otherwise that what smiley said.

People (team or not) who keep following http://irclogs.wildfiregames.com/ know what's going. It's something which everyone ought to do, but can also be time-consuming (as one cant find some little detail to comment everywhere and then gets caught up in some argument about something that still is a detail). Of course we also have internal staff forum threads, the trac roadmap (https://trac.wildfiregames.com/roadmap), the ReleaseProcessDraft and sometimes staff meetings (logged at https://wildfiregames.com/meetinglogs/) for scheduling. As a byproduct of the Phabricator irc bot, I had scripted an semi-automatic summary of activity on Phabricator. It could be polished and become full-automatic (weekly or user-determined-timeframe reports). But I had put it aside because it can be and was mistaken as a presenting ones ego. I'm attaching an example from the past. Of course an overview of the most recent commits and the trac.wildfiregames.com/timeline also helps getting a summary of what happened. The development reports on play0ad.com themselves maybe more digestable to the distant player who wants to know a summary in 2-5 minutes. But they are really lacking a lot of information. We probably want weekly reports with screenshots and twitter and facebook, so that all work (including server, forum, lobby and team administration) has a place to be mentioned. (But that also means that it will be very visible when people receide and there might be some infighting for the fame and the hearts of the groupies) Generic Progress Report for Wildfire Games in the time between Mon May 1 08:00:00 2017 and Sun May 7 22:00:00 2017 elexis: fatherbushido: fcxSanya: FeXoR: Imarok: Itms: leper: mimo: scythetwirler: wraitii: Progress by non-team members: bb: borg-: causative: Grugnas: Hannibal_Barca: minohaka: Phormio: Polakrity: s0600204: sacha_vrand: Sandarac: Stan: user1: vladislavbelov:

Alpha 17 and 18 took 5 months, Alpha 19 took 6 months. But comparing early to late releases is like comparing apples with potatoes: On the one hand: The more features there are, the more code has to be maintained, fixed, rewritten, improved. For example it took me 6 months to rewrite 65+ random maps during alpha 23 development. So many maps and bugs didn't exist back then. Secondly the capable motivated and available developers went down. Thirdly we put more emphasis on quality now than was done before from what I can tell (for example we try to balance the game so that it can be played competitively on the lobby, which wasn't the case until alpha 14-16 when the lobby was introduced and scythetwirler started trying to fix the balance. But the quality in other areas was neglected too. I recall alpha 18 was about to be released with an OOS, nowadays we would fix it). Another example are the trailers, which consumed up to 2-3 weeks. Very early releases often were only a new snapshot of the most recent state with sometimes only few and small addtions. In the last years we try to add at least 3-4 new impressive features that have distinct, memorable character to call it a release, so that people actually get excited about the release (rather than just installing something that doesn't differ from the predecessor). The 4th reason is also the reason why this should not be called alpha 24 but alpha 23b. There is literally not a single new feature unless you call privacy policies or connection encryption one. It's a classic maintenance release. An update to an existing product as the existing product had some serious defects. So if one wants to target 3-4 month release cycles, that will come with a serious quality or feature reduction unless there are some supermen coming. I think we should continue to keep the quality, use our time more economically / productively. People have kept piling hacks and workarounds. It seems we currently add more contributions the way they should end up in the final version of 0 A.D. and pyrogenesis. So the end of having to rewrite historic spaghetti code might come eventually. After that, we can provide the same quality and same new impressive features in a shorter timespan. I don't see how we can change the rest of the restrictions (in particular if we want to use the time most productively). Alpha 23 rerelease in particular had some weeks of timewaste unrelated to above argument as everyone fled the dirty GDPR work. That is more a problem of negligence.

That's me. A nice one day task with regards to the first implementation: D1674. Using this script I found there are three further strings that throw errors upon use that noone found yet: The nice thing is we know that we can find all of them by running a short script, i.e. there are certainly not more than these three. Now who wants to update transifex?

@gameboy please post this on https://www.transifex.com/wildfire-games/0ad/, otherwise the bug will reappear soon

Register at http://transifex.com/ and translate "Add another worker to speed up the repairs by %(second)s seconds" correctly. It should be in the "public-gui-other" section.

That ^, because in there is "Add another worker to speed up the repairs by %(second)s second." and using gives one result: Entirely: So someone added a broken translation that should be fixed as soon as possible on transifex. Gratis bonus fact, the translation was copied from: Now who wants to write the script that checks all *.po files for this mistake systematically, so that players don't have to randomly discover it (or even the trac ticket)?

Did you get the crash with Tobbis image or with one that you compiled yourself?

Looks like trompetin17, Itms and Tobbi are saving the day! To all macOS users: Please help us test this 0 A.D. Alpha 23 release candidate! Try to find and inform us of any bugs (in particular bugs that prevent you from actually playing the game)! macOS Alpha 23 re-release candidate: 0ad .dmg 840.3 MB https://mega.nz/#!Jcd2EaqB!uX5NiOYuaIzfdliy10nOZx9T2vsQK8AKltStDbE5IQs

scythetwirler had changed siege engines to be much more effective in Alpha 21 or so. It was mentioned in the trailer. A23 is indeed the most stable balance I played so far (still imperfect in various ways).

svn is tested more or less permanently by a number of players (those who are able to download svn and annoyed by some dealbreaker bugs), but not on macOS That assumes that there aren't compiling or linking issues, version conflicts. There are what feels like 1% Mac OS people on the lobby. Most of them are never seen again after few lobby joins (even if they could play with the icon fix mod). Of the handful remaining that occasionally join the lobby and can be communicated with, one of them had a version conflict issue, the others are not available for such discourses. It really needs a developer to record, investigate and fix reported issues. I guess that will again be done by people who don't have a mac again with a VM, rather than the developers with macOS fixing their system (please prove me wrong).

WFG members can't do the testing of bugfixes because we have noone with a platform to test, Tobbi is not doing the testing of bugfixes. So this is a deadlock with the remaining choices to ask other people who are not available or not interested, abandon macOS or bundling on an illegal virtual machine and running into the abence of macOS devs problem the next release bundling where noone run the application even once on macOS before everyting is in feature/string/translation/commit frozen again. The technical issues aside, what really bothers me is the attitude of people who accuse others of preventing them to commit game features, directly or indirectly, whether here or in other threads, without ever having lifted a single finger to go beyond ones own scope of interest in feature development and performing whatever is needed to have the next release (and a final release sometime). The ones going beyond their own scope of interest to accomplish a release are the stupid and exploited ones as they pay with their own time and energy to fix what ought to be shared obligations and then get the blame from the ones who feel too noble to substitute missing development occupation if it isn't fast enough according to their liking. cudos to stiefkampf and av93 who asked answerable questions rather than unactable statements that are not or not well distinguished from blame. At least on my side there has never been a lack of development either, just a lack of published development with more than hundred committs in git branches waiting to be committed, waiting to be rewritten because they coudln't be committed and patches not distributed as I'm not making myself a slave for the project in every instance. Have a nice day.

Mac issues are unresolved, existing solutions to mac issues from previous releases aren't committed because they can't be verified, noone can bundle the thing on a macintosh because none of us have one (or rather the only one who still is online sometimes has too few disk space to compile it). (The same thing will most likely repeat itself in the future development cycles and the holy grail of macOS being broken will probably be that they dropped openGL). The codebase is finished with regards to GDPR since Oct 16.

If you don't express what you mean, readers can only guess what you may want to say and that may lead to conflicting interpretations. Do you want to express that there is evil we are not allowed to talk about or not allowed to witness? If so, I agree. Otherwise,I don't know the purpose of this thread? If thread participants want to see a specific task being done, how about performing it if noone else does it? In that case the question that people should ask is what is needed for the next step and translate that into actions. To me it seems like can give up on releasing mac OS and go on with development for windows and linux, since every mac OS developer left the team long ago.

With the UnitAI code from before rP21630, the catapult does not unpack on sight. The described issue was introduced in that revision.

Unknown land with nomad and terra magna works for me.

Wasn't that the case in alpha 22 too?

@temple @mimo @bb_ this is frequently reported as a new bug in alpha 23, so I suppose it is related to rP21630, rP21784 or rP21786? Reproduce: Start a singleplayer match with 2 players with siege engine civs (athen, ptol, seleucid, mace...) on a tiny map Type "gift from the gods" cheat Build the building to train the siege engine and train a siege engine Move the siege engine to neutral territory. The siege engine is still unpacked and still in the default standground stance. Type "gift from the gods" cheat (so that packing isn't instant anymore) Press Alt+D and switch perspective to player 2 Type "gift from the gods" cheat Train some attackers, and let them attack the siege engine Switch perspective back to player 1 Observe that the packed siege engine starts unpacking on it's own as it was attacked by an enemy. You want the siege engine to retreat intead of continue to unpack and attack. Therefore you click on "cancel unpacking". Expected behavior: Clicking on "Cancel unpack" stops the unpack process and allows the still packed siege engine to process move orders. Current behavior: Clicking on "Cancel unpack" resets the the unpacking progress bar to zero, but the siege engine starts the unpack progress again on its own. The user has to wait to wait one full unpack cycle and then one full pack cycle to move the siege engine that was packed already. Here my somewhat concise replay: commands.txt Reported at #5328

If you just want to play against someone who is using the same internet connection, don't use the lobby, but click on multiplayer -> host, the other one clicks on multiplayer -> join and types the LAN IP address, something like 192.168.bla.bla, not the internet IP. Then most likely you don't need to forward. For internet games, only the host needs to forward the port, not the client. STUN allows joining for some but not all remote players if the host failed to forward properly (so you can test if you forwarded correctly by hosting with disabled stun and seeing if anyone can join).

The GPL license grants everyone to modify, redistribute and sell modifications or extensions to the 0 A.D., i.e. to compete for funds on third party online payment services. What is left for Wildfire Games to decide is what happens on Wildfire Games online services (lobby, forums, mod.io, download page, ...). The Lobby Terms say promotion of specific goods or services is not allowed (not allowed without WFGs permission in the new revision). I expect restrictions on that by the non-profit status too.

The ban was done on grounds of: You are right that the banreason "improper nick" should include the notification that one may create a new account with a different nick, rather than assuming it is implied, in particular due to: So consider this your allowance for different nick that moderators deem consistent with the Terms of Use.

refs