(Anyone else thinks merging building hotkeys and training hotkeys is a good idea?)

In D1763#71070, @vladislavbelov wrote:

In D1763#71069, @smiley wrote:

(Re: ssize_t to size_t
I thought that this was discouraged since it can introduce subtle bugs.
Google's C++ style guide also mentions something like this)

Yeah, we discusses about it yesterday with Stan. The problem is that ssize_t is used as size_t in some places.

(Re: ssize_t to size_t
I thought that this was discouraged since it can introduce subtle bugs.
Google's C++ style guide also mentions something like this)

I think the same problem exists with some playernames in the lag-warnings area too.

It won't exist there as the width check is done in that specific case.

Removing one arbitrary number with another arbitrary number can fix this.

Index: binaries/data/mods/public/gui/common/functions_global_object.js
===================================================================
--- binaries/data/mods/public/gui/common/functions_global_object.js	(revision 21929)
+++ binaries/data/mods/public/gui/common/functions_global_object.js	(working copy)
@@ -17,9 +17,9 @@
 	dataCounter.caption = counters.join("\n") + "\n";
 	dataCounter.hidden = !counters.length;
 	dataCounter.size = sprintf("%(left)s %(top)s %(right)s %(bottom)s", {
-		"left": "100%%-100",
+		"left": "100%-110",
 		"top": "40",
-		"right": "100%%-5",
+		"right": "100%-5",
 		"bottom": 40 + 14 * counters.length
 	});
 }

However, this would also break given a lengthy enough string. The correct solution would be to adapt the sizes based on the width of the longest string just as how it's done for the network warning thingy. Engine.GetTextWidth(font, string) IIRC.

(One can argue that something worse than an inconsistent code base is inconsistency within a single file. But then again, such arguments are probably what led to this situation in the first place)

Due to the lack of context I can’t be sure, but is the variant reset upon leaving the state?

Why this does not led to the issue before the commit that has the concern raised?
Previously, the sizes of the two panel would be adjusted onTick in updateSettingsPanelPosition.

let settingsBackground = Engine.GetGUIObjectByName("settingsBackground");
let backgroundSize = settingsBackground.size;
backgroundSize.left = settingsPanelSize.left;
settingsBackground.size = backgroundSize;

But now, if the offset is 0, that code would not be reached.

Could be a lot for people who save their games quite often.

(*Fork AD. No 0)

*commit archeology intensifies*

I suppose the AI is not receiving this message because IIRC it only receives those that it explicitly copies.

I don't know whether this is an oversight or intended behavior that a Vector will be holding strings. If it's the latter, then it should not mutate the vector but return a string. Warrants a concern whichever one it may be IMO.
Also, the inline comment highlights the result of what the current code can do for someone caught off-guard.

(Obligatory comment about num_clients/num_cities * 100 and how the current approach seems so wasteful even after ignoring player distributions and whatnot.)

(mail)

Lat/lon and distance is probably too much. An individual possessing the skills necessary to do it doesn't warrant making it available for the masses.
Although, I guess everyone knows how to look at a map and find the flag of the country in the list. Which raises the same "concern" about city.

In D1251#70539, @Stan wrote:

Wouldn't hurt to have this. What is missing ?

In D1688#70268, @smiley wrote:

I guess MapReader should do the same check before placing an entity.

(One might say that the info is badly placed. The better place would have been the gamesetup config pop-up itself. But that’s out of scope.)

(The patch is still here and can be commited if you want)

I would also like to apologise for the misunderstanding earlier. It wasn’t meant to say “your patch sucks”. It was meant to point you at the underlying bug without conflicting with the game design.

This should be commited before upgrading to whatever SM version corresponds to FF58.

This diff is with changes to the shape of the harbor to minimise perfect circles ftw. If that’s bad, I am sure there would be a DiskPlacer changed to ClumpPlacer somewhere.

I guess MapReader should do the same check before placing an entity.

I am like 93.24% sure this issue would exist in another form in at least one other map.

Doesn’t seem like the current gameplay design needs this.
Regarding the patch itself if a modder is interested.
It’s missing a max check.

The concerns I raised seems to be fixed. At least the id one. IDK about the _string one.

Add yourself to binaries/data/mods/public/gui/credit/programming.json. I might have messed up that path.

Usually when we pass a failFraction, we mean the amount of the intended area, so that the shape generated by the placer remains intact to the specified degree IIRC.

Not exactly how I had thought of it. I assumed it was more of tolerance. That's the closest word I could think of.

Still not convinced of that model. Priority being a tile property, it should be handled in rmgen as such.

MiniPatch.h which from what I have seen is the lowest level. I.e a single tile.

I never checked the map generation side of things. Only checked it’s type in tile defnition which is int.

As mentioned in the ticket, this is how the other placer does it and it’s nice to have some consistency. Also, the comment seems to suggest this is what the original author intended. Finally, as you have mentioned, it doesn’t really make sense to compare failed attempts with the size as opposed to the number of attempts.
The patch is correct.
At least now it would be stuck in some other queue.

It's also unnecessary to keep on going when failed exceeds the threshold only to discard the points later. But that is out-of-scope.

The one with the numbers up there show it already. Compare left vs right.

perhaps areas could also contain one area that does not contain any points (a placer with an according failFraction)?

Techincally (not logically), an area with 0 points is still an area, no?

One might argue that the current code is correct. Who's to say the author didn't meant to make failfraction be dependent upon the clump size rather than the number of attempts?

(Traders also are not updated when a market renames if one wants to go all the way)

Better blending. Generate a map like a African_plains, you would see what I am talking about. Straight lines, squares and whatnot.

Looks good. Tested with all combinations of wonder and non-wonder upgrades.

Take care of inline comments and use an early return.

Sounds like a neat system we got over here.

From a quick look at the AI files.

witch (data.attribs.mapType)
 		{
+		case "random":
+			loadingMapName.caption = sprintf(translate("Generating ΓÇ£%(map)sΓÇ¥"), { "map": mapName });
+			break;
+		
 		case "skirmish":
 		case "scenario":
+		default:
 			loadingMapName.caption = sprintf(translate("Loading ΓÇ£%(map)sΓÇ¥"), { "map": mapName });
 			break;
-
-		case "random":
-			loadingMapName.caption = sprintf(translate("Generating ΓÇ£%(map)sΓÇ¥"), { "map": mapName });
-			break;
 		}

From the raw diff. That doesn't look good.

JS only provides the one JS Number type and typed arrays.
I suppose you wanted the performance benefit.

I meant unsigned as opposed to signed.

What?

Simplest case I could think of; if we wanted to paint a 2x2 square with a low priority, the first tile would have -1, the next one -2 and so on. This is unnecessary when the whole square could just have had -1. (as Atlas does it)

The current implementation is pretty bad compared to Atlas. Unlike atlas, whats written now would have priority values which are unnecessary and all over the place. Especially when painting a large enough area. The values would have a chain-effect which would keep on incrementing/decrementing.

This should be exculsive to single-player.

Add filter to getPointsInBoundingBox and use that.

ping

Fix over/under flows.
Numerical priority.

Yes there is. I assume this is coming from the same roots as the health or capture bar.

Rename the function to what @bb proposed.

Is it really how god intended it though?
However I think a spear cav not being promoted at 149.9999997/150 is absolutely not what was intended.
I was under the impression that such things should be real numbers.

I mean it never was constant/read-only since we change it on the JS-side?

It’s not changed in JS AFAIK. The exposed function changes the internal C++ variable, not the exposed JS variable. At least that’s what I recall.

(Might want to ask who ever maintains the WFG servers whether this is something that is affordable space wise)

In D1724#68325, @Stan wrote:

Have you checked if there is any other occurence of such a code ? I think I've seen that syntax used multiple times.

In D1589#66440, @elexis wrote:

Perhaps instead of an object with 2 properties or an arry with 2 items, it would even be cleaner to use a function / constructor with 2 arguments (texture, entity = undefined), like using SimpleTerrain or RandomTerrain which receives an array of SimpleTerrain?

Worth having?

Might re-claim it in the future. But in the mean time.

Re: AI
With current behavior, not sure how such a thing could be done in an acceptable way. The quick and easy fix could end up being too unfair. People could attack the AI only to find it having the perfect army. An alternative option is to rely on past attack compositions. Which would of course allow people to “play” the AI. I guess the only sane option is to finally implement scouting.

Just output diff to a file, manually edit the thing and use web ui. That’s what I do in such situations.

In D1718#68039, @elexis wrote:

Flesh doesn't stop rotting and flora/fungi don't stop growing while gathering from them?