Cannot play custom maps. Please help!

[Mijorious]

I absolutely love this game but I've ran into a snag and am at my wits end.  While playing either single or with my wife, we noticed that there wasn't enough fish in the lake. So, I decided to either modify the "lake" map or create a new one with more fish

Well, that presented another issue that has become an obsession and it's driving me nuts! I modified/created a custom map using Atlas, named it, and saved it. BUT, it doesn't show up in the map list. Why?

I have searched the forum and google and have found several suggestions but none have worked. The files are being saved in "W:\Documents\My Games\0ad\mods\user\maps\scenarios" and "W:\Documents\My Games\0ad\mods\user\maps\skirmishes".  But my game is installed on another drive/path.  

I have created a "maps" directory under the public folder as one person suggested and copied the files into it but that didn't work either. My path is "W:\Gaming\Installed\0 A.D. alpha\binaries\data\mods\public\maps".  Is this where my custom games should be copied to?

Please help!  I cannot find a straight answer for this and I've spent MANY hours on it. I'm about to give up.

Thanks in advance.

[feneur]

Have you tried changing the map filter to All?

[Mijorious]

12 minutes ago, feneur said:

Have you tried changing the map filter to All?

Yes. I have tried every option that is available. My custom maps do not show up. However, they ARE saved in my "W:\Documents\My Games\0ad\mods\user\maps" folder in both the Skirmishes and Scenarios sub-directories.

[Mijorious]

Here's something else . . . .

I have searched everywhere, including the installation folder, but can't find the physical game maps. However, I just unzipped the "public.zip" file into a temp folder and there's over 2gb of files, INCLUDING all the game maps. So, does the game look into the public.zip file for it's maps?  Of should I have unzipped the file into the installation folder? 

This is not making any sense! I'm confused.

EDIT:  Ok, I have confirmed that the game looks inside of the public.zip file for just about everything. I mean the art, audio, shaders, etc AND all the standard maps.  I moved the public.zip file and the game errors when I load it because it cannot find some files. So that confirms it. Why is it done that way?  Anyway, I'm in the process of unzipping the public.zip forder to see if the game will read the files "outside" of the .zip file.

I should not have to do all this work just to play the game with custom maps, but it seems that I do.

Edited March 31, 2019 by Mijorious
Update

[feneur]

The pre-made maps are indeed found in public.zip, and should be there. You can un-zip it, but there is no need to. The game should look for maps in other places before the zip though, so that shouldn't be the problem.

I just tried creating and saving a map, and it showed up fine in-game. One thing to check is whether or not you've changed the name (seen in the first panel in Atlas - the scenario editor), if it's still the same it might be hard to find it in the menu.

[elexis]

1 hour ago, Mijorious said:

it doesn't show up in the map list. Why?

One of the most common reasons is as feneur mentioned: (1) not looking at the correct maptype in the maptype dropdown in the gamesetup, (2) not looking for the map title entered in atlas in the map selection dropdown in the gamesetup.

24 minutes ago, Mijorious said:

W:\Documents\My Games\0ad\mods\user\maps

That sounds like you created a directory for a new mod, but didn't add the mod.json file and didn't enable that mod in the options. Modding_Guide.

If you didn't intend to create a custom mod, it should be "public", but I'm not sure if if the public folder is launched if public.zip had been launched before. Also "user" is a reserved name for mods.

