Jump to content

wraitii

WFG Programming Team
  • Content Count

    2,745
  • Joined

  • Last visited

  • Days Won

    40

wraitii last won the day on September 20 2019

wraitii had the most liked content!

Community Reputation

1,281 Excellent

2 Followers

About wraitii

  • Rank
    Space Poodle

Profile Information

  • Gender
    Male

Recent Profile Visitors

2,708 profile views
  1. 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 .
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. Agreed. Pikemen and such, when gathering, aren't supposed to be burdened by their heavy armour anyways (since we show them not having it), so their regular walk speed should be basically identical. Only when in special 'formation' mode should they possibly be slower. Champions are a different deal.
  9. At some point we need configuration files to specify what to show directly, what to show in the tooltips, what to show in the Structure Tree.
  10. Yeah we need to rework the tooltips for sure. Adding some grid-like structure would definitely help a ton with readability, but the flexibility of the game's system make that difficult to get right. I think one thing we should do is take more vertical space, so that items are better separated, and then you can find the same info on the same vertical line. You might also note that HP is actually redundant with armour somewhat, since having more armour = having more HP for that attack type. One should find a few different cases for tooltips that are different and try and work something out that works OK for the general case.
  11. I have this idea, that I should flesh out in a mod, of having civilisations "Tiers", and only trying to balance inside intra-tier, not extra-tier. That would allow for more diversity imo, while still allowing balanced gameplay.
  12. With the phenotype system, we could have lefties and righties (probably not the best use of the system though)
  13. To be honest SVN doesn't really work that way right now + we don't really have spear-specific upgrades. This is just a good example of how your mod handles things differently.
  14. Another breaking change: rP22824 See commit message (or diff) for the changes.
×
×
  • Create New...