#exult@irc.freenode.net logs for 21 Mar 2014 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:46:24] <-- Baastuul has left IRC ()
[01:02:32] --> Rottingbeef has joined #exult
[02:02:52] <-- Marzo has left IRC (Ping timeout: 246 seconds)
[02:46:24] <-- Dominus has left IRC (Ping timeout: 252 seconds)
[02:51:28] --> Dominus has joined #exult
[02:51:28] --- ChanServ gives channel operator status to Dominus
[03:17:49] <-- i30817 has left IRC (Quit: ChatZilla [Firefox 28.0/20140226081007])
[04:36:57] --> Marzo has joined #exult
[08:01:53] --> i30817 has joined #exult
[08:02:08] <i30817> i think there is a sound bug on combat.cc
[08:02:18] <i30817> if you attack a non-monster npc
[08:02:48] <i30817> the combat music will never stop until you enter combat with a monster or enter a music egg
[08:03:54] <i30817> this seems to be because only in Combat_schedule::monster_died there is a chance of that music being replaced
[08:04:15] <i30817> while in Combat_schedule::stop_attacking_npc will not start another music
[08:04:28] <i30817> did the original behave this way?
[08:05:42] <i30817> anyway, would you maintainers accept a simple combat music disabling patch?
[08:05:57] <i30817> i was working on it when i noticed this bug
[08:12:07] <sh4rm4> i30817, i'm pretty sure they will if you come up with a patch
[08:13:03] <i30817> working on it
[08:14:01] <i30817> i'm also putting Audio::get_ptr()->stop_music(); on those branches of the combat state machine, that's annoying (Audio::get_ptr()->stop_music() because attacking a npc doesn't merit a fanfare).
[08:20:44] <Dominus> that bug sounds interesting...
[08:22:23] <i30817> well, the 'easy' solution didn't work. It's not called at all from actors.cc
[08:22:25] <i30817> You can test it easy by starting blackgate hackmove out of the city and attack the horses near the swamp
[08:22:56] <i30817> kill the horse. The music never stops
[08:24:04] <i30817> hmm actually it worked now (the work around). I hadn't compiled lol
[08:31:15] <i30817> strangely only charmed state and asleep appear to call stop_attacking_npc although the functon comment says it's for death also
[08:33:14] <i30817> possibly my ugly and buggy workaround 'worked' because the horse fell unconscious before dying, i don't know the mechanics of this
[08:39:59] <i30817> anyway, i better bug report this, since i don't dare touch it. It might be a consequence of the 'looping' setting which wasn't in the original game right?
[08:42:28] <Dominus> yes, could be the looping
[08:43:11] <Dominus> have you turned that off?
[08:43:31] <Dominus> i'm afk ;(
[08:50:21] <i30817> no i haven't. It makes sense that would limit the combat music so that maybe the original code didn't bother to stop it. Let me test it
[08:51:02] <i30817> err, once i remove my hack
[08:53:43] <i30817> yeah, without the looping it 'eventually' stops
[08:54:29] <i30817> it would be nice if those songs in particular could have their looping be dependent on the enemies around
[08:54:58] <i30817> although that actors.cc state machine will do the job well enough if it is repaired.
[08:55:38] <i30817> It will not be as 'natural' though. Once every hostile dies or falls asleep, *bang* music stopped
[08:56:04] <i30817> how does the original behave?
[09:00:54] <i30817> form my combat music patch i had to create a very similar function to 'Game_window::is_hostile_nearby', because that one only works for 'evil' enemies (Actor::evil) and has some interference with god mode (apparently if you're in god mode, you never have hostile nearby lol!). This is probably because this function is used to limit movement of the avatar... but then it probably should have a...
[09:00:55] <i30817> ...better name 'avatar_needs_to_slow_down()' or something, wouldn't make me think i could have used it.
[09:06:53] <i30817> wait a minute. This might actually be my fault.
[09:07:30] <i30817> mmm. now i did it from the start without going into the options gump and even with looping it 'eventually' stopped
[09:11:45] <i30817> I think... the bug is on AudioOptions_gump::save_settings, it starts the 'previous' music to the 'loop' if the *global* looping option is set
[09:12:28] <i30817> problem is, some music, like combat, is started purposefully with that option set to false, regardless of the global setting
[09:12:53] <i30817> so its not my fault, but me screwing around there made it obvious
[09:15:14] <i30817> Is there any way to query the looping behaviour of a single song?
[09:34:33] <i30817> mixer->getMidiPlayer()->is_repeating();
[09:34:55] <i30817> ok this is solvable for both my patch and exult proper if you decide not to accept it
[09:37:02] <-- sh4rm4 has left IRC (Remote host closed the connection)
[09:40:57] --> sh4rm4 has joined #exult
[09:49:54] --> Malignant_Manor has joined #exult
[10:29:48] <-- Malignant_Manor has left IRC (Quit: ChatZilla [Firefox 27.0.1/20140212131424])
[11:51:20] --> TheCycoONE has joined #exult
[12:44:31] <-- Kirben has left IRC ()
[13:24:34] <i30817> i posted the skip combat song on sourceforge
[13:24:45] <i30817> sleep now
[13:24:48] <-- i30817 has left IRC (Quit: ChatZilla [Firefox 28.0/20140226081007])
[18:21:17] <-- MisterBubbles has left IRC (Ping timeout: 252 seconds)
[18:22:22] --> MisterBubbles has joined #exult
[19:38:51] <-- sh4rm4 has left IRC (Remote host closed the connection)
[19:43:01] --> sh4rm4 has joined #exult
[20:27:04] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[21:25:02] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[22:28:47] --> Kirben has joined #exult
[22:28:47] --- ChanServ gives channel operator status to Kirben