--- Log opened Thu Jun 22 00:00:09 2017
20170622 00:15:37< irker272> wesnoth: Victor Sergienko wesnoth:master fd9f1153f74d / src/formula/function.cpp: fix #1763: crash in "poisoning" Formula AI (#1770) https://github.com/wesnoth/wesnoth/commit/fd9f1153f74da77f86f8732a7191c457c6ea4ac5
20170622 00:19:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170622 00:21:24-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 255 seconds]
20170622 00:21:38-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170622 00:31:10-!- horrowind [~Thunderbi@p2003008E6C0B2659964452FFFE0220ED.dip0.t-ipconnect.de] has quit [Quit: horrowind]
20170622 00:39:57-!- travis-ci [~travis-ci@ec2-54-82-70-90.compute-1.amazonaws.com] has joined #wesnoth-dev
20170622 00:39:58< travis-ci> wesnoth/wesnoth#14319 (accelerated_rendering - 3d23a6d : Charles Dang): The build has errored.
20170622 00:39:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/245525731
20170622 00:39:58-!- travis-ci [~travis-ci@ec2-54-82-70-90.compute-1.amazonaws.com] has left #wesnoth-dev []
20170622 00:47:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170622 00:47:51-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170622 01:05:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 01:09:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20170622 01:35:11< vultraz_iOS> blahhhh
20170622 01:35:19< vultraz_iOS> so much messy custom code to draw the in-game UI..
20170622 01:36:24-!- dragonofair0 [~dragonofa@2601:600:a280:7a31:606a:867a:8aa:e2f9] has joined #wesnoth-dev
20170622 01:37:03-!- dragonofair0 [~dragonofa@2601:600:a280:7a31:606a:867a:8aa:e2f9] has quit [Remote host closed the connection]
20170622 01:38:56< vultraz_iOS> the proper solution here would be to use GUI2, but...
20170622 01:40:17< vultraz_iOS> A. I don't have the precision I need to place things just so, and B: i haven't dealt with the modeless dialogs not drawing
20170622 01:41:27< vultraz_iOS> oh god dammit 
20170622 01:41:37< vultraz_iOS> gfgtdf why did you have to do all that resolution stuff
20170622 01:41:42< vultraz_iOS> you messed up everything >_>
20170622 01:48:57< celticminstrel> What's this about precision?
20170622 01:51:47< vultraz_iOS> celticminstrel: you can't position things exactly with GUI2
20170622 01:51:52< celticminstrel> Sure you can.
20170622 01:52:35< celticminstrel> I think it's the .place() function.
20170622 01:52:41< vultraz_iOS> not from WML
20170622 01:52:56< celticminstrel> It should be relatively easy to create a widget that lets you place children at arbitrary locations.
20170622 01:53:08< vultraz_iOS> GOD DAMMIT GFGTDF
20170622 01:53:22< vultraz_iOS> his changes are making everything use low-res definitions here
20170622 01:53:43< celticminstrel> I'd love to revert his resolution changes, but unfortunately he did at least address my most fundamental objection to them...
20170622 01:53:55< celticminstrel> Wait, why are they making everything use low-res definitions?
20170622 01:54:50< vultraz_iOS> DPI virtualization gives me an effective res of 1536x801
20170622 01:54:58< vultraz_iOS> (which is what I'd have at 96 DPI)
20170622 01:55:23< vultraz_iOS> i guess he didn't update size specifications for things like the addon manager
20170622 01:55:24< vultraz_iOS> lobby
20170622 01:55:28< vultraz_iOS> dropdown menu
20170622 01:55:38< celticminstrel> ...dropdown menu has low-res definitions?
20170622 01:55:52< vultraz_iOS> you make it narrower
20170622 01:56:05< celticminstrel> 1436x801 shouldn't trigger low-res definitions for most things.
20170622 01:56:15< celticminstrel> You might get the middle definition for MP Create.
20170622 01:56:59< vultraz_iOS> no, i get the proper one for Create
20170622 01:57:22< vultraz_iOS> i mean, i was getting the low-res titlescreen panels until he updated (though I haven't pulled that change yet)
20170622 01:59:09< vultraz_iOS> i guess you're right about using the place() function with a custom widget
20170622 01:59:32< vultraz_iOS> still, i need to figure out how to get modeless dialogs drawing
20170622 02:01:56< celticminstrel> If you mean overtop of the main game UI, I really think it's a waste of time.
20170622 02:02:02< vultraz_iOS> why?
20170622 02:02:25< celticminstrel> Because all that work will be rendered irrelevant as soon as the main game UI is GUI2.
20170622 02:02:40< vultraz_iOS> that's... the point :|
20170622 02:02:43< vultraz_iOS> I can't make it GUI2
20170622 02:03:06< irker272> wesnoth: Celtic Minstrel wesnoth:gui2_floating_textbox 916f8f63caf4 / src/ (9 files in 2 dirs): Use GUI2 for floating textboxes (WIP) https://github.com/wesnoth/wesnoth/commit/916f8f63caf44f881661f5797264ac3d37d1a830
20170622 02:03:08< irker272> wesnoth: Celtic Minstrel wesnoth:gui2_floating_textbox 6d8e44a4f0db / / (9 files in 5 dirs): Try floating textbox as popup instead of a standalone widget https://github.com/wesnoth/wesnoth/commit/6d8e44a4f0dbb9d756542feb37c1bf662065bc90
20170622 02:03:10< irker272> wesnoth: Celtic Minstrel wesnoth:gui2_floating_textbox 185fca8444a0 / / (4 files in 2 dirs): Misc WIP https://github.com/wesnoth/wesnoth/commit/185fca8444a003b733479ba06cb7aafc73661e60
20170622 02:03:17< celticminstrel> ^ That's my attempt at it, in case you want to take a look.
20170622 02:03:25< celticminstrel> It's old, but maybe it'll be helpful nonetheless.
20170622 02:03:37< vultraz_iOS> because unless its modal it will stop things drawing
20170622 02:03:42< vultraz_iOS> er
20170622 02:03:47< vultraz_iOS> unless it's modal it won't draw
20170622 02:03:52< celticminstrel> I think it's a waste of time, but I guess it's up to you if you want to insist on attempting it.
20170622 02:04:11< vultraz_iOS> why would it be a waste of time to make the main game UI GUI2 :|
20170622 02:04:15< celticminstrel> Not that.
20170622 02:04:33< vultraz_iOS> then what!
20170622 02:04:35< celticminstrel> I think it's a waste of time to make the floating textboxes GUI2 before making the main game UI GUI2.
20170622 02:04:50< vultraz_iOS> the main game UI would need to be modeless!
20170622 02:04:56< celticminstrel> Uh, no?
20170622 02:05:03< vultraz_iOS> uh
20170622 02:05:06< celticminstrel> The main game UI would be either modal or neither.
20170622 02:05:06< vultraz_iOS> ok I'm confused
20170622 02:05:07< vultraz_iOS> explain
20170622 02:05:39< celticminstrel> Where "neither" indicates my earlier proposal to just take the window and call show() on it directly, rather than using the modal_dialog or modeless_dialog class.
20170622 02:05:49< celticminstrel> Which part is confusing you?
20170622 02:05:51< vultraz_iOS> what???
20170622 02:07:05< celticminstrel> ?
20170622 02:07:07< vultraz_iOS> the main game map is not using the GUI2 API. It's all on its own.
20170622 02:07:17< celticminstrel> Yes, I know that.
20170622 02:07:20< vultraz_iOS> I had envisioned the sidebars, etc, being GUI2 whatevers drawing on top of the map
20170622 02:07:28< celticminstrel> Ah, well um.
20170622 02:07:52< celticminstrel> That's not likely to be any more successful than the GUI2 floating textbox that I attempted in my branch that I just pushed for your persual.
20170622 02:08:07< celticminstrel> Making the main game UI GUI2 though implies that the map is also part of that GUI2 interface, not behind it.
20170622 02:08:20< celticminstrel> At least, that's the implication that I intended when I said it.
20170622 02:08:51< vultraz_iOS> Well, that's what I originally thought to
20170622 02:09:13< celticminstrel> IIRC, that means a GUI2 version of game_display.
20170622 02:09:30< vultraz_iOS> But jyrki said the main map shouldn't be part of the GUI2 subsystem
20170622 02:09:34< celticminstrel> Ah.
20170622 02:09:44< celticminstrel> ISTR Aginor saying that it should be.
20170622 02:09:51< celticminstrel> But I actually have no strong opinion about this.
20170622 02:10:10< vultraz_iOS> I'm really not sure the best way to do it
20170622 02:10:27< celticminstrel> So if you really want to dig into the event system and figure out why GUI2 modeless dialogs over the map are not receiving events, then go right ahead.
20170622 02:10:56< vultraz_iOS> Have a [game_map] widget that hooks a DRAW event into the dispatcher and draws the map in its area and hooks into other events instead of using do_gameloop?
20170622 02:11:14< celticminstrel> If you get it working, feel free to cherrypick/merge that branch that I just pushed and see if that also works.
20170622 02:11:21< celticminstrel> Yeah, sure/
20170622 02:11:28< celticminstrel> That's a possibility.
20170622 02:11:54< vultraz_iOS> But what would mean pulling all the game event logic into GUI2
20170622 02:11:55< celticminstrel> Porting do_gameloop does seem like it might be a huge pain though.
20170622 02:12:09< celticminstrel> I'm not sure.
20170622 02:12:34< celticminstrel> The main game UI uses the MVC pattern.
20170622 02:12:45< celticminstrel> Porting to GUI2 means just substituting the V.
20170622 02:13:13< celticminstrel> It's probably a poorly generalized MVC, so substituting a different view is probably not as easy as the pattern would make it in an ideal case.
20170622 02:13:41< celticminstrel> But that implies that, for example, you can keep all the M (things like game_board, I think; not quite sure) and C (the player controllers and such).
20170622 02:14:25< vultraz_iOS> FTR I did activate some code in the dispatcher that makes GUI2 join the main event context or something
20170622 02:14:28< celticminstrel> If I recall correctly, the core class for the old view is game_display.
20170622 02:14:40< vultraz_iOS> whatever it does, it allows animated terrains to draw under modal GUI2 dialogs now
20170622 02:14:45< celticminstrel> Okay, and are your modeless dialogs now receiving events?
20170622 02:15:08< vultraz_iOS> I don;t know
20170622 02:15:49< vultraz_iOS> modal dialogs call events::pump in a loop
20170622 02:15:54< vultraz_iOS> modeless ones do not
20170622 02:16:38< celticminstrel> pump isn't really anything to do with this.
20170622 02:16:45< celticminstrel> The main game loop also calls it, anyway.
20170622 02:16:57< vultraz_iOS> uhhh
20170622 02:17:02< vultraz_iOS> yes
20170622 02:17:05< celticminstrel> To test if your modeless dialog is receiving events, why not try connecting some signals and see if they work?
20170622 02:18:39< celticminstrel> Though, if the dialog is drawing at all, it's probably receiving events.
20170622 02:18:56< vultraz_iOS> it draw for one frame
20170622 02:19:05< celticminstrel> Ah, so it's not receiving events then, I think.
20170622 02:19:16< vultraz_iOS> because events::pump controls everything
20170622 02:19:24< vultraz_iOS> that *sends* events 
20170622 02:19:51< celticminstrel> Though, you could still try connecting a mouse click signal, for example, to see if other events work.
20170622 02:21:27< vultraz_iOS> i wish we had a model where events were dispatched as soon as they hit the queue
20170622 02:22:39< celticminstrel> And how would that solve this?
20170622 02:23:31< vultraz_iOS> i dunno
20170622 02:24:56< celticminstrel> Can I merge tad's PR?
20170622 02:25:40< vultraz_iOS> up to you
20170622 02:26:04< vultraz_iOS> it seems the event loop itself is what stops map scrolling..
20170622 02:26:11< vultraz_iOS> obviously i haven't unified the contexts enough
20170622 02:26:31< vultraz_iOS> though TBH i understand nothing about all the events "contexts" aginor set up
20170622 02:27:31< vultraz_iOS> it is greek
20170622 02:27:41< irker272> wesnoth: Gregory A Lundberg wesnoth:master 468f07364e2a / data/lua/wml-flow.lua: Bug in [for] missing step https://github.com/wesnoth/wesnoth/commit/468f07364e2add38d09e5439ad3dab070a1ffc55
20170622 02:27:43< irker272> wesnoth: Gregory A Lundberg wesnoth:master eaccef65f840 / data/test/scenarios/test_for_tag.cfg wml_test_schedule: Add WML unit tests for [for] tag https://github.com/wesnoth/wesnoth/commit/eaccef65f840636a163c5e6ae9d9feb2831db7b0
20170622 02:27:45< irker272> wesnoth: Celtic Minstrel wesnoth:master 03cb2454b5c2 / data/lua/wml-flow.lua data/test/scenarios/test_for_tag.cfg wml_test_schedule: Merge pull request #1812 from GregoryLundberg/GL_for_bug https://github.com/wesnoth/wesnoth/commit/03cb2454b5c25e98f143d8089e36d6fe861c6fe2
20170622 02:29:08< celticminstrel> Anyway, if you wanted to look at the gui2_floating_textbox branch, now you can.
20170622 02:29:55< vultraz_iOS> you aren't really helping :|
20170622 02:33:41< celticminstrel> Not sure how much I can help.
20170622 02:34:44< vultraz_iOS> help me figure out the best design :|
20170622 02:35:34< celticminstrel> Well, first of all, stick with the existing MVC and just substitute V.
20170622 02:35:46< vultraz_iOS> *what MVC*
20170622 02:35:54< celticminstrel> ...
20170622 02:35:56< celticminstrel> The main game?
20170622 02:36:22< vultraz_iOS> *What does that encompass*
20170622 02:36:37< celticminstrel> Like what classes?
20170622 02:38:54< vultraz_iOS> play_controller owns a unique_ptr<game_display>
20170622 02:39:00< vultraz_iOS> game_display inherits from display
20170622 02:39:37< celticminstrel> (game_)display is basically the view, if I understand correctly; so that's what you'd need to replace.
20170622 02:40:15< vultraz_iOS> First we need to decide *what* the type of design we want is
20170622 02:40:30< vultraz_iOS> forget the existing code
20170622 02:40:33< vultraz_iOS> existing code can be changed
20170622 02:40:44< vultraz_iOS> what would be the *optimal* design
20170622 02:41:14< celticminstrel> In my opinion, this is actually a very good place for MVC. Thus, I'm recommending you leave the MVC intact.
20170622 02:41:33< celticminstrel> It's the MVC that enables the editor and main game to share so much code, for example.
20170622 02:41:34< vultraz_iOS> *groans*
20170622 02:41:51< celticminstrel> I don't think a rewrite that ditches the MVC would be any better at that.
20170622 02:42:03< vultraz_iOS> ok, when you say replace it
20170622 02:42:09< vultraz_iOS> replace it with *what*
20170622 02:42:16< celticminstrel> A GUI2 window.
20170622 02:42:42< vultraz_iOS> ok let's put that aside for a minute
20170622 02:43:30< vultraz_iOS> we need to decide how much we want the UI - ie, GUI2 - to be involved here
20170622 02:43:52< vultraz_iOS> remember, the UI has its own entire dispatch system
20170622 02:46:00< celticminstrel> I imagine that dispatch system could be linked up to all the normal game events, though.
20170622 02:46:02< vultraz_iOS> I'm trying to imagine what a GUI2 window gamescreen would look like
20170622 02:46:14< celticminstrel> That said, it might be a lot of work to do so.
20170622 02:46:41< celticminstrel> On the other hand, how would you make a GUI2 main UI without including the map in it?
20170622 02:47:07< celticminstrel> Can you make an irregular dialog with a transparent portion that sends mouse / touch events through to the map?
20170622 02:47:33< vultraz_iOS> don't want to do that
20170622 02:47:40< celticminstrel> You could make two separate dialog for the sidebar and status(?) bar, but I wonder if that would reduce the flexibility of the theming system.
20170622 02:47:58< vultraz_iOS> forget the goddamn theming system
20170622 02:48:09< celticminstrel> But maybe, instead of two, you could build a variable number of overlay windows based on the theme's specifications.
20170622 02:48:13< vultraz_iOS> that comes last
20170622 02:48:23< celticminstrel> Uh, no. I'm not going to forget the theming system.
20170622 02:48:57< celticminstrel> Perhaps you could build a game_ui class, which does something similar to modeless_dialog, but instead wraps a variable number of GUI2 window widgets.
20170622 02:50:00< vultraz_iOS> My original idea was basically this
20170622 02:50:13< vultraz_iOS> The game UI is a GUI2 window
20170622 02:50:20< vultraz_iOS> the game map is its own widget
20170622 02:52:07< vultraz_iOS> Either through impl_draw_background or hooking into a DRAW event, it draws a bunch of stuff
20170622 02:54:07< vultraz_iOS> I don't even know if that's efficient
20170622 02:55:27< celticminstrel> Well, if the game map is a widget, then you only need one GUI2 window for the game UI.
20170622 02:55:35< vultraz_iOS> yes
20170622 02:56:06< vultraz_iOS> but...
20170622 02:56:12< vultraz_iOS> ugh, I don't know how to visualize this
20170622 02:56:17< vultraz_iOS> ok, events
20170622 02:56:18< celticminstrel> And that window could be modal, which may make it easier to deal with the do_gameloop.
20170622 02:56:51< vultraz_iOS> see
20170622 02:56:52< vultraz_iOS> ugh
20170622 02:57:03< vultraz_iOS> Let's take the hex cursor
20170622 02:57:09< vultraz_iOS> or even scrolling
20170622 02:57:50< vultraz_iOS> how do you handle that
20170622 02:57:59< vultraz_iOS> or any event really
20170622 02:58:13< vultraz_iOS> remember, events::pump needs to be called for anything to happen at all
20170622 02:58:51< vultraz_iOS> in this mode, the window would need to own the game controllers
20170622 02:58:57< vultraz_iOS> there would be no gameloop
20170622 03:00:16< vultraz_iOS> This would put the GUI2 subsystem at the base of *anything* drawing on the screen
20170622 03:02:48< vultraz_iOS> So, ok, we could say the entire game is managed in terms of "windows"
20170622 03:04:33< vultraz_iOS> but
20170622 03:04:51< vultraz_iOS> celticminstrel: i just can't seem to envision us stuffing the entire game management logic into the UI!
20170622 03:05:11< vultraz_iOS> that would *need* to happen under this model
20170622 03:06:19< vultraz_iOS> as I said, no gameloop
20170622 03:06:33< celticminstrel> Why no game loop?
20170622 03:06:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170622 03:06:50< celticminstrel> If you're not using modal_dialog, you need to have a game loop.
20170622 03:06:54< vultraz_iOS> where would it run?
20170622 03:07:01< celticminstrel> I dunno.
20170622 03:07:07< celticminstrel> Somewhere.
20170622 03:07:13< celticminstrel> Maybe the same place as currently.
20170622 03:07:22< celticminstrel> Maybe in a hypothetical gui2::game_ui class.
20170622 03:07:57< vultraz_iOS> it just doesn't seem to make sense
20170622 03:08:02< celticminstrel> What doesn't?
20170622 03:08:09< vultraz_iOS> for the UI to own the game controller
20170622 03:08:13< vultraz_iOS> instead of the other way around
20170622 03:08:27< vultraz_iOS> like, imagine this were a 3D game
20170622 03:08:27< celticminstrel> Then don't?
20170622 03:08:40< celticminstrel> In fact, IIRC you mentioned earlier that the controller currently owns the UI.
20170622 03:08:45< vultraz_iOS> would we stuff the world rendering into the same framework that renders the main menu
20170622 03:08:47< celticminstrel> So is there a problem with keeping it that way?
20170622 03:09:09< vultraz_iOS> If the controller owns the UI then we go the other path
20170622 03:09:17< vultraz_iOS> UI elements drawn *over* the game
20170622 03:09:17< celticminstrel> "the other path"?
20170622 03:09:26< celticminstrel> Oh.
20170622 03:09:33< celticminstrel> Well, that's not really a given though.
20170622 03:09:42< vultraz_iOS> But I can't figure out how to make that work
20170622 03:09:42< celticminstrel> Both paths should work with the controller owning the UI.
20170622 03:09:53< vultraz_iOS> because the GUI2 loop was not designed for that
20170622 03:10:03< celticminstrel> So don't use the GUI2 loop.
20170622 03:10:05< vultraz_iOS> neither was the gameloop
20170622 03:10:09< celticminstrel> The GUI2 loop is modal_dialog, right?
20170622 03:10:18< vultraz_iOS> because of the fucking design of events::pump
20170622 03:10:20< celticminstrel> If you don't think that will work, don't use it.
20170622 03:10:49< celticminstrel> I don't see what's the issue with events::pump. How else would you handle events? I don't think there is another way.
20170622 03:11:02< vultraz_iOS> the problem is it needs to be called manually
20170622 03:11:38< celticminstrel> That's not really a problem?
20170622 03:11:51< vultraz_iOS> and I don't understand the goddamn design of these event contexts 
20170622 03:11:58< celticminstrel> "pump" is IMO a slightly misleading name.
20170622 03:12:04< vultraz_iOS> like, what the fuck is draw_layering
20170622 03:12:11< celticminstrel> All it's doing is handling the events in the queue.
20170622 03:12:35< celticminstrel> Admittedly, it's a little weird how it copies the events from the queue into a separate list, then handles them, but...
20170622 03:12:53< vultraz_iOS> what the hell is sdl_handler
20170622 03:12:53< celticminstrel> For the most part, it's just a standard event loop.
20170622 03:13:11< celticminstrel> I don't think you need to worry too much about all the random event contexts.
20170622 03:13:37< vultraz_iOS> why the hell do I need to call join() in sdl_event_handler::connect
20170622 03:13:40< vultraz_iOS> in gui2
20170622 03:13:48< celticminstrel> I don't know.
20170622 03:14:32< vultraz_iOS> for some reason right now, I can have the game draw underneath modal dialogs
20170622 03:14:33< vultraz_iOS> this is good
20170622 03:15:15< vultraz_iOS> how the fuck that works? I have no idea
20170622 03:15:42< vultraz_iOS> i think both game and UI are part of the same event context
20170622 03:15:47< vultraz_iOS> but i don't know
20170622 03:15:56< vultraz_iOS> there's something about that that fails in the tests
20170622 03:16:17< vultraz_iOS> but here's the thing
20170622 03:16:34< vultraz_iOS> if i want the sidebar etc to be GUI2
20170622 03:16:42< vultraz_iOS> it needs to handle events
20170622 03:16:50< vultraz_iOS> and the gamemap needs to handle events at the same time
20170622 03:17:18< vultraz_iOS> *how do I do that*
20170622 03:20:58< vultraz_iOS> not to mention the whole game loop isn't even attached to SDL events
20170622 03:21:05< celticminstrel> I'm not entirely sure.
20170622 03:21:09< vultraz_iOS> at least, most aren't
20170622 03:21:10< celticminstrel> Uh. What are you talking about?
20170622 03:21:11< vultraz_iOS> like scrolling
20170622 03:21:18< vultraz_iOS> this is all a fucking mess
20170622 03:21:20< celticminstrel> The game loop obviously handles SDL events.
20170622 03:21:59< celticminstrel> Scrolling may indeed be a special case, though.
20170622 03:22:34< vultraz_iOS> scrolling is a mes
20170622 03:22:35< vultraz_iOS> s
20170622 03:22:39< celticminstrel> If the game map were a GUI2 widget, you wouldn't have to worry about how to have both the game and the sidebar handle events.
20170622 03:23:11< celticminstrel> Because all events (except for a few special ones) would go through the GUI2 pipeline.
20170622 03:23:30< vultraz_iOS> but there would be no gameloop
20170622 03:24:42< celticminstrel> Why would you say that?
20170622 03:24:48< celticminstrel> No matter what you do, there'll be a game loop.
20170622 03:24:58< vultraz_iOS> because the loop is the window loop!
20170622 03:25:01< vultraz_iOS> that's the loop!
20170622 03:25:10< celticminstrel> It doesn't have to be.
20170622 03:25:23< celticminstrel> And there's no such thing as "the window loop", anyway.
20170622 03:25:31< celticminstrel> Windows have no concept of an event loop.
20170622 03:25:39< vultraz_iOS> uh
20170622 03:25:41< vultraz_iOS> what??
20170622 03:25:45< vultraz_iOS> of course they do
20170622 03:25:56< celticminstrel> No they don't. It's only the modal_dialog class that has its own event loop, which makes sense because, well, that's what modal means.
20170622 03:26:08< celticminstrel> "window" is just a widget.
20170622 03:26:17< vultraz_iOS> ok, fine
20170622 03:26:26< celticminstrel> You can show it or hide it or whatever. You can easily write your own loop that shows it, does stuff, and hides it when done.
20170622 03:27:05< celticminstrel> And modeless_dialog has never had an event loop, either. Tooltips are modeless dialogs, and they show and hide just fine, because the modal_dialog loop shows and hides them.
20170622 03:27:24-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has quit [Ping timeout: 268 seconds]
20170622 03:27:35< vultraz_iOS> ok, so the main game loop would need to manage the sidebar
20170622 03:27:36< vultraz_iOS> menubar
20170622 03:27:36< vultraz_iOS> etc
20170622 03:27:39< vultraz_iOS> I'm fine with that
20170622 03:27:42< vultraz_iOS> but *how*
20170622 03:27:48< vultraz_iOS> do i need to look at how modal manages tooltips?
20170622 03:28:49< celticminstrel> I don't actually know how exactly it manages tooltips, so I can't say for sure whether it would be useful.
20170622 03:29:14< vultraz_iOS> ok that aside
20170622 03:29:25< celticminstrel> But basically, if I understand correctly. the main game loop could basically do whatever it wants, and as long as it calls events::pump(), the sidebar would get all its events and respond to them.
20170622 03:29:33< vultraz_iOS> let's say the play_slice loop (the game loop) which also calls events::pump manages the modeless dialogs
20170622 03:31:12< vultraz_iOS> but again *how*
20170622 03:32:27< vultraz_iOS> even a non-modal window has a distributor
20170622 03:33:34< celticminstrel> Sure, having a distributor would make sense.
20170622 03:34:07 * celticminstrel is very deliberately avoiding the word "dialog" here, because I'm still not convinced that either modal_dialog or modeless_dialog is needed.
20170622 03:34:29< vultraz_iOS> you do realize that a lua dialog acts modal right
20170622 03:34:34< celticminstrel> Note that, functionally speaking, the game UI is actually modal.
20170622 03:34:41< celticminstrel> Yes, I know, what about it.
20170622 03:35:01< celticminstrel> (That's the game UI as a whole, including status bar, title, and map.)
20170622 03:35:12< vultraz_iOS> irrelevant
20170622 03:36:06< vultraz_iOS> for some reason my modeless dialog is drawing twice then exiting
20170622 03:36:07< vultraz_iOS> *why*
20170622 03:36:40< vultraz_iOS> it makes no *sense*
20170622 03:37:11< vultraz_iOS> for that matter
20170622 03:37:25< vultraz_iOS> why the hell does the debug clock window draw fine at the titlescreen despite being non modal
20170622 03:39:48< vultraz_iOS> this is probably something with event contexts
20170622 03:39:59< vultraz_iOS> curse them
20170622 03:45:01< celticminstrel> The debug clock is owned by the title screen.
20170622 03:45:47< celticminstrel> It's the title screen that shows and hides it. I'm not sure if it does anything else besides that, but unlike in-game there's only the GUI2 event context active.
20170622 03:46:13< vultraz_iOS> ye
20170622 03:46:19< celticminstrel> In my GUI2 floating textbox attempt, Aginor's theory was that GUI2 and GUI1 had two separate event contexts which were interfering with each other.
20170622 03:46:20< vultraz_iOS> as i said this is probably an event context thing
20170622 03:46:28< vultraz_iOS> yes
20170622 03:46:32< vultraz_iOS> but i thought i unified them
20170622 03:46:34< vultraz_iOS> thought
20170622 03:46:39< celticminstrel> So if you take that GUI1 event context out of the picture...
20170622 03:46:49< celticminstrel> What do you mean by "unified"?
20170622 03:47:04< celticminstrel> Does that mean deleting the GUI1 event context and piping all those events through the GUI2 event system?
20170622 03:47:23< vultraz_iOS> https://github.com/wesnoth/wesnoth/pull/1753/commits/85cc78f8639b912963c3e9e11b83fa3bcfe6bbd8
20170622 03:48:33< vultraz_iOS> i pinged aginor to as him if i did that properly but he never replied
20170622 03:49:00< vultraz_iOS> ask
20170622 03:49:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 03:50:06< celticminstrel> I assume you realize that the changes there are not equivalent to uncommenting those two defines.
20170622 03:50:20< vultraz_iOS> of course
20170622 03:50:27< vultraz_iOS> that didn't do what i wanted
20170622 03:50:29< celticminstrel> I don't really understand what you're doing in that commit.
20170622 03:50:40< vultraz_iOS> It Worked And I didn't Question It
20170622 03:51:35< celticminstrel> So, are all the game events now being piped through sdl_event_handler?
20170622 03:52:53< vultraz_iOS> i don't know!
20170622 03:54:17< celticminstrel> Then set some breakpoints and find out?
20170622 03:54:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170622 03:54:47< vultraz_iOS> i don't know how to set breakpoints
20170622 03:55:35< celticminstrel> That's kind of a problem.
20170622 03:56:49< vultraz_iOS> I know almost nothing about proper debugging
20170622 03:57:28< celticminstrel> Then you should learn.
20170622 03:58:44< vultraz_iOS> well i also don't have a good debugger
20170622 03:58:49< vultraz_iOS> gdb has always been rather useless
20170622 03:59:05< vultraz_iOS> and as i said, building with MSVC took 4x as long last time i tried
20170622 04:00:13< celticminstrel> gdb is far from useless, but it's not that user-friendly, I suppose.
20170622 04:02:35-!- travis-ci [~travis-ci@ec2-54-221-162-143.compute-1.amazonaws.com] has joined #wesnoth-dev
20170622 04:02:36< travis-ci> wesnoth/wesnoth#14326 (gui2_floating_textbox - 185fca8 : Celtic Minstrel): The build is still failing.
20170622 04:02:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/245612746
20170622 04:02:36-!- travis-ci [~travis-ci@ec2-54-221-162-143.compute-1.amazonaws.com] has left #wesnoth-dev []
20170622 04:06:14< vultraz_iOS> ok, there appear to be 2 event contexts
20170622 04:06:56< vultraz_iOS> Global, and main
20170622 04:07:55< celticminstrel> I think the global one is for things that need to always run.
20170622 04:10:42< vultraz_iOS> wait
20170622 04:10:43< vultraz_iOS> idea
20170622 04:16:53< celticminstrel> Sorry, I need to sleep...
20170622 04:17:41< vultraz_iOS> oh jesus christ
20170622 04:17:45< vultraz_iOS> jesus fucking christ
20170622 04:17:47< vultraz_iOS> i am stupid
20170622 04:17:50< vultraz_iOS> so stupid
20170622 04:17:52< vultraz_iOS> so so stupid
20170622 04:17:53< celticminstrel> ...
20170622 04:18:06< vultraz_iOS> OF COURSE the dialog was closing
20170622 04:18:10< vultraz_iOS> IT WAS LOCAL SCOPE IN THE FUNCTION
20170622 04:18:13< celticminstrel> ...
20170622 04:18:29< vultraz_iOS> MODELESS DIALOGS DON'T HAVE THEIR OWN LOOPS SO OF COURSE IT WOULD SHOW AND RETURN CONTROL TO THE FUNCTION THAT CALLED IT
20170622 04:18:38< vultraz_iOS> WHICH WOULD DESTROY THE DIALOG OBJECT
20170622 04:18:47< celticminstrel> Yeah, pretty sure I mentioned that awhile ago... the first part, that is.
20170622 04:18:52-!- Kwandulin [~Kwandulin@p200300760F7CBA31F1E4410287F39284.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170622 04:19:01< celticminstrel> The part about show() returning control to the caller.
20170622 04:19:16< vultraz_iOS> if i instead do the same thing the titlescreen does with the debug clock
20170622 04:19:57< vultraz_iOS> have a unique ptr in the menu_handler class
20170622 04:20:00< vultraz_iOS> and call show() on it
20170622 04:20:03< vultraz_iOS> *it works*
20170622 04:20:04< vultraz_iOS> good god
20170622 04:21:24< vultraz_iOS> I am so stupid :|
20170622 04:21:45< vultraz_iOS> I literally got so used to creating and showing dialogs with static display functions i didn't realize...
20170622 04:21:48< vultraz_iOS> good god 
20170622 04:22:01< vultraz_iOS> celticminstrel: all our problems are solved
20170622 04:27:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170622 04:27:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170622 04:27:29< celticminstrel> Yay?
20170622 04:27:53< celticminstrel> BTW, why don't you see if my floating textbox also works now?
20170622 04:29:44< celticminstrel> The floating textbox I made is a standard modeless_dialog.
20170622 04:31:21< celticminstrel> Might need a little work merging it in, as it's quite old.
20170622 04:32:08< celticminstrel> Is this still with OpenGL or did you temporarily give up on that?
20170622 04:36:16 * celticminstrel pokes vultraz_iOS 
20170622 04:39:19< celticminstrel> ...or I guess you can answer my questions tomorrow. Good night.
20170622 04:39:24-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170622 04:58:02-!- Kwandulin [~Kwandulin@p200300760F7CBA31F1E4410287F39284.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
20170622 05:03:16-!- Kwandulin [~Kwandulin@p200300760F7CBA5E49A016EEF96DE868.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170622 05:28:25-!- irker272 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170622 05:38:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 05:42:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170622 06:13:56< vultraz_iOS> celmin: temporarily postponed
20170622 06:14:07< vultraz_iOS> especially with jyrki being away for awhile I cannot do it alone
20170622 06:14:13< vultraz_iOS> and it would take too much time
20170622 06:15:00< vultraz_iOS> celmin: as for your branch, I think I'll just try to start from scratch. it's so old it pre-dates the t-prefix drop, even
20170622 06:38:10-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170622 06:48:46-!- Kwandulin [~Kwandulin@p200300760F7CBA5E49A016EEF96DE868.dip0.t-ipconnect.de] has quit [Quit: [endlevel]]
20170622 07:35:11-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170622 07:58:44-!- APic\splat [apic@apic.name] has quit [Ping timeout: 268 seconds]
20170622 08:01:38-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has joined #wesnoth-dev
20170622 08:16:25-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 08:21:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 08:25:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20170622 08:50:32-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has quit [Quit: ancestral]
20170622 08:51:04-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 09:16:50-!- atarocch [~atarocch@93.56.160.37] has quit [Ping timeout: 258 seconds]
20170622 09:17:42-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has quit [Quit: ancestral]
20170622 09:25:53-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has joined #wesnoth-dev
20170622 09:28:33-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170622 10:24:16-!- Appleman1234 [~quassel@z190230.ppp.asahi-net.or.jp] has quit [Ping timeout: 268 seconds]
20170622 10:27:50-!- Kwandulin [~Kwandulin@p200300760F7CBA5E49A016EEF96DE868.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170622 10:38:15-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has quit [Read error: Connection reset by peer]
20170622 10:46:59-!- vn971 [~vasya@0896414046.static.corbina.ru] has left #wesnoth-dev ["QUIT :Leaving."]
20170622 11:04:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 11:08:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170622 11:20:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170622 11:23:55-!- vn971 [~vasya@0896414046.static.corbina.ru] has joined #wesnoth-dev
20170622 11:24:57< vn971> download of wesnoth source lasts for about 1 infinity.(
20170622 11:27:03< vultraz_iOS> the git repo?
20170622 11:27:05< vultraz_iOS> indeed it does
20170622 11:28:35< vn971> vultraz_iOS: yup, git. Though I now noticed that ArchLinux (AUR) package downloads the whole history, not just a shallow clone. So there is some room for improvement.
20170622 11:47:27-!- Appleman1234 [~quassel@z190230.ppp.asahi-net.or.jp] has joined #wesnoth-dev
20170622 11:50:54-!- Appleman1234 [~quassel@z190230.ppp.asahi-net.or.jp] has quit [Remote host closed the connection]
20170622 11:52:58-!- Appleman1234 [~quassel@z190230.ppp.asahi-net.or.jp] has joined #wesnoth-dev
20170622 12:06:18< vn971> Anybody usnig ArchLinux BTW, and its AUR package?
20170622 12:07:05< vn971> I wonder how I can set parallelism (-j) for building wesnoth. I tried adding MAKEFLAGS="--jobs=7" to makepkg.conf, but somewhy that doesn't help.
20170622 12:09:24< DeFender> vn971, the source is just massive and not really structured well to allow quick recompiles. It routinely takes me 30-45 minutes to compile after even the most basic update.
20170622 12:09:39< DeFender> I complained about this a couple of days ago.
20170622 12:14:33< vn971> DeFender: well, parallel and incremental builds are different beasts. What I'd definitely like to see is parallel. Though, obviously, incremental would help a lot during development, too.
20170622 12:15:15< DeFender> Are you sure it's not doing parallel already?
20170622 12:28:03-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170622 12:46:23< vn971> DeFender: pretty sure. I have a CPU graphics on my OS, always visible. And it's around 100"%" when building wesnoth.
20170622 12:46:46< vn971> * cpu graph. The applet that draws the CPU graph. Well you get it.:)
20170622 13:50:52-!- Kwandulin [~Kwandulin@p200300760F7CBA5E49A016EEF96DE868.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170622 14:02:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170622 14:03:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170622 14:28:03-!- JyrkiVesterinen [~JyrkiVest@87-100-242-191.bb.dnainternet.fi] has joined #wesnoth-dev
20170622 14:28:34< JyrkiVesterinen> vn971: If you use SCons to build Wesnoth, you can set parallelism with "jobs=7" (no preceding dashes).
20170622 14:29:53-!- JyrkiVesterinen [~JyrkiVest@87-100-242-191.bb.dnainternet.fi] has quit [Client Quit]
20170622 14:32:42< vultraz_iOS> well, this is rather ironic
20170622 14:32:51< vultraz_iOS> i now have the *opposite* problem 
20170622 14:33:35< vultraz_iOS> instead of the game not responding to events while the prompt is open, i have the game actually responding to map events when a modal gui2 dialog is open
20170622 14:34:48< vultraz_iOS> oh well, can fix later
20170622 14:38:40< vn971> JyrkiVesterinen: I understood how to do it! Previously I had SCONSFLAGS="--jobs=7", and it didn't work. In reality, `makepkg.conf` is a _script_, and I should've used `export SCONSFLAGS="--jobs=7`. After I've done this, everything works.
20170622 14:57:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170622 14:57:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170622 15:50:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170622 15:51:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170622 15:57:40< DeFender> vultraz_iOS, any way you could also "accidentally" make map animations continue to render while a message or dialog is open? :P
20170622 15:57:57< vultraz_iOS> DeFender: already done
20170622 15:58:04< DeFender> :o
20170622 15:58:31< DeFender> Then I can't wait until this branch of yours is complete!
20170622 15:59:00< DeFender> Animations pausing on message is one of those things that really irked me.
20170622 15:59:14< DeFender> (I mean, you know how much I love animations...)
20170622 15:59:58< vultraz_iOS> It was an unfortunate side effect of the old render pipeline design
20170622 16:00:24< DeFender> right
20170622 16:01:35< vultraz_iOS> it was something that was Just Fixed once i merged GUI2 into the main event context
20170622 16:03:11< Ravana_> does that mean chat messages also arrive while message is open?
20170622 16:03:46< DeFender> Right, I'm familiar with that phenomenon.
20170622 16:04:38< DeFender> vultraz_iOS, though, if that's the case, then you really DID "accidentally" make map animations continue to render during a message or dialog.
20170622 16:05:59< DeFender> https://www.youtube.com/watch?v=9fuNNtmjDXs&t=8
20170622 16:11:05-!- oldlaptop [~quassel@45.63.78.126] has quit [Ping timeout: 240 seconds]
20170622 16:12:10-!- oldlaptop [~quassel@45.63.78.126] has joined #wesnoth-dev
20170622 16:13:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170622 16:14:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170622 16:18:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 16:19:39< vultraz_iOS> indeed
20170622 16:31:06-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 16:59:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170622 17:00:05-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
20170622 17:00:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 17:01:22< vultraz_iOS> celticminstrel: \o/ GUI2 floating textbox is working
20170622 17:02:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170622 17:02:48-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20170622 17:03:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 17:03:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20170622 17:04:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 17:06:02< vultraz_iOS> now just need to deal with differences in the call functionl..
20170622 17:09:13< vultraz_iOS> celticminstrel: where's the checkbox in the old version?
20170622 17:09:20< vultraz_iOS> (that is, position-wise)
20170622 17:52:33-!- APic [apic@apic.name] has joined #wesnoth-dev
20170622 17:56:16-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has quit [Quit: leaving]
20170622 18:06:34-!- JyrkiVesterinen [~JyrkiVest@87-100-242-191.bb.dnainternet.fi] has joined #wesnoth-dev
20170622 18:19:38< JyrkiVesterinen> Update: I can still reproduce bug 1808, yesterday's change didn't fix it.
20170622 18:19:43-!- APic [apic@apic.name] has quit [Quit: cul8r]
20170622 18:19:49< JyrkiVesterinen> As I suspected, 1808 and 1810 are distinct bugs.
20170622 18:20:15< JyrkiVesterinen> The exact value for prob_kill is 1.0000000000000002. Looks like a rounding error.
20170622 18:24:54< vn971> JyrkiVesterinen: OK. BTW, if that's interesting, I made a reply earlier:
20170622 18:25:12-!- Kwandulin [~Kwandulin@p200300760F7CBA5EA0B8473ECD9C125B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170622 18:25:49< vn971> I understood how to do it! Previously I had SCONSFLAGS="--jobs=7", and it didn't work. In reality, `makepkg.conf` is a _script_, and somehow it seems I've used `makepkg` in a nested shell. Well, I'm not sure about the reasoning, but this works: `export SCONSFLAGS="--jobs=7`
20170622 18:26:04< JyrkiVesterinen> Yes, I saw your reply in IRC logs.
20170622 18:26:10< JyrkiVesterinen> http://irclogs.wesnoth.org
20170622 18:26:11< vn971> JyrkiVesterinen: ah, Ok.
20170622 18:38:33< JyrkiVesterinen> Okay... analysis shows that the AI had simulated an unit (that has 6 HP at the start) having been attacked with three units in a row.
20170622 18:38:49< JyrkiVesterinen> After all three attacks, the poor unit had only about 0.000000000000004 % chance to stay alive.
20170622 18:39:24< JyrkiVesterinen> At that point, the calculated probability for it to be died had crept a bit above 100 % due to rounding error.
20170622 18:39:57< JyrkiVesterinen> I'll just make the function limit the probability to 100 %. That fixes the assertion once and for all.
20170622 18:44:22< zookeeper> vultraz_iOS, DeFender, so if a message pops up, terrain animations keep running but unit animations halt?
20170622 18:45:37-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has quit [Quit: ancestral]
20170622 18:46:44-!- atarocch_ [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170622 18:46:57-!- atarocch [~atarocch@93.56.160.37] has quit [Ping timeout: 240 seconds]
20170622 18:48:25< vn971> JyrkiVesterinen: wouldn't it be more appropriate to use rational numbers? (Keep the number of attempts and the number of failures.) Or maybe some other work-around.. Dunno, have to think about a bit more.
20170622 18:48:38-!- irker883 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170622 18:48:38< irker883> wesnoth: Jyrki Vesterinen wesnoth:master ddcc77352cb8 / src/attack_prediction.cpp: calculate_probability_of_debuff(): limit probability to kill to 100 % https://github.com/wesnoth/wesnoth/commit/ddcc77352cb8913fc9b32240b43b1832840defbe
20170622 18:48:55< JyrkiVesterinen> Nah, floating point is faster and this code is performance-critical.
20170622 18:49:14< vn971> Looking at the AI behavior, I guess it does not really use mini-max or UTC algorythms, right?
20170622 18:49:34< JyrkiVesterinen> I don't know what the AI does. I maintain only damage prediction.
20170622 18:49:39< vn971> JyrkiVesterinen: so it only maximises some function within 1 turn, right?
20170622 18:49:45< vn971> *maximizes
20170622 18:50:29< vn971> JyrkiVesterinen: well damage prediction seems to be OK. 0.000000..04 seems to be a valid number.
20170622 18:50:59< vn971> The code that can't deal with this number is the code that's erroneous. Isn't it?
20170622 18:52:38< JyrkiVesterinen> 0.000...4 was the highest probability in the HP distribution, apart from the probability of 0 HP.
20170622 18:52:56< JyrkiVesterinen> And probability of 0 HP was 1.0000000000000002.
20170622 18:53:27< JyrkiVesterinen> Obviously, the sum of probabilities can't exceed 1 from a mathematical perspective.
20170622 18:53:38< JyrkiVesterinen> But because of rounding errors, it had happened.
20170622 18:53:55< JyrkiVesterinen> And damage prediction code (as well as AI) needs to be able to deal with it.
20170622 18:54:22< JyrkiVesterinen> Due to performance requirements, I can't really do anything to prevent this situation.
20170622 18:56:52< vn971> JyrkiVesterinen: I don't fully get it. Damage prediction code should predict the unit to be alive after one battle, right? One float as output. Or does it predict chance to die, which can get higher than 1.0 ?
20170622 18:57:31< vn971> > And probability of 0 HP was 1.0000000000000002.  ah sorry, probably I get it now.
20170622 18:58:03< JyrkiVesterinen> It predicts the entire HP distribution. The same thing you can see if you click the "Damage Calculations" button.
20170622 19:01:26< DeFender> zookeeper, I would imagine that all animations would continue, no?
20170622 19:02:00< zookeeper> DeFender, is that always possible in a combat context?
20170622 19:02:45< DeFender> I would imagine it would only be standing/idle, as messages wouldn't happen during combat proper.
20170622 19:04:07< DeFender> though, i do wonder what happens if there's a message on something like attacker_hits...
20170622 19:04:26< zookeeper> [event] name=attacker hits {DEBUG_MSG "foo"} [/event] <- a message during combat proper
20170622 19:04:29< DeFender> I would imagine in that case, it'd show whatever the last frame was...
20170622 19:04:38< DeFender> zookeeper, yeah, that's not quite what I meant
20170622 19:04:48< DeFender> I meant, during an acctual attack sequence
20170622 19:05:06< DeFender> but yeah, perhaps this means that a new animation type would be in order?
20170622 19:05:07< zookeeper> what's an actual attack sequence?
20170622 19:05:38< DeFender> sorry, I'm not being clear. I mean while an actual hit is being carried out.
20170622 19:07:21< DeFender> but like I said, I'm wondering if something like a "combat_waiting" animation should be added if animations can now run during messages, and as such there'd be the potential for a length of time during combat where the actual attack animations wouldn't be taking place.
20170622 19:08:55< zookeeper> well, i wasn't just asking a rhetorical question about the combat context, i really don't know. the hits/misses events for example trigger only after the attack animation has finished, not during it.
20170622 19:09:52< zookeeper> so in that case, there doesn't seem to be a problem. of course the units in combat would appear frozen during the message whereas all other units would be playing their standing/idle anims.
20170622 19:11:38-!- horrowind [~Thunderbi@p2003008E6C0B26D9964452FFFE0220ED.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170622 19:16:29-!- JyrkiVesterinen [~JyrkiVest@87-100-242-191.bb.dnainternet.fi] has quit [Quit: .]
20170622 19:19:19< DeFender> "the hits/misses events for example trigger only after the attack animation has finished, not during it" I don't think this is true. I'm pretty sure I USE those events for a certain attack that changes what it does from one hit to the next.
20170622 19:21:02< zookeeper> well i tested it myself before saying that, feel free to do the same :>
20170622 19:24:47-!- Kwandulin [~Kwandulin@p200300760F7CBA5EA0B8473ECD9C125B.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170622 19:52:07< DeFender> is that a change from 1.12? becauce I'm positive that I'm using that in 1.12
20170622 19:52:55< DeFender> is it possible that the event runs, but all messages are deferred until after combat is over?
20170622 19:54:16< DeFender> I just checked myself, and I know for a fact that, at least in 1.12, the events actually do run at that point.
20170622 19:56:27< DeFender> zookeeper, ^^^
20170622 19:58:06-!- APic [apic@apic.name] has joined #wesnoth-dev
20170622 20:03:05-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170622 20:04:40-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 20:04:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170622 20:04:53-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 20:06:46< zookeeper> DeFender, right. i did at some point have a similar conviction that they used to trigger immediately instead of only after the animation, so i guess that's a change from 1.12 then.
20170622 20:08:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170622 20:23:37-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 20:27:03< DeFender> that doesn't bode well for what I'm doing...
20170622 20:27:15< DeFender> let me actually fully test that though...
20170622 20:30:24< DeFender> just tested 1.13, it still acts the way I said.
20170622 20:31:18< DeFender> It must just be that dialog actions are deferred if that's what you're seeing...
20170622 20:31:21< DeFender> but let me test that too.
20170622 20:33:36-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170622 20:33:36< DeFender> nope, I'm seeing [messages] come up in between attacks.
20170622 20:33:55< DeFender> I am on vult's accellerated render branch
20170622 20:34:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 20:34:09< DeFender> Lemme switch back to master if I can figure out how...
20170622 20:34:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170622 20:35:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 20:36:13< zookeeper> of course they come up in between attacks
20170622 20:37:17< DeFender> I mean between hits
20170622 20:37:24< DeFender> in the same attack
20170622 20:37:42< zookeeper> of course they come up in between hits in the same attack, too :p
20170622 20:37:50< vn971> JyrkiVesterinen: what new code would you like to use? If we want to be safe against rounding errors, we could use:
20170622 20:37:50< vn971>    if (probability > 1.0) { if (probability > 1.000001) { raise_exception_or_smth_like_that(); } else { probability = 1.0; } }
20170622 20:37:50< vn971> Seems a bit hack-y at first. But we'd still have the assertion that was there previously. And in normal cases, the code would be as fast as taking `min(*, 1.0)`.
20170622 20:37:51< DeFender> then I don't know what you were referring to?
20170622 20:38:19< zookeeper> what i said? animations
20170622 20:38:25< DeFender> ohhhhhhhhh
20170622 20:38:32< DeFender> okay, we were talking past each other
20170622 20:38:59< DeFender> yeah, of course they trigger after each hit's animation rather than before or during it
20170622 20:39:23< DeFender> that's not what I was referring to
20170622 20:40:12< DeFender> my point was that during combat, when there isn't actively an attack/defend animation going on, there's currently just the last frame of whatever the previous attack/defend animation was.
20170622 20:40:59< DeFender> Which makes sense, because the only thing going on at that time is either the next round of attack triggering immediately, or a [message] or dialog action which is pausing the animation completely.
20170622 20:41:35< DeFender> However, with vult's changes, if animations will be running, there may be certain units for which one might want to create an animation specifically for times between rounds of combat.
20170622 20:42:07< DeFender> It's a nice case, certainly, since it's rare to have a message or dialog event in the middle of combat like that, but it's still something I could envision wanting.
20170622 20:42:12< DeFender> That's all I meant to say.
20170622 20:42:19< DeFender> Am I being a little clearer now?
20170622 20:42:48-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170622 20:44:11< DeFender> vultraz_iOS, welcome back. You with us now?
20170622 20:44:16< vultraz_iOS> si
20170622 20:44:44< DeFender> See backlog, zookeeper had a question to which I assumed the answer and then we went off on some stuff about how animations are handled.
20170622 20:45:14< DeFender> And I'm suggesting a new animation type which might be necessary once accellerated rendering is doen.
20170622 20:46:49< vultraz_iOS> i an't answer to how events are fired
20170622 20:46:51< zookeeper> i dunno about that, it gets pretty horrid
20170622 20:47:17< vultraz_iOS> nor can i answer to it will affect certain anims
20170622 20:47:23< vultraz_iOS> some work will be needed on that front
20170622 20:48:29< vultraz_iOS> right now working on some other things
20170622 20:48:44< DeFender> vultraz_iOS, fair.
20170622 20:49:20< zookeeper> take your average sword/bow unit. it has a standing animation with sword, it has attack and defense animations for both weapons. what are you going to do with that hypothetical new animation type? to do anything which wouldn't look exactly the same as freezing the animation would, you'd have to actually draw a standing animations for the unit with bow in hand, and that'd be silly.
20170622 20:50:24< DeFender> zookeeper, IIRC, there are some units that actually have an unsheath weapon animation.
20170622 20:50:58< zookeeper> and i didn't even go there because i tried to keep the paragraph legible instead of branching into every conceivable extra detail.
20170622 20:51:03< DeFender> Hence, you'd want at the very least a single-sprite animation between attack segments which shows them holding the weapon.
20170622 20:51:46< zookeeper> that's the "wouldn't look exactly the same as freezing the animation would" part
20170622 20:52:20< DeFender> Well, it depends. If it just grabs the last frame, sure, but if it reverst to standing animation, not so much.
20170622 20:52:26< DeFender> Also consider bats.
20170622 20:52:32< DeFender> Or flying drakes.
20170622 20:52:41< DeFender> Or other units which look silly when frozen.
20170622 20:53:06< DeFender> For many of them, you'd specifically want the standing animation there rather than the last fram of the previous attack.
20170622 20:53:24< DeFender> I can't think of a sane way to specify that other than "new animation type"
20170622 20:54:00< zookeeper> sure, for bats etc that makes sense
20170622 20:54:02< DeFender> But since vult is nowhere near ready to even know what would happen in practice, this entire discussion is hypothetical anyway.
20170622 20:54:34< DeFender> zookeeper, is there a "but" there?
20170622 20:54:47< zookeeper> no
20170622 20:55:00< vultraz_iOS> many much things need to be done before we get to that point
20170622 20:55:20< vultraz_iOS> I'm not trying to make sure stuff works as I go along
20170622 20:55:23< zookeeper> in any case, the default would have to be "freeze on the last frame" anyway
20170622 20:56:12< DeFender> zookeeper, yes, obviously the default should be freeze on the last frame.
20170622 20:56:26-!- ash__ [d05f641e@gateway/web/freenode/ip.208.95.100.30] has joined #wesnoth-dev
20170622 20:56:43< DeFender> zookeeper, I wouldn't have suggested anything different.
20170622 20:57:56< DeFender> Though I could imagine some creative soul using it for something more interesting, like units making menacing faces at each other while flexing their bows or something.
20170622 20:58:22< vultraz_iOS> not with our current API
20170622 20:58:42< DeFender> vultraz_iOS, how do you mean?
20170622 20:58:53< vultraz_iOS> our API sucks ass for anything complicated, VFX-wise
20170622 20:59:07< DeFender> I just meant with sprites...
20170622 20:59:18< DeFender> It handles sprites sort of decently okayish.
20170622 20:59:30< vultraz_iOS> no spritesheets
20170622 20:59:35< DeFender> So what?
20170622 20:59:44< vultraz_iOS> irrelevant to this disucssion
20170622 20:59:52-!- ash__ [d05f641e@gateway/web/freenode/ip.208.95.100.30] has quit [Client Quit]
20170622 21:00:06< DeFender> What I mentioned would be no more complicated than any of the other existing animations
20170622 21:00:12< zookeeper> "i drew an animation of the orcish grunt making a menacing face at the enemy during a message or other modal dialog that might pop up during combat in some very rare cases"
20170622 21:00:16< zookeeper> yeah, maybe not :p
20170622 21:00:39< DeFender> Yeah, it seems a little farfetched, but whatever.
20170622 21:00:53< DeFender> Unless you know that there's going to be such an occurrence.
20170622 21:01:26< DeFender> On a similar note, I'm also wondering if message and dialog actions shouldn't allow for [animate] subtags which will play a particular animation on repeat while the dialog or message is active.
20170622 21:01:55< DeFender> Or maybe optionally on repeat?
20170622 21:02:52< DeFender> Point is, if animations can happen during messages, then a lot more fancy things can be done, like having whatever unit is speaking do some movement or action while the message is onscreen.
20170622 21:03:49< DeFender> Heck, if animation can continue, perhaps the message tag could just take an entire set of action subtags which it will then execute without waiting for the message to be dismissed...
20170622 21:03:58< DeFender> Though that could get complicated...
20170622 21:04:25< DeFender> especially since that'd have to account for a nexted [message] tag which would be icky.
20170622 21:04:32< DeFender> nested*
20170622 21:05:15< DeFender> though, that could just be that messages get queued up and appear once the previous message has been dismissed... hmm
20170622 21:05:57-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170622 21:06:01< DeFender> I imagine that would require a rework of at least part of how GUI2 initializes new dialogs though...
20170622 21:06:28< vultraz_iOS> not reallt
20170622 21:06:32< DeFender> Still, interesting ideas to consider.
20170622 21:06:33< vultraz_iOS> really
20170622 21:06:40< DeFender> Oh, well then in that case...
20170622 21:07:44< DeFender> It would be kinda nice to have the ability to allow certain action to continue up to a certain point while a certain message may or may not still be onscreen.
20170622 21:09:39< DeFender> Like, imagine: [message] / message=_"Too much! I'm out of here!" / speaker=$someUnit / [move_unit] / id=$someUnit / x,y=30,45 / [/move_unit] / [/message]
20170622 21:10:12< vultraz_iOS> I'm pretty sure that would happen right now
20170622 21:10:14< vultraz_iOS> not sure
20170622 21:10:15< zookeeper> hurr durr. too far into fancy future land.
20170622 21:10:33< vultraz_iOS> I need to actually make it so modal dialogs stop things again :P
20170622 21:10:33< DeFender> the unit would run away while yelling about how they're running away, but further actions wouldn't continue until after the message was dismissed.
20170622 21:10:58< DeFender> Likewise, if the message was dismissed before the movement was complete, the movement would still complete before the next action after the message was run.
20170622 21:11:20< DeFender> vultraz_iOS, well, what you describe is a little less controlled than I'm envisioning.
20170622 21:11:47< DeFender> You describe that actions AFTER the action that brings up the message or dialog continue.
20170622 21:12:12< DeFender> What I'm saying is to allow actions INSIDE that to define actions which will continue UP TO A POINT if the dialog is still open.
20170622 21:12:32< DeFender> Only a minor distinction, of course. :P
20170622 21:13:08< vultraz_iOS> yes
20170622 21:13:13< vultraz_iOS> it could be worked on
20170622 21:13:15< DeFender> zookeeper, yes, I know. Like I said, theoretical at this point, but it's good to have ideas of things one might want to work towards.
20170622 21:13:31< vultraz_iOS> again, a lot of testing will be needed
20170622 21:13:34< DeFender> of course.
20170622 21:13:48< vultraz_iOS> merging event contexts and removing certain conditionals causes some problems
20170622 21:13:58< DeFender> Though I can tell you that if that was a feature that was available, I'd abuse the heck out of it.
20170622 21:14:02< vultraz_iOS> or, at least, potentially
20170622 21:14:17< DeFender> So you'd get tons of testing from me.
20170622 21:14:48< DeFender> You know me, I love taking the engine to (and sometimes past) its theoretical limits...
20170622 21:21:12-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit []
20170622 21:25:23-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170622 22:07:57-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has quit [Quit: ancestral]
20170622 22:37:12-!- irker883 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170622 22:52:46-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170622 22:56:29-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20170622 23:02:59-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 23:06:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170622 23:06:59-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170622 23:08:00-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20170622 23:09:22-!- atarocch_ [~atarocch@93.56.160.37] has quit [Remote host closed the connection]
20170622 23:20:34-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 23:22:19-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170622 23:22:53-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20170622 23:23:53-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has quit [Client Quit]
20170622 23:26:57-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Ping timeout: 240 seconds]
20170622 23:27:47-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 23:38:28-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170622 23:38:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170622 23:44:24-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has quit [Quit: ancestral]
20170622 23:44:48-!- ancestral [~anonymous@75-161-194-127.mpls.qwest.net] has joined #wesnoth-dev
20170622 23:48:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170622 23:50:27< celticminstrel> vultraz_iOS: So you're telling me you merged in my floating textbox and it works in your branch?
20170622 23:50:44< vultraz_iOS> celticminstrel: no I'm saying I started from scratch and it's mostly working
20170622 23:51:12< celticminstrel> Aww.
20170622 23:51:14< vultraz_iOS> your branch was too old and not exactly the direction in which I wanted to go
20170622 23:51:18< celticminstrel> Did you look at my branch at all?
20170622 23:51:21< vultraz_iOS> I did
20170622 23:51:28< celticminstrel> What's different about your direction then?
20170622 23:51:36< vultraz_iOS> singleton command console
20170622 23:51:41< celticminstrel> Also, even if it was a different direction, did it help at all?
20170622 23:52:03< celticminstrel> If you're using a singleton, I hope the checkbox doesn't always show.
20170622 23:52:15< vultraz_iOS> i haven't implemented the textbox yet
20170622 23:52:15< celticminstrel> Also, was this with OpenGL or did you revert that?
20170622 23:52:17< vultraz_iOS> er
20170622 23:52:18< vultraz_iOS> checbox
20170622 23:52:20< vultraz_iOS> checkbox
20170622 23:52:26< vultraz_iOS> OGL is cordoned off
20170622 23:52:42< vultraz_iOS> I can't do it myself and as you saw jyrki will be busy for awhile
20170622 23:53:02< vultraz_iOS> plus zookeeper wants me to finish things as quickly as possible
20170622 23:53:11< vultraz_iOS> learning OGL would take too long
20170622 23:53:32< celticminstrel> Um, I don't see why it matters how quickly you finish?
20170622 23:53:45< celticminstrel> Or have you decided to push 1.14 back to the end of the year?
20170622 23:54:09< vultraz_iOS> I have not decided yet.
20170622 23:54:23< celticminstrel> I'm not recommending it.
20170622 23:56:17< vultraz_iOS> anyway, im trying to figure out how to get all the appropriate callbacks set up here..
20170622 23:57:00< vultraz_iOS> celticminstrel: this is my design https://pastebin.com/GXpK6SWn
--- Log closed Fri Jun 23 00:00:10 2017