--- Log opened Sun Nov 11 00:00:30 2018 20181111 00:05:24-!- sevu [~sevu@p54854E05.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20181111 00:26:24<+wesdiscordbot> @Yumi There's an httt rewrite being considered? Where can I read more on it? 20181111 09:38:57-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-umc-dev 20181111 10:45:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev 20181111 13:59:25<+wesdiscordbot> could someone help me with an WML ability? 20181111 14:04:56-!- celmin|away is now known as celticminstrel 20181111 14:05:11< celticminstrel> What do you want? 20181111 14:06:18<+wesdiscordbot> there's some string manipulation and i'm not really familiar with that 20181111 14:06:48< celticminstrel> That doesn't really answer the question but... 20181111 14:07:04< celticminstrel> If you want help with specific code rather than help deciding what to code, post it. 20181111 14:07:18< celticminstrel> Using a pastebin preferably. 20181111 14:07:36< celticminstrel> Because code posted directly in a post cannot be read very well from IRC. 20181111 14:07:46<+wesdiscordbot> basically, i need to extract a unit's name and then add a prefix to it 20181111 14:07:53<+wesdiscordbot> the rest i can handle 20181111 14:09:54<+wesdiscordbot> đŸ¤” 20181111 14:10:03< celticminstrel> Is the name with the prefix for use somewhere else or should it be set as the unit's new name? 20181111 14:10:32<+wesdiscordbot> it's going to be used as a unit id 20181111 14:10:41< celticminstrel> ... 20181111 14:11:02<+wesdiscordbot> shitcoding at it's finest :D 20181111 14:11:33< celticminstrel> FTR, don't use a unit's name as a unit id. 20181111 14:12:03<+wesdiscordbot> sorry, error here, i need to use the unit's initial ID, not the name 20181111 14:12:17< celticminstrel> Ah, okay. 20181111 14:14:45< celticminstrel> String manipulation in WML is a bit primitive... you could probably do it with [join] somehow with a blank separator? 20181111 14:15:03<+wesdiscordbot> hm 20181111 14:15:06< celticminstrel> There might be an undocumented prefix= too that does exactly what you need, but I can't remember. 20181111 14:15:34<+wesdiscordbot> alright 20181111 14:15:37<+wesdiscordbot> thanks for the help 20181111 14:15:45<+wesdiscordbot> i'll see what i'll get 20181111 15:39:33<+wesdiscordbot> I don't understand what exaclty you want to do, but I had a case where I did do sth. like that: 20181111 15:41:23<+wesdiscordbot> Imaging {UNITS} to be a list of unit ids.... like "Mermen Fighter,Mermen Hunter,ANLEra Meren Citizien" 20181111 15:42:48<+wesdiscordbot> and you want to transform it to show the unit name instead of the unit id (the name will be shown in your language, unlike the ids which are always english terms) 20181111 15:43:36<+wesdiscordbot> aditionally, you want to have a space after the comma, and before the last unit to show " and " instead of a comma: 20181111 15:43:41<+wesdiscordbot> https://github.com/Robertdebrus/ANLEra/blob/master/utils/ANLEra_extra_ai_units.cfg#L47-L106 20181111 15:44:22<+wesdiscordbot> ^ Then that would be a code which does it. 20181111 16:05:38< Ravana_> some of it is covered by https://wiki.wesnoth.org/LuaWML/Misc#wesnoth.format_conjunct_list 20181111 16:15:19<+wesdiscordbot> oh, very interesting… If I would have know that at that time … 20181111 16:15:37-!- vn971 [~vasya@2a02:a451:aaa9:1:c774:2d32:1da9:62e] has joined #wesnoth-umc-dev 20181111 16:16:36<+wesdiscordbot> @BarsukEughen https://bpaste.net/show/c65c67158ab0 20181111 16:18:09<+wesdiscordbot> I think that's what you were looking for … I'm not sure if line 14 is correct or needs to be wrapped into an $( … ) or something 20181111 16:20:21<+wesdiscordbot> $( … ) is for WFL related things, so wouldn't be what you want here. 20181111 16:20:52< celticminstrel> FTR sevu, format_conjunct_list is new in 1.13.x... but all old code should definitely be switched to it, because it's localization-friendly. 20181111 16:20:55<+wesdiscordbot> you would need quotes or just parenthesis around the value if you used the VARIABLE macro instead though. 20181111 16:22:15< celticminstrel> For example, if there were a language where the normal way of saying a list were "thing1; fa thing2; thing3" then format_conjunct_list({"thing1","thing2","thing2"}) would output just that when said language is selected. 20181111 16:22:38< celticminstrel> I don't know if it's flexible enough to accomodate every possible language, but... 20181111 16:26:18<+wesdiscordbot> :GWfroggyMonkaThink: 20181111 16:26:51<+wesdiscordbot> (why the heck is my message shown in read !¡?) 20181111 16:27:04<+wesdiscordbot> *red 20181111 16:27:25<+wesdiscordbot> it wasn't sent(properly) 20181111 16:27:30<+wesdiscordbot> net issues or something 20181111 16:28:10<+wesdiscordbot> Indeed 20181111 16:29:44-!- sevu [~sevu@edu243012.nat.uni-leipzig.de] has joined #wesnoth-umc-dev 20181111 16:30:46< sevu> So… for a given list, it prints usin a _comman + space_ as seperator, and for the last it uses " and " instead… and that thing would in German display as " und " instead of " and ". 20181111 16:35:34-!- sevu [~sevu@edu243012.nat.uni-leipzig.de] has quit [Remote host closed the connection] 20181111 16:42:53-!- sevu [~sevu@edu243012.nat.uni-leipzig.de] has joined #wesnoth-umc-dev 20181111 16:52:07< celticminstrel> sevu: Yes. 20181111 16:52:23< celticminstrel> (Assuming the string exists for it in the translation catalogue.) 20181111 17:23:14-!- sevu [~sevu@edu243012.nat.uni-leipzig.de] has quit [Remote host closed the connection] 20181111 17:44:38<+wesdiscordbot> So, I noticed this thing in 1.14: for persistent sides, if you don't specify the 'type' key inside the [side] tag, the leader is not automatically recalled and placed on the map. Has anybody noticed that too? Weird thing is, it doesn't matter what you specify as type, as long as the key is there the leader will be correctly recalled. Was this intended? 20181111 17:51:55< celticminstrel> I think so? 20181111 17:52:23< celticminstrel> If you have a [unit] or [leader] tag with the leader's ID, that should also cause the leader to be correctly recalled. 20181111 17:54:01<+wesdiscordbot> I previously used just the id o the leader, just inside the [side] tag, but this is no longer sufficient 20181111 17:55:01<+wesdiscordbot> ah, I will try the [leader] tag with the id and without the 'type', let's see what happens 20181111 17:55:04< celticminstrel> Ah. Not sure whether that is intended.+ 20181111 17:55:19< celticminstrel> FTR, that works for any [unit] tag. 20181111 17:55:24< celticminstrel> Not just a leader. 20181111 18:00:39<+wesdiscordbot> Ok, I tried that, with the [leader] tag you still need to specify any unit type, and you need to provide the correct id both inside the [leader] tag and outside it (the save_id for the side) 20181111 18:01:25<+wesdiscordbot> so ok, nothing problematic, just a bit weird 20181111 18:01:42< celticminstrel> Well, needing to provide save_id makes sense, at least. 20181111 18:01:53< celticminstrel> If you have that you shouldn't also need id in [side]. 20181111 18:02:25<+wesdiscordbot> I always let it get the 'id' of the leader by default 20181111 18:02:29< celticminstrel> If you use a leader tag with id and type, does it still work if the leader is of a different (advanced) type? 20181111 18:03:26<+wesdiscordbot> if inside the [leader] tag there is a different id, then the unit is of the specified type. If the id is the same of the side it recalls the previous leader, regardless of the type. 20181111 18:03:36<+wesdiscordbot> which makes sense, I'd say 20181111 18:04:03< celticminstrel> No, not really? 20181111 18:04:07<+wesdiscordbot> it would just be more natural if there wasn't the necessity to provide the 'type' key 20181111 18:04:12< celticminstrel> It shouldn't depend on the side's ID at all. 20181111 18:04:21< celticminstrel> It should depend only on the unit's ID. 20181111 18:04:38<+wesdiscordbot> sorry, I'm talking of the unit id, I'm making a bit of confusion there 20181111 18:04:43< celticminstrel> Essentially, [side][unit] is like "recall this unit or create it if it can't be found in the recall list". 20181111 18:04:56< celticminstrel> (And [side][leader] is just a [side][unit]canrecruit=yes) 20181111 18:05:23<+wesdiscordbot> yes so, if inside the [leader] the unit id matches a unit in the recall, I guess it will not read the other keys 20181111 18:05:35< celticminstrel> Yeah, I believe that's how it's supposed to work. 20181111 18:05:47<+wesdiscordbot> but still, a type MUST be provided, which is the weird thing 20181111 18:05:55<+wesdiscordbot> even if it gets ignored 20181111 18:06:00< celticminstrel> That is a little weird admittedly. 20181111 18:06:04<+wesdiscordbot> Hey, quick question: Is experience actually added in harm_unit.lua or somewhere else? I tried editing it and nothing happens. Am noob. 20181111 18:08:58< celticminstrel> harm_unit.lua is only relevant when using the [harm_unit] WML tag. 20181111 18:09:15< celticminstrel> For general combat experience, it's done somewhere deep in the engine. 20181111 18:10:30<+wesdiscordbot> ugh, this is above my paygrade. All I know how to do are copy/paste things and change numbers. 20181111 18:18:07<+wesdiscordbot> you could look at [store_unit]/[unstore_unit] or [modify_unit] for the xp part. 20181111 18:40:08-!- vn971 [~vasya@2a02:a451:aaa9:1:c774:2d32:1da9:62e] has quit [Quit: Leaving.] 20181111 19:00:33<+wesdiscordbot> @skeptical_troll There was a change which got rid of the no_leader attribute: If there is no type attribute pressent, it's equal to no_leaer=yes. Pretty sure that is the reason. 20181111 19:01:06<+wesdiscordbot> If there's a way to further improve it, gfgtdf would be the person to discuss it with 20181111 19:07:08-!- vn971 [~vasya@89.200.3.221] has joined #wesnoth-umc-dev 20181111 19:20:05<+wesdiscordbot> Ah, I see, that would explain it. I wasn't aware of that and it is not mentioned in the wiki that 'no_leader' is basically deprecated/redundant. I wouldn't have made it for persistent sides, but I guess it's not such a big deal. 20181111 19:49:22-!- sevu [~sevu@edu243012.nat.uni-leipzig.de] has joined #wesnoth-umc-dev 20181111 20:27:15-!- vn971 [~vasya@89.200.3.221] has quit [Ping timeout: 252 seconds] 20181111 20:27:15-!- sevu [~sevu@edu243012.nat.uni-leipzig.de] has quit [Remote host closed the connection] 20181111 21:10:43< celticminstrel> FTR I'm pretty sure no_leader is still checked sort og. 20181111 21:10:47< celticminstrel> ^of 20181111 21:11:14< celticminstrel> But I think the "canonical" replacement is something like faction_lock=yes (and then just don't declare a leader). 20181111 21:13:36< celticminstrel> lock_leader, not faction. 20181111 21:14:22<+wesdiscordbot> leader_lock, sorry… 20181111 22:40:22-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/] 20181111 23:30:06-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds] --- Log closed Mon Nov 12 00:00:32 2018