Vantha

The amentum https://github.com/indoptogopt/GUI-page-for-0ads-encyclopedia/pull/5 Also, I heard some people are pushing towards more unit-type-specific armor and damage upgrades... the amentum would make for a really good one.

Right, but that still doesn't make it track changes between the two source branches, does it?

How? Is there a feature I am missing? Or do you mean I should just mention it in the PR description?

I'd like to submit the code now, but it comprises of two split features that should probably get a pull request of their own. Firstly, the chat notifications, and secondly (built on top of it) the observer flares. They are very interconnected and I would like to have both pull requests open at the same time (especially since the chat notifications would become kinda pointless should the observer flare code be rejected). How should I do that? Open a pull request on the main 0ad repo for the base code (chat notifications) and then open another one to that new branch on my fork containing the additional code (observer flares)?

Yes. I think that would be more feasible.

Hmm. I'm not convinced. Wouldn't it just add another layer of complexity? What about articles requiring multiple citations? We might end up having to cite every statement individually. And it's not like our texts include controversial opinions or bold claims - most of the information provided is universally accepted as correct - in which case citations become rather pointless anyway. Not to mention the hassle of working with different citation styles for different languages and countries...

Possible, yes. I suppose there could be a small button "View Source" to the bottom of articles. I have some concerns with it, though. Firstly, there is (naturally) no consistent medium or platform we used as sources - sometimes it's a book, other times a Wikipedia entry, and other times again a scientific paper. Maybe I'm overthinking this a bit, but don't you think that would come across a bit... strange? Secondly, does the WildfireGames team event support/allow external links in their game?

Actually, I removed this line entirely here. It was part of the tip about resource gathering which ended up getting too long for the available space in the GUI. It had to be cut down and this line was not directly related to the topic anyway. That's not to say this information shouldn't be included in the tips. In fact, I believe a separate tip about unit ranks would be quite useful. To my knowledge, players are currently not taught about the game's experience system anywhere. Definitely something to keep in mind for the future.

Yeah, I worked a bit messy there... I just copied the folder containing the sources from the old repo to the new one (into gui/encyclopedia/articles/Sources/, for now) and added all missing entries. Although, some comments in the files are outdated, it's at least back up again, ready to collect the sources for future articles.

Got back into writing a handful of articles in the last days. Here's one about the spear-thrower: https://github.com/indoptogopt/GUI-page-for-0ads-encyclopedia/pull/4

Ok, cool. I'm gonna leave it as it is then.

What do you think of this? Is it indication enough that they're buttons?

To my knowledge, players can only be muted in the lobby chat, but not the pregame or ingame chats. I wonder why, though, since hosts can already kick and ban players - so, I imagine adding a mute command to be pretty straightforward. I'd even go as as far and say this is a must, flares can be much more annoying than chat messages.

My tendency would be to treat defeated players as observers and cut them off from their former allies - they can no longer access the team chat at that point either. However, they could still keep their color when flaring to observers - they also keep their color in the global chat.

Well, anyway, here are some more details: - Because all observers would flare in the same color (namely white) I also added an option for flare chat notifications. - Who can see whose flares is pretty simple to change codewise, we only need to come to agree on one possibility. To conclude this thread so far: there are no concerns raised about allowing observers to send flares to other observers. What remains debated, is whether observers can see the players' flares. I'm of the opinion they should.

Yes, that fixed it! I didn't notice there was a different function specifically for registering system component types. Thanks for your help.

Hmm, I still can't get it to work. I already added both the component and interface files. And I'm not querying a specific template, but the system entity (I want the code to be run globally). I believe I've correctly registered the component type and interface. Does the component maybe need to be instantiated somehow? (I've never worked with the simulation code before...)

Is this still relevant? I actually made a patch for observer flares a couple of months back and even created some art for it. (Although the implementation might be somewhat questionable)

So, I want to add a new simulation component. There is no documentation about it, so I tried replicating the existing components' setups. Here is what I did: I put my script in simulation/components/. It calls Engine.RegisterComponentType() at the end. Additionally, I created a script of the same name inside simulation/components/interfaces/ running Engine.RegisterInterface(). From searching the codebase I found most components only do exactly that. For mine, however, Engine.QueryInterface(SYSTEM_ENTITY, <Name>) still returns undefined... Does anyone know why? What am I missing?

That'd be so cool! As @ShadowOfHassensaid, we always hoped to eventually add a big gameplay/strategy section to the encyclopedia. About the scrollbar, it would require no additional code at all - only adding 'scrollbar=true' to the text field. The biggest effort would be designing the new style - which I think really needs to be done if we decide for it. I don't know how you're planning on structuring it, but my suggestion would be to use another interface (the encyclopedia page for example) for the in-depth parts and leave the current flipbook as it is (without adding a scrollbar) as a small section of the whole giving quick, superficial tips - most of the current ones are pretty useful already, but can't be directly expanded upon. Interesting, I didn't know this feature. I have a whole list of possible topics for tips, but currently lack time to create the text and images for them. I'll note it down.

Why not make it optional then? A gamesetting called "Reveal enemy civs" (which is enabled by default) There is an old ticket about it, it suggests to also hide them on the gamesetup page. I definitely like the idea. https://gitea.wildfiregames.com/0ad/0ad/issues/3971

Yes, that's possible. Although, I'm afraid the default scrollbar style (which is white and yellow) won't fit the parchment background. I guess I could create a simple, black scrollbar in the same style I made the other UI elements. But, as of now, no tip text exceeds the limit (which would need a scrollbar) and it could be argued that the tips are intended to only be this short in length and not to go too much into detail..

I made smaller changes to the patch and ported it to git: https://gitea.wildfiregames.com/0ad/0ad/pulls/6997

not. It's supposed to be AD 20, of course, my bad.

I just opened a pull request for it: https://gitea.wildfiregames.com/0ad/0ad/pulls/6980