elexis

What are the current goals though? The funding campaign from 2013 at https://www.indiegogo.com/projects/support-0-a-d-an-open-source-strategy-game#/ specified 40k for a new pathfinder, somewhere like 80k or whatnot for the singleplayer campaign if I recall correctly. 25k may get you to any single goal, but after that the funding is gone. The numbers are public https://spi-inc.org/corporate/annual-reports/, since Wildfire Games is a member of the non-profit organization Software in the Public Interest as mentioned. Notice that Wildfire Games has running costs, of maybe USD 1000 for the servers and few hundred USD for travel costs. Also notice of the 33k from the campaign, 5k went towards merchandise. In 2018 WFG received about USD 3000 in donations and about USD 1000 server costs. What to do with that money noone figured out yet, and so it is kept in reserves (at least that's what's been happening so far). If nothing changes, it's at least good to know that one can afford server costs for the decades to come. How can you guarantee that? 25k USD / (10 USD/h) = 2500 hours. With 25 hours per week that's 100 weeks, i.e. 2 years for one contributor, excluding server cost. So indeed it would need more funding. I expect Wildfire Games will not be able to raise sufficient money to hire even one contributor fulltime in the foreseeable future, but that doesn't mean one can't try to improve the situation. I can pull something out of the hat later, but I haven't finished the IRS documents, and they are just as dull as GDPR.

Moving seems like a pretty good idea then.  I could imagine some people critizing that the implementation is moving things around for no reason. So the question is whether the provided arguments are too hypothetical or defeating arguments. One can often increase the sample size in such situations, then the consequences accumulate, making the advantages or disadvantages more grave, giving one a more clear picture which alternative is preferable. ResourceSupply.prototype.Schema = Engine.ReadFile("simulation/components/schemas/ResourceSupply.xml").replace("Resources.BuildChoicesSchema(true, true)", Resources.BuildChoicesSchema(true, true)); Those should be *.xsd files, because they contains the Schema to validate XML files, if Im not mistaken. The most simple solution would probably be to remove the Schema code entirely from the component code (JS or C++) and have the component manager instead load the Schema from <componentname>.xsd. I don't know if that approach could work with the resource type definitions, or whether one can just skip validating these, or whether one could do something fancy with including another xsd file.

The only arguable benefit of having the Schema in the JS Component implementation is to to have less user interaction when comparing the Schema with the implementation? We also have the JS and C++ interface files. The benefits of moving the Schema to an XML file each: Mixing multiple languages in a single file is an anti-pattern. In webdevelopment one can easily mix html, css, javascript , php and mysql in the same file. While there is less user interaction between searching lines in the same file, it may become even more fragmented; and the encoding of one language in the other language adds some overhead. For the same reason it's also better to keep GUI page JS in JS files and use the XML files to specify only how the page will appear and be accessible to JS. Syntax highlighting in XML / JS supporting editors will be correct Syntax checks by the Phabricator bot or in the IDE of the developer will inspect correctly The Schema file could be read by external scripts. Parsing XML is much easier than JS or even C++. One doesn't always have to compile C++ code again in order to changing some minor property of the Schema of a C++ component. It reminds me of the time when special templates were hardcoded in C++. (Special templates are more variable than Schemas though.) The componentmanager implementaiton might or might not become cleaner. Those global JS Engine.RegisterComponentType calls at the end of every JS Simulation component file break a bit the nice pattern of these JS files only specifying one prototype and doing nothing else. Is the Schema actually used currently anywhere? I can't find any call to GetSchema() in *.js, *.cpp. Why the heck does the Pyrogenesis simulation not use the Schema currently to validate entity templates upon entity construction? Seems like a glaring use case. And SimulationDocs.h is disabled? And CCmpTemplateManager::Init also looks incomplete: virtual void Init(const CParamNode& UNUSED(paramNode)) { m_DisableValidation = false; m_Validator.LoadGrammar(GetSimContext().GetComponentManager().GenerateSchema()); // TODO: handle errors loading the grammar here? // TODO: support hotloading changes to the grammar } About the word "engine components" -> #5366 works with JS components being engine components as well and should thus be moved to the pyrogenesis engine mod instead of the 0ad gamecontent mod. The only difference between the two types is that one of them has to be fast C++ and the other one can be slow but comfortable JS. C++ even hardcodes references to the JS components in the C++ / JS interfaces and via the C++ components that refer to the JS components through these interfaces. At least I don't find any other distinction between these JS simulation components and the C++ simulation components that would qualify them as gamecontent: Notice there is a gotcha about using XML files for the Schema, since some JS files (resources and damage types) create the Schema programmatically using JS. With XML one would have to have one XML file per resource per affected simulation component if one wants to support enabling multiple mods that add new resources each. The large XML file you posted above appears nicer than encoding that in JS. Another random example: CCmpPosition.cpp probably wouldn't look worse when that XML is in a separate file. So seems possibly nice, perhaps one can find some more specific applications to see if it's worth the refactoring and the additional userinteraction. (JSON might be more compact, but simulation components used XML to gain validation. Then I wonder why validation isn't reasonable for aura and tech templates if its reasonable for entity templates. Weren't auras introduced as JSON, then converted to XML by merging them into the entity templates, but that failed because different entity templates should refer to the same aura types? But perhaps that could have also been solved by having auras as separate validatable XML files? Actually, meh.)

