Jump to content

Leaderboard

Popular Content

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

  1. I have to fix the size of the walls. XD
    5 points
  2. 0 A.D. 0.0.25b is now available on Debian Backports! You can play the current release of this wonderful game on Debian versions >= 11.x
    4 points
  3. In my experience, GitHub ability to bring valuable contributions is overrated. I even took down the GitHub mirrors of the software I maintain a couple months ago, after years with no contributions coming this way (while we still get contributions on our dedicated GitLab instance).
    3 points
  4. https://dzone.com/articles/git-lfs-why-and-how-to-use Basically it would solve the size issue on the server While I generally agree with the fact it would be more complicated, I do believe that things with different livetimes e.g the CI pipelines, the lobby should be in another repository. Actually feel free to prove me wrong but I don't think anyone in the team clones the audio, art, and art_source folders which are the same repository than the main SVN. Nor do we have the design document In the future, having an empires_ascendant mod in a separate repo we could do hotfixes through mod.io No argument on that end which is why I'm currently pushing for a self hosted gitlab (and such the git migration) A few people on linux complained about the presence of windows binaries in the repo, because that makes the download heavier for no reason. The git migration ticket planned to have a download script for the windows plateform just like we can download the spidermonkey tarball. I think this could be acceptable if it works straight out of the box. eg double click on a script would pull all the binaries and update the relevant ones using md5 or sha1 or something.
    3 points
  5. I think for either svn or git, there are appropriately easy to use GUI, so imo this should be taken care of either way. I agree, but that could be avoided through better documentation about what patches / art / sound assets are actually wanted and what quality is expected. Having a lower barrier of entry doesn't mean you have to accept anything and it is totally fine to decline patches / pull requests when they don't meet the quality standard. The important thing for people to not get mad about this is: having a proper reason why something is declined and having a place / code of conduct / design document where all the quality standards are described.
    3 points
  6. As far as I see Git's handling of binary assets just does not work right Linus designed git for text based code on the kernel project so it's binary capabilities are very limited.And GitHub may start wanting cash as the repos grow binary data are just blobs that git has no handle on. Enjoy the Choice
    3 points
  7. 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.)
    3 points
  8. Also, I think the gate could be wider to allow the passage of elephants and covered rams.
    2 points
  9. Some input as a non-programmer: My main experience is with Git, primarily using GUI-based tools like Github Desktop. I have not used much of any SVN. I generally think a lot of this comes down to a question of accessibility and features. Obviously with an open source project it is important that it is accessible, even to novices and less-technical people. I think anything that requires command line/text-based use is too advanced for many non-programmer contributors (art/audio), so I would encourage that we consider an option that has some kind of at least somewhat functional GUI-based option. Yes, command line is not really that scary and even a few hours of digging around the file system and doing basic stuff in there is enough for it to become second nature and very simple in retrospect. However, there are many people who are truly afraid of using it or have such a limited understanding of basic command line use that it is genuinely dangerous for them to be poking around on their own. I think the last thing we want is to have to spend a hour or more giving each new contributor a tutorial on how to submit changes. On the other hand, if something is so easy that even a total beginner can contribute to it without any kind of technical hurdle, it may lead to a risk of lower quality code or assets being contributed. In the current state, I feel like the use of SVN acts as a very minor gatekeeper and encourages less experienced potential contributors to spend more time on the forum. I have had occasional issues where people have submitted unusable content in merge requests to projects I have run on GitHub and had to decline them. Regarding sovereignty, I definitely agree that we should maintain some kind of local version, if not the main working version, on servers we control. Although I do not think a place like Github or similar is going to go 'poof!' one day, I have had occasional problems in the past with companies deciding to stop running services I rely on as essential and do not think it is healthy to keep something this large and important in one place, especially one controlled by another party. I can also see how using the same version control system as most mods might be advantageous as well. It might make it easier for those who have just started to get the hang of modding the game to then contribute directly to the game. I'll leave the actual deciding to those of you with more experience, but these are just some thoughts which may help provide a different perspective.
    2 points
  10. The original works, yes. But maybe it's cutted in the top and the bottom.
    2 points
  11. 2 points
  12. 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?
    1 point
  13. He probably means to follow the shapes and sizes of the buildings other civs do. Lol.
    1 point
  14. I wonder if it would be best to continue using svn for the handling of binary assets, and how well it would work to use an svn repo as a git submodule (There are some results when I search "using svn repo as git submodule"). Some of the original quote is missing here, but to the question of whether or not maintainers can edit pull requests: on GitHub as well, it can be done. On a GitHub PR, there's a default option: also, when reviewing the PR(diff), maintainers, or even reviewers with no write access can insert a suggestion, and then the original submitter can click to commit the suggestion. I haven't worked with submodules enough to form an opinion yet whether or not subs are are PITA. I struggle with sometimes just because I don't use them regularly and forget some of the basic git commands for using them. Based on the little experience I have with them so far, I'm of the opinion they should generally only be used -- and it's when they're most practical to have them included as submodules -- if they are completely independent of the project, such as third-party libraries (although there are exceptions). For anyone that hasn't worked with submodules yet, you might want to check out the SuperTux project and follow their instructions for fetching the submodules and building the project. As for pull requests on GitHub, if anyone wants to experiment or practice, feel free to make a pull request on community maps 2. You can just edit any file and add "Hello World" and make your pull request. (Gitlab PRs are pretty similar, as far as I know.) And of course you can also make practice PRs on your own repo, or other repos that already exist for that purpose.
    1 point
  15. The scope of the discussion isn't particularly clear, going by title and poll it seems a debate svn vs git. I'm a proponent of git. For most part either works, and whoever prefers to work with the other can do so independent of what the master repo uses. So what would one gain from migrating to git, there is quite a list but I limit myself to what I think is most important for 0ad mostly based on commit history and what comes to mind right now. Git unlike svn respects authorship. Pyrogenesis/0ad is a volunteer project as such attribution is of paramount importance for many if not most. Git workflows encourage commit often. As such commits are far more likely to be properly split, i.e do one thing only and do it properly. Git workflows don't differ between diff and commit. Often subject and message of the commit are even more important than the code change itself. Using a git workflow both are made part of the review process. With git you push commits. Bad commits, which happens to the best, can be fixed before publicizing. Some points made in this thread I think are worth addressing with a few words. Git and binary handling: Well, the current binaries in tree and their history are a non issue when using git. Stan mentioned lfs, there are other means of binary handling as well, all with their own pros and cons. Discussing them might make sense but can be ignored just as well. Autobuild: It's _very poor_ practice to store build artifacts in the repo irrespective of vcs. Also last I checked there were more Linux than Windows users therefore we need to replace them immediately with Linux binaries to maximize the use for our users. A proper solution if people want to use prebuilt artifacts is to add a script which fetches them from CI. This would work for any commit and not just selected ones plus for all supported platforms. Regular proper pre-releases for testing could be provided as well, so pure testers wouldn't even have to bother with a vcs at all. Split repo: If pyrogenesis/0ad is considered an engine plus a game and not just a game a split is almost mandatory. We can have a very lengthy discussion about this but is out of scope here. First, yes, a proper split is more complex than putting public into it's own repo. Second, as for why spidermonkey as a dep sucks for us/distros is to a large part that it's in the same repo as firefox.
    1 point
  16. Many times in game, a player can tell when one player or the other advances to p2 or p3 or builds a new base just purely because they had pre-scouted the land, I believe it isn't fair as it wouldn't make sense for the enemy to know the territorial claim of your land without going to check it again, this would be a balancing request what is everyone's Thoughts on this?
    1 point
  17. A raider is also called a plunderer, which you can translate to German by writhing it with a capital letter and putting an umlaut on the first U.
    1 point
  18. Just a bug that'll be fixed for Alpha 26
    1 point
  19. @wowgetoffyourcellphone I hope my post finds you well. One of our kids just saw this and asked me why the "Hero War Elephant" shows a horse: I assume that this is still WIP, or is there something wrong with our installation? We installed DE via the in-game menu. Wishing all of you a nice weekend!
    1 point
  20. Isn't possible yet. But it is something requested and quite thought out. It will probably be included as advanced diplomacy options.
    1 point
  21. Hey @SeanCJ Meant to send you a message. Two years ago for the FOSDEM and a bit more recently I contacted nearly all the open source projects I could find for spring that's (BA, BAR, Zero-K, Spring 1944, and the official spring discords) Wesnoth, Wyrmsum, and Warzone 2100, Devsh' Irrlicht, SuperTux Kart, Urho3D, and godot. Some came to the Game dev room and you can find all the videos of that event here https://video.fosdem.org/2020/K.3.201/ I really hope we can bring more of that shared experience in the future. EDIT: I'm also on most of their discords.
    1 point
  22. 1 point
  23. It is in fact totally up to the reviewers/upstream to merge, ie nothing gets in the upstream repo from a fork without explicitly merging it. Besides the technical decision what vcs to use, if the decision goes git, it is more or less a decision what self hosted server to use that suits best. Gitlab is little monster, builtin Ci, lots of features, same for github server, but there are also lighter ones providing the basics, really depends what is required. The main point of git, besides technical specs is considerable, that vast pool of devs and easy collaboration. No problem to include git repos hosted on another platform.
    1 point
  24. Ok, I've been rooting round the SpringRTS forums (I've not been round there myself - 'xept for short glimpses - the last 10 years ). My impression was right, what most games use is a lobby-client bot, that also starts headless "dedicated" servers that run the game: https://springrts.com/phpbb/viewtopic.php?f=88&t=17130 I'm sure this helped address some issues (lag and other), but from descriptions I read here, that's only part of the problem for you. Side note: a difference between here and things with SpringRTS, is that over there, its more of an "ecosystem" than the more clearly deliminated and official components that you have here (my impression - The "SPADS" server being an example of that). I reckon both has its advantages and disadvantages.
    1 point
  25. @seeh Just to make sure: You are aware that there are a lot of translations available? German, for example. (Weren't you German (speaking) too?) What helped me a lot to get what's what was the structure tree. You can see the buildings and the units and by clicking on them you get more information. I don't know the best translation for 'Raiders', but I do know that I don't want them and therefor never build a Blemmye Camp...
    1 point
  26. Not been working properly for a long time for me almost always drops me on to the second last page. Enjoy the Choice
    1 point
  27. @user1 hi im mr.michael vs dihiya ( 1347) when he felt defeated he ledt the game without giving up , thanks for you help. commands.txt metadata.json
    1 point
  28. Hey CJ, you know, This is an OG gangsta gaming community from Grove Streat. What's up with OG Loc, is he still rappin'?
    1 point
  29. I mentioned elsewhere but what about changing the current Legionary Engineers bonus from just a straight catapult attack bonus to rather having legionaries build catapults instead like they do in Delende Est, which is an awesome mechanic, the idea of catapult dropping someone is hilarious. It completes the roman siege inventory of siege walls and fortified camps I think.
    1 point
  30. I think I could come up with a pretty good "Republican Centurion" actor with the available assets if the rest of the team signs off on such a feature.
    1 point
  31. oh wow yes that looks bad. Does 32:9 actually work with the original design? I will put in on my list of things to look at for the next release. Can't promise that I will find a solution tho.
    1 point
  32. @bb_ I agree with many of your points. Sovereignty and the option to be able to switch the platform if anything with a certain provider goes wrong, are important things. Also the stuff @Freagarach and @Lion.Kanzen mentioned about people loosing access due to police changes. That sucks. But then again, what are the odds that actually happening/ having an impact on the currently active team members and also as @smiley said: Despite this point, I think we need a more differentiated discussion on the different aspects that influence the choice of a version control system. (Or create different threads, whatever is preferred). Because it is not only a question of: What system has which features. Other options / question are bound to the choice of hosting solution/ provider: Should the code hosting, documentation/ wiki and project/ feature planning be on one platform? Here I think Gitlab would be the best option. It is actually quite decent in the whole project managing department as well as code hosting and CI. I heard good stuff about OpenProject @Freagarach mentioned, but their focus is more on project management and less on code hosting/ review. How do we want to handle account registration/ third party data collection and stuff you mentioned? I can not argue with that. If that is a heavy concern than there is no way around self hosting. Personally I wouldn't care that much. Just wanted to mention that keeping control means putting in maintenance work and binding human resources. What does the choice of hosting provider mean for the barrier of entry and the possible pool of contributors. This would be the biggest argument for GitHub. It has an extremely large and active community of developers. _________________________________ Something to the cons of svn: to move / rename files is majorly annoying (to me). Git seems to handle that way better.
    1 point
  33. I can try to break it down. Co authoring commits, there is an upstream repo, and there is a fork of that repo. Anyone can fork a repo with git, which is easy to keep uptodate with the upstream repo that is forked, the remotes. You can author a patch in a branch, and send a request to the upstream repo, chose a target branch, master or some feature whatever. Then the merge or pull request can be reviewed, and merged according a selected merge strategy. Or the review determines the PR requires some more changes in order to merge. This also works from a branch of the upstream repo, same concept, you can merge that branch into master branch or any other branch. What all these git servers provide is more or less just a web UI to git. It can all be done locally too and then pushed, ie merge branch 'super_feature' into master, or merge branch 'hotfix-123' into master. submodules are git's native way to include another git repo. Many people, including myself find these a PITA, but there are different ways, including a native git only solution of just using branches. In summary, it is a way to make from more than one repo one unified source tree.
    1 point
  34. @maroder nice work, thank you. I tested it with my 32:9, seems like the backround is a bit broken.
    1 point
  35. 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.
    1 point
  36. to me the dependence on a platform that could close projects because they do not adhere to its policies. Policies that change according to the convenience of states and companies at the cost of individual freedom.
    1 point
  37. 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.
    1 point
  38. @wowgetoffyourcellphone should have said something, and since he didn't say it, I will say it. In delenda est, you can place farmsteads and storehouses in neutral territory and they don't give extra territory, so you wont have that problem. I think being able to place farmsteads outside your territory might make the game more interesting. However that feature does no solve a the other issues mentioned in this tread.
    1 point
  39. That's what I find one worrying aspect. The other would be you depend on 3rd party services, GL or GH, if its down, its bad for the project, and there is nothing you can do about it, but wait.
    1 point
  40. This is fun But I didn't know it existed so thanks https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html
    1 point
  41. 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.
    1 point
  42. This. You can monitor enemy berry expansions for by just looking at territory expansion by berry patches. If expansion exists there likely is a grainery and to rush.
    1 point
×
×
  • Create New...