[02:14:38] <-- |Cable| has left IRC (Ping timeout: 256 seconds)
[02:28:00] --> |Cable| has joined #gemrb
[02:32:40] <-- vampi-the-frog has left IRC (Quit: Leaving)
[03:14:39] <-- Gekz` has left IRC (Remote host closed the connection)
[03:15:02] --> Gekz has joined #gemrb
[03:17:19] <-- Gekz has left IRC (Read error: Connection reset by peer)
[05:40:21] --> Gekz has joined #gemrb
[07:23:50] --- ermo^ is now known as ermo
[07:50:33] --> WingedHussar has joined #gemrb
[08:27:10] --- ermo is now known as ermo^
[15:00:50] --> brada has joined #gemrb
[15:01:36] <brada> psch: can't you just run a dialog in a loop at a point prior to gemrb terminating?
[15:03:32] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:09:36] --- ermo^ is now known as ermo
[15:10:39] <psch> as in, after returning from the sdl thread but before exiting the activity?
[15:11:17] <psch> i don't know, i guess it's possible
[15:11:25] <psch> i'll have a look
[15:20:41] <psch> i don't think i can; when the sdl thread closes, the app closes, and when that happens it collects all it's children
[15:21:23] <psch> at least im not seeing how; i can't run a blocking dialog in android, from what my googling tells me
[15:25:01] <-- brada has left IRC (Quit: brada)
[15:39:58] --> brada has joined #gemrb
[15:40:18] <brada> psch: no, i mean running the dialog in a loop inside the android logger class a la ios/mac
[15:40:55] <fuzzie> you can't technically do that
[15:41:08] <brada> no?
[15:41:09] <fuzzie> you'd get killed for stalling on the main thread
[15:41:15] <brada> ah
[15:41:39] <fuzzie> so you'd presumably have to rather invasively mess with SDL's activity, or else make a new one
[15:41:43] <fuzzie> it looks annoying
[15:41:55] <brada> well he could use the sdl2 alert box
[15:42:04] <brada> afik it works on android
[15:44:03] <brada> i guess no
[15:44:23] <psch> no as in doesn't work on android?
[15:44:29] <brada> well, hang on
[15:44:33] <psch> alright
[15:44:34] <brada> it should work on android
[15:44:44] <fuzzie> well this should be easy enough to see
[15:44:45] <brada> i just dont know if it will work before teh video system is inited
[15:45:09] <brada> and i cant seem to remember the function name :/
[15:45:10] <fuzzie> what *is* the alert box?
[15:45:23] <brada> i will link you when i find it :p
[15:45:42] <fuzzie> SDL_ShowMessageBox
[15:45:54] <fuzzie> implemented as SDL_SetError("No message system available");
[15:45:57] <fuzzie> probably not very helpful
[15:46:01] <brada> heh
[15:46:15] <brada> so its not implemented on android?
[15:46:17] <fuzzie> works on windows/cocoa/uikit/x11
[15:46:27] <brada> bah
[15:46:28] <fuzzie> those are hardcoded into SDL_video.c
[15:50:09] <brada> if they are in SDL_video does that mean they require the video system to be initialized before use?
[15:50:18] <brada> not that it matters since he cant use it?
[15:50:25] <fuzzie> no, they're just calling into the OS I think
[15:50:40] <fuzzie> which is rather more of a pain when the API is in Java, so understandable
[16:00:16] --> fizzle has joined #gemrb
[16:04:40] <fizzle> is there a good way to check whether an actor is "the same" as another?
[16:05:10] <fuzzie> can't you just compare pointers? :)
[16:05:13] <fizzle> what I'm interested in is whether they came from the same CRE, really, but that info's not kept
[16:05:14] <brada> im guessing you dont mean the same actor object
[16:05:24] <fuzzie> why do you need that..?
[16:05:48] <fizzle> because the replacement actor code is acting funny
[16:06:00] <fizzle> and respawning the same actor over and over
[16:06:41] <fizzle> I'm currently simply comparing levels and that probably works fine as an approximation
[16:07:06] <brada> you could temporarily add a field to store the name of the file
[16:07:10] <brada> right?
[16:07:31] <fizzle> temporarily wouldn't be enough
[16:07:55] <fizzle> and I don't know if we really want to carry that around just for an edge case
[16:08:03] <brada> wouldnt be enough?
[16:08:36] <fizzle> you'd need to be able to check that an actor spawned "sometime" is the same as an actor you want to spawn now
[16:08:56] <fizzle> that pretty much means you need to keep the info around indefinitely
[16:09:29] <brada> but you just need it for debugging
[16:09:36] <fizzle> no
[16:09:40] <fuzzie> then you're doing it wrong
[16:10:16] <fizzle> CheckForReplacementActor is doing it wrong :P
[16:11:23] <fuzzie> so what's the problem with it?
[16:12:27] <fizzle> in short: if (currentActorLevel < partyLevel) find replacement, spawn it and add to map
[16:12:30] <fuzzie> it reads like "if NPC hasn't been in party, and NPC is not dead, and they are below party level, upgrade them on map load"
[16:13:10] <fizzle> however, if replacementLevel is also < partyLevel then it gets replaced again AND placed on the map again
[16:13:16] <fizzle> and you have two clones
[16:13:42] <fizzle> and that gets repeated again and again and again each time a party member MoveToArea's
[16:14:06] <fuzzie> well, you shouldn't get any clones
[16:14:20] <fizzle> you do, because each gets added to the map
[16:14:33] <fuzzie> yes, but I mean that's clearly the fix, right?
[16:14:51] <fuzzie> you only want to keep the last actor
[16:15:13] <fizzle> one possible fix, but even better would be not to replace it in the first place, IMO
[16:15:26] <fuzzie> yes, except you *have* to replace it
[16:15:32] <fuzzie> since that's kind of the whole point
[16:15:39] <fuzzie> so that has to be dealt with anyway, right?
[16:15:49] <fizzle> not if it's already the same
[16:16:02] <fuzzie> yes, but only considering the other case for now
[16:16:14] <fizzle> the other case works fine as is
[16:16:28] <fuzzie> so then I totally don't understand the problem
[16:16:56] <fuzzie> how would you get two clones in this case but not in the other case?
[16:17:09] <fizzle> say a party of 6 enters the copper coronet
[16:17:47] <fizzle> party has an average level of 7, NPC anomen has level 4
[16:17:51] <fuzzie> i mean, a better question is
[16:17:53] <fuzzie> is there actually a bug here?
[16:18:00] <fuzzie> like, one which breaks things
[16:18:00] <fuzzie> ?
[16:18:04] <fizzle> yes, obviously
[16:18:11] <fuzzie> ok. so, go on.
[16:18:22] <fizzle> I have 6 anomens, 6 nalias, and 6 korgans in copper coronet
[16:18:28] <fuzzie> right
[16:18:33] <fuzzie> what does this have to do with them being replaced?
[16:18:50] <fizzle> okay, let me continue my hypothetical example
[16:19:18] <fizzle> we check the npc 2da which has anomen6.cre as a replacement
[16:19:39] <fizzle> so we spawn that and add it to the map, fine
[16:19:45] <fuzzie> what happens to the old anomen?
[16:20:16] <fizzle> gets removed, or rather, not added to the area
[16:20:41] <fizzle> now the second party member MovesToArea
[16:20:42] <fuzzie> right
[16:20:57] <fuzzie> so I still don't see why you think the bug is like this
[16:21:03] <fizzle> we find anomen6, which is level 6 while the party is level 7
[16:21:04] <fuzzie> it seems the bug is, we do this when we're not loading the map.
[16:21:22] <fuzzie> and it coincidentally works ok for non-replacements because Map::AddActor has a sanity check.
[16:22:33] <fizzle> not sure if that's coincidence
[16:22:54] <fizzle> you could fix it at any number of places, to be sure
[16:23:02] <fuzzie> well, you don't seem to be proposing to fix it at all
[16:23:32] <fizzle> not replacing the actor if unnecessary would actually fix it
[16:23:33] <fuzzie> if the party happens to level up and you get some actor to leave and come back, it'll still break, right?
[16:23:55] <fizzle> why would it?
[16:24:03] <fuzzie> because you have a new different actor to upgrade to
[16:24:19] <fizzle> but that works fine
[16:24:22] <fuzzie> so it won't be an identical actor, and this code will still break
[16:24:30] <fuzzie> because the old NPC is still on the map
[16:24:46] <fizzle> no, the old actor doesn't get added if it's replaced
[16:24:51] <fuzzie> but it's already there
[16:25:01] <fuzzie> because the map is still loaded if you just get an actor to leave and come back
[16:25:24] <fuzzie> so it doesn't matter that you don't get a sanity-checked AddActor call
[16:25:41] <fizzle> ah, yes, you might be right in that case
[16:26:09] <fuzzie> i mean replacing the actor repeatedly is *dumb*
[16:27:32] <fuzzie> but really I'd be surprised if this code is correct anyway
[16:30:42] <fuzzie> i'd have to check some original saves to see what they doo
[16:31:51] <fizzle> I'll play with moving the code to on-load only
[16:32:07] <fuzzie> you can just delete the line avenger added i think
[16:32:26] <fuzzie> obviously that makes it not level-up if the map is still loaded, but that's sort of a corner-case
[16:34:11] <fuzzie> it's sort of tangental but if the original engine stores the creature resrefs we should too..
[16:34:46] <fuzzie> the comment says it stored a '*' though
[16:39:09] <brada> whats up with the error() calls there?
[16:39:18] <brada> didnt we replace those all with Log()
[16:43:14] <fizzle> there's lots of non-Log statements left
[16:43:45] <fuzzie> surely that would be silly
[16:43:56] <brada> why?
[16:44:02] <fuzzie> because we added error() at the same time
[16:44:05] <fuzzie> for this exact reason
[16:44:51] <fizzle> just removing the PlacePersistents for already loaded maps works fine in the standard case at least
[16:45:07] <brada> as long as error reports to the logging system i dont care
[16:45:10] <fuzzie> yes
[16:45:13] <brada> i thought it was the original function
[16:45:13] <fuzzie> that's what it's for
[16:45:15] <fuzzie> it logs and then exits :)
[16:46:12] <fuzzie> looks like it was added *before* the Log function, but after the split out of Logging.h etc
[16:46:44] <fuzzie> i mean, to be clear, it *does* exit
[16:47:30] <fuzzie> so probably most of the error()s should be replaced with some actual error code
[16:47:32] <brada> yeah i was just confused by thinking it was the function that was used before the logging system was in place
[16:47:37] <fuzzie> but we don't have any nice way to do that I think
[17:41:56] --> Yoshimo has joined #gemrb
[17:59:37] --> edheldil_ has joined #gemrb
[18:14:11] --> kingron has joined #gemrb
[18:40:38] --> vampi-the-frog has joined #gemrb
[19:11:19] --> ronsen has joined #gemrb
[19:14:30] <-- kingron has left IRC (Ping timeout: 264 seconds)
[19:38:04] <-- vampi-the-frog has left IRC (Remote host closed the connection)
[19:40:53] --> edheldil__ has joined #gemrb
[20:06:30] <fizzle> hm, something seems to be wrong with the staff of thunder and lightning
[20:07:00] <fizzle> whenever I hit something, all party members get hit by 8 points of damage
[20:07:09] <fuzzie> shiny
[20:07:25] <fuzzie> targeting issue I expect? :)
[20:07:27] <fizzle> does not look like a desirable weapon
[20:07:28] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:07:39] <fuzzie> well, it depends how *much* damage it does
[20:07:50] <fizzle> not that much
[20:07:57] <fizzle> and its effect should be stun, anyway
[20:08:57] <fizzle> it has its projectile set to inareapa, though
[20:09:00] <fizzle> that looks odd
[20:16:21] <-- brada has left IRC (Ping timeout: 252 seconds)
[20:19:07] --> brada has joined #gemrb
[20:22:59] <fizzle> no idea how that's supposed to work
[20:33:31] <-- fizzle has left IRC (Ping timeout: 260 seconds)
[20:34:40] --> fizzle has joined #gemrb
[20:49:01] <-- nutron|w has left IRC (Changing host)
[20:49:01] --> nutron|w has joined #gemrb
[20:53:00] <Pepelka> [commit] fizzet: improve error reporting when a bag is full https://github.com/gemrb/gemrb/commit/34ec5fe835f005546c469c82e04c37020d27eb4d
[20:53:02] <Pepelka> [commit] fizzet: don't reactivate spawn points with living spawns in the area https://github.com/gemrb/gemrb/commit/7f06f2c6667da1b9689066776033d98a69a6fa18
[20:53:03] <Pepelka> [commit] fizzet: don't place persistent actors again for already loaded areas https://github.com/gemrb/gemrb/commit/245c5ee4bcd300b79124b7fd6790eb48bb7898b4
[20:53:04] <Pepelka> [commit] fizzet: fix leak when buying items from a store https://github.com/gemrb/gemrb/commit/73760ee3988152e01b0a5714cdbf982a4f53620f
[20:54:06] <fuzzie> thanks
[20:55:06] <fizzle> thank you
[21:01:08] --- ermo is now known as ermo^
[21:10:02] <fizzle> fuzzie: do you see anything in staf13 that could mean we should ignore the projectile?
[21:10:23] <fuzzie> don't have the data here :/
[21:11:05] <fizzle> would be nice if you could try to have a look later
[21:11:12] <fuzzie> sure
[21:11:21] <fuzzie> well, it'd be tomorrow now
[21:11:31] <fuzzie> if someone can throw me a copy (or ielister dump?) I could make a guess
[21:11:52] <fizzle> a copy of the itm?
[21:12:14] <fuzzie> ye
[21:14:17] <fizzle> https://dl.dropboxusercontent.com/u/7644877/STAF13.ITM
[21:15:52] <fuzzie> thanks
[21:16:26] <fuzzie> which usage, the first?
[21:16:42] <fizzle> the melee one, the third I think
[21:17:01] <fizzle> ah, no, first
[21:17:02] <fuzzie> the icon for the first is ISTAF13
[21:17:04] <fuzzie> right
[21:19:37] <fuzzie> so that's features 2/3/4, does it have a projectile attached? bit lost now
[21:20:12] <fizzle> 157, inareapa
[21:23:04] <fuzzie> oh right, and you're actually using it as a weapon
[21:23:22] <fizzle> yes, none of the magic stuff
[21:30:07] <fuzzie> i hate the projectile numbering
[21:31:11] <fuzzie> is it really 157?
[21:32:00] <fizzle> yes
[21:32:38] <fuzzie> i know there's an off-by-one in here somewhere but i don't recall where
[21:33:24] <fizzle> both NI and gemrb agree that it's inareapa
[21:33:30] <fuzzie> yes, but why?
[21:33:52] <fizzle> NI says 158 but I get 157 in gem
[21:34:04] <fuzzie> yes, so, it's 158 in the file, which would be nice, because it's party-friendly
[21:35:03] <fizzle> so it should be all BUT party?
[21:35:18] <fuzzie> yes, except i remember there's an off-by-one here soemwhere
[21:35:31] <fuzzie> so probably it actually is 157, which is inareapa
[21:36:42] <fizzle> party-friendly would make sense for the effects, but not for the actual damage, I think
[21:36:54] <fuzzie> but i don't understand why any of this happens anyway
[21:38:06] <fuzzie> oh, right, it gets returned by the itm->GetProjectile
[21:38:43] <fuzzie> hm, i have no clue
[21:41:19] <fizzle> hm
[21:41:42] <fizzle> use projectile for ranged or for effects but not for melee, maybe?
[21:42:03] <fizzle> I'm trying to find other melee weapons with projectile set
[21:42:18] <fuzzie> i think it's required
[21:42:27] <fuzzie> so if it's wrong it would be about the targeting
[21:42:55] <fuzzie> but looking for an example is the best start, i'm sure
[21:42:55] <fizzle> melee weapons seem to have projectile None usually
[21:43:49] <fizzle> throwing axes have it set for their melee ability, too
[21:44:01] <fuzzie> yes, you should be looking for magic weapons ofc
[21:44:21] <fizzle> none of the staves have it
[21:45:58] <fuzzie> yes, not sure where i'd look. halb04?
[21:46:34] <fizzle> None
[21:46:42] <fuzzie> i'm assuming you're not fixpacked
[21:46:53] <fizzle> correct
[21:49:01] <fizzle> I didn't find any mention of this in the fixpack notes, though
[21:49:23] <fuzzie> yes, i'm just guessing based on reports
[21:49:51] <-- edheldil__ has left IRC (Read error: Operation timed out)
[21:51:56] <fuzzie> it's used for projectile weapons only you think? weird. but not awake enough to think about it.
[21:52:22] <fizzle> just a guess
[21:52:46] <fizzle> but from the one example we have it could work
[21:53:43] <fizzle> still looking through the swords but haven't found any other instances yet
[21:57:17] <fizzle> none of the 1h swords has a projectile
[22:00:49] <fizzle> SW2H19: sparklgr
[22:03:34] <fizzle> enough for today though
[22:03:37] <fizzle> gn
[22:04:07] <-- fizzle has left #gemrb
[22:41:58] <-- ronsen has left IRC (Remote host closed the connection)
[23:05:19] --> vampi-the-frog has joined #gemrb
[23:20:35] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[23:23:20] --> vampirefrog has joined #gemrb