Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2024-07-28 in all areas

  1. Well all templates inherit from one another, so you only have to update the highest parent you can find.
    2 points
  2. Yesterday I took a look at the Steam page and noticed I could get access to the Playtest. I was very hyped and the game seems to work fine on my PC, which is great. But I can't actually play, there is no single player available, and the multiplayer tells me I don't have a network connection. @wowgetoffyourcellphone do you know more about that? By the way, when starting the game demo for the first time, I was presented with the variety of accessibility options, including the possibility of navigating with WASD and of disabling the auto gathering for villagers.
    2 points
  3. That is expected, multiplayer attracts alot of jerks around ps: maybe PC not very powerful or running antivirus?
    2 points
  4. Guys, I experiment with the local.cfg settings and come up with some good settings to try out isometric view. ; Isometric View view.zoom.min = 2500.0 ; Zoom needs to be this far because of low fovview.zoom.max = 2500.0 ; Zoom needs to be this far because of low fovview.zoom.default = 2500.0 ; Zoom needs to be this far because of low fovview.rotate.y.speed = 0.0 ; This prevents camera rotationview.rotate.x.speed = 0.0 ; This prevents camera tiltingview.fov = 2.0 ; This is what gives the nearly isometric viewview.near = 32.0 ; Near plane distance increased to prevent z-fighting Result: Compare with 45 fov: The isometric view is very easy to see when moving camera, but harder to tell difference in static screenshot. Guys it is like night and day. These setting disable rotating and zooming for real classic feel. I personally think the true 3D 45 degree FOV is better (everything to me in iso games look like they are sliding down the screen, and I think game world in 45 fov look more expansive), but maybe have this for game option in Alpga 20? Should be simple to add and could be fun to showcase when release. Some pros: Some people like this view and might find it easier. I get +15fps in this view. Could help player with low rig spec. Would be even better perf gain if game had alternative asset optimized for this view (back faces remove etc). A couple of problem: Action sounds cannot be heard. Camera zoom is too far away. Distance fog very heavy (again because zoom is very far). Clouds need to be disable in this view too. Anyway can be fun to add for Alpha 20 and maybe capture some of aok audience attention.
    1 point
  5. Hi everyone, For a few years now we have pondered whether git would be the right VCS for the development of 0 A.D. One of the main selling points of git is the ability to create numerous branches for parallel development of features and bugfixes. Several popular platforms (Github, Gitlab.com, ...) leverage this to provide a feature-packed development environment, where people can contribute, discuss, review, and test patches. Historically, the development of 0 A.D. has been performed using SVN, which is a bit old... but suits our needs in a number of ways, already discussed elsewhere. We are using Phabricator to supercharge SVN with a review and CI/CD platform, but alas, Phabricator has been abandoned by its developers. In any case, a lot of contributors in the past couple of years have expressed disappointment with the peculiarities of Phabricator. Thus, we have discussed finally moving to git, without any strong urgency or hard opinions on the matter. I have proposed myself to set up a migration path and a new development environment for 0 A.D., and I am proud to present it to you folks today. I have started working on this "for real" more than a year ago, and started dedicating all my "0 A.D. time" (which has been very scarce) on this project at the end of Spring 2023. It is still, unfortunately, very much a work-in-progress, but now is the time to reveal it and receive feedback. Ideally, I would like to collect feedback from the community, finish the CI/CD system, and fix bugs, over the course of the spring, with the aim of performing the actual migration, if the community wishes to perform it, during the summer. As always, delays should be expected. It is worth noting that personal changes in my life/work balance will give me more free time after the summer. Thanks in advance for the feedback you will provide Presentation of the Proof of Concept I am self-hosting the services for the duration of the tests, so that I have full control and do not divert resources from WFG. All URLs are under itms.ovh, which should eventually become wildfiregames.com Email does not work on this Proof of Concept! I have no will to setup email and I certainly don't want to spam anyone with tests. The services are not updated automatically: the full migration takes around 48h and necessitates some human input. The PoC I am presenting was generated from scratch the past two days. I will update stuff from time to time, when I fix bugs or when I'm bored, but don't expect the PoC to follow the actual development of the WFG services. Please test as many things as you want and don't hesitate to try to break things! Now is the time to make sure I didn't forget anything. All the data sent to the PoC will be wiped out whenever I re-migrate the services, and of course whenever the actual migration happens. Please feel free to play around all this. The services (this will be regularly updated) - gitea.itms.ovh The development platform. This is an instance of Gitea, a self-hosted lightweight alternative to Gitlab/Github. If, in the far future, we want to stop self-hosting stuff, Gitea is compatible with Github features to allow for easy migration. The git repository is at wfg/0ad. Commit messages were reformatted, contain the original SVN revision, links to other commits are preserved as much as possible. The HEAD revision of the main "trunk" branch is the HEAD of the SVN repo. If you wish to use the git repository for development, you must, for now, use the "future" branch, which will be merged to trunk upon the migration. All Gitea users were imported from Trac. Since email does not work, if you want to login, shoot me a DM and I'll send you a password. All Trac tickets are imported at wfg/0ad/issues. The Trac wiki is imported at wfg/0ad/wiki. I tried to self-document the PoC as much as possible, so please read the updated pages, especially BuildInstructionsGettingTheCode and BuildAndDeploymentEnvironment. The FAQ is defaced beyond readability because of its formatting peculiarities, work is needed, my apologies to everyone who worked hard on the visuals of the Trac page... - trac.itms.ovh A read-only copy of Trac, upgraded to the latest release. This serves as a reference, and can stay online as long as needed. See below for the redirect tool. - code.itms.ovh A registration-disabled copy of Phabricator, upgraded to the latest version (RIP). All the inactive accounts were deleted, especially the dormant spam accounts. We need to keep all the discussions on patches and commits online, however, Phabricator is now a security liability. I disabled the API access as well as the possibility to upload new diffs or files, and, in the future, I might make it read-only. I will consider migrating to Phorge (the community-maintained fork of Phabricator) when they officially support PHP8, which will allow us to stop using a deprecated version of PHP. However, migrating to Phorge does not mean we will start using Phabricator again. - svn.itms.ovh The old and new SVN repositories. This holds the current ps repo (which will stop receiving commits after the migration), the audio and art sources (which will keep working as-is), the new libraries repos for precompiled Windows and for bundled libs, and most importantly the new nightly-build repo. The nightly build can be used by anyone to test the latest development version. Please read NightlyBuild if you want to know more. - ariadne.itms.ovh Ariadne is a small redirect tool I wrote as a drop-in replacement for Trac or Phabricator when/if we decide to drop them. A lot of links to Trac exist on the Internet. You can follow Trac-like paths on Ariadne to find the relevant content. Each Trac page displays a link to the associated Ariadne path. For instance : A ticket https://ariadne.itms.ovh/ticket/666 A wiki page https://ariadne.itms.ovh/wiki/Manual_Settings A SVN changeset https://ariadne.itms.ovh/changeset/28056 A Phabricator commit page https://ariadne.itms.ovh/rP28056 A file in the Trac browser https://ariadne.itms.ovh/browser/ps/trunk/source/test_setup.cpp Ariadne also provides a nice page for knowing commit correspondence, just use `rXXXX` as path: https://ariadne.itms.ovh/r28056 https://ariadne.itms.ovh/r28000 Enjoy! And see you soon for regular updates
    1 point
  6. Walls are pretty underused. Maybe some tweaks to cost/buildtime could be done, but avoiding wall spam is an absolute must. I think instead, some improvements could be made to wall placing. Is there any way to let walls not be obstructed by trees and destroy trees upon construction? Essentially the behavior of shrubs in the eurasian steppe biome, but for stone walls (maybe palisades too). The existing mechanic is very centered around the resource rather than the building being built on the resource, so it might be quite an undertaking.
    1 point
  7. Nice, I must've overlooked that in all of the options you are bombarded with at the beginning. lol It's over, unfortunately.
    1 point
  8. Hello, why are you still use SVN for the development and not git? Trac does support Git: https://trac.edgewall.org/wiki/TracGit
    1 point
  9. Maybe the "Popular Posts" featured in the top right of the page can help you find the best answer in a multi-page thread faster.
    1 point
  10. 150 max pop is my favorite. 100 is a bit too low, but also good. borg well described the consequences of low pop cap on meta, in fact it's very easy to reach pop cap before even getting to p3.
    1 point
  11. Sure, but this is essentially the same system, right? Just different naming. What if we made Fortresses have 8000 health, have more arrows, but shorter attack range.
    1 point
  12. Can you provide a bit of an in-depth explanation as to what "active/actively" means in specific. Thanks. Neat mod. Technologies: Higher priority for those that give a bonus to the gatherer (stone and metal moved to phase 1) and a few others (house population, new technologies and forge). Market Price Search: Several parameters are taken into account when selecting an item to “buy”. 1. The amount of available resource (which is selected for “sale”). The more available, the lower the buying price can be. Example: if available 100 - rate 90 500 - rate 75 1000 - rate 60 2. Resources are infinite or not. New resources and food in the game are infinite, so when bartering them for resources that are finite, the rates are set to lower values. Conversely, if a resource is finite, the rate for selling it is set to a higher level. For example, the base rate is set to 80: When bartering 100 metal for food, the rate is set to 80+10. Thus, bartering is done if the price of food is greater than 90. When bartering 100 food for metal, the rate is set to 80-20. In this case, barter is performed if the price of metal is greater than 60. 3. Uniqueness of the Resource Coins have an increased base rate 165. It is bartered when there are high price spikes in the Market. The activity of the barters has been increased by changing some restrictions. For example, in the base version of the game, bartering is allowed if more than 500 resources are available. In the mod this parameter is reduced to 100.
    1 point
  13. So gitea, doesn't have anything to mark comments off-topic, but I managed to delete @Gurken Khan's obnoxiously rude comment. I, as moderator, could also edit it. So I guess permissions are working.
    1 point
  14. You can make a rude comment in this issue: https://gitea.itms.ovh/PoppaSmurf/historyencylopedia/issues/1 The second problem probably is OK because I renamed that file around the same timeframe to Readme.md, so you might have had a glitch around there. (Nothing wrong with @Itms setup, just a qwirk that gitea has.
    1 point
  15. So is the plan to allow us to have multiple repos in the wildfire Git. Clearly you'd need permissions (We ain't hosing no GitLab here) but it would be interesting to be able to have multiple repos (keep the community mod in the gitea perhaps?)
    1 point
  16. Also my ShadowOfHassen Account can only have one repo. Poppa Smurf has several but he is still banned from creating another. Which is a shame because I wanted to test private repositories.
    1 point
  17. Would someone do me a favor and say something obnoxously rude in an issue on the encylopedia repo: https://gitea.itms.ovh/PoppaSmurf/historyencylopedia I want to see if I can delete a post as a moderator.
    1 point
  18. Just recently looked at arcanist and thought it's trouble. Then came across https://gitlab.haskell.org/ghc/ghc/-/wikis/why-not-phabricator and have to say the section "one year of arc on #ghc" is a hilarious read. Not going to use it ever. I think facebook took over maintenance of phab, not sure what their plans are yet. Guess little short term implications for wfg but a possible switch would be a good opportunity to migrate to git as well.
    1 point
  19. There were 2 instances of big platforms creating problems in the last few years: SourceForge chose to replace installers with their own and added ads/additional software to them Google Code shut down (to be fair to them, they made it easy to migrate to GitHub) Also, GitHub (as opposed to Git) isn't free/libre. So, as long as Wildfire Games has the manpower and money to maintain their own, they should stick with it. And a webserver maintainer isn't necessarily an application programmer as well, so maintaining the thing probably doesn't take that much away from development time. Personally, I'm a big fan of Bazaar because the commands are dead easy, but sadly their tools are seriously undermaintained these days.
    1 point
  20. I pinned this topic as it's one that comes up often and Georg's reply explains things nicely.
    1 point
  21. (I guess I should write a slightly longer answer to this and related questions since this seems to pop up regularly.) TL;DR: SVN works. Why don't you use git, you can do so right now (either one of the clones on github/gitlab, or via git-svn)? Why (still) SVN? It works. More details: Partial checkouts are supported (which some contributors needed due to network limits), it doesn't require users to download the whole history (same reasoning), checkouts can be resumed (helps with unstable network connections). Apart from using shallow clones or incremental shallow clones this isn't possible with git. Keeping autobuilds for windows users (which is needed for artists) in the repo is not an issue (yes, there have been discussions and plans for how to solve this for git; but that is some work nobody has volunteered for yet). Why not git? There's a git clone (github and gitlab) so nothing stops you from using it right now, and we do accept git patches just the same as svn patches. If you don't like that you can use git-svn directly (which works fine). Educating users about git is more work than doing the same for svn, also this question ignores artists and modders and increases the barrier of entry for new contributors. Also most git GUIs are quite bad, which is somewhat important for those users. Programmers should be able to use their tools and can already use git right now. Why not git-lfs or git-annex or git-whatever? Those are third-party extensions and require more administration work. Of course we could move all to some third-party hosting platform, but those might impose arbitrary limits or just cease to exist. Also that seems to counteract one of the main advantages of a DVCS namely being distributed and not being locked to a single central repository. (These approaches tend to have issues with having the full history available locally, which makes bisecting issues harder. Also they do list merge conflicts for binary files as one of the rough edges. (I'm not sure how those would interact with signing commits, which would be one of the things to consider if switching to git.)) But I want to submit pull-requests? No. Diffs work, man git-format-patch might be worth reading. Why not just merge things? A merge-based workflow creates issues with bisecting issues, so one would have to educate users about rebasing their work on top of the main branch. (Not very entertaining in the long run (and that refers to both points).) What could be done instead? Reroll the git clones in a nicer way by excluding all build artifacts (the current clones have a few incremental stages, and are likely not excluding everything). However this should be planned carefully, since this is going to break the "upstream" for a lot of people and I would strongly recommend against doing this more than once.
    1 point
  22. @FeXoR In this case I misunderstood the problem. However, what is so different besides using SVN and Git for large files? I mean yes, small changes on big binary files require to rewrite the files and create a lot of traffic, but how is SVN different or more efficient?
    1 point
  23. Have you thought about using Git Large File Storage (Git LFS): https://git-lfs.github.com/.
    1 point
  24. If you want you can use the git clone on git hub. Biggest issue with git is binary files which if hosted on their local server would reduce HDD space drastically. AFAIK @Itms is looking for a way to avoid that but until then no git migration will be made.
    1 point
  25. Btw, it's possible to clone 0ad repo on github, create a branch for some feature and in any moment have a SVN-compatible patch for these changes. I'm currently slowly working on #2305, I initially attached a SVN patch for it, but then realized that I want to do a lot of small incremental updates to it, a final version won't be ready soon and it would be much more convenient to have a git branch for an interim period: the latest version is published as soon as I push a new commit, all changes are visible as separate commits with messages and diffs and the ticket isn't cluttered with a lot of intermediate patches (it's already cluttered enough with all those research results, current state reports and discussions :)). 'Comparing changes' page allows to see both overall diff and log of all commits present in the branch: https://github.com/0ad/0ad/compare/master...AlexanderOlkhovskiy:stk-stun Diff can be downloaded and applied to SVN copy using the same link (with appended '.diff'): curl https://github.com/0ad/0ad/compare/master...AlexanderOlkhovskiy:stk-stun.diff | patch -p1
    1 point
  26. Moving to Github was not really considered because we want to be in control of things ourselves and not have to depend on another service working or even existing years down the line.
    1 point
  27. A migration to git is planned, also there is an official repo on github. See: http://trac.wildfiregames.com/ticket/1814 http://trac.wildfiregames.com/ticket/1816 http://trac.wildfiregames.com/ticket/1819 Until those are done, no final migration will be done.
    1 point
  28. I am realativly new to programming for 0ad and am picking up tickets in order to learn the code design and layout. I have decided to take on something a little more than just simple bug fixes or finishing something someone else has started (and also something which is more javascript than c++ so I can learn more about that aspect). Ticket 1774 (http://trac.wildfire...com/ticket/1774) wants a quick way to see how many units are garrisoned in a structure or unit without having to click on it. So when you are trying to fill up all of your towers with troops you don't have to keep clicking around to see which ones still need them. Using one of the ticket's suggestions I through together a quick patch which displays the number of units as a status bar (The patch is with the ticket). The patch uses the icons for packing for now because I am not an artist. I did this simple implementation to act as a spring board for discussion and feedback. The ticket mentions several other suggestions as well like not allowing the enemy to see how many units are garrisoned in your structures (I think with my simple implementation the enemy can see this information). I actually like this idea because it adds an unknown element. The enemy would not see the garrison status bar. It has a few other ideas as well. The other question is: Is a status bar a good way to display this information? Thanks.
    1 point
  29. I think this should be restructured into a sort of FAQ list, with concerns in order of importance/frequency. The question should be in layman's terms. Some examples: Q: The game is slow or lagging, what can I do? A: The game does not run as fast as we would like. Late in the game you will probably experience some lag, this is caused by a mixture of things, AI and pathfinding are big ones. One thing that can be helpful is giving us the profiler information, if you hit Shift-F11 this will be dumped into a file (location given at the top of the screen), the contents of which are useful for working out where the lag is coming from so please upload. Q: I have a fast computer with multiple cores and a fancy graphics card, so why is the game still slow? A: Currently most of the game engine is single threaded and so unable to take advantage of multiple cores. Eventually the more intensive parts of the game such as AI and pathfinding will be multi-threaded. The limiting factor on the game's speed is typically the processor, rather than the graphics card (since the game is designed to work even with older computers). Q: I see visual glitches, textures not loaded, etc. A: Sometimes this is a driver problem, make sure you have the latest drivers for your graphics card. If you have a custom build of the game, textures might be slow to cache, during which time they will appear grey. Otherwise submit a bug report with as much info as possible including screenshots. Q: The game has an error or crashes, what can I do? A: Report the error and provide as much information as possible. Unfortunately there are many possible causes of crashes and the game's error messages are not always sufficient. Please provide steps to reproduce the problem, if possible, and post relevant parts of the logs (interestinglog.html) and crash dumps if available. Q: Islands and water maps are very slow. A: AIs don't really support water maps currently, so try playing water maps against human players or else playing a land map against AIs. Q: There's no sound on OS X. A: Sound is currently disabled on OS X due to errors in our sound implementation. Q: Sound is choppy, sometimes I don't hear music. A: The game's sound system is currently very buggy and will be redesigned. Q: Units appear to glide around or don't have proper animations. A: Some animations are still missing, we have someone who is working on animal animations. It could even be split into sections, like "Performance", "Gameplay", "Graphics", "Sound", "Crashes/Errors".
    1 point
  30. If the player gave the order to retreat it should have priority anyway IMO.
    1 point
  31. good for newcomers maybe you could add instructions about how posting useful info of new bugs in bugs forum section, for example how to take a screenshothow find interestinglog.html and others log files
    1 point
  32. 0 points
×
×
  • Create New...