[Highly Customized] Distribution click action mode

[CrimRecya]

[ ] Distribution Mode Spread / Filter / Enable

• Change the click action when hold down the specific hotkey if enabled AllowDistributionCommand.
  • When the range is 0, it is the original default behavior of the game. The range can be adjusted to 4, 8 or 16 cells by shortcut keys.
    • The targets within the range will be allocated equally to the selected technos. Only when the behavior to be performed by the current techno is the same as that displayed by the mouse will it be allocated. Otherwise, it will return to the original default behavior of the game (it will not be effective for technos in the air). This will display a range ring.
  • When the filter is None, it is the default behavior of the game. If the range is not zero at this time, a green ring will be displayed. You can adjust the filter mode to:
    • Auto - if the behavior to be executed by the current techno is different from the behavior displayed by the mouse, and the behavior to be executed will make the techno move near the target, the behavior will be replaced with area guard. At this time, a blue ring will be displayed.
    • Type - on the basis of Auto, only targets of the same type (like infantries, vehicles or buildings) will be selected among the targets allocated in the range. At this time, a yellow ring will be displayed.
    • Name - on the basis of Type, only targets of the same name (or with the same GroupAs) will be selected among the targets allocated in the range. At this time, a red ring will be displayed.
• For localization add TXT_DISTR_SPREAD, TXT_DISTR_FILTER, TXT_DISTR_HOLDDOWN, TXT_DISTR_SPREAD_DESC, TXT_DISTR_FILTER_DESC and TXT_DISTR_HOLDDOWN_DESC into your .csf file.

In rulesmd.ini:

[GlobalControls]
AllowDistributionCommand=false  ; boolean

2024-12-16.01-47-48.mp4

[github-actions]

Nightly build for this pull request:

• compiled-dll-4f1ec876c282592b44e32f56d1c3eebf1452c288.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[TaranDahl]

lgtm

[CrimRecya]

In theory, it should work normally in multi-players, but I haven't tested it yet. It would be great if it could work as expected.
In addition, as for the display of the current mode, the scheme has not been finalized yet. At present, I want it to be displayed directly at the mouse position, such as the display range of SW, instead of using print message like in video. If anyone has any good ideas, PLEASE comment.

[TaranDahl]

Tested locally. Doing good.

[Metadorius]

I am hesitant on how to deal with this feature. It removes a huge amount of microcontrol from the game, essentially automating half of whatever required skill before and now just requires a mouse click.

[TaranDahl]

I am hesitant on how to deal with this feature. It removes a huge amount of microcontrol from the game, essentially automating half of whatever required skill before and now just requires a mouse click.-----------谷歌翻译-----------我对如何处理此功能感到犹豫。它从游戏中删除了大量的微控制，从本质上讲是在此之前所需的任何技能的一半，现在只需单击鼠标即可。

I think all you want is a toggle?

[Metadorius]

I would say that if we will merge it, a toggle is a must, because the whole existence of such a hotkey alters gameplay significantly, removing a huge amount of microcontrol requireemtn.

The bigger question is where do we draw the line on what should be included in mainline Phobos and what not? In other words, what is the scope of the project?

This is an exaggeration, but just to show the point that I am trying to make -- imagine suddenly a pull request appears that is intended specifically to turn YR into a whole different genre of game (say, a visual novel with no RTS stuff at all) and is not usable for purposes of regular RTS players or modders. Should we merge it at all? I don't think we should, it is, as we say, out of scope.

The main question is where do we draw the line between such features that are out of scope and the features that should be merged and are in the scope? And what potential drawbacks are there if we merge it?

[TaranDahl]

The main question is where do we draw the line between such features that are out of scope and the features that should be merged and are in the scope?

Personally, I came to Phobos because everyone knows Phobos. If I get something done here, then people will know it's done and other people don't need to spend time on what I've already done. I think it is meaningful.
So for me, as long as I think this feature is likely to be used by others, then it is not out of scope.

And what potential drawbacks are there if we merge it?

Negligible performance impact.
Careless devs can introduce issues that can cause crashes even if features are not enabled.

[TaranDahl]

If you have to decide on a scope, then we can vote on those PRs that anyone says are out of scope.