The lobby users have accepted the lobby terms and conditions. While there is a clause about multiple accounts being permissible, such requests are exemptions for specific reasons, for example if someone wants to test a lobby patch, if someone is a moderator, or if someone can host two games simultaneously with the (almost) same nickname. Otherwise, requests for nickname changes and secondary accounts are not granted, so that players are able to identify each other after they have seen each others in games, thus able to avoid each other if they can't stand each other etc. (one of the reasons).

(It were 2000 new tickets from 2015 to 2017 if I recall correctly.)

Then +1 ticket references.

If I'm not mistaken, there are tickets on http://trac.wildfiregames.com/ for all four of them. Arbitrary colors have the problem that they might become indistinguishable. Same problem with increasing the number of players. Logos or color-combinations would work better with that regard.

Wildfire Games is a member project of Software in the Public Interest, so 501(c)(3) applies. Also, yes.

That is on MacOS / OSX or not? Gloox TLS is bugged differently on every platform ¯\_(o.o)_/¯ I'm unable to determine what a normal error might be, also those are warnings. But opening the file and the accoring line number and reading the error message shows that the language code is undefined. Opening the error screenshot and reading the language dropdown reveals an undefined there too. So I'd be wondering whether the locale code is broken on that platform. The terms dialog uses the same code as the language selector, so I'd be wondering whether that's broken on the affected platform equally (main menu -> options -> language or something). No, I don't want no scrub... Also I guess that indicates you being the author of #5404.

