--- Log opened Fri Mar 04 00:00:58 2016
20160304 00:03:53-!- wario [~wario_@unaffiliated/wario] has quit [Quit: Leaving]
20160304 01:30:50-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth
20160304 02:35:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160304 02:35:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth
20160304 03:20:22-!- ArneBab [~quassel@55d44874.access.ecotel.net] has joined #wesnoth
20160304 03:24:15-!- ArneBab_ [~quassel@55d4100e.access.ecotel.net] has quit [Ping timeout: 246 seconds]
20160304 04:28:33-!- HeyCitiz` [~HeyCitize@STTRPQ3809W-LP140-03-1177721983.dsl.bell.ca] has quit [Ping timeout: 250 seconds]
20160304 04:33:44-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Ping timeout: 250 seconds]
20160304 04:34:10-!- HeyCitizen [~HeyCitize@STTRPQ3809W-LP140-03-1177721983.dsl.bell.ca] has joined #wesnoth
20160304 04:37:21-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth
20160304 04:39:18-!- daeath [~toothless@162.208.11.57] has joined #wesnoth
20160304 04:39:20-!- daeath [~toothless@162.208.11.57] has quit [Read error: Connection reset by peer]
20160304 04:39:41-!- daeath [~toothless@162.208.11.57] has joined #wesnoth
20160304 04:44:12-!- daeath [~toothless@162.208.11.57] has left #wesnoth []
20160304 04:54:14-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160304 05:04:43-!- Waste [~Cracker@blk-138-75-91.eastlink.ca] has joined #wesnoth
20160304 05:25:19-!- DreadKnight [~DreadKnig@unaffiliated/dreadknight] has joined #wesnoth
20160304 05:26:43-!- Waste [~Cracker@blk-138-75-91.eastlink.ca] has quit [Quit: Leaving]
20160304 05:48:11-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160304 06:02:12-!- Kwandulin [~Miranda@p200300760F0BD430893693D142112FFF.dip0.t-ipconnect.de] has joined #wesnoth
20160304 06:11:52-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth
20160304 07:33:40-!- Alduin_ [~Alduin@2001:4ca0:4fff:1::1f] has joined #wesnoth
20160304 07:36:29-!- Kwandulin [~Miranda@p200300760F0BD430893693D142112FFF.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]
20160304 07:43:12-!- Smedles [~quassel@58.160.136.199] has quit [Ping timeout: 240 seconds]
20160304 08:08:21-!- Alduin_ [~Alduin@2001:4ca0:4fff:1::1f] has quit [Quit: Leaving]
20160304 08:10:45-!- Smedles [~quassel@58.160.136.199] has joined #wesnoth
20160304 08:37:17-!- Alduin_ [~Alduin@2001:4ca0:4fff:1::b0] has joined #wesnoth
20160304 08:38:49-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 252 seconds]
20160304 08:59:29-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth
20160304 09:18:49-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160304 09:24:48-!- irco [~irco@HSI-KBW-078-042-015-165.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth
20160304 09:25:17-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth
20160304 10:02:29-!- celticminstrel is now known as celmin|sleep
20160304 10:29:31-!- Haldrik [~haldrik@unaffiliated/haldrik] has joined #wesnoth
20160304 10:36:47-!- Nean [~elouin@fob.spline.inf.fu-berlin.de] has quit [Ping timeout: 268 seconds]
20160304 11:11:51-!- Nean [~elouin@fob.spline.inf.fu-berlin.de] has joined #wesnoth
20160304 11:28:25< DeFender1031> here's a weird one that I wonder if anyone can help me with. I don't have portrait images yet for a certain unit, so currently it does the thing where the image for her speaking defaults to using her sprite. This is all fine. However, I have a point during my scene where I'm using [modify_unit] to advance her (exactly how {ADVANCE_UNIT} does it, but with an added "variation=" because she's a variation), and after that point, 
20160304 11:28:26< DeFender1031> when she speaks, it uses her sprite from before the advancement, and in addition, it doesn't recolor the magenta anymore. Meaning, at the start of the scene, she's type A variation 1 belonging to a player whose color is white, and when she speaks, it shows a white colored sprite for A1. Then I advance her to type B, variation 2, and after that point, it shows a MAGENTA colored sprite, but still for A1. Anyone have any idea what 
20160304 11:28:28< DeFender1031> i'm doing wrong and how to fix it?
20160304 11:30:33< zookeeper> so are you setting their portrait to the sprite, or doing nothing to set it?
20160304 11:30:40< DeFender1031> nothing at all
20160304 11:31:09< zookeeper> well that sounds odd, give me a minute...
20160304 11:31:12< DeFender1031> at least, i checked both the unit definition and creation and i can't find anywhere that i'm setting it.
20160304 11:31:38< DeFender1031> while you're doing whatever you're doing, i'll check one more time
20160304 11:33:26< DeFender1031> nope. searched for instances of "portrait" and "profile" in both places. all are either commented out with a TODO or referring to something else in the scenario entirely
20160304 11:34:18< zookeeper> seems to work correctly for me, at least when advancing naturally from combat
20160304 11:35:04< zookeeper> maybe try that, to see if that makes a difference
20160304 11:35:40< DeFender1031> can't, it's not a combat scenario, it's a cutscene and there aren't even any enemies
20160304 11:36:26< DeFender1031> oh, and the one she's advancing from doesn't acttually advance naturally into what she's advancing to
20160304 11:36:51< zookeeper> make it a combat scenario, :debug and right-click to create an enemy, :unit experience=99 to set XP, fight -> advance
20160304 11:38:11< zookeeper> i can't say more when i don't know what exactly you're doing
20160304 11:40:50< DeFender1031> i'm using [modify_unit]
20160304 11:41:49< DeFender1031> let's try a different approach. is there a way for me to easily print the entire contents of a container variable to some debug output?
20160304 11:42:09< DeFender1031> this way i could store_unit and then see what data is actually in there
20160304 11:42:33< zookeeper> easiest is to use :inspect
20160304 11:42:51< DeFender1031> what does that do?
20160304 11:43:10< zookeeper> show you everything
20160304 11:43:14< zookeeper> first :debug, then :inspect
20160304 11:43:15< zookeeper> https://wiki.wesnoth.org/CommandMode
20160304 11:43:46< DeFender1031> ah
20160304 11:43:47< DeFender1031> thanks
20160304 11:44:40< zookeeper> there's no way that i know to output a whole container to the log, so :inspect is good for looking over those
20160304 11:46:07< DeFender1031> yeah, that's basically even better than what i needed
20160304 11:46:09< DeFender1031> thanks
20160304 11:46:16< DeFender1031> now to see what's going wrong.
20160304 11:48:24< DeFender1031> yeah, for some reason somehow she's being assigned a profile and a small profile directly to her unit, and for some reason changing her type isn't updating those.
20160304 11:49:49< DeFender1031> interesting... her hitpoints and experience are also still where they were.
20160304 11:50:23< DeFender1031> seems like {ADVANCE_UNIT} doesn't actually behave the same way that actually advancing a unit does :(
20160304 11:51:42< DeFender1031> and this isn't because i'm using a variation... tried it without. anything I use it on only has SOME of their data updated appropriately.
20160304 11:54:07< zookeeper> try TRANSFORM_UNIT and see if it fixes the profile issue
20160304 11:54:52< zookeeper> (takes the same arguments)
20160304 11:55:32< zookeeper> it won't touch hp,xp,status, but i think it'll probably handle the profile right
20160304 11:59:43< zookeeper> or, set the unit's XP to max_experience and their advances_to to what you want, and then unstore with advance=yes
20160304 12:00:04< zookeeper> that's probably the most hassle-free way
20160304 12:04:08< DeFender1031> i could do that, but {ADVANCE_UNIT} (and the underlying [modify_unit] SHOULD work. I just tested it with the example given and it DOES work right. So the question is really why it works right with Spearmen and Cavalrymen but not with my custom units
20160304 12:04:35< DeFender1031> i could just do what you said, but this would seem to indicate a more pervasive problem with how i'm doing my units
20160304 12:04:54< DeFender1031> (which may end up causing more issues than just this)
20160304 12:05:14< zookeeper> profiles are handled specially upon advancement (so that a single unit with a unique portrait doesn't lose it on advancement), and that's most likely what [modify_unit] fails to take into account
20160304 12:07:05< zookeeper> maybe vultraz wants to fix it
20160304 12:07:20< vultraz> what
20160304 12:07:22< vultraz> ?
20160304 12:07:49< DeFender1031> zookeeper, except that i'm not actually setting the profile. in addition, i noticed that the hp and xp aren't changing either
20160304 12:07:53< DeFender1031> (meaning the max)
20160304 12:08:03< DeFender1031> which they DO change with the built-in units i tested
20160304 12:08:14< DeFender1031> which means that it must be something i've done wrong
20160304 12:09:20< DeFender1031> meaning, i tested the actual example given for ADVANCE_UNIT. there, the profile, xp, hp, etc. all update properly as one would expect. not so with my stuff
20160304 12:09:42< zookeeper> if that's true, then there must be a difference.
20160304 12:10:13< vultraz> zookeeper: explain the problem to me
20160304 12:11:39< zookeeper> there's some kind of problem. i don't know.
20160304 12:11:44 * zookeeper blames 47ed3148
20160304 12:13:28< zookeeper> because at the very least it must have broken the "" usecase and documentation
20160304 12:14:14< zookeeper> i'm surprised we apparently still don't have a clean forced advancement thingy
20160304 12:14:53< vultraz> DeFender1031: please explain the problem to me
20160304 12:15:24< zookeeper> i guess one can summarize it as ADVANCE_UNIT not working.
20160304 12:15:31< DeFender1031> ah, well i just did some more tests and the problem is not quite as i described before, so i'll give it a shot.
20160304 12:17:26< DeFender1031> {ADVANCE_UNIT} uses [modify_unit] internally, so this is really about how [modify_unit] works. Basically, I have a custom unit type where i haven't set a profile image yet. It defaults to using the character sprite for that. However, when [modify_unit] is called to change a unit of my custom type into another, the profile image remains the one from the previous type. In addition, it now displays with the magenta rather than 
20160304 12:17:28< DeFender1031> being team-recolored.
20160304 12:18:14< zookeeper> ...and i theorized that [modify_unit] doesn't handle profile= as it should
20160304 12:18:31< DeFender1031> {MODIFY_UNIT}, which does some crazy [store_unit] stuff internally, is even worse, as it will leave stuff like max hp and experience needed to advance as those belonging to the base unit as well
20160304 12:19:40< zookeeper> oh wait, "" does work right after all. how odd.
20160304 12:20:30< vultraz> yes, our interface for changing types is messy
20160304 12:21:44< zookeeper> 1.12 ADVANCE_UNIT works just right for me, it seems
20160304 12:22:23< DeFender1031> vultraz, so what's the cleanest way to change the type A: and show the advancement animation B: instantly, such that both A and B take all the necessary data from the new type and such that they behave identically aside from whether they show the animation or not?
20160304 12:22:36< DeFender1031> i would imagine that [modify_unit] is on the right track for both
20160304 12:22:51< DeFender1031> seems that that only screws up the profiles, and only when they aren't explicitly set
20160304 12:22:51< vultraz> transform_unit
20160304 12:23:33< zookeeper> hp, etc
20160304 12:23:43< DeFender1031> transform_unit increases the max hp and xp, but leaves the current level the same. that's not what i want (though i suppose i could follow it up with a full heal and a reset xp to 0)
20160304 12:24:40< DeFender1031> i'm thinking though that maybe [modify_unit] is correct, and i should follow that up with a fix to the profile image, and then if i don't want the animation, just stick the unit into recall before doing it and pull it out again after.
20160304 12:25:26< vultraz> you can reset stats in transform, unit
20160304 12:25:29< vultraz> transform_unit
20160304 12:25:55< zookeeper> what?
20160304 12:26:02< zookeeper> citation needed
20160304 12:27:03< zookeeper> DeFender1031, i've tried exactly what you've described: using ADVANCE_UNIT to advance a single unit without a given profile and no unit type profile into a unit type it can't normally advance to, and the correct sprite with correct TC appears in messages both before and after.
20160304 12:27:12< zookeeper> 1.12.5
20160304 12:28:55< DeFender1031> zookeeper, then i'm totally confused.
20160304 12:29:39< DeFender1031> i'm on 1.12.4
20160304 12:30:58< DeFender1031> zookeeper, you're advancing both from and to a type which doesn't set a profile?
20160304 12:31:42< vultraz> oh, hm, you can't
20160304 12:34:01< zookeeper> DeFender1031, yes
20160304 12:34:27< DeFender1031> okay, i think i finally found the issue
20160304 12:34:32< DeFender1031> she's a variation
20160304 12:34:38< DeFender1031> using inherit=yes
20160304 12:34:55< DeFender1031> apparently, that means that she EXPLICITLY inherits the IMPLICIT profile from the base unit
20160304 12:35:05< DeFender1031> when i remove the variation, she works fine.
20160304 12:38:08< DeFender1031> which is weird, because that wasn't the case earler
20160304 12:38:19< zookeeper> sounds plausible enough
20160304 12:40:32< DeFender1031> hmm... even when i explicitly set the profile images for her variation on both, it STILL stays the previous one... i think i'll have to do it at the unit level :(
20160304 12:44:10< DeFender1031> or i may just switch her to being a unit with a base unit rather than a variation
20160304 12:44:23< DeFender1031> seems variation is causing more trouble than it's worth
20160304 12:48:05< zookeeper> or you can just give her an [object] with [effect] apply_to=profile image=unit_image or whatever it was from the get-go and it should carry over across all type changes and such
20160304 12:50:54< DeFender1031> hmmm
20160304 12:51:21< DeFender1031> true, but then i'll also have to add all sorts of hacks for when she DOES advance naturally through compat
20160304 12:51:24< DeFender1031> combat*
20160304 12:55:56< zookeeper> why?
20160304 13:23:47-!- prkc [~prkc@46.166.188.227] has quit [Ping timeout: 260 seconds]
20160304 13:38:05-!- prkc [~prkc@108.61.123.68] has joined #wesnoth
20160304 14:06:43-!- Haudegen [~quassel@85.124.51.57] has quit [Remote host closed the connection]
20160304 14:14:19-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth
20160304 14:16:05-!- Haudegen [~quassel@85.124.51.57] has quit [Remote host closed the connection]
20160304 14:16:43-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth
20160304 14:23:15-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth
20160304 14:23:53< DeFender1031> zookeeper, because the image needs to be updated when she advances?
20160304 14:24:33-!- Haudegen [~quassel@85.124.51.57] has quit [Remote host closed the connection]
20160304 14:26:52< zookeeper> DeFender1031, and that should do the trick
20160304 14:27:40< DeFender1031> no, meaning her advanced form has a different sprite than the base form
20160304 14:27:52< zookeeper> i know
20160304 14:28:15< zookeeper> i'm not saying i know for sure that's not buggy too.
20160304 14:37:10< zookeeper> and in case it was unclear, when i said unit_image i meant unit_image
20160304 14:41:39< DeFender1031> huh?
20160304 14:42:53< DeFender1031> whatever, my point is that it means that the image will need to be updated when she advances
20160304 14:44:00< zookeeper> if you say so. i'm not buying it :p
20160304 14:45:36< DeFender1031> ohhhh
20160304 14:45:51< DeFender1031> you mean LITERALLY say "image=unit_mage"
20160304 14:45:51-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth
20160304 14:46:06< DeFender1031> not "image=whatever_my_image_is"
20160304 14:46:16< DeFender1031> uhdoy!
20160304 14:46:30< DeFender1031> yeah, that makes sense actually
20160304 14:50:41< DeFender1031> zookeeper, thanks. that worked. sorry i doubted/misunderstood you.
20160304 14:54:05< DeFender1031> actually, explicitly setting profile and small_profile to unit_image on the variation itself did it.
20160304 14:54:22< DeFender1031> no need for the object
20160304 14:54:39< DeFender1031> weird that the implicit declaration doesn't do the same thing
20160304 14:55:49< DeFender1031> gotta go... i'll be back tomorrow.
20160304 14:55:54-!- DeFender1031 [~DeFender1@89-139-31-110.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20160304 15:15:09-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 248 seconds]
20160304 15:21:17-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth
20160304 15:36:29-!- irco [~irco@HSI-KBW-078-042-015-165.hsi3.kabel-badenwuerttemberg.de] has quit [Ping timeout: 268 seconds]
20160304 15:36:43-!- irco [~irco@HSI-KBW-078-042-015-165.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth
20160304 15:55:27-!- Appleman1234 [~Appleman1@KD106161136215.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20160304 16:02:33-!- Kwandulin [~Miranda@p200300760F0BD4977DB89C8645B828CE.dip0.t-ipconnect.de] has joined #wesnoth
20160304 16:36:37-!- celmin|sleep is now known as celticminstrel
20160304 16:44:14-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160304 17:05:58-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 244 seconds]
20160304 17:30:09-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth
20160304 17:42:16-!- shurnormal [~uxio@unaffiliated/ushiu] has joined #wesnoth
20160304 17:58:20-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth
20160304 18:15:54-!- claymore2 [~hexchat@host86-167-29-40.range86-167.btcentralplus.com] has joined #wesnoth
20160304 18:36:33-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth
20160304 18:42:02-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160304 19:42:12-!- Waste [~Cracker@blk-138-75-115.eastlink.ca] has joined #wesnoth
20160304 19:44:52-!- Waste [~Cracker@blk-138-75-115.eastlink.ca] has quit [Client Quit]
20160304 20:09:44-!- irco [~irco@HSI-KBW-078-042-015-165.hsi3.kabel-badenwuerttemberg.de] has quit [Ping timeout: 250 seconds]
20160304 20:10:07-!- irco [~irco@HSI-KBW-078-042-015-165.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth
20160304 20:52:13-!- Alduin_ [~Alduin@2001:4ca0:4fff:1::b0] has quit [Ping timeout: 248 seconds]
20160304 21:05:16-!- Alduin_ [~Alduin@p200300864450A900E29467FFFE0EE8C4.dip0.t-ipconnect.de] has joined #wesnoth
20160304 21:06:24-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160304 21:11:57-!- Alduin_ [~Alduin@p200300864450A900E29467FFFE0EE8C4.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]
20160304 21:12:03-!- DreadKnight [~DreadKnig@unaffiliated/dreadknight] has quit [Quit: #AncientBeast - Master Your Beasts ( www.AncientBeast.com )]
20160304 21:37:26-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth
20160304 21:38:43-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has left #wesnoth []
20160304 21:45:37-!- louis94 [~~louis94@91.178.241.95] has joined #wesnoth
20160304 22:14:11-!- Kwandulin [~Miranda@p200300760F0BD4977DB89C8645B828CE.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160304 22:42:12-!- oldlaptop [~quassel@50-37-53-169.mskg.mi.frontiernet.net] has quit [Read error: Connection reset by peer]
20160304 23:00:47-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth
20160304 23:01:58-!- ancestral [~ancestral@63.92.240.233] has quit [Client Quit]
20160304 23:12:35-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth
20160304 23:12:56-!- claymore2 [~hexchat@host86-167-29-40.range86-167.btcentralplus.com] has quit [Quit: Leaving]
20160304 23:14:43-!- irco [~irco@HSI-KBW-078-042-015-165.hsi3.kabel-badenwuerttemberg.de] has quit [Ping timeout: 248 seconds]
20160304 23:32:32-!- louis94 [~~louis94@91.178.241.95] has quit [Quit: Konversation terminated!]
20160304 23:55:39-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
--- Log closed Sat Mar 05 00:00:42 2016