Suggestions for 0 A.D.

[Guest]

- Sometimes when I want to place a building I want to see the highlight to have gaps, you know how you select a building there is the blue outline? Ye include that, before I want to place it since I intend to leave some gaps for my workers to move in between. Many times do I get blocked by it and I had to destroy the building and redo it even if its free...

- Today I realised in multiplayer I can check resource by hovering to the left topside, here's a problem I never knew about it, you should mention that in tutorial or something... while at it, it needs to be improved, I want to see teammate's resource in one go just like modernGUI by using arrow key of some kind to open/minimise the look. Not that I'm going to to use such mods since I'm more of a vanilla guy.

- If buddy feature exist, there should be enemy. In a sense that player is muted to you, they can still join for fairness sake and they do see their status by you to be aware. Is there even a way to identify easily whose buddy or not in one list just like friend list? Atleast colour them differently... I do forgot how it works though since lobby is a bit mysterious to me, like there is no mention on various commands I can do there... example typing /away.

[Seleucids]

16 minutes ago, Tapothei said:

- Sometimes when I want to place a building I want to see the highlight to have gaps, you know how you select a building there is the blue outline? Ye include that, before I want to place it since I intend to leave some gaps for my workers to move in between. Many times do I get blocked by it and I had to destroy the building and redo it even if its free...

- Today I realised in multiplayer I can check resource by hovering to the left topside, here's a problem I never knew about it, you should mention that in tutorial or something... while at it, it needs to be improved, I want to see teammate's resource in one go just like modernGUI by using arrow key of some kind to open/minimise the look. Not that I'm going to to use such mods since I'm more of a vanilla guy.

- If buddy feature exist, there should be enemy. In a sense that player is muted to you, they can still join for fairness sake and they do see their status by you to be aware. Is there even a way to identify easily whose buddy or not in one list just like friend list? Atleast colour them differently... I do forgot how it works though since lobby is a bit mysterious to me, like there is no mention on various commands I can do there... example typing /away.

Point 1: you can visually check that there is a gap. If you want the units to pass through smoothly, your gap should be large enough to be visually obvious 

Point 2: moderngui is the way to go right now

Point 3: every time you mark someone as buddy, their name is written to a list in user.cfg locally. Nobody else knows who you mark as buddy as this is a purely local action and not synced. If you log in on a different computer, you will loose all of your friends. You can implement an enemy list in a similar way but I recommend you to get along with other players instead 

[Guest]

21 minutes ago, Seleucids said:

Point 1: you can visually check that there is a gap. If you want the units to pass through smoothly, your gap should be large enough to be visually obvious 

Point 2: moderngui is the way to go right now

Point 3: every time you mark someone as buddy, their name is written to a list in user.cfg locally. Nobody else knows who you mark as buddy as this is a purely local action and not synced. If you log in on a different computer, you will loose all of your friends. You can implement an enemy list in a similar way but I recommend you to get along with other players instead 

1) Even when it looks like a gap I still get it wrong, I tried many times already its just quite unreliable.

2) I'll ask, does it contain any advantage mechanics or is it just gui being improved and if so, can I turn it off? I only need to see ally resource properly so I don't have to look it up majority of the time.

3) If this game ever increased its popularity then I'll need this feature since there will be some bad apples I'll don't ever want to ruin my mood. Atleast I won't be negatively effected nor would I disturb them.

[DesertRose]

21 hours ago, real_tabasco_sauce said:

Do workers tasked on busy farms not already look for spots on nearby farms? Or do you mean that they should automatically distribute to all available farms?

Like, you have 5 Gathers and 3 Farms, and click on 1 Farm that already has 3 Gathers. The gathers will first populate the two other Fields.

But maybe some modifier hotkey to toggle smart Villager allocation on.

20 hours ago, ffm2 said:

Why though?

It would be 2 developers working against each other.

First develops a game mechanic where each farmer has x0.9 of the efficiency of the former.

Second just optimize the effect automatically to a minimum making it meaningless for the player.

