wraitii
-
Posts
3.395 -
Joined
-
Last visited
-
Days Won
75
Posts posted by wraitii
-
-
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
-
5
-
-
8 hours ago, real_tabasco_sauce said:
I guess we have seen no complaints for making a 5th release of the community mod. @wraitii is there still time to do this?
Sure
8 hours ago, real_tabasco_sauce said:would it be possible/good to keep the 4th version on modio in case people want to keep playing that version?
I think ModIO keeps past versions automatically, though from within 0 A.D. you won't get it
-
1
-
-
(Also noticed a similar error on Jebel Barka, didn't investigate more)
-
5 hours ago, real_tabasco_sauce said:
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-
1
-
-
On topic, I do agree that Cappadocian is probably much better than nearestern, yes.
-
1
-
1
-
-
50 minutes ago, alre said:
if the map depicts a H-shaped terrain with square seas, I'd argue that it shouldn't be called Corinthian Isthmus whatever the biome. Isthmus is fine, it's not boring (then why would you think a better name should make a map look better, if it's only loosely related to it?).
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...)
-
28 minutes ago, wowgetoffyourcellphone said:
So you have a "Deep Forest" generic map, then by choosing the available biomes you turn it into something more specific, like temperate = Hercynian Forest, india = Deccan, etc. Generic maps wouldn't have all biomes available. For instance, it wouldn't make sense for Deep Forest to have a Saharan biome option, or Islands to have a Steppes option.
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.
-
20 minutes ago, wowgetoffyourcellphone said:
What's the use of having interesting names if the maps don't look like what their name suggests?
There's degrees to this, our Corinthian Isthmus isn't a 1-1 match for the real thing either.
20 minutes ago, wowgetoffyourcellphone said:I don't think what I was suggesting doubled the map count. If anything there would be a small selection of general shapes and layouts (about a dozen), then you'd choose a "biome" which turns the map into somewhere specific.
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.
-
On 6/11/2021 at 8:21 PM, wowgetoffyourcellphone said:
Mainly that maps should either be specific or generic, not both. So, if a random map is called "Corinthian Isthmus", then it should use the Aegean biome. If it's called just "Isthmus" then it can have more biome options. So, "Badlands" can have various biome options, but "Cappadocian Badlands" should use an Anatolian or Middle Eastern biome. I've gone rounds with @wraitii about this.
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. -
- Popular Post
- Popular Post
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-
13
-
10
-
3
-
16 hours ago, real_tabasco_sauce said:
Sad, but it makes sense. The release is already delayed a little (from ff)
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.
-
1
-
-
17 hours ago, Gurken Khan said:
@hyperion There's an eleven years old ticket: https://trac.wildfiregames.com/ticket/1468
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
-
8 hours ago, phosit said:
Do you have a clue why there are the two spikes in `OnUpdate`?
Most likely these are turns during which a unit dies and all other units go in 'FindingNewTargets' mode, or some other event like that.
-
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.
-
4
-
2
-
The largest hurdle is the RangeManager, the LOS code only supports up to 14 players at most right now I believe. Until D3938 is merged, that can't easily be changed.
I'm not sure which other components assume 8 players after that, probably territories ?
-
1
-
-
A few things that I'd say prevent 'beta', though I've argued differently in the past as well:
- No dedicated servers (and with it stuff like what Dunedan describes)
- Game Performance woes, and turn-length issues (200ms turns are not so acceptable these days I feel)
- Graphics performance - though the Vulcan rewrite will probably end up fixing that soon-ish
- No actual campaigns.
- AI still isn't great.
However, these are only sorta relevant. The reason we're not in 'beta' is because the 'original vision' for 0 A.D. included a lot more features, including things like running units / charging / better formation & naval play which we have not been able to deliver on. We just don't have a good design for these within the current scope of the game.
In the end, this isn't a race. This isn't a money-making project. It's a side-hobby for all of us. It moves slowly, it moves surely, and it'll likely get there (or computers will catch up...)
-
6
-
Good news and bad news about the future.
As of Firefox 115, which will be the latest ESR soon, I can finally properly profile the game including JIT code.
The only thing to do is compile spidermonkey with `enable-perf` and `--enable-jitspew` (I think), then run it form within https://github.com/mstange/samply like so: `IONPERF=func PERF_SPEW_DIR=. samply record -n --rate 10000 binaries/system/pyrogenesis -mod=public -autostart="random/continent" --autostart-ai="1:petra" -autostart-ai="2:petra" -autostart-nonvisual -autostart-seed=150`This gives you a full profile that you can then access on the firefox profiler, like so: https://share.firefox.dev/3IHH7ho (AI 1v1)
There are some interesting overall insights:- In this AI 1v1 75-80% of the time is spent in C++ code. But a lot of that time is calls from JS.
- As I have reported in the staff forums in the past, the main cost in the SimUpdate is `Timer Update` (about 15% of total time), split between ResourceGatherer, ProductionQueue, Builder, Attack, DelayedDamage.
- Most of the code appears to end up properly jitted.
- But the GCs 'dump' the JIT code regularly, which means we spend more time in baseline than we probably should. I have reported a bug about this, we'll see what happens: https://bugzilla.mozilla.org/show_bug.cgi?id=1834848
-
There is a fair amount of Spidermonkey overhead, though there are things we could improve.
-
To take the Example of calling `Engine.QueryInterface`, the costs breakdown as follow:
- ToJSVal<IComponent*> is about 40-45%. This is largely because of D5004.
- The actual C++ QueryInterface is only 20%, which is slow because of std::map. But it's not the most major cost.
- Getting the ComponentManager pointer is 7%
- ScriptRequest enters the realm (for no reason), which accounts for about 10% total
- So as you can see there are a lot of things we could do to skip some time, but it's also going to be kinda hard.
-
To take the Example of calling `Engine.QueryInterface`, the costs breakdown as follow:
Some obvious things that show up and could probably be improved:
- Having a `Engine.QueryInterfaces()` function is probably interesting.
- Identity:Init() is slow because of splitting the identity classes. We can cache that in ParamNode directly I think.
- There are some regex constructions in loop which are slow, such as in MatchesClassList
- AI Interface and AI Proxy are fairly slow.
- The AI in general also seems poorly jitted, and that might have to do with how the objects are structured, hard to say.
- Modifiers are kinda costly, but we knew that.
Now, right now we are still on ESR92, so this is some ways off, but I have compiled it on a local branch, and I think the results are rather interesting, and encouraging for the future.
-
3
-
3
-
It should be possible to completely disable by setting the 'radius' in pathfinder.xml to 0. But you'll also want to increase unit obstruction radius in that same file to something like '2' if you want no overlap at all. This will generally make pathfinding terrible though.
-
1
-
-
16 hours ago, alre said:
I believe range queries used by fighitng routines and auras could be optimized wildly by implementing a matrix of moving units such as that used by the pushing component - in fact, no reason to use another one, that one would do just right. I don't know c++ enough to try this change myself though, and it sounds absurd to remake it in javascript (although that would probably be an improvement already).
I'm fairly certain the range manager already does this in a way. The problem is that you do want to send _only_ the right units to JS, because doing further filtering in JS is super slow.
-
21 hours ago, Philip the Swaggerless said:
I just voted. Because some of the merge requests are "package deals" I had to say no to some that had some things I liked.
You should specify that on the merge requests as comments then, maybe we can clean them out
-
Created with the relevant requests right now.
We are also interested by people coming forward to get the rights to merge requests on your own, as a reminder.
-
It's a bit difficult for me to know what should be merged here since there the forum discussion is long & not many people are voting on gitlab.
How about I make a forum Poll with the different merge requests and people vote there directly ?
-
1
-
2
-
-
1 hour ago, chrstgtr said:
Just a suggestion that maybe that OP should list what changes were made to each version of the mod. Something like the below. This will allow players to see what actually changes and help determine whether a change is actually desirable.
I'll look into that at some point, but I don't believe you can see it from inside the game anyways ?
-
43 minutes ago, alre said:
does any update to the main branch make up for a new release? I hope not, use a develop branch instead.
No, to make a release one has to:
- Increment the mod version
- Run the 'release' CI job
- Run the 'sign and upload' CI job.
The latter two tasks can only be done by Maintainers, aka me or Stan.
35 minutes ago, LetswaveaBook said:When I tried to make a merge request, Git asked me either to verify with a credit card or send an email. Is it necessary to do a merge request by one of these two options, or are there other options?
Mh, I think that's because of the CI pipeline, but you should be able to create the merge request without it, no ?
I'll give it a try with a newly created account to check how things work.
We definitely don't want to force people to verify a credit card...-
2
Issues with Building on Mac M1 - Spidermonkey - "ld: Undefined symbols: _main, referenced from: <initial-undefines>"
in Bug reports
Posted
Yeah that's what those are. I guess I just forgot to upload the tarball.
I've done that now, should fix the link.