Vantha

Me too. The campaign features have higher priority for me since they'll probably be more exciting for players, but as I said in the encyclopedia thread, I am also going to continue working on the encyclopedia eventually and then hopefully finally get it into the game. They are both huge projects, they have taken and will still take a lot of work and time, but it'll be great when they're completed, I believe we gotta think long-term here. In theory, yes, but you always have to account for smaller screen resolutions, where the in-game screen is quite cluttered already, so there aren't really many options. Maybe moving it to the right edge instead could also work, but there on small screen resolutions it'll conflict with the dropdown menu and also the tooltips of the units and buildings in the selection panel. Yeah, I'll do that, it's a comparably quick change, I just want to get a few things of my plate first.

@Gönndolsalv Hey, I only just now saw your message. So here's an update from my side: I remain convinced that the game would really benefit from a new tutorial and that the story around Carthago Nova would make for a great campaign. And this project is still a big long-term goal of mine. And, yes, there absolutely is progress, even though it might no be always visible to the outside. As I explained above, when I started making the campaign last year, I essentially came to the conclusion that the game just lacked the capabilities to tell the story and teach the player stuff the way I had imagined it and would personally be content with. So what I decided to do was to lay down the campaign and instead to first implement these features myself, and only then pick up the campaign again to write it using that new functionality. And in the last year I have worked on all points that I mentioned above: https://gitea.wildfiregames.com/0ad/0ad/pulls/7785 https://gitea.wildfiregames.com/0ad/0ad/pulls/8318 https://gitea.wildfiregames.com/0ad/0ad/pulls/8614 No PR yet, but I have started working on this and more (like highlighting GUI objects to explain what they do) locally. I ended up creating a new set of terrain textures for it from scratch: https://gitea.wildfiregames.com/0ad/0ad/pulls/8214 And the first map is basically done. Now, all of these PRs are still open, meaning the features aren't in the game yet. And realistically, it'll be quite some time before all of them do and until there's an actually playable version of this campaign. Especially since lately I've obviously focused more on stuff for the R28 release. However, even though I can't promise anything right now, my personal goal is to get it all ready for R29. I can always use help, but not really with coding, just input and feedback is always helpful to me. Also, I would love to have illustrations in the campaign, so if anyone is, knows, or finds an artist to draw some images to our story (when we eventually get to writing it) that would be incredible.

It works for me just as expected. Have you tested it with other maps? If it works with other maps, the issue probably lies with your trigger script.

For the German speakers:

My idea is to place each tip in one category of each, e.g. the siege tower tip in "Medium" & "Military". That way the number of tips per combination stays relatively small and will hopefully make it easier to find specific tips or browse in an area that you're interested in. An index for all tips would be nice to have indeed, and some basic search functionality too. But that'll be more work.

All clear now? (it would be possible to run the game headlessly (with no rendering) and to force it to execute turns a quickly as it can)

Yes, notifications are the best way to communicate stuff like this from the simulation to the GUI (and it works just as @phosit said). What kind of calculations? A "tick" in the GUI happens for each rendered frame, so the tick rate won't go up if you increase the sim rate (in fact, it'll probably go down a bit, since the game is busier with the simulation and has less time for rendering).

That's not possible, unfortunately. Essentially, the engine creates different JS script interfaces for different purposes - one for the GUI (scripts in gui/), one for the simulation (scripts in simulation/ and trigger scripts in maps/scenarios/) and one for map generation (scripts in maps/random/). And those Engine functions are always registered in specific contexts. Engine.QueryInterface, for example, is obviously only available in simulation context, since that's were simulation components and interfaces are. Similarly, Engine.SetSimRate and Engine.GetSimRate are only registered in the GUI scripting context, meaning you can only call them from GUI scripts. What exactly are you trying to achieve? There are some possible workarounds because the engine allows you to communicate between contexts and modifying the engine to register SetSimRate and GetSimRate in simulation scripting context too is quite straightforward actually.

Which are missing? Only the two Han tracks as far as I can tell, Red Dawn and Hills of Sorrow.

There is this tip: Yeah, I figured someone would bring this up eventually. An idea I had a while ago but never got to implement was to categorize them by level (beginner - intermediate -advanced, which is already done in the code) and then by topic, like features, units, buildings, gamemodes, etc. How does that sound?

I suppose since the patch contains engine changes, for that you'd currently have to build the game locally... but that version would be incompatible with any other releases or patch releases. If you don't want to do that and are working on a campaign, I recommend you to finish it without the dialogues for now and to just note them down instead. When the PR is merged, the feature will be part of the nightly builds where you can then embed the dialogue and test it.

I hope this gets you as excited as me: https://gitea.wildfiregames.com/0ad/0ad/pulls/8614 (please don't judge my sense of humor )

Should it be removed (temporarily) for this release then?

The only new map is the sandbox map of the Germans. But I don't know whether sandbox maps were shown by that filter in the past.

Generally yes. But in this case, there is already an open issue tracking this: https://gitea.wildfiregames.com/0ad/0ad/issues/8328

Note: This has already been fixed on the release branch. The Germans will be actually playable in the next release candidate.

Please be more respectful and appreciative of other people's work. The addition of the Germans was certainly not rushed; the pull request was open since well before the release of A27 and being reviewed for a full year before merged. And that time doesn't even include much of the work of creating the content itself, like researching, brainstorming, making the 3D models, the portraits, and putting everything together. Creating a complete new civilization takes tremendous effort and we should all be grateful for the wonderful people who dedicated their free time to achieve it. And in my opinion the Germans are definitely up to the standard of other civilizations in terms of art, historical accuracy, uniqueness, and balance. Stuff like custom phase names are just the cherry on top and can very well just be added in the future.

It isn't witchcraft. You've done much already (creating the fork, clone, branch, and finally the PR) and I'm confident you'll figure out the rest too as we move along. Then I suggest that you create the PR.

I assume you mean that the civ is set to random by default?

@Atrik Apologies for only responding now. Considering that you have now set up a Gitea account and fork in the meantime, do you want to open a PR for this now? I'm still up to do the testing and reviewing. (If not, it's also fine, I can take care of all the git stuff for you, if you want)

I got an error like this a while ago too and the cause was that the compiler version was too old.

Very nice. It also adds the missing tooltip when the starting turret can't be placed. Do you want to open a PR? I can help with testing and reviewing.

You could either define it in the GUI globally somewhere and then pass it to every GuiInterface call, or just make it a member of the GuiInterface directly. The Engine.PickSimilarPlayerEntities method does not exist in the simulation scripting context, but the same thing can be achieved through the GetEntitiesByPlayer method combined some additional manual checks. That would also allow filtering entities by the "Tower" class instead of their template names (as you mentioned in the comment), if wanted. By the way, the GUI already caches entity states (in g_EntityStates).

I took a quick look at the code, correct me if I'm wrong, but for a PR it looks like you could directly move most of the logic to the GuiInterface.prototype.SetWallPlacementPreview method. I don't think length would be an issue since you largely rewrote the logic of that method anyway, which is itself already quite long. And I don't think anyone would mind having a bit more code for more desired behaviour. Also, that would make it even more performant because you wouldn't have to compute the entire entity state for each snap candidate and could pull values like the position from the simulation directly, which is a lot quicker. What do you think? I believe a lot of people (including me) would love to see this added to the main game.

https://gitea.wildfiregames.com/0ad/0ad/wiki/FAQ#what-shall-i-do-when-joining-multiplayer-matches-fails-with-an-error-message By the way, in the future (starting with R28) there will be a button on the error dialog that opens this FAQ entry directly.