--- Log opened Mon Aug 13 00:00:00 2018 20180813 00:43:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 00:43:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 00:48:44-!- Jordys [~Jordys@154.68.5.110] has joined #wesnoth-umc-dev 20180813 00:48:51-!- Jordys [~Jordys@154.68.5.110] has quit [Client Quit] 20180813 01:03:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 01:03:06-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 01:12:36-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180813 01:48:56-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 01:49:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 02:22:48-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 02:22:54-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 02:59:51-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 02:59:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 03:34:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 03:35:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 03:42:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 03:42:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 06:24:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 06:24:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 07:27:49< vn971> @sevu morning (or good day time). Am I correct that you want to find if _any_ of the upgrades will have melee or ranged attacks? 20180813 07:28:12< vn971> any of the possible advances I mean, even 2-step. 20180813 07:31:06< vn971> if I'm right, then you generally have to do the following: 20180813 07:31:06< vn971> 1. collect all possible advances. May start with just direct advances and write a recursive function later. I've written exactly this function for CreepWars, shouldn't be hard. 20180813 07:31:06< vn971> 2. for each unit, iterate over all weapons and form a set of all possible ranges ("melee", "ranged", "secret" from Ageless etc). 20180813 07:31:06< vn971> 3. have a function that wraps it all. You give it a unit type and it returns whether any of the upgrades have "melee", "ranged" or other types of attack. Store it in global variables for WML compatibility (?). 20180813 07:31:06< vn971> Am I right? 20180813 07:31:19< vn971> I mean, is this what you want? 20180813 08:00:36< vn971> Checked my code a bit. I already have fuction 1 defined in Creep Wars (unit_analyze_common.lua line 54). Also a function to check **weapon** specials is nearby. The one that analyzes unit abilities is OK to write too. 20180813 08:09:19< vn971> > if it can ever get a a healing ability – and should thus not be able to buy one 20180813 08:09:20< vn971> but what if the unit choses another path and won't have the ability? 20180813 09:21:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev 20180813 09:40:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 09:40:54-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 10:47:28<+wesdiscordbot> Hi vn971 20180813 10:47:49< vn971> hi 20180813 10:48:17<+wesdiscordbot> You are right with all your guesses. I tried to write it yesterday, this is what I came up with: https://bpaste.net/show/42f1b18f0416 20180813 10:48:58<+wesdiscordbot> This lua things are not as hard as I thought 20180813 10:50:48< vn971> sevu: yes. Actually, while I look at your code, I don't actually even see any flaws in it. 20180813 10:50:59<+wesdiscordbot> it has 😃 20180813 10:51:05<+wesdiscordbot> It's simpla and nice, but … 20180813 10:51:21< vn971> well except the alignment of the first 2 lines maybe. Also the advances array could/should be moved near it's use (to the bottom). But that's cosmetical as you see. 20180813 10:52:17<+wesdiscordbot> if any UMC author there has a unit which advances to it self, directly or with other units in between, we have an endless recursion 20180813 10:52:52< vn971> sevu. I see. Add a "set" then. A parameter for the function 20180813 10:53:12<+wesdiscordbot> This could be solved by first creating a list of all advancements, and checking if that type has alreay been processed earlier. 20180813 10:53:13< vn971> local function search_unit_types(current_type, exclude_set) 20180813 10:53:21< vn971> exclude_set = exclude_set or {} 20180813 10:53:55< vn971> exclude_set[current_type] = true 20180813 10:53:58<+wesdiscordbot> oh, so sets DO exist ? 20180813 10:54:50< vn971> and later, when you invocate recursion, do: 20180813 10:54:50< vn971> if (not exclude_set[u]) then ...recursion_invocation... end 20180813 10:55:18< vn971> sevu: yes! Actually Lua has arrays and sets combined. There's only one data structure in fact: a "table". 20180813 10:56:05< vn971> if you iterate it with `ipairs`, it'll only go from index 1 onwards to the end of the array. If you iterate it with `pairs`, you iterate over all key-value pairs, with undefined order. 20180813 10:56:34< vn971> and if you store only `true` or `nil` in a table, you get a classical "Set". 20180813 10:57:13<+wesdiscordbot> Programming in Lua has a page about using tables as sets: http://www.lua.org/pil/11.5.html 20180813 11:00:28<+wesdiscordbot> Thanks, vn971 and jyrkive, I looked yesterday mostly for lists and it looked like I have to do the operations manually 20180813 11:02:47< vn971> sevu: oh, by the way, you probably also want to reset global variables to "false". 20180813 11:03:42< vn971> Also, you can actually write this: 20180813 11:03:42< vn971> for _, ability in ipairs(possible_abilities) do 20180813 11:03:42< vn971> wesnoth.set_variable("can_get_" + ability, true) 20180813 11:03:52< vn971> thus avoiding multiple "if"-s. 20180813 11:05:00< vn971> UPD: no, there's on "+" sign on strings. You have to write "can_get_" .. ability 20180813 11:05:12< vn971> (Lua concatenation.) 20180813 11:07:30<+wesdiscordbot> ah, okay… it would lead then to the question how to free the variables later, as I don't know how many variables I may get while iterating. 20180813 11:08:06<+wesdiscordbot> I wonder if wesnoth.set_variable("foo.canget" ability, true) 20180813 11:08:33<+wesdiscordbot> would store it in a container which can be removed by {CLEAR_VARIABLE foo} later 20180813 11:10:29< vn971> sevu: IDK. I'm personally seriously afraid of WML and the containers, so I try to keep everything in Lua only. So I'd just have a global "table": unit_type -> ability_set , or avoid having globals at all and pass data around as function result. 20180813 11:10:37< vn971> that being said, I guess containers could work. 20180813 11:12:11< vn971> sevu: if you only deal with one unit at a itme (like in the user scenario you described with Colosseum), I guess you can just avoid freeing at all. 20180813 11:13:35< vn971> sevu: just clear the globals "can_get_" before re-calculating them, have them correct while shopping and don't care after that. Or maybe clean variables after you exit the shop if you have this stage ("exiting the shop"). 20180813 11:13:51<+wesdiscordbot> containers are sometimes scary, at least the unit.modifications one 20180813 11:15:41<+wesdiscordbot> If I think about it, it's maybe better to leave it as is because I do not, or can not, handle custom abilites of which I only know the ID in the shop. It may be more lua lines, but … 😉 20180813 11:19:12<+wesdiscordbot> The other limitations in the code is… I only get information by unit ID. more useful would be to know if there is an ability which is defined by an [heals] tag (And in some other case eventually if it has a value > 0 or if it only cures, but not heals) 20180813 11:19:24<+wesdiscordbot> *ability ID, not unit ID 20180813 11:21:04<+wesdiscordbot> your unit_count_specials looks close to that 😉 20180813 11:23:26< vn971> sevu: yeah the "simplification" is only to get fewer lines of code (and fewer typos), but that's about it. No real difference in features. 20180813 11:24:56< vn971> I didn't totally get the difference in "unit ID" versus "ability ID" though. Basically, the current code says whether the unit can possibly upgrade to a "heal"-ing unit. What else is there to wish? 20180813 11:26:14<+wesdiscordbot> unit id was a typo,I meant ability id 20180813 11:26:18< vn971> or you mean to understand whether a unit is "strong" enough, give an estimate about that? And implement code like "if you are charger, strength +10%" etc? 20180813 11:26:55< vn971> "curing" and "heals" are already distinguished though aren't they? 20180813 11:27:36<+wesdiscordbot> the thing is … the healing id gives me an id - if it is an ability which is not from core, this id itself doesn't tell much 20180813 11:27:49< vn971> sevu: By the way, one possible thing you can do in the "melee" VS "range" thing. As I understand it, your general idea is to favor "biased" melee-only units a bit. 20180813 11:28:29< vn971> sevu: I think wesnoth doesn't support any abilities other than those in core anyway? 20180813 11:29:04<+wesdiscordbot> if I could check instead what the tag used for defining the ability is, then I have more information, and can thus say, e.g. this unit can get some kind of healing ability later and thus not let it buy healing 20180813 11:29:39<+wesdiscordbot> I thought of things like an UMC helaing ability which… only works on undead 20180813 11:29:47< vn971> sevu: the alternative you may want to consider is this. Increase unit strength by percentage instead of +1. This way, Thunderer will not be as strong for example. Because +100% strikes will only make it a 40-2 attack. (80 expected damage). 20180813 11:29:53<+wesdiscordbot> and has an ID such as undead_healing 20180813 11:30:24<+wesdiscordbot> In that case I would not like to give additionally the normal healing abilit 20180813 11:30:28< vn971> as a comparison, a loyal guard with +100% strikes will get a similar total damage, thus making both units behave more closely to what they were originally. 20180813 11:31:40< vn971> also, unit specials will be perfectly accounted for this way. If you "drain", then it doesn't matter much. A +100% drain damage is not over-powered anymore because it's not constant +N damage. (Drainers usually have somewhat slower absolute damage values, which get neglected if you upgrade it severely.) 20180813 11:32:14< vn971> *somewhat Lower absolute damage 20180813 11:33:02< vn971> sevu: ah, I see your problem. I'd suggest iterating on tags then. 20180813 11:33:05< vn971> WML tags. 20180813 11:33:47<+wesdiscordbot> That makes actually a lot of sense, Colosseum is only with a few units playable. But it's a change which is currently to big to be done now (in means of time) 20180813 11:34:18< vn971> wesnoth.unit_types["Lich"].__cfg -> then extract all "abilities" inside, then traverse all abilities and check the tag names. 20180813 11:35:13< vn971> sevu: yes. It's a totally different "play" experience for those who got used to "+1" upgrades as well. People won't be happy to let old habits go, I'm almost sure of that. 20180813 11:35:42< vn971> I still want to experiment with "%" upgrades for XP Mod, Creep Wars or something like that, but it may not end up "accepted" by players. 20180813 11:37:09< zookeeper> no idea what the context is exactly, but you might also want to consider that making upgrades/specials "balanced" in the sense that they benefit all units more or less equally will also mean not having to think which unit to give which upgrade. 20180813 11:40:26<+wesdiscordbot> % upgrades would be an way to use the basic balancing of unit values 20180813 11:40:55<+wesdiscordbot> I think these +x upgrades got very popular because it's easily doable in WML 20180813 11:43:19< vn971> that was my taking on it as well. That, and maybe also +1 got wesnoth support earlier. 20180813 11:43:59<+wesdiscordbot> Creep wars and Colosseum have in fact the same way of upgrading a unit, they could use the same shop system, maybe even the same offers in the shop (That was my complaining about reinventing the wheel with each add-on which has a shop a mont ago or so) 20180813 11:44:02< vn971> percentages don't add up, that's the main problem. +5% +5% +5% +5% +5% on a damage of 9 gives... guess what? You're right, 9. Doesn't change at all. 20180813 11:44:55<+wesdiscordbot> With objects, I give them an id now, and when upgrading I remove them and add their bonus to the new object instead of giving multiple objects 20180813 11:45:15<+wesdiscordbot> (taking advantage of the new [remove_object] tag) 20180813 11:45:16< vn971> sevu: that could make sense. Only I'm not sure about **the same** options and interface in shops. I thought of starting with "XP Mod" interface which you can plug in to. (Which maps and other mods can plug in to.) 20180813 11:45:42< vn971> maybe interface re-usage could happen as well though. Not sure yet. 20180813 11:46:52< vn971> > and when upgrading I remove them and 20180813 11:46:52< vn971> exactly! And this function only appeared in our last stable release, 1.14! So basically, it's the first time in wesnoth history that you can really do +5% upgrades. No wonder it's not being done before. 20180813 11:48:16<+wesdiscordbot> There's been a lot of useful stuff in 1.14… 20180813 11:48:43< vn971> I tried to hack into [objects] in 1.12 as well, but removing objects from __cfg doesn't help on 1.12 at all. It seems that, when you apply an object on 1.12, it gets applied internally AND its text representation gets inserted into __cfg. But no matter what you do in the __cfg, the internals won't change anymore. Basically, no way to remove an object at all it seems. 20180813 11:50:02<+wesdiscordbot> There are still things an object can change but whose removal is limited – e.g. ellipses 20180813 11:50:47< vn971> sevu: also image mods, yes. (I raised an issue about that I think.) 20180813 11:51:01< vn971> anyway, I guess that's offtopic. 20180813 11:51:42<+wesdiscordbot> There must be some great changes be left for 1.15 😉 20180813 13:46:00-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds] 20180813 14:10:52-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-umc-dev 20180813 14:11:06< hk238> hi 20180813 14:20:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 14:20:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 14:29:53< vn971> hi 20180813 14:39:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 14:39:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 15:23:17-!- Robson [b3bb3214@gateway/web/freenode/ip.179.187.50.20] has joined #wesnoth-umc-dev 20180813 15:23:26-!- Robson [b3bb3214@gateway/web/freenode/ip.179.187.50.20] has quit [Client Quit] 20180813 15:59:04< hk238> seems the 4p version of afterlife works vn971 :) 20180813 15:59:27< hk238> have you seen the map? or there's actually 2 but one of them is higher quality and closer to the original afterlife 20180813 16:28:46< vn971> hk238: I haven't, yet. I'll take a look when I notice one.) 20180813 17:16:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev 20180813 17:45:44-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/] 20180813 18:05:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 18:05:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 19:01:01-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 19:01:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 19:25:20-!- Netsplit *.net <-> *.split quits: Elvish_Hunter 20180813 19:31:19-!- Netsplit over, joins: Elvish_Hunter 20180813 19:50:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180813 19:50:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180813 21:58:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds] --- Log closed Tue Aug 14 00:00:02 2018