If you like to plan less for your setup, why don't you just suggest to remove the feature that's also not full documented with the numbers?

I'd just keep it as it is, but it should be documented with the numbers clearer.

It's more to make the strategic decision to spend more Wood for faster Food production more feasible. Imo such a basic economic decision should not be barred behind a certain APM threshold / having to use a certain mod.

[guerringuerrin]

4 minutes ago, DesertRose said:

Like, you have 5 Gathers and 3 Farms, and click on 1 Farm that already has 3 Gathers. The gathers will first populate the two other Fields.

But maybe some modifier hotkey to toggle smart Villager allocation on.

Right now you can accomplished the same by using the "Order one unit" command (alt by default I think) . You can grab a bunch of units and, by holding the modifier key assigned for this command, send one by one to each farm. like alt+left click 3 times on every farm.
I think a feature similar like this #8525 would also be useful for gathering. It would help with chopping wood as well, since targeting certain trees can be a pain and workers often end up crowding on one side of the woodline.

[Atrik]

9 minutes ago, Tapothei said:

2) I'll ask, does it contain any advantage mechanics or is it just gui being improved and if so, can I turn it off? I only need to see ally resource properly so I don't have to look it up majority of the time.

Glad you ask!
I'll try to make a short answer even if I could talk so much about this point.

ModernGUI is almost a mod that allow you to build the GUI. You have the basic UI reworked, that looks like that : 

The panels are reworked nicely with generally slightly bigger buttons, and importantly, access to cool stats and data is easy and tones more of them are accessible in stylized tooltips.

You can then open the "GUI builder" using the gear icon near the minimap, and start customizing the UI, including adding the top panel for stats.

The "advantage mechanics" are disable by default, and can be enabled in the "EcoPanel" menu of this GUI builder. So if you don't want them, you just don't enable anything in there.
There are a couple of features like the ability the use "order one" hotkey for certain actions where it isn't implemented in vanilla, as well as the farm buttons discussed above that don't have an option yet, but I doubt you were thinking about that.

As a side note, autociv mod also has a panel to display allied stats although it is not very visually appealing.

[wowgetoffyourcellphone]

6 minutes ago, Atrik said:

The "advantage mechanics" are disable by default, and can be enabled in the "EcoPanel" menu of this GUI builder. So if you don't want them, you just don't enable anything in there.

 

 

But I will say I enjoy the GUI customization screen. Hadn't seen that before. I wish you would focus on adding things like that to the base game. You are indeed talented at this. 

[DesertRose]

31 minutes ago, guerringuerrin said:

Right now you can accomplished the same by using the "Order one unit" command

Well, the issue with that method is that right now it's very hard to see how many Farmers work on which Field.

Maybe this could made more clear by adding 5 gather points on a Field where each Farmer has to do.
Like

. . . . . . .
. X . . . X .
. . . . . . .
. . . X . . .
. . . . . . .
. X . . . X .
. . . . . . .

Basically there are 5 invisible "trees" placed at those "X", and each "tree" has a maximum of one Farmer.

Edited March 10 by DesertRose

[DesertRose]

I mean, when I looked through the options offered by ModernGUI and saw the option of "Queue in idle buildings first" I was baffled that apparently is not how the game already behaves.

[guerringuerrin]

13 minutes ago, Emacz said:

@Atrik has talent! I'm not sure if they allow him to add things to the base game.  People have very strong recations and beliefs to some aspects of ModernGUI and I feel treat Atrik in an unfair manor because of that.  I for one am a big supporter of adding some of his GUI aspects to the main game.  I think its more visually pleasing, and easier for people with not great eyesight.  

I guess that’s a bit like life, right? A person can be many things at the same time. It’s also true that we are a very small community, so frictions naturally arise. Also, I don’t support encouraging hatred. And I think @Atrik has contributed many positive things, even if there are some aspects I don’t like.

Personally, I consider the automation features in ModernGUI’s training system a clear advantage, and we have discussed this publicly many times. Aside from that, all the GUI aspects of the mod are really great. The configuration wizard is excellent.

