Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2021-11-25 in all areas

  1. This thread is meant to gather and streamline the discussion regarding our choice of version control system. Discussion appeared to be in several places. I did my best to gather all relevant material, but feel free to add any missing information. We currently use svn, this has been working ever since 2004. Some earlier discussion about the lobby bots: Below an excerpt from an e-mail Stan has send round a while ago to all staff members: A relevant related topic is On November 24 2021, a discussion on IRC: What I did like to hear from everyone (staff, contributors, svn testers etc.): What is required from the version control system and CI? Which features are required? And what is only nice to have? Please list your wishes in this topic, preferably ordered in priority. What are the current limitations and what are possible solutions for that? What are the pro's and cons for them?
    3 points
  2. If a team tried making different changes to overlapping code, they would know that trunk based development, especially the model this article suggests, which is pushing to main often won't do. Instead of ugly merge graphs, you get a ugly history. Large changes take weeks and months, not 3 or 2 days. Try keeping track of all that without using branches. When I wrote patches here. I had to clutter the whole workspace with multiple patch files, and svn revert, patch apply, repeat. good luck if someone wants to run an svn match while you were working on something. Instead of branches, everyone had a dozen copies which is clearly not better. This is a strong con of svn in my opinion. Also being able to rewrite history is underrated. Along with git stash. Hosting providers are not relevant to this discussion, you change remotes and push to another place if "Company Hosting Git Repo" shut downs.
    3 points
  3. Agreed for the git pros: clearer use of branch (the huge one for me) and release tags remote being THE main standard The submodules possibility I think the shutdown argument is a strawman. The problems are rather in my view: the use conditions of the platform the users'personnal data management by the company how much you're stuck with the proprietary solution So my view is that self-hosting is a good solution over these points but using, for example, an instance of the community (FLOSS) version of GitLab from a provider is OK : Migration is possible in another instance of GitLab Community, self-hosted or not You're not stuck with the proprietary management of issues and all on GitHub for example. I said it for GitLab but the same goes for any git management FLOSS solution (Gitea, Tuleap, etc.).
    3 points
  4. The gameplay would be so much better if Workers were set to surrender once they were out of the defensive range of their own buildings or Soldiers. They should go Gaia and be subject to capture. Same for the women. I dont like how I have to invade an enemy territory and then massacre everyone all the time. There are some games where it would be fun and appropriate against certain enemies or in some situations but I would prefer to just defeat enemy forces and then incorporate their civilization toward mine. We used to build civ centers and then all of the enemy buildings in it became ours after a capture time, right? Am I mistaken? Because lately I build a civ center after destroying an enemy's, and all of the houses burn down and vanish, when the Housing is why I wanted the territory in the first place.
    2 points
  5. Capturing enemy slaves/"servants" is quite satisfying. lol Also, in DE, if you capture an enemy CC you can train that culture's citizens (who can build their cultural Temples and Wonders, adding diversity to your empire).
    2 points
  6. I distilled a feature list from the posts above and will continue doing so. Please yell if I wrongdo anything here. Some questions from my side: How does that work with versioning of the binaries? And with clones? Can someone elaborate on these? what these are? why we would care? etc I am not sure if I understand the exact feature one is after here. "Being able to say 'this patch is ready to be merged'"? Lastly my own requested features: First and foremost, I find that all code, art and anything else must be in one and the same repo. Obviously there must be a clear directory structure. But for some patches (the secondary attack patch #252, is just one example) it is required to change both code and art at the same time. Having to propose different patches for different repo's, will make life a lot harder. We have been around a long time, the world around us will change and we don't know what will happen. Therefore I will strongly plea for keeping sovereignty. Make sure everything is available in a self-hosted variant. Using third-party services is perfectly fine with me, however we should depend minimally on them. Whether it is to avoid a total collapse of the service, changes in the service itself, or changes in the terms, it shouldn't matter us. We should be able to continue, and at any point be able to decide to stop using any service. To make things secure and reliable, I would recommend to have a third party back up which is usable as is, preferably using a different vcs. This will make sure that if our one server or vcs collapses, we can continue, using the other at will. A VCS should work, for everyone from anywhere. There should be a minimum of potential restrictions on joining deving. This means that the vcs should work on many platforms, be free of (third party) account registrations, have a simple workflow with straightforward commands (also understandable for ppl who never used a vcs before). Dev version testers should be made easy to test: we need them and they might not be as experienced as devs when it comes to handling code bases. Therefore precompiled binaries (autobuilds) should be directly available in the repo. This might also help devs on some platforms.
    2 points
  7. In the mod Delenda Est we can capture servants, something close to your idea: https://0ad.mod.io/delenda-est
    2 points
  8. I've read thew article, but that is still not a pro for me, that's a con With branches you don't have to stop development of new features just because there is a release. You can split the release branch of, feature freeze it and still continue other work. See the blender release process: https://wiki.blender.org/wiki/Process/Release_Cycle _____________________________________ What I generally want from a version control system: Since patches tend to stay uncommitted for quite some time, it should be easy to rebase them. And maybe its my fault, but I never found out how to do that easily in svn. The branching system of git on the other hand does that quite well in my experience. As a windows user I would like to keep the autobuild. ___________________________________ General thoughts not specific to only version control: It hugely annoys me that there are at the moment so many different places (trac, forum, irc, phab) where stuff is discussed and where information is scattered (and more or less outdated). Whatever option is chosen should combine them (probably still +forum +irc). ^ this. huge pro for git. It is just the standard. ____________________________________ General thoughts on self hosting vs relying on third parties: I get the whole point about reducing the dependency on big companies and honestly, at the end of the day I don't really care as I won't be the one maintaining it, but there are a few things to consider imo. Yes the companies may shutdown their platform without any warning and we couldn't do anything about it. But how realistic is that? Self-hosting means that there still needs to be someone in the team who puts in the work maintaining the server, getting new updates, doing other sysadmin stuff.... Sure, this reduces the potential risk, but it binds development resources that are from what I know very sparse right now. So is it worth it? Imo no.
    2 points
  9. Some people do, then you upload the patches to Phabricator. Re binary files support could use this https://git-lfs.github.com/ Well I can't do any of this if we don't agree migrating to git is necessary.
    2 points
  10. If you go git, I would probably use (a) dedicated art repo(s), ie separate art from code. Keeps the code repo small in terms of history compared to art repos containing images. Git has two builtin options to handle possible external repo inclusion, subtree and submodules, but in my view, both are a PITA. There is also a 3rd party solution that works, git-subrepo.
    2 points
  11. ahahahaha yeah!! we wrote basically the same stuff at the same time
    2 points
  12. Version 2.0 is out - check the first post for more info and the download link
    2 points
  13. This thread never takes me to the post I click on but always a page before that. Wonder why. @Stan`?
    1 point
  14. @maroder nice work, thank you. I tested it with my 32:9, seems like the backround is a bit broken.
    1 point
  15. I think it is not because people hated them, unit pushing was the culprit. If you put your archers in box formation, they would move fairly smoothly, and units without a formation had path-finding issues. Not only is the path finding superior, also the fact that units can stack has been disadvantageous to archers. In A24, when the front row of skirmishers attacked the archers, the ones behind needed to path around their allies to find a spot from which they could shoot. In A24 you would never get all your skirmishers shooting at the enemy in a smooth motion. First of all, no matter how creative the solution is, archers seem to suffer from a material disadvantage in their stats. I think A24 mainly had good archers because turn rates made pathfinding awkward. Sometimes if you have the material disadvantage, there is not much you can do except getting better material. I ran some tests in the scenario editor with 10 basic pikes+10 basic skirms against 10 advanced spears+10 basic skrims, the side with the pikes won. If you do the same test with a weaker ranged unit, the advanced units get the win (which they deserve). Also the attack-ground(or attack group) would be a nice feature, but it does not solve the pike issue. All pike factions do have access to skirmishers and archers of some kind. Anyway, this is not about AoE4, whereas the OP wanted to talk about AoE4.
    1 point
  16. It is mostly this kind of stuff: Thanks for reacting on my personal preferences. Please don't think I hate git, or admire SVN. I just want an educated decision to be made and not follow along with whatever is popular. If we're good with the binaries (I have no experience in that) I don't mind (too much) a change in workflow. Regarding the supported platforms: Redmine supports SVN? (As do RhodeCode, OpenProject, pach.no.)
    1 point
  17. https://git-scm.com/docs/git-sparse-checkout
    1 point
  18. I only read the article in diagonal but from my small experience, the current svn workflow with patches which are sometimes not trivial and get merged at the end, is not a solution to the problem this article mentions. I also think the current svn workflow is no different than doing git branch and rebasing at the end before merging (with amending every commit if we want stricter equivalence)
    1 point
  19. skirms OP and pikes OP are linked. if skirmishers didn't deal that exaggerated amount of damage (compared to melee), pikes resistance wouldn't be so relevant. archers should be faster, they have no use anymore because people hated them so much in A24 they were nerfed to the ground. it really makes no sense to have them slower than all other ranged units, it means they have no strengths.
    1 point
  20. https://github.com/0ad/0ad https://gitlab.com/0ad/0ad You need some of it for the engine to run. See https://trac.wildfiregames.com/ticket/5366 (For another topic)
    1 point
  21. Looking just from outside at the current project structure, if you migrate to git, reorganizing the project in git should be chosen wisely in my view in respect to the future repo sizes, commit history etc. I think it would be no fun to put the current source tree in git as is, accumulating tiny problems over time. I would probably consider an image repo for skins, textures, icons, portraits. If you wanted these included in source tree, probably git-subrepo would be the most painless solution. But even submodules might work for the purpose.
    1 point
  22. Yeah submodules are generally a PITA. Mentioned them for the sake of the argument, because I believe more things should be split from the repo, which is not a consensus inside the team see the spoiler in the first post. Relevant links https://wildfiregames.com/forum/topic/16149-git-migration/ [Git] [Step 1] Update autobuild utility for git workflow [Git] [Step 3] Create .gitattributes for Git code repo [Git] [Step 2] Create update.bat to sync windows binaries
    1 point
  23. Pro Git Industry standard Co-authoring of commits Submodules? With different access Supported by maintained platforms (Gitlab, Gitea, Github, Bitbucket, Azure Devops) Already used by most (if not all) mods Assuming you want to extract diffs from branches once we have to drop Phabricator because it becomes a security flaw (or doesn't work anymore, currently we need to use hacks on the macOS and Linux VMs for certificates to work. Needs for a VCS for me: Require the least sysadmin possible Be common enough to lower the entry barrier by having resources to use
    1 point
  24. Thanks for making this topic, @bb_! So I guess the first step is the difference of SVN vs git. There are several websites discussing that (e.g. https://svnvsgit.com/), but I think the main conclusions are: Pro SVN: Partial checkouts. (And access control.) Handles binaries better (our art). No branching (https://www.freecodecamp.org/news/why-you-should-not-use-feature-branches-a86950126124/). Easy to copy, delete or rename files. Pro git: Backup on every dev machine. Pull requests? Note that since we have git mirrors, one can still use branches on personal development copies and work offline (SVN needs connection with the server). Needs for a VCS for me: Handle binaries properly. Support refactorings (if I rename and change a file, I don't want it to show up as a new file, that totally breaks blaming me).
    1 point
  25. 1 point
  26. ok thanks, now I get what you mean Yeah I did that deliberately, since the logo takes up too much space otherwise. But yes maybe I will increase the margin in the next iteration or decrease the logo size. mh yes, maybe I will revert back the the last round design or a rectangular one. I just have a hard time with the logo. It's at the same time round an also not centered due to the text.
    1 point
  27. is the advantage that there is someone else with my kind of expertise in the project.
    1 point
  28. mmmh I think is more those hard, straight angles of the notch in the top that host the logo that have a different "vibe" (or design language), compared than the rest. It's a detail I would agree with. Maybe a further improvement would be to have it round, so it can host the logo more softly, or maybe a square, without those angles. The logo could be a little bit smaller to fit more armoniously with the rest. These are really small details if you want to reach a 100%. The overall look is an amazing 98% nevertheless!! And I hope it will be implemented into the game, is very refreshing to see!
    1 point
  29. the minimum area of the logo should be this, the red square. why? in graphic design logos have margins, officially 0 A.D. does not. You can see that the margin at the top with the "0" is very low, at the bottom you have the same problem and more serious and the final dot (.) also has that problem. just increase the central element.
    1 point
  30. sorry, still don't quite get what you mean. So you would want the logo smaller in comparison to the surrounding background?
    1 point
  31. I would have to show it graphically. Perceptual mind gives the feeling that the logo is coming off. (Design psychology). The mind tends to see objects as real things that can fall and are subject to physics. The size is always increased where they are contained. That would be aesthetics and perception. I can't imagine how it works at different resolutions.
    1 point
  32. not 100% sure what you mean. the golden outline?
    1 point
  33. try to improve the edges where the logo is contained. improve margin and enlarge that element.
    1 point
  34. Well Ideally you could complete this section https://trac.wildfiregames.com/#Formodders
    1 point
  35. Estas seguro con los colores? Yo todavía puedo diseñarlo.
    1 point
  36. oh, that would be great and make the process A LOT easier! For example, I found immensely helpful your old tutorial on how to set "props" into the game, Stan! But I recognize it's something that would require quite a bit of time and effort to develop fully. Maybe an idea could be to take advantage of the development of a mod, and try to make each step more open..? Like, step one: creating a new civ (zergs) - step two: template structure - step three: basics of 3d modeling etcc.. I found the initial phase the most difficult, where I had no idea where to even start. But after that step, then people would have the tools to proceed autonomously for a while and it would lower the learning curve exponentially for a lot of new users. This, assuming that incentivize modding is something that would be meaningful to pursue for the whole 0ad project
    1 point
  37. Well as @Locynaeh told me last week we need moar documentation :P
    1 point
  38. Hi, I'll use this thread to introduce myself: I'm Sean, from Heidelberg, Germany. (And my Nick stands for my first name, followed by the initials of my second names :P. - CJ). I'm just installing 0 AD right now. The reason I'm here is because I'd like to see better cooperation between different Libre / Open Source Games (RTS games to get started with). But more on that in a different thread + Subforum . P.S. Me and two other guys made the following game some time ago (died pretty quick though ) : https://www.indiedb.com/games/engines-of-war
    1 point
  39. Buenos días o tardes; -Nuevo símbolo de facción (escudo) ; -Los colores son a sugerencia de @wowgetoffyourcellphone, naranja y negro , aunque no sé si era a esto a lo que se refería wowgeto... ( o si tendría que invertir los colores). (Es una remodelación de la anterior , pero no será la definitiva ) -Mezclé diferentes símbolos de escudos y otros elementos artísticos galaico-lusitanos , lusitanos y castreños, dándole un aspecto muy distinguido de los escudos que usarían las unidades. A lo mejor quito la parte metálica , pongo más ornamentación o quito algunos elementos... ¿Ustedes qué opinan? @Lopess, @Stan` @Lion.Kanzen @Ultimate Aurelian @Trinketos @Carltonus @soloooy0 @artoo @maroder @Radiotraining @wowgetoffyourcellphone @Dizaka @nani @m7600 @Belisarius17 @Genava55 @Mr.lie @ribez @Dasaavawar Disculpen las molestias*
    1 point
  40. Different enough. No copyrighted names, different building looks. I suppose one can copy stats. I wanted to do that for Stella Artis and crossover between that game starcraft and maybe some others
    1 point
  41. Understood. In that case as a further expansion, how about borrowing the rank four centurion promotion from Delende Est and applying it to the core 0 AD Rome? With the extra distinction of applying to either Triarii or Hastati/Principe?
    1 point
  42. No impossible. Rules do have exceptions.
    1 point
  43. Its an interesting idea, it does make certain automatic third rank troops impossible though, for instance Skiritai commandos and the possibility of third rank Triarii( which I am hopeful gets added).
    1 point
  44. There is another solution: make this unit completely unaffordable in most games, like the will to fight tech. We can raise the cost of each champion cavalry to 300 food, 300 wood, 200 stone and 250 metal. If you want to assemble an army of 20 fire cavalry, you would need 5000 metal, 6000 food and wood as well as 4000 stone. Not many people can afford this in a team game without being an useless team mate. At this cost, they can only be trained 1 by 1, which is a lot less deadly.
    1 point
  45. It's like @m7600 said. Ugi's is like a popular brand here in buenos aires. Many customers "joke complain" in social networks waiting their bizzarre answers. It has manu places in the city and It's a popular place between middle-low and low classes workers bc of their cheap prices. Most of this places have a cleaning service once a day or sometimes the same ppl that cook the pizza must clean the place for a very small salary so I can understand his lack of motivation to "wear the t-shirt of the company" (like we often say here, as an idiom?). So the place is always kinda dirty, the cheese is mostly oil and flour and probably u even get a napkin to clean your hands
    1 point
  46. Animal and human ai was unified so they react according to stances like humans would do
    1 point
×
×
  • Create New...