Up

Fixes so the linter can rest in peace.

In D4319#185357, @marder wrote:

@nani do you plan to patch the AI so this can be used in SP? For the regular wonder victory condition the AI tries to build a wonder.
If not, then a warning in the description would be necessary. I.e. : this does not work in Single player mode

Bumping, I think the patch is fairly complete and production ready. Any blocking issues left @Freagarach ?

@Freagarach do the new changes fix the issues?

Looks good to me.

Now the gamesetup properly shows the victory condition only if the map supports it. Some code cleanup on the remgen side, passed most of the wonder placement code to the map itself instead of trying to make generic solution. Solved all the pending concerns and tested it again, everything seems to be working. Note that this is backwards compatible with any map.

Up

In D4319#184167, @smiley wrote:

It's possible to make this work in the same way as AoE2 king of the hill mode. Not sure if that's desirable.

Relevant for this,

For now only mainland is compatible with this mode. A map will be considered compatible with this mode if it has the "SupportsCaptureTheWonder" : true in his setting's JSON or xml equivalent.

AoE2 maps always support it and they basically just place the wonder in the middle without much consideration. In water maps, a wonder sized island is created.

In D4319#183888, @wowgetoffyourcellphone wrote:

Any plans on using different wonders? Perhaps allow the biome files to determine Wonders.

@Stan any idea?

In rP25381#53216, @Freagarach wrote:

But I guess it is not enough, since @nani did not resign from this commit yet.

In rP25381#53200, @Freagarach wrote:

@nani has the autoqueue been adapted enough to your liking?

