wraitii

I think it would be _awesome_ to do a UX-oriented review of our GUI and our screens.

I think you just have to iterate over it, or use some set-functions: https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/Set

I think for techs and such, it might be because they're using a Map() object which doesn't print much when printing it?

This looks interesting As one of the older AI devs (Mostly on Aegis, which was the intermediate between qBot and our current Petra), I think you might want to focus on a single bot with configurability. Improving capabilities and having distinct personalities are somewhat orthogonal concerns. I see two options for getting this in-game: - Propose incremental changes as patches. - If the bot becomes impossibly different, you can always request that we package yours alongside Petra at some point once it's stable enough.

Thanks for reporting this, I did miss this case. See D2894 for a fix.

Hello all, I'm making this thread public - I probably should have done so from the get go. This is my idea on how we can get out of the balancing tarpit.

Are you using a QWERTY-English setup? I have to say I haven't tested all hotkeys, but I'm plying on a french keyboard and they're mostly borked because of the Azerty layout. We do need to fix it though. More work for A 24

That seems logical, the doc indicates that content scaling is not applied automatically when running a GL viewport:

I think @Itms will agree that we probably should move incrementally anyways, if only to make sure we aren't missing something that will come back and haunt us. The work will likely not be repeated too much regardless.

Agreed that it looks like z-fighting in the shadow map (this sounds more epic than it is btw :p ) Did this never happen before? Is that just on this one map? What happens if you lower the shadow quality settings?

This is fixed with https://code.wildfiregames.com/D2788

I've fixed the assertion here: https://code.wildfiregames.com/D2788

Hello & welcome to the forums Is there any chance you could give a try to http://code.wildfiregames.com/D11 ? It's a patch that adds a campaign screen, and you should be able to fairly easily make a campaign that starts your scenarios in order.

You need to do a right click, which you should be able to do by clicking with two fingers on the trackpad.

Hello Gameboy, thanks for the report and replay I'll revert these changes momentarily and fix the issues with the patches.

Hey, thanks for reporting this. I'll revert the changes and fix the issues in those cases.

@wik : aye that's actually just caused by my unfinished patch . As written here https://code.wildfiregames.com/D2752 "I haven't yet bothered to reimplement "renderer incremental loop". If you start the actual game a few times, it'll populate your cache and the issue will be fixed.

Seems to me you've been sent from above to fix WxWidgets bugs, wik . If you want to, you can make a patch on Phabricator, see SubmittingPatches and Phabricator .

I think this is a know bug on all platforms. @Stan`?

Aye, I expected that. Investigating: there is actually a rather old, still open ticket about this "return false"change: https://trac.wildfiregames.com/ticket/2427 . It seems to have been a hack if I'm being honest. I'm not too sure what's happening exactly, but somehow wxWidgets end up with double-events. On that specific, I feel like we should return true here. Perhaps SDL2 fixed something. It's definitely related to windows, anyways. On to "how to fix the text" -> Based on the WxWidgets doc, we will get keydown/keyUp events and also, for text, special "Char" events that contain "translated" test, i.e. shift+a returns "A" instead of "a". When a key is pressed, it ought to send both a KeyDown and a KeyChar event. What we do is skip the keydown event for chars > 256 (i.e. non-ascii) and use KeyChar instead. The pushing of event is done in ScenarioEditor.cpp, and the handling of messages here. Based on a cursory reading, this should all work, so what goes wrong? Well, the comment here seems accurate. CInput, the class responsible for input fields in the 0 A.D. GUI, also processes these "translated" events _> In fact historic_bruno did that change. But as you can see in the atlas Message handler, we do a "keydown/keyup" thing, which won't work -> the game expects a TextEditing message. Based on the SDL2 doc, it seems TEXTINPUT is when the text is "committed", i.e. should be stored, while TEXTEDITING is while text is "going on". This doesn't make much sense in English, but think Mandarin where multiple characters can merge into one glyph (actually, there's an SDL wiki page for that) It seems WxWidgets doesn't really expose this low-level stuff, so all we get is the "end" character. So I think you should be able to simulate a SDL_TextInputEvent instead of an SDL_TextEditingEvent.

I think I "cmd-tab cmd tab" to get the focus back into Atlas. It's not impossible that we have some outdated settings in WXWidgets, the "return false" here is indeed rather suspect. If that also fixes the double key input it's pretty good. Can you delete text? In A23 it's also messed up. Can you input text if you "start'" the simulation? Edit -> That being said, there might be something else to do, given the fact that we are supposed to use SDL2 for events, so I don't really know.

I'm assuming we don't have a window because WxWidgets is providing the window. That being said, this might now be buggy. Thanks for the investigation, I'll try and give this another look next week.

I failed to read your post and found a different solution in https://code.wildfiregames.com/D2752, but I suppose people will prefer your fixes for being less disruptive. I'll make a diff with your changes too. Thanks for reporting and debugging this. I report text input as working "correctly" if launched from in-game (as in, it's broken as it is on 10.14 with the double character thing). Edit: mh, pathching wxwidgets though.

Sadly that code is from @mimo and I've never looked at it. WRT to work, I invite you to post a patch on Phabricator at https://code.wildfiregames.com

Two ways to fix this: - fix the purely graphical issue. This is probably easy enough to do. - make entities visible as soon as some of it is out of FOW. That's likely trickier, but I'd have to check the implementation. Either way, I don't think a flag makes too much sense, though thanks for pinging about the issue, I'd forgotten about it.