--- Log opened Thu Aug 23 00:00:21 2018 20180823 00:08:39-!- sevu [~sevu@p548557AE.dip0.t-ipconnect.de] has joined #wesnoth-umc-dev 20180823 01:45:13-!- sevu [~sevu@p548557AE.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20180823 02:00:05-!- wesdiscordbot [~wesdiscor@wesnoth/bot/discord-bridge] has quit [Remote host closed the connection] 20180823 02:00:20-!- wesdiscordbot [~wesdiscor@wesnoth/bot/discord-bridge] has joined #wesnoth-umc-dev 20180823 02:00:21-!- mode/#wesnoth-umc-dev [+v wesdiscordbot] by ChanServ 20180823 03:02:01<+wesdiscordbot> https://cdn.discordapp.com/attachments/442775044590927873/482021664947699722/ANLEra.png 20180823 03:02:20<+wesdiscordbot> vn971: ^ see this image ^ 20180823 03:02:42<+wesdiscordbot> wild guess: male and female have different advancements for this unit, it was a female one 20180823 03:02:51<+wesdiscordbot> happened upon recruit 20180823 03:04:49<+wesdiscordbot> and the GUI2 window does show the possible advancements for the male version instead 20180823 07:48:10-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev 20180823 07:49:17< vn971> sevu: thanks for sharing. But ouch - that's crazy! "Fighter" and "Archer" are totally different units aren't they? 20180823 07:49:32< vn971> Also, "Archer" and "Shaman" are totally different units as well. 20180823 07:50:04< vn971> or hmm, was it non-Default Era?.. 20180823 08:32:58< vn971> @sevu: could this Era _change_ since you last played it? 20180823 08:36:13< vn971> @sevu: regarding gender. It's probably something else: the unit "type" is the same for both genders. For a unit, it's like a separate flag withing the same unit type. I'm thinking about Era change or PUA bug currently. 20180823 12:36:24<+wesdiscordbot> vn971, this is the unit ttps://github.com/Robertdebrus/ANLEra/blob/master/units/elves/Civilian.cfg#L89 20180823 12:37:39<+wesdiscordbot> And this are the persisten variables https://bpaste.net/show/afbecf443226 20180823 12:55:04<+wesdiscordbot> talk about long variable names 20180823 13:11:54< vn971> @sevu: why does this unit have overrides for "Merman Warrior" though? 🤔 20180823 13:12:13< vn971> Does the Era transform units under some conditions? Change its type I mean. 20180823 13:15:14< vn971> @Pentarctagon: too late to change anything now.. Or at least, if we do, old "same map" overrides will stop working for everyone. 20180823 13:16:13< Soliton> if you look at the github link you can see that male and female units advance differently. 20180823 13:17:01< vn971> @sevu: waaaaaiiit! [female] is an actual official tag, and it does indeed override "advances_to"... 20180823 13:17:11< vn971> Soliton: indeed, I got to those lines. 20180823 13:17:42< vn971> Any way to get this information from wesnoth.unit_types though?... 20180823 13:17:45<+wesdiscordbot> The Merman things surprised mee too. I played them yesterday the first time, and I wasn't aware of setting advancements 20180823 13:18:52< vn971> @sevu: you were right aboet gender issue though. It seems indeed to be geder-related. I understood that part now. 20180823 13:19:04< vn971> *gender 20180823 13:21:41< vn971> So it seems I won't be able to fix the issue unless wesnoth introduces a new API or if I stop using unit type information and re-store everything in variables.. 20180823 13:49:02<+wesdiscordbot> For the Merman… I observed a game where someone wanted to advance it to a Triton… afterwards I played it myself… I think I advanced randomly to a Holpite. Could it be that the variable was saved while I observed? 20180823 13:54:19-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-umc-dev 20180823 13:56:31< vn971> @sevu: the add-on shouldn't do that (shouldn't make any changes on your permanent preferences while you observe). 20180823 13:57:47< hk238> hi 20180823 13:58:19< hk238> vn971 I was thinking about an afterlife scenario that was for 3 players 20180823 13:58:48< hk238> basically the wave interval would be like 3 turns, and the enemy wave for each player would consist of the units of both of the opponents, or alternatively they would cycle 20180823 13:59:05< hk238> I'm not sure it's a good idea but it's something 20180823 14:01:54< vn971> hk238: hi 20180823 14:03:08< vn971> IDK! Feel free to implement. Some of your ideas work out pretty cool, so you can just go ahead and try it.:) 20180823 14:03:47< hk238> yeah maybe next weekend :o wait that's like tomorrow 20180823 14:03:48< hk238> :D 20180823 14:04:39< hk238> hmm I like the version where both opponents' units spawn , perhaps they would spawn from different directions 20180823 14:05:40< hk238> that way the player could decide what units to designate towards defending that area.. but it does come with the problem that then you only have half as much units as those that are spawning, although if you look at the spawnrate over time, then changing the interval fixes that.. but 4 turns starts to seem a lot like waiting 20180823 14:06:09< hk238> did you see the 2vs2 afterlife map by the way? I particularly like the smaller one "fourriversafter" I think it's kind of pretty and also similar in style 20180823 14:11:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 14:11:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 14:30:43< vn971> hk238: I haven't, yet. I'm not actively playing in the last 2 weeks. 20180823 14:31:00< vn971> // Also I'm sad that a "Plan Unit Advancement" bug showed up that's really non-trivial to fix.( 20180823 14:35:27< hk238> perhaps you could create a copy of a unit and modify it so that it only has one possible advancement and replace the old unit with that? Or hmm reversing that when changing decision though 20180823 14:36:40< vn971> Yeah, reversion is where things get even more complex.. 20180823 15:44:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 15:44:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 15:49:31< Soliton> vn971: i guess you'll have to get variations from the __cfg field yourself. 20180823 15:49:54< vn971> Soliton: oh, that's a solution! Thanks!!! 20180823 15:51:10<+wesdiscordbot> technically [female] and [male] tags are variations? 20180823 15:51:16< Soliton> yes. 20180823 15:51:52< Soliton> also there'll be the same issue for [variation]. 20180823 15:54:39< vn971> So in order to get unit type advancements, I should check the appropriate gender [male]/[female] tag, and use the main unit type info as fallback -- right? 20180823 15:54:48< vn971> I mean, should I check variations as well? 20180823 15:55:19< Soliton> yes. 20180823 15:55:45< Soliton> you need to check the inherit key to decide whether to fall back or not. 20180823 15:59:46< vn971> So the correct order is "variation override" -> "gender override" -> "no override, just unit type info" ? 20180823 16:07:20<+wesdiscordbot> I unterstoof it like that variation is a list over which you have to iterate, for each of them get another cfg, and depending if this contains inherit or not, to take the value from said cfg or to take it from whjat you got originally when only checking the unit type 20180823 16:08:27<+wesdiscordbot> I think your question is about the last point, wether to check the unit type or another variation such as female? 20180823 16:14:28< vn971> @sevu: I'm asking if it's possible to be male/female and have a variation at the same time. If "yes", then "variation" takes preference, right? 20180823 16:31:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds] 20180823 16:37:32< vn971> This all feels very time-draining.( And not compatible with add-ons that alter "advancements" on the fly as well. Probably I should go for storing original advancements in a variable if I do this. 20180823 16:37:56< vn971> Does anybody know BTW, are add-ons loaded in alphabetical directory order? 20180823 16:48:18<+wesdiscordbot> It sounds pretty good to me. In the average case variations would be nil anyway, somtimes having one element, and very seldom you have things like zombies. It sounds to me as compatible as what you were doing so far. 20180823 16:48:47<+wesdiscordbot> Just, I don't know the answer to the question, I just tried to understand what soliton said 20180823 17:08:14< Soliton> not sure what you mean with override. variations are somewhat another unit type. so for what unit types there are they just add to that list. for a specific unit you may need to figure out what variation if any they are to look up in your list of unit types. 20180823 17:09:03< Soliton> and indeed [male]/[female] can potentially contain [variation]. 20180823 17:09:31< Soliton> not sure that's ever been used though. 20180823 17:11:54<+wesdiscordbot> can [variation] contain as well male ? 20180823 17:12:11< Soliton> no. 20180823 17:12:22< Soliton> https://wiki.wesnoth.org/UnitTypeWML#Other_tags 20180823 17:38:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 17:38:06-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 17:58:50< vn971> I think I won't analyze unit _types_ at all, if I'm going to change anything at all. 20180823 17:59:11< vn971> in other words, if I'll make any change at all, I'd instead look at _unit-s_ advancements. 20180823 17:59:23< vn971> remember what they were before modifying, etc. 20180823 18:00:55< vn971> this way I'll be compatible with more add-ons, and will avoid looking into unit types at all. At the same time, it's more time consuming than if there'd be a simple API instead (but there isn't).. 20180823 18:06:45< Soliton> well, no clue how your addon works but it seemed to me like you're saving stuff based on the unit type. there certainly may be other ways to reach whatever the goal is. 20180823 18:07:10-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/] 20180823 18:14:18< vn971> Soliton: yes. Thanks for your suggestions again. 20180823 18:52:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 18:52:22-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 19:11:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 19:11:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 19:25:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 19:25:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 19:30:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 19:30:16-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 20:04:06< vn971> ouch, I caught an unrelated bug in PUA as well now. If a unit was leveled during an enemy-s turn, add-on chose an advance of the current player-s liking, not the owner of the unit. This happened because I used "post advance" event, and inside the event I invoked the "sync" methods. 20180823 20:04:54< vn971> I felt there was a bug in PUA relating to leveling on enemy turn, but I couldn't nail it down. Now I got it, I think. Maybe PUA will not have bugs at least, when I release the fix. 20180823 20:05:02< vn971> It was the last one I noticed, I think. 20180823 20:05:19< vn971> If I won't introduce any new bugs of course, and I can. 20180823 20:10:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180823 20:10:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180823 20:57:01<+wesdiscordbot> speaking of bugs, while probably not a bug, can you explain me how the variable names are created? https://bpaste.net/show/afbecf443226 (link from earlier) 20180823 20:58:29<+wesdiscordbot> the base dir (or the name which counts in the add-on manager) is Colosseum_3p 20180823 20:59:02<+wesdiscordbot> the scenario id is "Colosseum_3p" 20180823 21:00:26<+wesdiscordbot> and "3S – Kolosseum" would be the localized scenario name (not id) 20180823 21:01:03<+wesdiscordbot> so, the »K« must comehow come from this ^ 20180823 21:02:04<+wesdiscordbot> what confuses me as well is the »S« in both variable names 20180823 21:36:26< vn971> @sevu: will be AFK soon. The requirement is the following: "map override" name should be unique for all scenarios and all units (presuming they don't confilict themselves). The practical implementation that "almost" satisfies the rule is: 20180823 21:36:27< vn971> "pickadvance_override_" .. scenario_id .. scenario_name .. unit_clean_type 20180823 21:37:17< vn971> "Colosseum_p" is what's left after leaving only a-zA-Z, as you correctly guessed. 20180823 21:37:56< vn971> And "SKolosseum" is what you get if you only keep a-zA-Z from the string "3S – Kolosseum" 20180823 21:38:44< vn971> I remove numbers and other characters because I hope it'll not add ambiguity, and because doing it this way will ensure that variable name is correct. 20180823 21:40:36< vn971> @sevu: so yeah, I both have the id AND the localized name. I don't remember now why I needed it, but I think I did. It doesn't hurt though, right? 20180823 21:56:37< vn971> @sevu: in the "ANL" map, the "S" is probably for the same reasons. It's being retained from the "3S - ..." string if you only keep a-zA-Z_ 20180823 21:59:01<+wesdiscordbot> I see, thanks 20180823 22:00:04<+wesdiscordbot> nice side effect is that it's one variable for 3p and 6p scenario variants 20180823 22:01:28<+wesdiscordbot> I'll make PUA a dependency for Colosseum --- Log closed Fri Aug 24 00:00:22 2018