Jump to content

WhiteTreePaladin

WFG Retired
  • Posts

    2.319
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by WhiteTreePaladin

  1. I agree with limiting to positive reactions. I think "disliked" content should either be ignored, or require an actual response with an explanation. I don't favor a "downvote" option. I think it has its place to help suppress spam-like content, but I don't think we have nearly enough volume to even remotely need that functionality.

  2. 5 hours ago, Basshunter said:

    I think It won't. If I remember correctly, the last time I used DAE instead of dae, meshes were not recognized. So I think I'll follow Stan advice.

    If the code is doing an actual case-sensitive string check for the file name, then it wouldn't work on any system without an exact match. If it's a simple file loading, then it should work on Windows even with a case mismatch. If Stan says it doesn't work with mismatched case file extensions, then it's very possibly the former situation. I agree with following Stan's advice though. He's looked at more of the code than I have. :)

    • Like 1
  3. 21 minutes ago, Stan` said:

    (Be careful for some reason capital extensions ex DAE do not work)

    Probably would work on Windows since its filesystem isn't case sensitive. I once made a webpage where some of the image file extensions were uppercase and some were lowercase. Worked fine on Windows, but on Linux it failed to load images with file extensions of mismatched case.

  4. @Stan`

    Perhaps bonuses should just be separately added (rather than multiplied) to avoid confusion and make the arithmetic easier. The order of the bonus wouldn't matter if they were all added to a combined bonus before being applied.

    [edit]

    Then again, I usually just ignore the harder to calculate bonuses like diminishing return farms. :P

    • Like 1
  5. 2 hours ago, historic_bruno said:

    I don't agree that "SVN is ok", it's a development choke point when we're juggling multiple features and bug fixes at once, that all have to be resolved to SVN. Also, I want a stable branch (where well-tested and reviewed code goes, that always compiles and runs with minimal regressions) and a less stable master branch (might or might not compile and run well at any given time), in addition to feature branches which can be integrated with CI, to make it easier for devs to test each other's changes and thus, being more efficient to review.

    YES! Agree on every single point! :laugh:

    I've been wanting this for several years, and have brought it up multiple times. I don't really know why it hasn't happened yet, but recently there has been more support. I still have hope we'll switch to git eventually. :)

    I remember discussing it with Philip awhile back. He wasn't really against moving to git, but felt (at the time) that the migration effort was significant, and that svn was good enough for smaller projects. The project has grown a bit since then though.

    [edit]

    From conventions I've seen, it's generally "master" and "dev" for very stable and mostly stable respectively, with various other release, feature, and bugfix branches.

    • Like 2
  6. 11 hours ago, wraitii said:

    During AoE2's design they considered allowing capturing. The way it worked was that building below 25% HP would become disabled, and repairing them above 50% would make them yours. I've come to think, over time, that this is a strictly better design than ours.

    That makes more sense than what we have. How would multiple capturing parties be handled? Right now there is split loyalty, and the structure is awarded to the player with the most loyalty points when the original owner's points have been fully depleted.

  7. 18 hours ago, Wijitmaker said:

    Probably a mute point... but this thread caught my eye. 

    I had numerous discussions about this exact issue over a decade ago.  There was a reason the original game design limited the number of civs.  The civs were intended to branch as the game developed.  So, for example - when you start the game you choose the generic civ of "celts" then when you reach a certain phase (city) then you are offered the strategic choice of either going with the Britons or the Gauls.  Depending on what strategies and tactics you wanted to finish the game with (based on the sub-faction's strengths and weaknesses).  

    Michael didn't agree and opted to separated them all into their own factions....  So... happy balancing guys ;)  

    According to Michael, civ branching was meant to work like Age of Mythology / Age of Empires 3:

    https://wildfiregames.com/forum/index.php?/topic/12600-about-the-hellenic-factions/&tab=comments#comment-201511

    At some point we gave up on the implementation, but I'm not sure exactly when that happened. A few years later and we were discussing splitting the Celts up into Briton and Gaul.

    https://wildfiregames.com/forum/index.php?/topic/15776-alpha-10-tomfoolery/&tab=comments#comment-237426

    It's mentioned in the Alpha 11 release preparation, so that was the release it was first split.

    https://wildfiregames.com/forum/index.php?/topic/16140-alpha-11-planning/page/7/&tab=comments#comment-250234

    We aren't limited by any of these things. It would be possible to group civs back together if someone with vision designed how it would work. Leaving them separate can work too.

     

    [edit]

    These are private links, so most won't be able to read them.

    [edit 2]

    Nevermind, this is the staff forum. :laugh:

    • Like 1
  8. 7 hours ago, wraitii said:

    would also be a neat way to introduce handicap.

    That's exactly what I was thinking when I read your first post. Instead of striving for perfect balance, let weaker civs serve as a built-in handcap. I'm not sure how I feel about this, but I don't think it is automatically bad. It does mean that top tier players would have fewer civ options, but that's almost a certainty anyway considering the quantity of civs we have. Historical accuracy could definitely be a basis.

     

    • Like 1
  9. On 5/3/2019 at 9:08 PM, Bigtiger said:

    One game-play change that is coming with the mod is taking away the ability to build walls. Walls will be built in with the maps, and walls are going to be at-least 5x-10x stronger. So how you use the castle is up to the player, but wooden palisades can still be built.

    You could consider allowing the construction of middle-tier, double-sided stone walls to provide something between the palisades and the well established fortress walls. Not required, just a thought.

    AoE3 had three tiers of walls: palisades, stone walls (double-sided), and fortress walls (single-sided, scenario editor only).

    BFME2 had two tiers: extra strong, one-sided, prebuilt walls (like shown in your picture) that could be repaired but not rebuilt, and smaller double-sided stone walls that could be built by the player. (Units could walk on the large prebuild walls, but not on the player-built stone walls.)

    Would be nice if the fortress walls could be used in random maps for randomized fortress designs.

    • Like 3
  10. 31 minutes ago, nani said:

    Would be noice to make them public or is there some secret reason not to?

    Well, some of the discussions are really old (2003-2004) and the people involved may not have ever considered that their discussions could become public. We would want to contact them as a courtesy. At a minimum, we have to look very carefully through each post for anything we release. However, a lot of relevant content from some of those meetings has actually been copied to a public post. It was linked earlier in this thread, but here's another link for convenience: https://wildfiregames.com/forum/index.php?/topic/15068-why-chose-javascript-for-scripting/

    [Edit] The "public" posts are actually the beginning of this very thread. :D

    @stanislas69

    I'm sure the decision was at least somewhat logical at the time, since performance is just one metric. Ideally, for performance we would stick most code in C++ and only have a few items (like AI) implemented in scripts as they did in Age of Empires. The original plan was for 0 A.D. to be closed source freeware, but still much more highly modifiable than Age of Empires. With closed source code, this requires more implementation to be moved to scripts which is itself a major performance trade-off. With the goal of allowing easy modification by hobbyists, rather than professionals, it's much easier to see why syntax would be such a major consideration.

    • Thanks 1
×
×
  • Create New...