Jump to content

wraitii

WFG Programming Team
  • Posts

    3.395
  • Joined

  • Last visited

  • Days Won

    75

wraitii last won the day on June 29 2023

wraitii had the most liked content!

3 Followers

About wraitii

Profile Information

  • Gender
    Male

Recent Profile Visitors

5.861 profile views

wraitii's Achievements

Primus Pilus

Primus Pilus (7/14)

2k

Reputation

1

Community Answers

  1. Yeah that's what those are. I guess I just forgot to upload the tarball. I've done that now, should fix the link.
  2. As an eternally sometimes active and sometimes burned out dev, I relate to the struggle. Thanks for all the years of leadership and support, thanks for all the events you attended, all the mods you carried and updated, and all the releases you shipped ! Enjoy the rest
  3. Sure I think ModIO keeps past versions automatically, though from within 0 A.D. you won't get it
  4. (Also noticed a similar error on Jebel Barka, didn't investigate more)
  5. Seems like it's just not running. Presumably because you don't have the Developer role https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html#prerequisites Edit: ran them, looks like it fails 'cause the pipeline is broken. If people are OK with the changes I can merge them regardless
  6. On topic, I do agree that Cappadocian is probably much better than nearestern, yes.
  7. I think flavourful names do a few nice things: They're cooler, which is more memorable They highlight potentially important places in history (depending what we choose), which fits the historical vibe of the game. They make 0 A.D. less like a generic RTS. Contrast 'Arabia' on AoE 2 with 'Highlands' on AoE 1, despite it effectively nowadays having different biomes. Some names are more generic, I'll admit, but I don't see the harm in giving them cooler names. (Not that this is the thread topic...)
  8. Yeah I think that's a good approach. The map selector might by default show specific biomes, or if you force 'random' just default names. I'm not 100% sure on the biome-map availability thing, it's a trickier issue to me. IMO you should be able to pick a map and get an expected RM experience, if the biome can completely change around to map in un-expected ways it's probably bad. However, knowing that there might be slightly less wood or it's configured slightly differently might be good. So it's kind of a case-by-case thing. Deep forest is probably a good example that having a Saharan / steppe option might just not work yes. I'm less sure about e.g. Oasis - conceptually that can work with any kind of biome, sorta.
  9. There's degrees to this, our Corinthian Isthmus isn't a 1-1 match for the real thing either. Think we sorta agree on the 'biome changes map name' approach then. It's just that my default approach would probably be more to show interesting names (and thus maybe default biomes) than generic names in the map selection screen.
  10. I vaguely remember this, but I think my argument was that this just doubles the map count for no real reason, right? And IIRC I disliked switching to generic names for random maps as I thought that was kinda boring. Wouldn't necessarily be against setting a 'default' biome for those maps that can be over-turned by players to 'random' however. Edit: or changing the map name based on biome tbh. I'd rather just avoid all our maps having generic, boring names by default in RM.
  11. Hello everyone, This is an update on the progress of the Alpha 27 release. After extensive deliberation, the team has decided to abort the release process for the foreseeable future. As some of you know, we've been in a "feature freeze" for the past 3 months. This period, during which we halt all new code merging except for crucial bug fixes, is typically a final step before a release. Unfortunately, progress on the release has been slower than anticipated, and Alpha 27 is still several weeks away. Some of the outstanding issues include: Acquiring the necessary macOS certificates for signing the packages Completing the trailer for the announcement, and finishing the announcement itself More testing is potentially needed, and some important bug fixes are not yet merged. The balance of A27 has not been extensively tested and refined. The time it takes to actually release (uploading packages, informing maintainers, etc.) is potentially more than any of the team can commit to right now. Our current pace on these matters is unsustainable. Following a vote, we have chosen to abort the release and refocus. This decision wasn't made lightly, but we believe it's in the best interest of 0 A.D.'s long-term health. We will use this time to: Merge improvements that have been developed during the feature freeze, such as optimizations and further fixes. Identify and address the issues that have hindered the current release process, as we cannot hope to release in the future without fixing them. We will likely come back to the community with more information on this last point and potentially requests for help. We realize that this news may be disappointing. We thank you for your patience, understanding, and ongoing support. On behalf of everyone at Wildfire Games, Wraitii
  12. In my experience, merging things in feature freeze delays the release as it introduces new bugs. I don't want to do it this time. Might make an exception for the password change feature as that seems like it could lift off quite a bit of weight on the lobby mod team & Stan by proxy.
  13. Yeah the reason it's still not implemented is that it's much slower to compute some kind of proper distance than to assume euclidian / spherical cows. The UnitAI part is the part that's the same between the AI and a regular player, but the AI has the same problems. As far as I know the best solution for AI dev is to share things on the forum, and then we can consider actual patches in the future if it proves to be better. -- You should note that nowadays, you can implement your own cheats in the AI by giving it custom modifiers. It doesn't have to be just the resource gathering. You can also use LOS data nowadays, but IIRC that needs to be implemented in entity.js
  14. Most likely these are turns during which a unit dies and all other units go in 'FindingNewTargets' mode, or some other event like that.
  15. 0 A.D. currently updates the simulation state every 200ms. This update usually takes 20-40ms, depending on the number of units doing things. This means even if you're running at 60 FPS graphically, when the sim is running, you'll get worse FPS, and worst you might get a lot of 'micro-freezes'. Furthermore, the 200 ms turn length gives high input lag which would be nice to shorten. I ran some quick experiments on Combat Demo Huge to see what changing the turn length would do to performance, and the results are somewhat more promising than I expected. First, what to expect: We should run fewer JS timers each simulation turn, as they will tend to hit on different frames. This should 'smooth' the framerate. Movement might be a little easier and smoother since we're going less far away (in practice, I'd need to update Pushing, it's too smooth) Things like 'range queries' shouldn't change too much, as we still run all of them every turn. Overall the FPS should be lower, as we compute more things, but also smoother, as we don't stop as long. Frames would go "16-16-30-16-16-30ms..." instead of "16-16-16-16-80-16-16-16-16-80ms..." The results are quite interesting. The 'smoothing' effect is rather convincing. I think if we adapted to not run all Range queries on all turns, and perhaps tweaked movement appropriately, it might be worth looking into running turns every 100ms for example. In the profiling runs below, Red is 350ms turns, green is 200ms (normal), dark-blue is 100ms and cyan is 50ms turns. Remember that the red curve is farther ahead in time at any given time.
×
×
  • Create New...