In my view, a game that allows you to configure the GUI the way you like—the more freedom it gives you, the better the user experience. Of course, there can be some nuance regarding how far certain visualizations might also be considered an advantage, although I see that as a relatively minor issue.

Edited March 10 by guerringuerrin

[Guest]

Thx @Atrik, should've split advantage from updating the GUI, one for the looks and one for QOL type of thing for those that prefer playing it like that. The game does need some ease of readability when it comes to multiplayer.

[guerringuerrin]

8 minutes ago, DesertRose said:

I mean, when I looked through the options offered by ModernGUI and saw the option of "Queue in idle buildings first" I was baffled that apparently is not how the game already behaves.

Yes, the vanilla training system has many limitations that, in my opinion, are a form of malfunction. I think that frustration can lead users to look for alternatives. In fact, I’ve been working on a mod that always prioritizes empty barracks, and my goal is to have it implemented in the next release (PR #8483). While respecting the “no automation principle”, I believe removing unnecessary limitations is something positive.

[real_tabasco_sauce]

16 minutes ago, DesertRose said:

Well, the issue with that method is that right now it's very hard to see how many Farmers work on which Field.

Maybe this could made more clear by adding 5 gather points on a Field where each Farmer has to do.
Like

. . . . . . .
. X . . . X .
. . . . . . .
. . . X . . .
. . . . . . .
. X . . . X .
. . . . . . .

Basically there are 5 invisible "trees" placed at those "X", and each "tree" has a maximum of one Farmer.

This could be a neat way to replace the less intuitive diminishing returns feature. As long as the spots get filled by proximity to the storehouses, and the farmers choose the move to the closer spots if they are vacant. Lots of stuff to implement for this tho.

[Guest]

7 minutes ago, real_tabasco_sauce said:

This could be a neat way to replace the less intuitive diminishing returns feature. As long as the spots get filled by proximity to the storehouses, and the farmers choose the move to the closer spots if they are vacant. Lots of stuff to implement for this tho.

Just add an outline to indicate how full it is, from red to green. [Can change colour in setting for the colourblind]. Hmm... then again this needs further ways to identify easily.

Edit; Whoops I thought they mean't how to identify how full fields are, since I sometimes miss some numbers.

Edited March 10 by Tapothei

[real_tabasco_sauce]

Just now, Tapothei said:

Just add an outline to indicate how full it is, from red to green. [Can change colour in setting for the colourblind]

Not precisely related to what I was discussing, but i think that would conflict with HP bars.

[wowgetoffyourcellphone]

22 minutes ago, Emacz said:

@Atrik has talent! I'm not sure if they allow him to add things to the base game.  People have very strong recations and beliefs to some aspects of ModernGUI and I feel treat Atrik in an unfair manor because of that.  I for one am a big supporter of adding some of his GUI aspects to the main game.  I think its more visually pleasing, and easier for people with not great eyesight.  

He already is adding things to the base game. All one has to do is make Pull Requests. Other people criticize the code to improve it, or a design discussion occurs so that the design is honed and refined and meets the criteria of the game. 

[wowgetoffyourcellphone]

10 minutes ago, real_tabasco_sauce said:

This could be a neat way to replace the less intuitive diminishing returns feature. As long as the spots get filled by proximity to the storehouses, and the farmers choose the move to the closer spots if they are vacant. Lots of stuff to implement for this tho.

This can be a compromise between what we have now (which kinda sucks, not gonna lie) and the "wandering farmer" of Age of Empires. 

[DesertRose]

24 minutes ago, real_tabasco_sauce said:

This could be a neat way to replace the less intuitive diminishing returns feature. As long as the spots get filled by proximity to the storehouses, and the farmers choose the move to the closer spots if they are vacant. Lots of stuff to implement for this tho.

That's actually something I wanted to say, but I feared that the walking distance is too small to replace the 10% diminishing return.

[Atrik]

1 minute ago, wowgetoffyourcellphone said:

All one has to do is make Pull Requests.

It's a bit more complicated then that however. It's not just about good will.

• There are things that I can do in a mod that won't be accepted in vanilla, like dropping support for minuscule screens.
• The time spent on developing anything for vanilla is of a large order of magnitude (often even two) longer then for a mod, due to requirements, process, need of communications..
• Reviewer availability is scarce and mismatch with your own motivation and availability creates a even bigger gap between making something in a mod and for vanilla.
• Some ideas are very often initiated in the mod as a totally buggy POC, and refined over time since you can immediately play test it (or dropped). Which is something you cannot really do with vanilla.

[wowgetoffyourcellphone]

Just now, Atrik said:

There are things that I can do in a mod that won't be accepted in vanilla, like dropping support for minuscule screens.

That's not necessarily true. It's definitely a discussion we can have. 

Your other points are 100% fair. My main reasons for starting DE. 

Collaboration, especially online collaboration, can be very frustrating at times. But what you can do (which you've already done and which I've done) is use your mod for experimentation, etc., then parse out bits and pieces you think would serve well the base game and make PRs. 

[BreakfastBurrito_007]

I like the distributed farmers idea. There would be lots of gameplay ramifications for eco efficiency and vulnerability to raids.

One outstanding point is the slot ("trees" as mentioned by @DesertRose) priority per farmers. Instead of some script that would place each additional farmer at the best possible slot depending on dropsite and farm orientation, slot prioritization should be done based off the path the farmer takes to access the farm when tasked to farm on it (whichever slot is closest).

Edited March 10 by BreakfastBurrito_007

[Seleucids]

@Atrik @wowgetoffyourcellphoneI want to touch on the recent discussion regarding our development workflows and how best to align our modding efforts with the vanilla codebase. I have read through both of your points and really appreciate the nuance around resource allocation and reviewer availability. The reality is that there are definitely valid differences between the timelines for mods versus full game integration, particularly when it comes to compliance and QA scrutiny.

However, as we move forward on larger project deliverables, our goal is to streamline the process without sacrificing quality. I am proposing that we introduce weekly alignment sessions on Microsoft Teams to keep everyone synced with QA and product management. This would allow us to surface blockers earlier and ensure our technical direction remains aligned with the broader roadmap. Regarding the specific debate on mods versus pull requests, standardising our integration protocols can actually help bridge the gap you mentioned regarding reviewer availability. By centralising these reviews within a PR workflow, we create a more predictable pipeline for feedback and refinement before code enters the core system.

This is a collective effort to improve how we scale our development operations. If we can establish these regular touchpoints and adopt a shared development standard, we should see fewer integration headaches  and faster cycles for feature releases. I would love to hear your feedback on how you think we can implement this in a way that respects the workflow differences you are facing while still moving us toward greater consistency.

 

[Atrik]

24 minutes ago, Seleucids said:

I have read through both of your points and really appreciate the nuance around resource allocation and reviewer availability.

Tiny precision, I wasn't trying to blame the process  I saw how it works well to generate hardened quality code, the time reviewer spend to read your (sometimes sh!ty) code is never to be taken granted --thanks by the way @Vantha, @phosit, @Stan` for the reviews on my PRs --.

But simply the additional time to be spent on trying to get any feature into the game (again the 1-2 order of magnitude larger of work isn't a exaggeration, add to this waiting time) create a very real limit to what you can get done, even over a large time frame.

Your suggestions to try to organize the collaboration although nice, can hardly solve this dilemma.

 

Edited March 10 by Atrik

[AlexHerbert]

On 12/7/2004 at 7:34 PM, deaconwar said:

How do you guys guys think being able to use smilys in the game would affect it.

or being able to use smilys http://www.wildfiregames.com/forum/uploads//emoticons/default_biggrin.png in the chat room

This is already possible, isn't?

Can be done with characters like =P

[Guest]

As far as I'm aware, there doesn't seem to be a way to cancel producing mass amount of units in a building, so my only choice is to manually click cancel and its annoying in multiplayer where input lag is present as well as mistaking a batch number or wrong unit, so solving it by a click of a button would be nice. I've made an issue already on github.

Edited March 11 by Tapothei