[Metadorius]

as for the display of the current mode, the scheme has not been finalized yet. At present, I want it to be displayed directly at the mouse position, such as the display range of SW, instead of using print message like in video. If anyone has any good ideas, PLEASE comment.

I have an idea.

First, the radius can be controlled not via hotkeys, but with a mouse. How that would work? You press a hotkey to activate distribution mode, and when you press right mouse button on the target and drag your mouse without releasing the mouse button - it displays the circle and changes the radius depending on how far you drag the cursor, so you regulate the radius with the mouse drag. Then when you release the mouse - the orders are given to every selected unit. You do that each time and effectively draw circles to give orders.

This is inspired by Call to Arms: Gates of Hell game. There you can spread your infantry among covers this way, click behind covers and drag to spread people better.

[CrimRecya]

I would say that if we will merge it, a toggle is a must, because the whole existence of such a hotkey alters gameplay significantly, removing a huge amount of microcontrol requireemtn.

Yes, I think we still need a toggle to enable this feature, not just defining buttons. I will add later.

The bigger question is where do we draw the line on what should be included in mainline Phobos and what not? In other words, what is the scope of the project?

Personally, if someone (whether they are modders or task package authors) needs a certain feature and I happen to be interested in it, I will try to do it. Whether to merge or not is actually related to whether more people will use it. But no matter what, these features will only be pushed if there is a demand.

This is an exaggeration, but just to show the point that I am trying to make -- imagine suddenly a pull request appears that is intended specifically to turn YR into a whole different genre of game (say, a visual novel with no RTS stuff at all) and is not usable for purposes of regular RTS players or modders. Should we merge it at all? I don't think we should, it is, as we say, out of scope.

If it is assessed that this should not be merged, then I will close it.

The main question is where do we draw the line between such features that are out of scope and the features that should be merged and are in the scope? And what potential drawbacks are there if we merge it?

As TaranDahl said, for example, if this feature does not have any impact on performance and can be disabled (assuming I have already added the switch), then I think it can be merged.

[CrimRecya]

The opening video is based on the initial design, which is now outdated. I will share another one when I have time.

[TaranDahl]

Regarding the feature itself: Can you save mode1 and mode2 (or at least a default value that can be manually set by a player) into KeyboardMD.ini or somewhere else? Currently, every time the game is started (including loaded), they need to be adjusted again, which is not very convenient.

[DeathFishAtEase]

Kerbiter's suggestion is quite interesting,

You press a hotkey to activate distribution mode, and when you press right mouse button on the target and drag your mouse without releasing the mouse button - it displays the circle and changes the radius depending on how far you drag the cursor, so you regulate the radius with the mouse drag. Then when you release the mouse - the orders are given to every selected unit. You do that each time and effectively draw circles to give orders.

but I'd prefer it to be another optional manifestation of this feature.
Correspondingly, I believe that as long as the switches used by modders are kept, ensuring that the extension is aimed at mod creators and providing sufficient freedom, that's enough.
People always have various needs, and as long as a new feature is not mandatory, it can be acceptable.

[Metadorius]

but I'd prefer it to be another optional manifestation of this feature.

Do you mean toggle between hotkey radius selection and mouse adjustment? I am not sure if the hotkey radius selection is intuitive enough to be left in.

Compare "a single long enough drag to give and customize the order" against "toggle a hotkey or multiple, give an order, toggle hotkeys again". It is also far more intuitive to adjust the radius with a mouse, just like you do in a 2D or 3D graphics editor when you create a circle or, say, a cylinder, and change the size with a mouse. Hotkey doesn't have immediate visual feedback, you have to read the number and translate it into a circle in your mind, or, alternatively, you'll have a constantly floating circle around, and a toggle to enable/disable the feature altogether. If you implement it like I suggested - there will be much less friction for the user.

[CrimRecya]

Do you mean toggle between hotkey radius selection and mouse adjustment? I am not sure if the hotkey radius selection is intuitive enough to be left in.

I currently have a new solution that uses the mouse wheel to assist. Still testing and waiting for feedback.

[Metadorius]

