Jump to content

mimo

WFG Programming Team
  • Content count

    377
  • Joined

  • Last visited

  • Days Won

    11

mimo last won the day on March 9

mimo had the most liked content!

Community Reputation

277 Excellent

1 Follower

About mimo

  • Rank
    Duplicarius

Profile Information

  • Gender
    Male
  1. 0ad bug with firefox 55?

    I had the same values, and you have no problems when starting 0ad while firefox was open with some tabs? should then be something in my system
  2. 0ad bug with firefox 55?

    After some investigation, the problem is linked to the new tab multithreading of firefox, actived by default on my kubuntu with firefox 55. I switched "browser.tabs.remote.autostart.2" to false in about:config and that cured the problem (although loosing the multi-threading). But still i don't understand why this only happened when starting Oad. I'd be interested if others are also running firefox 55: what are your values of browser.tabs.remote.autostart and browser.tabs.remote.autostart.2 in about:config? and do you see the same problem when multithread is activated?
  3. 0ad bug with firefox 55?

    As i was not sure how it is set when i compile it, i've installed the 0ad A22 package from ppa:wfg/0ad and have the same problem.
  4. 0ad bug with firefox 55?

    I had disabled them, with still the same problem.
  5. 0ad bug with firefox 55?

    Since my update to firefox 55, I'm facing a strange bug: each time i start a 0ad game, all my firefox tabs become empty, even when reloading. Reopening a new tab works though. It could be a bug with firefox55, but no other application apart 0ad give me that problem. Anybody facing the same problem? I've 2 pc with kubuntu 17.04 and both have it.
  6. Yes, i also really like where they are going to, and agree they would be a nice addition to vanilla. Maybe you could start a discussion about it within the team?
  7. DE gameplay discuss

    yes, any naval map should do it. Just check that it now builds shipyards. D705 is quite small and could be included in A22 if well tested. While D654 touches too many parts and it's safer to wait for after the release.
  8. DE gameplay discuss

    Tests of https://code.wildfiregames.com/D705 with delenda would be nice, but you need to remove first your petra changes (it seems you've included D654 which is not a good idea as not necessarily compatible with latest ai changes, it will need to be rebased).
  9. DE gameplay discuss

    Strange, in my own tests, it built cult statues. Currently the patch only works well for simple requirements like vesta temple. If the Arch needs glory, somebody has to learn him how to accumulate glories, that was not the purpose of D654.
  10. DE gameplay discuss

    The AI knows it (that's the easy part), but somebody must write the logic to find a good location (what are the requirements for a good position, how far from your borders, how to defend it, ...).
  11. DE gameplay discuss

    I've made a patch for the phasing up, with the delenda requirements in. Could you test it? https://code.wildfiregames.com/D654
  12. DE gameplay discuss

    I've no time left to work on mod's support, but some of the points listed here looks generic enough and should definitively be implemented. When A22 is out, i may have a look at the phase requirements, but don't think i can do much more. You should post tickets on trac about them (with the AI keyword) hoping that they may get the attention of some developpers.
  13. A cool thing happen

    Should be https://trac.wildfiregames.com/changeset/19209 so already quite old
  14. No that won't be enough because the update to 17.04 seems to remove the libboost-filesystem-dev package (I had the same problem yesterday when switching to 17.04 and had to reinstall it with apt get). So check that you have libboost-dev and libboost-filesystem-dev packages installed and then proceed as Itms said.
  15. @wowgetoffyourcellphone : how can it be complex to have the fields decay when unattended and regenerate when attended? that's on the contrary something which looks natural to me, and certainly not less natural no more complex than having health regen when passing nearby a temple, or when idle if we have a medecine tech. Futhermore, while i understand that everybody can change its mind, it's funny how you can say the exact opposite of what you said previously in this same thread that does not support taking your opinion too seriously, at least up to the next change of mind @WhiteTreePaladin : why would you ever need to keep track of these rates? do you also try to follow the changes of rate each time a man comes near a female? hopefully not! a game should stay a game, not a mind torture. For me, the only useful information is the base rate (knowing that a female is x% more efficient than a given male soldier), this does not change because of tech, mill, auras ..., nor because of D227, except the female aura which you should then also find much too complicated! @niektb : as said before, no complexity here. And don't worry, nobody has asked you to give a yes or a no, my only demand was to test the patch for people to give a useful feedback Just to clarify what is D227: fields are built much faster (15s instead of previous 50s), but starts with a lower rate which increases with time. Typically after 2 mn, it reaches the nominal rate which won't change anymore as long as you have people working on it. As fields are long term resources, nobody cares about the rate of these 2 first mn. Then when abondonned, the rate that the field can provide decreases, and this "field rate" is visualized by the health bar (the field is destroyed when the health reaches 0). What it brings is that, when a field is half destroyed because of an attack, it looks more natural for me that the farming rate is decreased accordingly during the time the field is restored. And if when attacked, you garrison all your gatherers in the nearest cc, your fields will start to decay, which also looks more natural, but more importantly that makes raids against fields more efficient even if the defender has used the town bell.
×