In D4159#177321, @vladislavbelov wrote:

In D4159#177320, @wraitii wrote:

Mh, would it really matter? The individual PNGs are about 160Kb each. At best we'd gain 1-2 MB total maybe?

Sure, in total we leak 40MB of GPU memory. So we can save 20MB.

Also some of our previews have alpha channel which is useless.

In D4159#177320, @wraitii wrote:

Mh, would it really matter? The individual PNGs are about 160Kb each. At best we'd gain 1-2 MB total maybe?

Sure, in total we leak 40MB of GPU memory. So we can save 20MB.

In D4159#177317, @vladislavbelov wrote:

I think our previews are bad in terms of wasting space. They can be easily reduced to 512x256 without quality loss.

I think our previews are bad in terms of wasting space. They can be easily reduced to 512x256 without quality loss.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

swap out the known problems button for just the forums. GO back to old button size.

I don't mind a slight reduction in cost. Probably better to just remove metal cost and keep stone cost the same. Should then also include mil colonies. Balancing @StarAtt would be nice to get more opinions.

Works for me.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Added corrections

Just for my information, what is your reasoning behind putting it in Commands.js (the simulation) as opposed to in unit_actions.js (the GUI)?

Why keep the "Known issues" button? We got the FAQ button.
Since you have resized the buttons, it breaks the consistency with all other buttons, normally they are 28 pixels high. Except for the mapBrowser, there the size is 30 pixels.

Alright. I think I'll merge it as-is, IMO it's a significant UI improvement on the feature, and I see no way this can bug too badly.
The delay seems useful to me mostly to avoid the autoqueue training hundreds of units if you somehow end up in a situation where you can train units really fast, such as when cheating.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Fix inlines.

In D4154#177194, @Freagarach wrote:

Visually it is not really noticable.

No, it's the lack of sound that's mostly problematic.

I guess this is inferior to D4144?

Just for my information, what is your reasoning behind putting it in Commands.js (the simulation) as opposed to in unit_actions.js (the GUI)?

Visually it is not really noticable.
Isn't there a way to avoid this hack? I mean we would expect the animation to be on its end when we reach this condition, right?

Works nicely.
(I didn't perform an in-depth code review, merely superficial. But I'm accepting the idea (though I'd say the delay is not necessary).)

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Found the lobby bots mentioned in the licensing information for the tools and removed it there as well.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Update wrt D4135 and fix comment wording

In D4099#177045, @marder wrote:

When the max is 120 sec as in D4135 implemented, I wouldn't lower the cooldown (or at least not so much). It can get quite crowded otherwise. Maybe 4?

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Update with what I was actually trying to do.

Was fixed between A24 and A25

Definitely, something I'd love to see.

Also, it's hard to tell from this small number of gens, but it looks like there will now be at least 4 metal mines per every player. If so, that seems high to me.

It's about the same for 1v1s currently, 30-35k metal generated on average. Just sometimes the mines would really gravitate towards one of the players. For TGs being able to have about 3 metal mines per player is a great improvement. Too often I haven't been able to do anything fun with champs/mercs or even swordsmen because I've just no metal.

Successful build - Chance fights ever on the side of the prudent.

In D4148#177108, @wraitii wrote:

In D4148#177096, @chrstgtr wrote:

Personally, I like the randomness. [...] Based on the couple of gens you posted, I don't know if diverse strategies will necessarily be eliminated but it's something to consider when we start talking about being "fairer" and spacing things farther apart.

I agree, and I don't think this changes the randomness factor too much. In fact, it's why I added 'wildcard' mines that can be placed much nearer to other mines, to occasionally create some really good dropsites zones.

Also, it's hard to tell from this small number of gens, but it looks like there will now be at least 4 metal mines per every player. If so, that seems high to me.

Yeah, on looking back, I agree I overdid it :p.
The current mapgen is one large mine per player (starting mine) + A number between 4 & 16 depending on mapsize. A 'normal' map would get 8. The problem is that this scales poorly: in 1v1 on Small, you can expect 40K total metal. In 4v4 on Medium, you can expect 90K, so you go from 20K per player to a little over 11K.

These new settings will still give you 40K on a 1v1 Small, but instead of there being an additional 6 5K mines, there are 3 5K mines and about 6-7 mines of 2/3K metal. This lowers the chances of having not access to any metal beyond your starting base, though it might still not be a complete panacea.
On 4v4 Medium however, this bumps the metal to 140K, which is slightly less than you'd get on 1v1 but a lot more than on SVN. The mines are mostly 5K mines, so that you won't find metal everywhere either and there might be some good dropsite spots.

I've also made a quick change that Metal mines get generated before Stone mines. This should make the distribution slightly fairer, and should it be impossible to place some mines, the metal mines are likely to be placed and you might be missing stone, which seems less damaging on gameplay.

Successful build - Chance fights ever on the side of the prudent.

In D4148#177096, @chrstgtr wrote:

Personally, I like the randomness. [...] Based on the couple of gens you posted, I don't know if diverse strategies will necessarily be eliminated but it's something to consider when we start talking about being "fairer" and spacing things farther apart.

I agree, and I don't think this changes the randomness factor too much. In fact, it's why I added 'wildcard' mines that can be placed much nearer to other mines, to occasionally create some really good dropsites zones.

(didn't re-test, gonna resign, but this looks OK)

Feel free to accept, @Langbart. ;)

Personally, I like the randomness. It creates more diverse strategies (i.e., I see I have a lot of metal on this map, so I will go champs/mercs or I see there are three mines located in one spot, so I am going to invest in an early CC to get the good spot). The problem is that too often some players are blessed with massive amounts of extra resources while other other players have no extra mines. This creates the situation where map position becomes outcome determinative. Based on the couple of gens you posted, I don't know if diverse strategies will necessarily be eliminated but it's something to consider when we start talking about being "fairer" and spacing things farther apart.

It addresses the main problems like moving large groups from one wood line to another or sending large batches from your CC to a specific wood line. They don't get lost anymore and that is a good thing. I think you should commit it.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

In rP25767#53025, @Langbart wrote:

Created a diff: D4151

Make the bot happy with const

Looking good

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

CMiniMap: Use floats for flareLifetime and animationSpeed.
js: use a slider.