I currently have a new solution that uses the mouse wheel to assist. Still testing and waiting for feedback.

Sounds like an interesting option, is that what you mentioned earlier?

[DeathFishAtEase]

Do you mean toggle between hotkey radius selection and mouse adjustment? I am not sure if the hotkey radius selection is intuitive enough to be left in.

不，我认为它们都应当是可选的，它们的具体效果都非常有趣，它们也同样会有人希望使用

The bigger question is where do we draw the line on what should be included in mainline Phobos and what not? In other words, what is the scope of the project?

所以只要给足 mod 创作者是否使用这个效果的自由，再确保它们不会拖累 FPS，那么它们就是可以保留的。

---

Do you mean toggle between hotkey radius selection and mouse adjustment? I am not sure if the hotkey radius selection is intuitive enough to be left in.

No, I mean they should all be optional.
Their specific effects are very interesting, and there are also always have people who would want to use them.

The bigger question is where do we draw the line on what should be included in mainline Phobos and what not? In other words, what is the scope of the project?

So as long as mod creators are given the freedom to choose whether to use these effects and ensure that they don't drag down the FPS, then they can be kept.

[CrimRecya]

Sounds like an interesting option, is that what you mentioned earlier?

Yes, it's based on #1522 .

[DeathFishAtEase]

This is an exaggeration, but just to show the point that I am trying to make -- imagine suddenly a pull request appears that is intended specifically to turn YR into a whole different genre of game (say, a visual novel with no RTS stuff at all) and is not usable for purposes of regular RTS players or modders. Should we merge it at all? I don't think we should, it is, as we say, out of scope.

Have you heard of TS: Another World? It is a YR MOD that is set in the world of TS, retains RTS elements, and features visual novel-style missions. We might not need to focus on requirements that may deviate from RTS content, but if someone provides a feature, accepting it with the option to disable it is not an issue. Unless we are convinced that it will have a negative impact on other feature.

If a user will specifically implement functions that do not belong to RTS and are not closely related to YR content, then I think they should also base on something like Ares0A or ts-patches to create an independent new expansion engine instead of making changes on current version Phobos.

---

这有点夸张，但只是为了说明我想要表达的一点——想象一下突然出现一个拉取请求，它专门用于将 YR 变成一个完全不同类型的游戏（比如，一部根本没有 RTS 内容的视觉小说），并且不适用于普通 RTS 玩家或 Mod 作者。我们应该合并它吗？我认为我们不应该这样做，正如我们所说，这超出了范围。

你听说过《TS:AnotherWorld》吗，它是一个以 TS 为世界背景、保留部分 RTS 内容，任务内容属于视觉小说的 YR MOD。我们或许不必要将可能有些偏离 RTS 内容的需求作为重点，但如果有人提供了功能那么在允许关闭的情况下接收它并不是什么问题。除非我们确信它会对其他功能造成不良影响。

如果某个用户会专门去做不属于 RTS 也与 YR 内容没有太多关联的功能，那么我想他们也应该会去基于类似 Ares0A 和 ts-patches 制作一个独立的新拓展引擎而不是在当前版本的 Phobos 上更改。

[Metadorius]

Well, after a bit of thinking and input from you all I think that if we gate it behind a toggle - it's fine. The feature is isolated and doesn't make a big impact neither at modders, nor at users, nor at developers if it's off. Of course, it's a maintenance cost, but hopefully there won't be much problems with it.

[Metadorius]

Another example of the approach I suggested. This GIF is a recording of an RTS game Zero-K, based on Spring RTS engine. It has one of the best-in-class user interface features, which make playing the game a delight. You can draw paths or areas with the mouse and it's all very intuitive. I recommend you give it a look and maybe even try it.
Can be downloaded for free on Steam or without it from the official site.

[Metadorius]

(If someone is not familiar with Supreme Commander/Total Annihilation style gameplay: the GIF shows designating metal extractors to be built at all spots that are available in the area designated by drag and click.)

[DeathFishAtEase]

Personally, I might prefer to use two separate clicks to determine the center and radius (the second click on a point on the arc) rather than long-pressing and dragging, unless it's for weapons like bows in a first-person perspective that require a special feel :P