Just create "mods/yourmaps", add the mod.json file and your maps to "mods/yourmaps/maps/scenarios/". (I hope I didn't add a typo.)

[Mijorious]

8 minutes ago, feneur said:

The pre-made maps are indeed found in public.zip, and should be there. You can un-zip it, but there is no need to. The game should look for maps in other places before the zip though, so that shouldn't be the problem.

I just tried creating and saving a map, and it showed up fine in-game. One thing to check is whether or not you've changed the name (seen in the first panel in Atlas - the scenario editor), if it's still the same it might be hard to find it in the menu.

Understood.

Yes I have changed the name in Atlas and the two file ( .pmp and .xml ) are created. They are in my "W:\Documents\My Games\0ad\mods\user\maps" folder. The name of my test game is "lake 2" and it does not show up in the map list in-game.  Even if I copy the files to my installed game directory.  Can you confirm the "exact" directory path that they need to be in?  I've gotten several different ones from other people.  Thanks.

[elexis]

1 hour ago, Mijorious said:

Yes I have changed the name in Atlas and the two file ( .pmp and .xml ) are created.

Title != filename.

A map titled "Good" could be found in bad.xml.

1 hour ago, Mijorious said:

Can you confirm the "exact" directory path that they need to be in? I've gotten several different ones from other people.

http://trac.wildfiregames.com/wiki/GameDataPaths

https://trac.wildfiregames.com/wiki/Modding_Guide

[Guest]

10 hours ago, elexis said:

That sounds like you created a directory for a new mod, but didn't add the mod.json file and didn't enable that mod in the options. Modding_Guide.

If you didn't intend to create a custom mod, it should be "public", but I'm not sure if if the public folder is launched if public.zip had been launched before. Also "user" is a reserved name for mods. 

Not really. `user` is a game created "mod" that is mounted every time. User created maps are saved in there. That is why it is reserved.

GameSetup.cpp

Edited April 1, 2019 by Guest

[elexis]

As I never fully understood the purposes of this mod and why it's only used for development copies, I didn't want to say something wrong, so I only said that it's a reserved keyword.

I recall the user mod mostly from the fact that it resulted in the same code marking replays as either comaptible or incompatible depending on whether one runs a code checkout or a release. It was hotfixed by making the replay compatibility check ignore the "user" mod. The same check was added to other places. So the question is whether one could achieve the same the user mod was supposed to achieve differently, without having to spread exceptions throughout the codebase.

The purpose of the "user" mod is to allow users to store custom maps / mod data?

I know it's in Gamesetup.cpp, but the information there doesn't clarify the purpose of the mod:

	const bool add_user = !InDevelopmentCopy() && !args.Has("noUserMod");

	// Add the user mod if not explicitly disabled or we have a dev copy so
	// that saved files end up in version control and not in the user mod.
	if (add_user)
		g_modsLoaded.push_back("user");

From reading the file, it is not clear what "saved files" refers to.

But it doesn't sound like an invitation to create a "user" folder to store mod data. If that's the purpose, it should be added to the ModdingGuide or similar.

"saved files" could mean for instance savegames or modified JS/XML code.

The idea comes #895#comment:7, implementation from rP13472 fixing #1940.

Quote

If the application wants to save data when run by a user, it should use that user's home directory - we should probably mount a directory like ~/.local/share/0ad/mods/user/ or something, and save everything in there by default (except for SVN users who should default to the normal mods/public/ directory).

So the historic use case is Atlas saving maps indeed, just like the user reported here.

So the reason was to provide Pyrogenesis a writable path for both dev copy and for a copy fo the release.

I wonder why it was chosen that Pyrogenesis should write to a different location in dev mode than in release mode: Yes one can open an existing map, modify it, save it, and commit it. But one could also open the map, edit it, save it, move it to the data path and then commit it. There is the posisbility that Pyrogenesis overwrites gamedata that wasn't intended to be overwritten, possibly without the dev noticing. If only the developer can overwrite data files, then there won't be any accidents.

• One simplification of the existing implementation would be to launch the "user" mod in any case. It was mentioned in #1940#comment:3 too. So sounds like a committed improvement with an open question that future users have to answer to deal with the unexpected implementation.
• The other question is whether a "user" mod needs to be invented to achieve the given purpose to begin with. It could just as well write to a "public" folder instead of a "user" folder?

Perhaps the expectation to always have a Pyrogenesis writable path can be implemented without introducing multiple unexpected behaviors. Perhaps there were discussions on IRC, the ones on trac are very brief. At the very least, the reasoning should become clear from the codebase itself, and the wikipages should answer related questions.

Going back to the code:

	const bool add_user = !InDevelopmentCopy() && !args.Has("noUserMod");

	// Add the user mod if not explicitly disabled or we have a dev copy so
	// that saved files end up in version control and not in the user mod.
	if (add_user)
		g_modsLoaded.push_back("user");

Is the comment wrong in four ways or am I wrong in four or less ways?

• Add the user mod is added if not explicitly disabled AND (not or) we have a RELEASE copy (not dev copy)
• so that Pyrogenesis always has a writable path
• "That saved files end up in the version control and not in the user" is the purpose for _not_ launching the user mod under development copies.

Even better than fixing the comment would be implementing something that is clear without comments, without having to study the code or the metadata, or contacting a spirit medium.

[Guest]

26 minutes ago, elexis said:

Is the comment wrong in four ways or am I wrong in four or less ways?

• Add the user mod is added if not explicitly disabled AND (not or) we have a RELEASE copy (not dev copy)
• so that Pyrogenesis always has a writable path
• "That saved files end up in the version control and not in the user" is the purpose for _not_ launching the user mod under development copies.

Yes. Save a map in Atlas under a dev version, it would end up in the source. They end up under ~/.local/share/0ad/mods/user under a release version. I mean where else would it go. The alternative is allowing pyrogenesis to read files from other places (bad idea) or put those things in the public.zip which is located in /usr/ or something IIRC  in a release copy.

[elexis]

1 hour ago, elexis said:

Is the comment wrong in four ways or am I wrong in four or less ways?

37 minutes ago, (-_-) said:

Yes.

Joke acknowledged, one of the two propositions is obviously correct, and the sentence can be interpreted as only asking whether at least one of the two propositions is correct, not which of the two it is, that is funny. But the purpose of the forums is to further 0 A.D. development.

Although I read this precise pattern of jokes (answering a question syntactically correctly but intentionally semantically incorrectly by omitting information) the first time from this account, it had been seen as unconstructive by readers and moderators in the past. So it should be made transparent to users as soon as possible by Wildfire Games what communication patterns may result in needless disputes before it can accumulate and escalate. (So I clarify this not because of this single incident but because of the entire history of this pattern.) If people complain about not being asked before taking decisions, it might be the that they don't respond to questions with answers but intentionally don't answer the question, but make a joke out of not answering it, and possibly even taking it as a sign of a weakness of the one who asking (lack of knowledge) rather than offer of participation in the decisiontaking process.

Phrasing a hypothesis as a question instead of a statement establishes space for the communication partners to determine answer without any presupposition, leaving room for providing reasoning in answer and avoids phrasing statements as a priori fixed facts.

(For the same reason foldernames that are jokes that don't inform the reader what the folder contains and not contains are inappropriate, especially when the files in that folder are claimed to be an area of code of supreme importance.)

That's what I read in these three letters, but perhaps you meant those three letters differently and I am bananas

35 minutes ago, (-_-) said:

They end up under ~/.local/share/0ad/mods/user under a release version. I mean where else would it go

1 hour ago, elexis said:

It could just as well write to a "public" folder instead of a "user" folder?

 

1 hour ago, (-_-) said:

The alternative is allowing pyrogenesis to read files from other places (bad idea) or put those things in the public.zip which is located in /usr/ or something IIRC  in a release copy. 

I suspect it's not the only alternative.

The question is whether it's a good idea to overwrite data in the svn dev copy from Pyrogenesis, or whether it should not instead behave identically for dev copies and release copies - always writing to user/ or whatever that may become.

I mentioned two possible alternatives:

1 hour ago, elexis said:

• One simplification of the existing implementation would be to launch the "user" mod in any case. It was mentioned in #1940#comment:3 too.
• The other question is whether a "user" mod needs to be invented to achieve the given purpose to begin with. It could just as well write to a "public" folder instead of a "user" folder? 

Thank you for your answers!

[Guest]

That “yes” was acknowledgement of the points you wrote. As in they are the same as what I know.

I did not read the whole post before posting that. Just the bullets. Looking back, I can see how you may have taken that the wrong way.

[elexis]

2 hours ago, (-_-) said:

2 hours ago, elexis said:

Is the comment wrong in four ways or am I wrong in four or less ways? 

Yes

31 minutes ago, (-_-) said:

That “yes” was acknowledgement of the points you wrote

So it was "Yes, the comment wrong in four ways", not "Yes, the comment is wrong in four ways or I am wrong in four or less ways". The bad news is I only have one banana left, the good news is that we discovered actionable information.

[Guest]

59 minutes ago, elexis said:

we discovered actionable information.

Great! what now? From the looks of things, doesn't look either of the participants in this discussion would act in the near future. Maybe a bystander?

 

1 hour ago, elexis said:

(For the same reason foldernames that are jokes that don't inform the reader what the folder contains and not contains are inappropriate, especially when the files in that folder are claimed to be an area of code of supreme importance.)

Ever wondered what "graphics/" hold?

 

1 hour ago, elexis said:

The question is whether it's a good idea to overwrite data in the svn dev copy from Pyrogenesis, or whether it should not instead behave identically for dev copies and release copies - always writing to user/ or whatever that may become.

I do not see any issues with user/ existing. And I lean towards dev copies not using user/.

[elexis]

11 minutes ago, (-_-) said:

Great! what now? From the looks of things, doesn't look either of the participants in this discussion would act in the near future.

We use the software development platforms precisely in order to remove the need for communication and action to be immediate and allow delayed communication and action. Tickets on trac, reviewable patches on trac and Phabricator, concerns on Phabricator don't lose their validity or their informative value over time. It is one of the reasons why we should gather all knowledge about a patch in the revision proposals / trac tickets, not only enough information to get it committed, but provide information for the people who will audit it years in future years. And for that reason we also preserve and publish the versioning history, not hindering anyone in any way to extend the free software.

I have three requirements on my list that need to be met for me to be motivated to commit code, one of them has been established, the other two are in progress. It's just demotivating to walk alone, so months pass by. But I do intend to work on code if I can fix the remaining two metadevelopment problems, and if nothing unpredictable stops me from having as much computertime in the future.

So such information is valuable in the distant future, and I would act in the near future, depending on what near means.

The other participant in the discussion has the freedom to act on the information in the near future in various, on Wildfire Games platform for instance by finding a way to get someone to commit a patch. The problem in most cases with that is that people don't want to spend time.

If a patch uploader can (1) demonstrate undeniable proof of correctness of a proposed patch within few sentences, (2) demonstrate that there is damage to players if the patch is not committed and (3) show a responsibility of the contributor to commit the patch (him having introduced a defect for instance or him having done the most maintenance on the code), then that person has the choice to commit the patch with as little time as possible, maybe within less than an hour or even minutes, and has the incentive to do so. (As in bothering people in the most friendly way to get a commit and never resigning until the commit happened.)

28 minutes ago, (-_-) said:

Ever wondered what "graphics/" hold?

No, but I would wonder graphics/graphicsgraphics would hold.

29 minutes ago, (-_-) said:

I do not see any issues with user/ existing.

The absence of a defect does not imply the absence of possibility improvements.

It may be argued to be a defect if it would be shown that the additional complexity is not necessary to achieve the same purposes of the code.

35 minutes ago, (-_-) said:

And I lean towards dev copies not using user/. 

Maybe you do based on the current information, but is it the best choice for the general public and can we convince our self-critical minds and communicate it to others?

I don't have an opinion yet as I didn't gather all information, requirements, alternative solutions (no condemnation without investigation).

Indeed we don't have to dive into this now if we don't intend to commit something in the next 2 months or so, because the topic won't go away until the purpose and implementation logic of the user mod became clear as crystal to any developer and any user encounteing the mod, including Mijorious. So if there was an unclarity and discoverable improvement, there will be future threads or tickets or revision proposals to discuss it. .

[Guest]

14 minutes ago, elexis said:

The other participant in the discussion has the freedom to act on the information in the near future in various, on Wildfire Games platform for instance by finding a way to get someone to commit a patch. The problem in most cases with that is that people don't want to spend time.

Sounds good, doesn't work. And nothing has changed since then. Also, if you didn't notice, personally, I don't believe in bothering people in accomplishing my own goals. If the other side has any benefit or interest in said goal, I expect them to hold up their end without someone nagging. It's something like "here it is, take it if you think it is any good". If none seems to think so, what is the point?

[elexis]

1 hour ago, (-_-) said:

accomplishing my own goals.

If you find someone at Wildfire Games who tries to accomplish their own goals, please notify me!

Finding people who try to accomplish goals is one thing. Wildfire Games should exclusivley operate for the  furtherance of charitable purposes, for the creation of a public good. I don't recall people being here to do their own thing but to do something for the public benefit, for the software and the organization. Hence I mentioned:

1 hour ago, elexis said:

(2) demonstrate that there is damage to players if the patch is not committed

(or analogously demonstrate the benefits of a feature if committed)

As long as the usage terms are met, contributors are entitled to ask for a review of patches they upload to Wildfire Games development platforms.

1 hour ago, (-_-) said:

I don't believe in bothering people

One can also ask more than once without actually bothering the people. And one can ask a different question everytime instead of repeating oneself. What does it hurt someone to receive a friendly mail to ask for 5 minutes to voluntarily further a charitable cause? If the patch is perfect, the proof of correctness undeniable and delivered along, all possible questions of the reviewer anticipated, then ideally you're only asking for time to understand and approve your argument and grant authorization. Hence:

1 hour ago, elexis said:

(1) demonstrate undeniable proof of correctness of a proposed patch within few sentences

The few-sentences clause however implies that one can ask people only few times if they are not motivated to volunteer further.

So if people aren't active themselves (review spree), there is only a limited window of opportunity to get responses from people. So you have to work with what is there and try to achieve  the most with the least effort for the requested person. That inherently should motivate the requester to work on the more important tasks first, and those should be tasks that are important for the success of the project, not only for one person.

There is a small grammatical trick, one can say "bothering people is bad because X", this way one removes the subject component "I believe" which obfuscates the reason why that belief is not a random one, but an understandable one.

Another communication enhancement is to not ask people to do anything, but just to show how great a feature would be. Then only by chance the person could figure out that he could actually commit the patch. Making their mouth watery without asking anything. The more one restricts his own messages to the properties and goals of the task, then people can jump in and drop out at anytime they want (something between textbook voluntarism and post-volunteer voluntarism I guess).

1 hour ago, (-_-) said:

If the other side has any benefit or interest in said goal, I expect them to hold up their end without someone nagging.

This states how people are expected to behave (should), but the problem stated how we expect people to behave (actually do).

There is apparently a discrepancy between what is the case and what should be the case. The conclusion can't be to remain passive but to determine why the discrepancy exists, and which means you have to change that. As a reader of irclogs and being somewhat familiar with the devs, you can exactly find out who has which weaknesses. But one can work around them, or better, one can find the actual cause of the discrepancy in expected behavior. For example in some cases I remember that I had explained in long forum posts (30-40 sentences?) how some thing worked, reprhased the thing three times, but the only thing that the user on the other side needed was the definition of a single word used, and suddenly he understood everything.

Communication is a tool, it can and should be used and adapted to the problems at hand, instead of assuming that everyone can be triggered with a simple rational request. If the people didn't respond with the communication pattern chosen, one didn't use the right "attack vector" for the problem yet. So the question is to find the magic passphrase to the brains of people that make them do stuff that is beneficial to the general public, without lying, without being unkind, without being selfish or so forth. It's a hack and we should only use it with our whitehats on (not the racist ones).

See comments above with regards to "exclusive operation for charitable purposes" and the voluntarism mechanism.

1 hour ago, (-_-) said:

nagging

Where did you get that vocabulary?  I'd have to look again, but I think the Community Guidelines discourages nagging. There is not only the choice between being silent and nagging. If people are not motivated then one can try to improve the presentation. Putting pressure on people can demotivate them, whereas making their mouth watry can motivate them to support the cause. If every "you" reference in the sentences is removed, there is no personal pressure expressed in the sentence. If you ask people whether they want a pizza, they might decline because they have other plans. But if you happen to bake one, they might trace the smell to the concerned item voluntarily, even without any verbal information.

If (1) effort minimization (2) exclusive operation for public benefit aren't incontrovertible,  they at least stand unrefuted for now. The other aspect, (3) appeal to responsibility is restricted to addressees who assume responsibility. And one can appeal to responsibility of a person without blaming the person. If one can show that there's a bug that makes the game crash and that the situations in which it crashes are not uncommon, that's objectively bad and who wouldn't want to fix that if he had a verified patch.

I just often have the feeling people constrain themselves to follow the guidelines on trac, and give up if the branded workflow doesn't flow; instead of taking a step back,  using their creativity, analytic thinking and good faith to determine what can be systematically changed to change systematic problems.

Carrot > Stick.

6 hours ago, (-_-) said:

It's something like "here it is, take it if you think it is any good". If none seems to think so, what is the point? 

This is a perfect process in theory. But the observations and measurements say it's not working, therefore something has to be changed systematically. While WFG does have authority over which code is ultimately committed, WFG does require honest, trustworthy and capable people to take the responsibility that they don't have the capacity to take.

First phrase the goal to achieve (for example get a patch committed), then observe what the realworld situation is (who hasn't left completely yet), then try to design a process that can achieve the goals with the existing resources. We can't just take a process that works well for a billion dollar company and apply it to a group of 5 volunteers without modification. If we see someone who can't swim, we don't let him drown either just because we expect him to be able to swim if he enters the deep water.

At least many people work on 0 A.D. because of 0 A.D., not because of the participation in the workflow being the goal. If the goal isn't the path but the objective, then it's worth considering to change the path to achieve the objective. It's not forbidden to upload patches because uploading patches is fun, but some upload patches because they want them committed. The worth is in the commit, therefore, the question is how to obtain the commit (and in the long term, see how WFG can get more active people that can commit patches).

6 hours ago, (-_-) said:

"here it is, take it if you think it is any good"

"here it is, using it would benefit hundred thousands of players for reason1, reason2, and the patch is correct because of reason3, reason4, something friendly" (so you only need to press the red button as you already saw it's good and as you already know the related code)

So there's a big difference between asking people to do a lot of work (asking for a better design) and asking people to do little work (reading a proof that this is undeniably the best design).

Basically one can do the task of the reviewer beforehand except doing the commit.

(The law places no duty for reviewers operating a non-profit organization to volunteer their services, so there is no moral duty for people to review patches. Therefore one can't argue it' to be WFGs obligation to move any finger, it has to go through voluntarism if there is no contract.)

[Guest]

10 hours ago, elexis said:

(The law places no duty for reviewers operating a non-profit organization to volunteer their services, so there is no moral duty for people to review patches. Therefore one can't argue it' to be WFGs obligation to move any finger, it has to go through voluntarism if there is no contract.)

An open source project can only work if the people working on it have some level of enthusiasm. "Well, there is no law saying I have to do it, so meh!" does not work, If someone who has some level of enthusiasm about the project comes along and meets a bunch of people who does not have any, well that won't last.

Being an outsider, a contributor does not have much incentive to tackle the logistical and other such troublesome things to convince whoever is in charge to get a patch in to *their* own product. (This does not include explaining the changes being made and why. And I have not seen any patch by a contributor where that is not done to the best of his abilities.) You cant expect someone to walk all the way.

In such a case, it is more productive, faster and fulfilling to walk on your own road following your own vision of the project. Looking at some random stats, I have got more done in 3 weeks than the entirety of 2018.

[elexis]

5 hours ago, (-_-) said:

If someone who has some level of enthusiasm about the project comes along and meets a bunch of people who does not have any

That's again taking the presence for an immutable fact instead of determining the ways to change it. Maybe you can't change the lives of the members, but you can change the members by trying to become. Meeting a bunch of people with too few enthusiasm and availability is exactly the situation I found myself in in 2015, so I could increase that number by 1 and maybe more,  depending on how you count. And that's the point that I'm trying to get across. If the external contributor doesn't show that he is autonomous enough to manage to work in spite of the limitations of the environment, how would he be able to work with the limitations of his environment if he became a member. We need people who take over responsibility where responsibility is not assumed, rather than more people that require more attention.

Bunch of people with no enthusiasm + 1 people with enthusiasm > people with no enthusiasm

We have enough team members who upload patches in the sense you said, offering something but not going further, but we need reviewers, and a reviewer means that he is able to walk the entire way. By definition we can't trust external contributors to do their thing right, so we require the reviewer to walk the entire way. If a reviewer shows that he can walk the entire way, he showed that he is qualified. So while it does work for people who are employed to have half of the work done being by the author and the other half being done by the reviewer, it is much more likely for the author to suceed in a enthusiasm-limited volunteer group to do 99% of the work and leave the other 1% to the reviewer (pressing the commit button).

5 hours ago, (-_-) said:

*their* own product

Sure, many people do see this as *their own* product, I never did, I see it as a public good. From the general public, for the general public.

If I play this game and I see 20 times the same bugreport per day, how does this bugreport relate to my personal desire, but not to benefit of the general public? me and you are the means, not the ends.

5 hours ago, (-_-) said:

Being an outsider, a contributor does not have much incentive to tackle the logistical and other such troublesome things to convince whoever is in charge to get a patch in to *their* own product. 

The incentive depends on

• whether the objective of the contributor is to participate in a review process or
• whether the objective of the contributor is to improve the software or
• whether the objective of the contributor is to fix the missing enthusiasm in the team by becoming an enthusiastic team member

We really need the last type if we can't fix our own motivation problems.

5 hours ago, (-_-) said:

And I have not seen any patch by a contributor where that is not done to the best of his abilities.) You cant expect someone to walk all the way.

If they want to become a team member, they should walk all the way.

It's exactly the crux of the problem. Wildfire Games is comprised of volunteers and their enthusiasm and assumption of responsibility is only as great as that of their volunteers. There is no difference between external volunteers and member volunteers, other than that the latter had gained the trust to work autonomously.

WFG is not a corporation who exclusively hire employees as members to participate 8 hours per day in a review process, so it's simply false to expect volunteers who work 8 hours per day on something else to behave like that.

5 hours ago, (-_-) said:

In such a case, it is more productive, faster and fulfilling to walk on your own road following your own vision of the project. Looking at some random stats, I have got more done in 3 weeks than the entirety of 2018.

Programming a patch is not the same as getting a patch into the codebase that the general public uses. There are so many mods that are dead because a new version was released and the mod hadn't been updated. But if the features in that mod were committed to 0 A.D., they would have been migrated.

The more the codebase becomes unified, the more the general public benefits. The more it becomes fractured, the more features are lost.

I agree, as a contributors who gained Wildfire Games trust, I became limitated only by myself and could get more done in 3 weeks than in a whole year of noone volunteering to go through my review queue.

23 hours ago, (-_-) said:

I expect them to hold up their end without someone nagging.

5 hours ago, (-_-) said:

You cant expect someone to walk all the way. 

Both are volunteers, which means they work on something if they have positive motiviation to do so, and the motivation is the furtherance of the project.

I'm not talking about lala fantasy land but I talk from the past years of experience and looking at how Wildfire Games had operated in previous decades, it seems quite similar.

External contributors who are enthusiastic and overcome logistic problems of the team are exactly those that are invited to the team. If a contributor shows that he gives up too early, how would he not also become an unenthusiastic member if he is surrounded by them. You have a brain and muscles in your fingertips, and the situation is bad, therefore it's in your ability to change it as far as your brain and fingertips carry you.
 

[Guest]

Finding an alternative is not the same as giving up. We all work towards the same goal. And if the new approach is clearly better, why stop now?

Can’t say I didn’t try. I did stick around for a year. Luck would have it that I joined the community at literally the worst time possible.

[elexis]

18 minutes ago, (-_-) said:

We all work towards the same goal.

Apparently not.

[WhiteTreePaladin]

I think it is fine for developers to have different individual motivations. Some might care most about project leadership, or open source software, or even just the challenge to create something. For many others, the overarching goal is to create a fun game that can be fully modified as desired. I believe this is likely the common goal referenced by Smiley, because it is similar to the original creators' purpose for 0 A.D.

[Guest]

7 hours ago, elexis said:

Apparently not.

Finishing the game envisioned by a few optimistic individuals in the early 2000s. That is what you are working towards, right?

[elexis]

7 hours ago, (-_-) said:

Can’t say I didn’t try.

Sure, but that approach:

On 4/1/2019 at 5:00 PM, (-_-) said:

"here it is, take it if you think it is any good".

The recommendations above are to recommend not limiting oneself to that. At least one contributor got himself a review by acting on that post, so it wasn't useless.

If you see that people don't have enough manpower to keep up with the review queue, the obvious conclusion is that there must be more team members that do reviews, and thus you and everyone else capable should become one and allow others to upload patches in the principle "here it is, take it if it's any good".

21 hours ago, (-_-) said:

You cant expect someone to walk all the way. 

That may be true for newcomers, but you have gained much more knowledge than that. Contributors become educated over time, become able to take responsibility, so that they can also take decisions on community patches. If people persist walking, they will walk all the way.

19 minutes ago, (-_-) said:

Finishing the game envisioned by a few optimistic individuals in the early 2000s. That is what you are working towards, right?

Finishing the game, making it available under exclusive free licensing, minimzing the cost for others to study, reuse and extend it, and thus for instance publish revision history. So apparently there are some differences.

On 4/1/2019 at 3:53 PM, (-_-) said:

On 4/1/2019 at 2:49 PM, elexis said:

we discovered actionable information.

Great! what now?

Just because it can take a while to get to the bottom of feature doesn't mean that we shouldn't start working towards this, but rather because it takes a while, we should start working towards this and document any pieces of information when we come across them. Hence I raised a concern on this commit, since at the comment is wrong, the documentation missing, and at least one more person than dismissible me having wondered the same about the possibility of more appealing solution.

@Mijorious any progress with finding the maps ingame?