We can't distinguish how fast it actually runs, this gamespeed number is an upper limit. Also the rendering is cut to 1 frame per simulation update when doing signficant fast-forwards. Running a non-visual replay with one and multiple threads would provide a comparison. Threading indeed won't solve the slow algorithm (laptops with only one core won't benefit), nor is the problem related in any way to networking code. It's just that the pathfinding is too slow, burns too much CPU cyles, with threading the other cores burn too many cycles more equally. It will make the CPU fan more noisy I suppose, but it should probably still be done (and then the algorithm improvements on top of that).

In case you imported a heightmap image to gain the shape of the coastlines, the source should be mentioned.

We have no lack of people who want to decide on gameplay as a whole. The gamedesign plans where one doesn't know which individuals will implement them, doesn't how they can be implemented, doesn't know when they will be implemented by the envisioned individuals are doomed to remain pipedreams. The plan usually put forward by gamedesign proposals is that someone invents a fun game concept, and then Wildfire Games is supposed to implement that. The reality is that Wildfire Games is not a company, doesn't have any employees. The people that have worked on 0 A.D. and pyrogenesis at a time, throughout the soon two decades of existence one way or another were countable on one or two hands. When they worked on it, they worked on it in their spare time. In contrast, some commercial companies that provide comparable "triple A" RTS games may spend millions on hundreds of employees. What a single person can accomplish in their free time is very small, in particular when every possible alternative proposal by players shall be taken into account. S, to be honest, what 0 A.D. needs is more people who are capable and available for years to work on 0 A.D as a whole, so that they can decide on 0 A.D. as a whole and then implement 0 A.D. as a whole. Gameplans that decide on 0 A.D. as a whole without being able to plan an implementation with our current technical C++/JS implementation is not able to estimate the amount of work that is needed for that plan, not able to demonstrate the feasibility of 'the whole'. So it should be I'm pointing this out because if we only get "someone who decides on gameplay as a whole" without the proof of concept, we might actually worsen the situation for 0 A.D. as a whole, because it removes the freedom of the contributors to plan what they will implement. They are degraded from the developer to the programmer. I do get that the point that is often brought about is that developers can keep adding random stuff if they didn't subscribe to a common vision. But it seems rather that this is due to the absence of experience with the game and existing game concepts (implemented and not implemented), rather than the lack of "a person who decides on the game as a whole". (Also notice that Wildfire Games as a whole should decide on 0 A.D. as a whole in an ideal world (i.e. no time and effort cost to gain knowledge and take decisions and no possibility of mistakes due to partial knowledge).) But that's reversed. If we didn't had to spend past and future years on defects (and too long or sometimes emotional discussions on minor details), we could instead spend (and have had spent) our time on implementing new features and mechanics and revisioning the game. Depends on whether "planned" means "scheduled" and what threshold one defines for "major", because we have several lifetimes of plans on trac issues, in the old design documents, in forum threads. And I guess everyone has desires and imagination of the potential 0 A.D. could become, but fails to develop them (both figuratively and literally) because of the reallife constraints (the time it takes to implement it). I can provide a recent example. From August 2017 to February 2018 I worked merely on fixing bugs of the rmgen codebase. There was no space for any imagination, because there were just defects in the code that consumed months to rework. While doing so I gained a lot more knowledge on the gamedesign background, what the authors of these maps and map library methods (Spahbod, matei, Mythos Ruler, FeXoR) had in mind (or at least published) at the time of authorship. After most of the defects were gone and after months of time to think about the essence of that codebase, I gained the freedom to envision and implement the Kushite mapscripts, 'as a whole'. Exchange the program folder worked on, and we get the same storyline that we would need for someone who will work on formations/batallions, or a history mode, or as in this thread, many news civs. I elaborated on this because (a) it has potential for damage if put into action as is (spending time and effort on possibly unrealizable project ideas), (b) the same is stated by others in other threads, (c) there are no hypotheticals or conditions in that statement. I agree. On topic, it would be great to have many more civs, but they should IMO be part of separate games that use the same pyrogenesis engine. Like the 0ad mod for civs between 500 bc and 0 ad, the 500ad mod for the civs between 0 and 500ad, and so forth. Then if someone wants to go bananas and do extremely ahistoric fights, they can launch the games as mods simultaneously. 0 A.D. has the claimed purpose to inform players of the history of each civilization. So there should be a historical campaign for each these civilizations that should be more fascinating visual entertainment than any movie or documentary while the player gains the knowledge without any efforts to blindly learn it, like in school. At least that's what I would spend my time on before spending equal amount of time adding more civs. (Though I still think that the celtic tribes that aren't britons and aren't gauls, north of rome are missing if we want to implement the early history of rome in a campaign.)

Show us an fgod presentation in russian and we'll compare ;-) I'm glad we have good people who can represent Wildfire Games on software conventions, thanks guys!

Use cases for accounts: Accountability before WFG: Being able to enforce terms of service by rejecting the service to users that violate the terms. Accountability before the community: You stand by the history of your posts. To allow others to seek you out or avoid you, they are able to recognize you by the nickname that is displayed. They shouldn't have to conclude from the forum post content, let alone stray forum posts from years ago. Examples: People who look through past forum or phabricator messages and have a question to the author of messages or patches are actually able to find the author under that nickname. People don't try to inform you of things they have already informed you before. For example the GettingStarted bit was the first thing people send to you, but you have have a long Phabricator history, so the people were mislead by the new account. If someone would create a new account on Phabricator, one would repeat all the newcomer stories on coding conventions and codebase explanations from scratch instead of recalling what that one already knows or doesn't know. Use cases for uniqueness of accounts: By definition of the account: The defined purpose of the nickname field is to indicate the author of the message. Two different names are supposed to identify two different people. If people are permitted a second account for testing software, the nicknames should be similar, for example "user" and "user-testing". If we don't want that but a forum where noone knows who everyone else is, it would have to be built into the software, similar to 4chan, so that people have no false expectations of what an account means. Missing practicality: Even if you post in your forum posts that this is your second account, it is unfeasible as a general rule. For example servo didn't get that you are smiley although it was stated explicitly. Sending a personal message to every community member and writing it in every forum post costs a lot of time and space while the nickname field still displays you as a different natural person and people don't get it. Imagine everyone would have 3-4 fun accounts. People would not be able to keep track of who is who anymore. While this 'not hiding the identity' model works when 99% of the users stick to the rule and 1% exempts itself from the rule, it surely wouldn't work anymore if the other 99% exempt themselves too. Visitors in the same house are different persons that should have their own account. That's not the same as having two accounts for your own. If there is a technical reason to have two accounts, for example one for permitted lurking and one for playing, or a secondary account to test a bug in the development lobby. But in these cases, it should be accountname1 and accountname2, so that it is clear who the owner is (which is also the reason why we are ok with (-_-) using the smiley accountname on the lobby, but not the cloud9 one). The same is true for all the other people on the lobby or forums, high profile or not, who create smurf accounts. Creating a new nickname so that people assume you are a different person is behavior that we used to see from people who solely join the community to enjoy playing and harassing others, but not from people who have worked hand in hand for years on the project. So thanks if that is the case. I don't like being in a trilemma situation as a moderator where I either have to abandon the no-smurfing rule, ban or stop moderating. By the way game companies (like Blizzard if I recall correctly) counter smurfing by new accounts not being able to participate in chat or rated games until they gained a reputation and having account creation cost money (instead of moderation afaik).

Then use the account that people know you under.

Perhaps that argument could be filled with some examples, since it can only be true for a part of the battles, perhaps the majority. For example Vercingetorix had to surrender to Cesar because they were starving, despite still being fortified as far as I know.

Your legal person doesn't concern anyone unless you became criminally active on our online platform. Otherwise we only care about your IP address and whether that uses our service in violation of the terms of service. The service is rejected to users that violate the terms. Notice that you know all of that already because you have commented about all of that stuff with your other online account on phabricator and the lobby, and probably irc too. That about the legal side. About the moral part: If you actually "don't hide" that you are smiley, then why are you arguing for registering as many accounts as you desire? Chanigng nicknames because they are more interesting is not covered by the terms and imply the problem that people lose the ability to ban you from their matches, lose the ability to leave matches when they see you are there too, or correspondingly stop responding to your forum output. An account enables accountability, removing accounts removes accountability. Pretending to people who you have become very familiar with after countless hours of game sessions and partnership in code projects, for, it must have been years, to be a a total stranger is joining the discussion under false pretenses. I can't keep track of how often you have intentionally posted profanity in order to become muted, changed your nickname after we kicked you many times already and how often we banned your multiple smurf accounts and your original account temporarily. Last time I logged into the lobby I only saw you shouting "why the @#&#036;% am I not muted". Saying that you don't understand the rules and that it was unintentional is something that works the first 5-10 times, but at some point I cannot take this as honest and good faith anymore. We just had the same discussion about your "accidentally lost" lobby account password last week already with at least two other lobby accounts. Given that you have bragged on the lobby that you have intentionally changed your phabricator password so that you lose access makes me doubt whether your lobby password loss was an accident. But in case that you have created the cloud9 forum account because you merely lost your forum password: https://wildfiregames.com/forum/index.php?/lostpassword/.

How does anyone other than me, let alone everybody know who you actually are?

But why is the duplicate forum account not banned?

The talk by Vladislav has been uploaded: https://video.fosdem.org/2019/K.4.401/

What do you think how bloody my knees were sending PMs and begging people to commit who had no interest in the patches throughout 2015? One always had to consider how far one could go with spamming people before they would stop responding and go offline. If you want something to change, you gotta be that change, noone else can or will do it for you. Sure, there's a condition to getting commit access, that is mostly leaving a good impression on the members.

No I agree. Just the conclusion is that you have to gain commit access so that you don't have to rely on reviewers with commit access anymore.

Looking at stats, I guess someone is confusing Wildfire Games for their personal patchslave.

Techs in the summary screen are a must-have. It's good that they are ordered chronologically, but we should also record the time when they were researched, so that viewers can compare when the players researched a specific technology and how it influenced their economic or attack stats. In particular it would be nice to show them on the graphs as icons. Equally should record the time when players are defeated or have won, and the defeat reason. (Also it would help to formally report that Set vs. JSON issue of the GUIInterface that you informally reported on multiple occasion.) Great features, popular mod. I guess the terms-and-conditions check for lobby-autologin is still missing, and I guess noone reads the terms anyway, and they are updated rarely as well. The nickname option was removed? If so and if someone checked for the absence of possible security problems, perhaps the popular mod should be upload to mod.io finally.

Corresponding ticket: #3145