Tried it, I think it behaves as it should now. As I said before, we could add some negative characteristics like a % extra time to train an unit or something similar but that can be added with ease in the next alpha if in this one we detect the function is too overpowered (personally I think is not, but I like it because I have to click less and thus don't get my wrist all work up, see https://en.wikipedia.org/wiki/Carpal_tunnel_syndrome )

In D3687#166315, @Stan wrote:

Not sure what I did with ffm_visiblity but I got this

ERROR: JavaScript error: gui/gamesetup/NetMessages/GameRegisterStanza~badmod.js line 1 GameRegisterStanza is not defined @gui/gamesetup/NetMessages/GameRegisterStanza~badmod.js:1:1 onPress@gui/pregame/MainMenuItems.js:90:13 performButtonAction@gui/pregame/MainMenuItemHandler.js:77:9 pressButton@gui/pregame/MainMenuItemHandler.js:63:10

A commit changed the name of the class.

Why are the files names different from the class names? Makes search twice difficult.

In rP25381#52932, @wraitii wrote:

In rP25381#52929, @nani wrote:

Well, that makes no sense

As written, it does, it makes auto queue slightly worse than manual queueing.

The previous problem makes it worse when you want to delete the unit that is in training (or all the units in the queue) and the auto queue starts to add more units to queue before you can delete them.

That is more problematic, we probably de-activate the auto queue if the production queue is manually changed.

Creating ticket.

In rP25381#52928, @Stan wrote:

@nani Apparently it's intended so it's no OP.

Although the auto-queue works it has some pretty apparent broken functionality:

In D4009#172695, @Langbart wrote:

In D4009#172642, @nani wrote:

Maybe also a "last summary" button would be nice as is domething people always wan to check after the game and comment in the lobby

I can pass you the code for it here if willing

I added a 5th button, you can add the code to it. Would be great.

In D4009#172645, @Angen wrote:

isnt this too much buttons ?

Maybe also a "last summary" button would be nice as is domething people always wan to check after the game and comment in the lobby

In D4003#172444, @vladislavbelov wrote:

In D4003#172443, @nani wrote:

Doesn't the summary screen use z-index for some icons pretty extensibly? the same for the tech tree, the barter dialog and the teams dialog in session.

z-level != z-index, the latter one is used for the mentioned objects.

Doesn't the summary screen use z-index for some icons pretty extensibly? the same for the tech tree, the barter dialog and the teams dialog in session.

In D4003#172426, @vladislavbelov wrote:

In D4003#172422, @Imarok wrote:

I guess this issue is old:

Yes, it's pretty old. Since we don't know how to draw text there properly. Because "borders" are not real borders but a single background texture. And for a single texture you need to crop the text, but there is no information about the "border" width. So the simplest solution is to split the single texture into background and borders to draw them after the text.

In D3985#172035, @wraitii wrote:

Unfortunately, proper scrolling in the GUI is not possible for now because the GUI renderer won't support it. It needs more fundamental changes before that becomes possible.

In D3532#169361, @wraitii wrote:

I find myself agreeing with @nani - this would be convenient.
However, what I would do is that 'Enter' when the input box is in Focus selects the first grid item, and then 'Enter' again actually submits the selection (so you can also navigate - which may or may not work itself, don't recall).

@Freagarach: I can try and take over for you, I'm more familiar with this code than you are.

As for if we should check what the mods changes, I think @wraitii is right that we should just let the user and creator decide for themselves.
Trying to analize if the mod is OOS safe is IMHO a waste of time as there a many way to mod and it would be a frustration more than anything else.
Maybe there could be a notice for mods with "compatibleMods" true or the engine could analyze what folders the mods touches but I think with the notice alone should be enough.
Also a notice if the host or someone else is using an extra mod would be a good idea.

Is intended for those who don't overwrite the parent setting, which means is intended.

You might want to add some hotkeys for this.
I suggest these ones I already use that I think work well:
Alt+q to enable auto queue
Alt+w to disable auto queue

@Freagarach this D3833: Map browser: input filter, also filter random map entry

(I add this code to the folder /simulation/components and /simulation/helpers/ )

@wraitii testing this on a casual multiplayer game gives me that the most expensive simulation update looks to be on the component timer.update and all the handlers is has to process , maybe this will help find a way to finally find why javascript has this terrible simulation performance

@DanW58 what happened? This diff looked so promising would be a pity to be left to accumulate dust.

At first glance seem to work as advertised, testing different hotkeys doesn't produce "retriggers" anymore. Haven't look at the code. Functional part of the diff: accepted.

In D3767#163832, @wraitii wrote:

In D3767#163831, @nani wrote:

What if the user defines his own custom hotkeys in user.cfg which you didn't specify in GUI/hotkeys/spec/**.json. I know I'm stretching the limits but will they be deleted?

Only if they're empty/unmapped.
It seems to me you're trying to get at some feature of your mod to automatically create hotkeys or something like that? One option would be to write a JSON file with the hotkeys from your mod code (it'll get written to the user mod, but that's fine).

If you actually need this feature, I could also make it more configurable that empty hotkeys get deleted.

What if the user defines his own custom hotkeys in user.cfg which you didn't specify in GUI/hotkeys/spec/**.json. I know I'm stretching the limits but will they be deleted?

I'm even more confused now, where are things stored, how are they handled, there seems to be at least 3 independent places where hotkey config is being modified and stored.

Should 'Down' still be sent? This is the 'repeating' event.

In rP23701#50076, @bb wrote:

That is a feature not a bug. Keydown should repeat, keyPress should fire just once. StopUnits has been explicitly discussed to be keyDown (hence repeating), (One reason being ungarrison, another being units going the attack)

KeyDown event still keeps being called after being pressed down.
Example: add a warn inside stopUnits functions and see how it repeats.

Good option to add nonetheless.

In D3737#162862, @wraitii wrote:

In D3737#162860, @nani wrote:

Given this is not a technical issue but gameplay decision maybe would be better do a poll in forums?

I'll just add a config option that defaults to "wait for observers" for now.

Given this is not a technical issue but gameplay decision maybe would be better do a poll in forums?

What if the host is an observer? Host should then always be on sync.
I am aginst this as a default, it will break the experience of observing games online and make everyone confused.

As is it now, this looks like a frankentrain mixed with the two old systems that still linger in the gamesetup code.
I suggest to try it on an simpler case instead of going for the last boss, for example the options page looks like an easy candidate to change and fom there we can feel how it would translate to other more complex pages like gamesetup once we have the idea flesh out.

In D2936#157392, @OptimusShepard wrote:

I made a new battle profile map and profiled it.

Vanilla

Limited to 100 corpses

Limited to 50 corpses

profil_data.zip4 MBDownload

skirmishes.zip108 KBDownload

(D3554 is needed)

You need an ordered set by insertion, all the others options are just doing the same with extra steps. Maybe you can skip the set and do a linked list if you can guarantee no insert repetition.

Maybe change default map size for random maps to "Medium" then?

In D3532#155200, @Freagarach wrote:

Ah, I'm not sure how to fix that, @nani.

Works perfectly now.

Tested it, now there is no lag for clients. You can lower it to 200 ms so is more responsive (the lag starts when you send more than 30 network messages per second so 200 ms >> 1000/30 ~ 33.33 )
The host still lags as it updates his GUI state on its own so it should have another debounce for it somewhere (idk where but the profiler (F11) says updateGameAttributes is the culprit) for that and a debounce of 50 ms should be fine.

Should'va ve said sooner :(

I don't know if I clarified enough in the forum post but what I meant was having the confirmation hotkey trigger when you press enter while searching with the text input functionality and if you press Enter then it selects the first result for you. The idea was that when you are doing a search by name you don't need to leave/move your hands from the keyboard and directly hit enter without the need of mouse interaction and then leave the case for mouse interaction for when doing a more visual search exploration.

In D2805#119475, @wraitii wrote:

• nani said there was something about possible Z issues

@nani < input?

Fair enough. Then I pass the commander to you if you want to try the grid approax.

std::array bool doesn't do bitpacking and its size must be known at compile time ( < c++2020 ), std::vector allocates in the heap. current diff has many more chances than a more extensive refactor + upgrade to have less bugs. Is practically guaranteed same performance as previous because it doesn't leave to chance the optimisations that the compiler should make (is basically a wrapper of some operations and data encapsulation). So I don't see an extra benefit changing current diff to using grid.

Adding wraitii as it might interest him.

Not sure of this change. All the other siege units also do a similar damage to regular units and the cost is the same and this change would mean a great disadvantage compared to other siege units. Also in this case the bonus should also apply against other siege units.