--- Log opened Thu Sep 20 00:00:41 2018 20180920 00:13:32-!- gfgtdf [~Daniel@x4dbc6595.dyn.telefonica.de] has quit [Quit: Leaving] 20180920 00:50:26-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180920 00:50:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180920 01:00:45-!- Netsplit *.net <-> *.split quits: Soliton 20180920 01:01:01-!- Soliton [~Soliton@baldras.wesnoth.org] has joined #wesnoth-umc-dev 20180920 01:01:40-!- Soliton [~Soliton@baldras.wesnoth.org] has quit [Changing host] 20180920 01:01:40-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-umc-dev 20180920 01:20:30-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180920 01:20:36-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180920 01:26:14-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-umc-dev 20180920 02:28:14-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/] 20180920 03:19:55-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180920 04:48:17-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev 20180920 05:09:11-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev 20180920 06:21:41-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-umc-dev 20180920 08:19:36-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180920 14:15:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180920 14:15:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180920 14:21:05-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev 20180920 15:08:56-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180920 15:23:18-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-umc-dev 20180920 15:23:20< hk238> hi 20180920 15:40:39<+wesdiscordbot> Hi 20180920 16:34:46< vn971> hi) 20180920 16:35:40< vn971> BTW, talking about crazy add-on ideas. I have one new.:) 20180920 16:36:41< vn971> So, is it a common scenario?: you start a game, play out smartly, then in 5-10 turns your opponent is basically crashed -- leaving you no real challenge. 20180920 16:37:18< vn971> One work-around is to play new (for you) maps. Or know strong players by names and invite only them. 20180920 16:37:47< vn971> Or write "know the map please" / "strong players only" etc. in room name. 20180920 16:38:12< vn971> Or, finally -- meet the new add-on idea. Give an automated handicap to players who have less experience on a map. 20180920 16:39:46< vn971> The idea is to write the current map ID into local player preferences file, along with a count (how many times was this map played). 20180920 16:40:48< vn971> Now, at game start, the add-on can ask all participants the number of times they played the map. If the number for your opponent is lower than yours, you can remove some % of starting money so that the game will be more challenging. 20180920 16:41:02< Soliton> sounds difficult to balance. 20180920 16:41:32< vn971> Soliton: you mean to propose a good enough %? 20180920 16:41:41< Soliton> yes. 20180920 16:42:31< Soliton> some people learn quicker than others. some might learn from having observed the game before. 20180920 16:43:06< vn971> Soliton: well the basic idea is to show a text like "You played this map 23 times. Your opponent played it 10-15 times. Would you like to give your opponent a handicap by removing your gold?" and then a slider 0..100 20180920 16:43:28< vn971> or if you're the weaker player, you get no window at all. 20180920 16:43:43< Soliton> let the player choose? ok, that helps some. 20180920 16:44:15< vn971> Soliton: yes, let the player choose and only make a random guess on the starting position of the slider. 20180920 16:44:18< Soliton> seems still impossible to judge. 20180920 16:45:11< Soliton> i guess the question is how much better this is than just providing the handicap option. 20180920 16:45:18< vn971> Soliton: maybe. I'm also worried if the add-on will be popular (at all). I also consider doing the nasty thing of NOT putting stats aggregation inside [modification], thus make it run at each and every game after you install the add-on. 20180920 16:46:12< vn971> so, IDK how many players will actually be willing to give away gold. Personally, I would, because I otherwise beat most players and discourage them from playing my map.:( And I'd very much wanted to just see how experienced the opponent is. 20180920 16:46:48< vn971> if they're not, I'd give them the handicap straight away. But how many people besides me will do that? 20180920 16:47:03< Soliton> but you can just ask them in chat and figure something out and set the handicap according to that. 20180920 16:47:24< Soliton> how much does it help to ask people for the number of games they've played? 20180920 16:47:25< zookeeper> well, that is the kind of thing that would naturally happen by people talking in the game lobby and deciding to give the newbie more gold or whatever. 20180920 16:47:49< zookeeper> your method is basically a shortcut for that. 20180920 16:47:56< Soliton> i suppose it helps if there is a language barrier. 20180920 16:48:16< vn971> Soliton: well if it's automated, then it'd help. I mean, if at least 10% of players will have the add-on and stats will be > 0 20180920 16:48:34< vn971> if I'd know the exact numbers I'd be pretty OK with giving some handicap that I see fit. 20180920 16:49:20< Soliton> so "ask all participants the number of times they played the map" means check their preference not actually ask them? 20180920 16:49:25< vn971> Soliton: the problem is that it has to be done very early in the game. And also I can't just take 17 gold at game start. I can only take 25 or 50 from myself, and do that *before* the game starts. 20180920 16:49:34< zookeeper> i guess. but then again, with a dialog that pops up and suggests giving the opponent more gold, the "newbie" doesn't even need to lie to get the handicap, they might just have fun on your expense and clear their counter. 20180920 16:49:37< vn971> Soliton: yes! The automated thing. 20180920 16:49:49< Soliton> so keeping those stats for the player could be nice, yes. 20180920 16:49:54< vn971> zookeeper: that I wouldn't mind too much. 20180920 16:50:13< vn971> zookeeper: though I'd take gold from myself, not give to opponent. This way it's easier to avoid confusion. 20180920 16:51:18< Soliton> this needs to be quite transparent to the players. which hashing this out in chat naturally is. 20180920 16:52:01< Soliton> you understand how it works but does some random user of your addon let alone the other player? 20180920 16:52:05< vn971> Soliton: do you think that a silent approach would make people less happy? 20180920 16:52:27< Soliton> yes, that sounds bad. 20180920 16:52:33< vn971> Soliton: this is actually important. This is why I've raised it in this chat. 20180920 16:53:02< Soliton> ideally you should see it in the status dialog. 20180920 16:53:10< Soliton> so you can check again later. 20180920 16:53:19< vn971> Soliton: that's a pity. Personally, I wouldn't feel bad. 20180920 16:53:25< Soliton> if it's like starting gold. 20180920 16:53:59< vn971> Soliton: I don't think it'll be visible as I'm not intending to change starting gold directly. 20180920 16:54:12< Soliton> if you want to auto-balance behind player's backs it needs to be perfect. 20180920 16:54:17-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev 20180920 16:54:30< Soliton> even then it sounds questionable. 20180920 16:54:35< vn971> Soliton: not sure it'd even be possible since I can only show dialogs in a somewhat later events. 20180920 16:55:07< Soliton> yeah, just saying that would be ideal. probably isn't possible., 20180920 16:55:14< vn971> Soliton: the point is to make it "more challenging", not "balance" exactly. I mean, "better" instead of "perfect". 20180920 16:55:41< vn971> Soliton: I mean, changing starting gold from statistics wouldn't be possible. I answered an earlier statement. 20180920 16:55:50< Soliton> i know. 20180920 16:55:54< vn971> 'k 20180920 16:56:16< zookeeper> so you envision this primarily as a general-purpose modification that could be used on (pretty much) any map, not a feature of a particular scenario? 20180920 16:56:26< vn971> zookeeper: yes 20180920 16:57:19< Soliton> for serious players that will know how much you should be able to recruit for example this will be confusing. 20180920 16:58:36< vn971> Soliton: if the map gets popular though, serious players will often have high numbers, so it's either them who will give the handicap, or the other person who has even more experience -- but why whould he give handicap at all then? 20180920 16:58:51< vn971> * if the add-on gets popular enough 20180920 16:59:25< zookeeper> okay. the basic problem is that you can't _automatically_ balance anything like that (because it's so easily abusable by editing the local values it's based on), and even if you let the player choose whether to give the other player the handicap, you don't have any means of knowing whether they're actually a newbie or not. you can only know if they're experienced enough that you 20180920 16:59:25< zookeeper> _shouldn't_ give them the handicap. plus, skill isn't really map-specific, except maybe on particularly high levels. 20180920 16:59:26< Soliton> serious player doesn't mean they've played every scenario. 20180920 16:59:55< vn971> Soliton: I mean, only the proposition of the handicap is intended to be automated. The actually handicap would only be invokable by a human, thus (hopefully) eliminating corner cases. 20180920 17:00:24< Soliton> i think he's thinking about custom scenarios where general skill really isn't always that helpful. 20180920 17:00:42< Soliton> or rather the skill for the specific scenario is much more important. 20180920 17:01:27< vn971> Soliton: well I'm interested in making it popular (if make at all), so I'd want it to be runnable on all kinds of maps. Including general ones, where knowledge of a particular map is less important. 20180920 17:02:38< vn971> zookeeper: so basically what you're saying is that there will be blinds spots that can't be covered. I agree to that. Still, would the add-on hurt then? 20180920 17:02:41< zookeeper> if this was for specific scenarios, then the feature could be some other form of opt-in extra challenges (say, an enemy spawn at a time of your opponent's choosing). for general use, i just don't think it'd work well enough in a technical sense. 20180920 17:02:52< Soliton> you could implement a ranking system... :-P 20180920 17:04:01< vn971> Soliton: you mean the super-serious approach I discussed some weeks/months ago? Have a real daemon server that crawls wesnoth game records and updates the add-on daily etc? 20180920 17:04:43< Soliton> well, a ranking system is the general approach to the problem you're describing, no? 20180920 17:05:08< zookeeper> if you find that you're clearly dominating your opponent, nothing prevents you from simply deciding to recruit one or two less units. would you say that that's psychologically not appealing enough, when the game doesn't acknowledge it in any way? 20180920 17:05:13< Soliton> to either find equal opponents or have some way to measure needed handicaps. 20180920 17:05:19< vn971> Soliton: you have a point here though. From some point of view, this is exactly what I'm doing. Only, in my case, it's "a ranking system for the poor", meaning a very straightforward, and abusable, implementation. 20180920 17:06:25< vn971> zookeeper: one of the problems for me is that I don't know how much experience does a player have on a particular map. I only ask "do you know the map?" sometimes, but it only gives a very vague data (yes/no). 20180920 17:07:06< vn971> Soliton: yes, a ranking system would be the general approach. Or better to say, falls into the same or similar category. 20180920 17:07:52< vn971> Soliton: only a ranking system would be abusable, it would even be human-like (for some players) to try abuse it. Cheating on my add-on would be very stupid though. 20180920 17:09:35-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has joined #wesnoth-umc-dev 20180920 17:10:50< vn971> zookeeper: so to answer the question -- "yes". Kinda hard to operate on observations only, and heavily counter-intuitive. (Once you start a game, the goal is to win, not to lose. Also, not play indefinitely by increasing the handi.) 20180920 17:14:42< hk238> hm 20180920 17:15:02< hk238> I think that typically a larger part of performance is explained by player experience in general rather than map specific experience 20180920 17:15:45< hk238> you could represent that by tracking a general factor alongside the map specific factor and then use somekind of method for approximating results 20180920 17:17:00< hk238> although I suppose that may vary between scenarios, such as creep wars or afterlife, might require more scenario specific experience 20180920 17:20:06< hk238> it would also be possible to use somekind of variable to estimate scenario saliency in that respect 20180920 17:22:46< Soliton> vn971: obviously it would be the perfect ranking system. it would be transparent to the user. no way to game the system. it was also tongue-in-cheek. 20180920 17:24:52< Ravana_> I don't think it will make sense for pvp games, but the stats alone would make it useful to get 20180920 17:32:28< vn971> Ravana_: "would make it useful to get"? You mean the stats themselves could be useful? 20180920 17:32:48< Ravana_> stats are nice to have 20180920 17:34:04< vn971> Actually I thought a bit on what hk238, Ravana_ and Soliton have said. It seems possible to do an add-on that would still crawl publicly recorded games. Only it'd search player names and only them, not looking inside. So it'd only provide stats on being familiar with a map. Non-cheatable unless you create new nicknames. 20180920 17:35:55< vn971> ok cheatable, but that's not the point. Since this "stats" or "database" wouldn't tell "who is best", it wouldn't make much sense to cheat it. 20180920 17:36:28< Soliton> the add-on couldn't do the crawling. but you could and then upload a new version with the collected data. you'd have to constantly update the add-on though and people would have to constantly download it. 20180920 17:36:41< vn971> Soliton: true. 20180920 17:39:16< Soliton> i think the idea has merit on the basis that communication is cumbersome, especially with people you don't know. so getting the stats from them without asking would be useful. how useful the stats are to decide some handicap and whether you should do that in secrecy... 20180920 17:39:40<+wesdiscordbot> Merit shmerit 20180920 17:40:09< gfgtdf> i think it's be easier to implement and such tracking system in wesnoth itself, 20180920 17:40:31< vn971> Soliton: if it'd be a separate add-on providing stats only, alternative handicap implementations would be possible. Though that'll confuse players even more... 20180920 17:41:25< vn971> gfgtdf: waiting for the other part of the message - this felt a bit unfinished. 20180920 17:41:48< gfgtdf> hmm yes was going to write more but then decided against it. 20180920 17:42:05< Soliton> gfgtdf: i also thought that the general idea of tracking how much you played some scenario would be useful in wesnoth itself. especially since you then can add a way to view those stats outside of a game. 20180920 17:43:28< gfgtdf> having data on for eachample which factions won woudl also be nice to ahve for exampel for balancing. Te detaisl might be a little hard to do though, for example correctlky matching reloaded games. 20180920 17:44:23< vn971> gfgtdf: yes. If "who won" starts to be involved, complexity rises by a whole new degree I think. 20180920 17:44:49< Soliton> well, we do have a surrender feature now which makes it possible to check replays for this. 20180920 17:45:03< vn971> gfgtdf: who started the game, who left, was anyone droided, how to determine the game result itself, etc etc. 20180920 17:45:08< Soliton> not sure how often it's used though. 20180920 17:45:23< vn971> Soliton: oh, indeed. If it's preessed though. But for Era balancing, it'll be good enough. 20180920 17:45:57< Soliton> someone would have to try to gather some stats to see how much you can get out of it. 20180920 17:46:52< gfgtdf> Soliton: i actuall think its used rather often, but also for 'normal' game ends the server offers afaik no way to detemine the winnder without replaying the whole thing (which might be doable though, but is a but triycky in particular since it menas running addon code on a 'replay server') 20180920 17:47:32< vn971> can this really happen with wesnoth (wesnothd) though? I mean, if we talk about add-ons, then there's no policy except ethics. You can just go ahead and do anything you want. But for wesnoth itself, some people would vote against "rankings" and could even vote against "statistics". But again, I'm not a member of the real core devs. For anyone having more familiarity -- does "stats" sound like an actual possibility? 20180920 17:47:36< zookeeper> you clearly need a bot that lurks on the server, constantly updates a database with who plays on which map, and pops in as an observer to every single game lobby and announces who's a newbie and who's not, so the players can set the gold sliders accordingly :] 20180920 17:47:40< Soliton> gfgtdf: no way to get the add-on code. 20180920 17:48:22< Soliton> (unless you track all add-on updates and keep old versions.) 20180920 17:50:00< vn971> zookeeper: that sounds exactly like the thing that'll never happen though.:D 20180920 17:50:02< Soliton> is there even a way to know what add-ons/mods were all involved? 20180920 17:50:34< vn971> zookeeper: I mean, many people would oppose that. Also it's intrusive, and I'd even say very hard to maintain properly/sanely. 20180920 17:51:05< vn971> Soliton: one of the fields of the savefile (and in Lua API) is a comma-separated list of add-on names. 20180920 17:51:34< Soliton> all add-ons each player had installed? 20180920 17:52:08< Soliton> those are just required add-ons or so, right? 20180920 17:52:35< gfgtdf> Soliton, it contains all addosn that are used in that game, but not all addons that the user has installed. 20180920 17:53:05< Soliton> what does used in that game mean exactly? 20180920 17:53:06< vn971> Soliton: only add-ons enabled on a map are stored in savefile I think. 20180920 17:53:25< gfgtdf> Soliton, there is the rare case of addons that have an effect without beeing enabled but i think we can inore those for this ducussion. 20180920 17:53:45< Soliton> gfgtdf: well, that is what i was going for though. :-P 20180920 17:54:21< gfgtdf> i think some of a 'no random' mods fork that way, but ye in partiuclar for multiplayer those usualyl ranet used becasue tehy lead to oos anyway becous usually other do not have them installed. 20180920 17:54:31< gfgtdf> s/fork/work 20180920 17:55:25< Soliton> well, i'd rather ignore the whole trying to work out a winner from actually replaying a game to just focus on the surrender feature. 20180920 17:55:46< vn971> Soliton: agree one hundred percent on this one. 20180920 17:56:23< vn971> Soliton: or, alternatively, not measure "winnings" at all. 20180920 17:56:52< vn971> Soliton: could use the stats for Era balancing though. Just not for rank. 20180920 17:56:53< gfgtdf> yes, but we ahve the alterntive is makign the game tell the server the winner even when it happens the normal way (surrender not used) 20180920 17:57:27< Soliton> how? 20180920 17:58:00< Soliton> i don't think there is such a way. 20180920 17:58:11< Soliton> maybe that is what you meant. 20180920 17:58:16< gfgtdf> edit the client, like adding `send_to_wesnothd(did_win ? "win" : "loose")` at game end. 20180920 17:58:31< Soliton> who's going to decide that? 20180920 17:58:56< Soliton> that is exaclty what the surrender feature is about because there is no way to decide that automatically in general. 20180920 17:59:00< gfgtdf> the client, if the clients send diffetrn data, maybe count it as invalid, not sure 20180920 17:59:42< gfgtdf> not in gernal but often the games simpyl end because one of the leader dies. and in that case the surrender feature is not used. 20180920 18:00:05< gfgtdf> with reyling on the surrender feature, you automaticially ignore all games that ended by leader death 20180920 18:00:11< Soliton> for those cases it would be nice, yes. 20180920 18:00:37< Soliton> those you can actually figure out from the replays with not that much effort though. 20180920 18:00:46-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has quit [Remote host closed the connection] 20180920 18:00:54< vn971> gfgtdf: what would you want out of this stats anyway? How would you use it? Surely you don't think of making a rank system out of this thinly reasoned data right? (If you don't object to my estimation anyway). 20180920 18:00:59< vn971> oh, oops. 20180920 18:01:14-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has joined #wesnoth-umc-dev 20180920 18:01:16< hk238> hm it would be nice to have some co-op game modes that would be interesting 20180920 18:01:19< vn971> gfgtdf: what would you want out of this stats anyway? How would you use it? Surely you don't think of making a rank system out of this thinly reasoned data right? (If you don't object to my estimation anyway). 20180920 18:01:50< hk238> since this stats and rankings and handicaps tends to get into competive playing, which is fine, but in a sense co-op game modes are more prosocial 20180920 18:02:05< vn971> Soliton: not sure about "not that much". You have no way of telling whether a unit was "canrecruit". 20180920 18:02:20< Soliton> what's "thinly reasoned data"? 20180920 18:02:27< gfgtdf> not an numeric ranking systm, but of course player could just look at the games of a player and estimate his strength. 20180920 18:02:55< vn971> Soliton: I meant trying to decide who is winner without explicit things like "team death" or "surrender feature used". 20180920 18:03:24< gfgtdf> Soliton: how am i able to determine this ending form replay without replaying? 20180920 18:03:43< Soliton> pretty sure there is a way to figure out the leaders from a replay. 20180920 18:03:44< vn971> gfgtdf: do you hope for this to become integrated into wesnoth/wesnothd, or would you see it implemented as an add-on? 20180920 18:03:59< vn971> Soliton: don't think so TBH. 20180920 18:04:07< Soliton> so then you check whether the replay ends with a successful attack on them. 20180920 18:04:26< vn971> Soliton: but the savegame _could_ contain explicit data on side being destroyed. This I don't know. 20180920 18:04:44< gfgtdf> Soliton, reoplays odn't contain information about attack results (except the rtandom seeds which can generate that attck by reypling) 20180920 18:04:44< hk238> considering the mp server uploads replays, it wouldn't be a stretch to supplement those replys with some win value 20180920 18:05:03< gfgtdf> Soliton, also addosn with even driven wepon specials migth be involved for example 20180920 18:05:05< vn971> Soliton: consider for example the "switch leader" add-on. The thing that modifies "canrecruit" is an add-on... 20180920 18:05:37< gfgtdf> vn971: my plan woudl be to intgrate it into wesnoth/wesnothd, anym make asoem website that exposes the database. 20180920 18:05:37< Soliton> yes, for simple cases. not multiple leaders and dynamically switching them in the game or whatever. 20180920 18:06:32< vn971> I think wesnoth client could be changed to explicitly write team/side loss, no matter the current state of things. Seems both doable and I doubt it could get serious negative feeback. 20180920 18:06:56< Soliton> i'm thinking about stats to balance default for example. you don't care about crazy scenario games there. 20180920 18:08:11< vn971> Soliton: you'd probably want to consentrate on specific maps as well then. Avoiding e.g. CreepWars or Colosseum. 20180920 18:08:20< vn971> *concentrate 20180920 18:08:49< Soliton> not that i'm against having wesnoth explicitely log this in the cases were it knows. that'd certainly be nice. 20180920 18:09:17< vn971> gfgtdf: if you do that, it'd be quite an undertaking, and probably VERY useful for writing any kind of ranking systems (even add-on based ones). 20180920 18:10:10< Soliton> there is no need for wesnothd integration at first. start small and save the info in replays then we already have replays.w.o as a database. 20180920 18:13:51< gfgtdf> vn971: not sure, i might attept it. 20180920 18:14:21<+wesdiscordbot> Is there any official movement at all to try and improve balance of any of deafult or dunefolk fractions? 20180920 18:14:33< hk238> hmm a co-op mode where 1 player acts as an antagonist might also be interesting 20180920 18:15:06< hk238> default is quite well balanced for lvl1 units, though I don't think it's that balanced for lvl2 or lvl3 units, in most cases that doesn't matter 20180920 18:15:15< Soliton> balance is between factions. you cannot improve the balance of one faction. 20180920 18:15:36< hk238> with these stats including win/loss information you could also find out if some factions are performing better statistically 20180920 18:15:38< gfgtdf> hk238: so basically a 1vs2 map whetre the 2p team wins after a trunX 20180920 18:16:18< hk238> gtgdf I was something like an adventure where a group of players of arbitrary size tries to complete some question, and there's a system for 1 player to try and prevent them, such as raising undead monsters along the way, or so on 20180920 18:16:25< hk238> *question, quest 20180920 18:17:00< gfgtdf> iom actuall unsure whether we woudl actually get enough data to make decisions based on it, if we for example hav onl a few players and one very good player has a significal favour of one certain factions this could bias the statisitcs quite a bit 20180920 18:17:01< hk238> so it would in a sense be co-operative, due to the team having some common goal, but also competive, since the antagonist could be considered winning if the quest ends early, and vice versa 20180920 18:17:20<+wesdiscordbot> And if its a mirror? Anyway i'm especially curious about dunesfolk. 20180920 18:17:44< hk238> certainly the stats could be biased by a bunch of confounding factors and not represent some ultimate truth about the fundamental balance between the factions 20180920 18:18:08< hk238> but they would most likely be reasonable approximations to consider 20180920 18:18:38< hk238> e.g. if one faction has above average win% with all other factions, that would certainly be evidence towards the faction being objectively better 20180920 18:18:42<+wesdiscordbot> Try to count how much healing is worth 😄 fun stuff... 20180920 18:19:22< vn971> Soliton: > you cannot improve the balance of one faction. -- to narrow it further down -- I'd consider Faction-VS-Faction balance. 20180920 18:19:35< vn971> Like for example A could be strong in general, but not against B. 20180920 18:19:48< hk238> where as if you have some faction statistically performing much worse than other factions, it would be reasonable to assume it's evidence against the notion that the faction in question is objectively better.. but of course it's not entirely true, just a good way of guessing 20180920 18:19:49< vn971> for example Drakes could be OK, but not very much so against UD. 20180920 18:19:58<+wesdiscordbot> Eg. Loyal, but Ud exists. 20180920 18:20:16<+wesdiscordbot> Drakes have problem not only with Ud. 20180920 18:20:33< hk238> Drakes should have one more unit, they seem a little too simple 20180920 18:20:48< hk238> as an unrelated notion 20180920 18:20:48< hk238> :D 20180920 18:20:51<+wesdiscordbot> They are complicated enough. 20180920 18:21:04< vn971> hk238: I'll add my usual comment: or everyone else should have 1-2 units less. :D 20180920 18:21:36<+wesdiscordbot> Srsly... I tried to touch drakes... Lizards are ok on other hand. 20180920 18:22:04< hk238> we've definitely a difference of opinion in this matter. I believe the reason is that you're misguided about the nature of complexity and unaware of it's possible manifestations, but that's a little arrogant a way to put it 20180920 18:24:11<+wesdiscordbot> There were tries to come up with any changes but always someone disagrees. 20180920 18:24:18< hk238> I'm in favour of a type of complexity where the majority of ever diminishing nuances have decreasing significance 20180920 18:24:53< hk238> thus that there is a simple representation that is accurate upto a probability, but to increase accuracy you'd need to take into account the nuanced information 20180920 18:25:20< hk238> which then rules out arbitrariness in a sense.. I'm not sure if that description is decipherable 20180920 18:26:21< hk238> I don't know how to change drakes either, haven't really thought about that. But matches involving drakes seem to be simpler and more often reduce to some simple logic while many other match ups can be complicated 20180920 18:26:29<+wesdiscordbot> Well that's why i only believe in match not in opinion. Kinda is. 😄 20180920 18:28:22<+wesdiscordbot> Hmm if i send graphic will people on IRC see it? 20180920 18:28:28<+wesdiscordbot> Yes 20180920 18:28:35<+wesdiscordbot> (It shows up in link form) 20180920 18:28:48<+wesdiscordbot> Wow that was fast. Thanks. 20180920 18:40:22<+wesdiscordbot> @hk238 I do not feel like any matchup is particularly commplicated. Maybe its just me becouse im just so used to them at this point.... 20180920 18:55:40< hk238> maybe :o 20180920 19:02:34<+wesdiscordbot> Healing value acctualy quite accuratley counted. 😄 Almost 2 days of work tho... 20180920 19:04:17-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has quit [Remote host closed the connection] 20180920 19:04:39-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has joined #wesnoth-umc-dev 20180920 19:11:46< vn971> BTW, I've finally spent even more time on my add-on tooling, and I now have a specific command to publish an update and automatically bump the major component, minor component or the "patch" component of the version. 20180920 19:12:30< vn971> e.g. if add-on had version 3.8.6, then I can automatically upload a new version under 3.8.7. Or 3.9.0 for a more serious change, or 4.0.0 for super-serious change. 20180920 19:12:57< vn971> finally the "git tag" and _server.pbl hassle is gone. Making a small change and uploading it takes seconds now. 20180920 19:15:17< hk238> sounds pretty cool 20180920 19:15:18< hk238> :D 20180920 20:40:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180920 20:40:38-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-umc-dev 20180920 21:17:54-!- vn971 [~vasya@94.158.103.15] has quit [Ping timeout: 252 seconds] 20180920 21:44:59-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180920 21:46:10-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev 20180920 21:51:20-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180920 22:03:36< hk238> hmm I'd need somekind of project.. any suggestions? 20180920 22:03:38< hk238> :D 20180920 22:18:09<+wesdiscordbot> Write an AI that plays as good as a human player. 20180920 22:20:24< hk238> D: 20180920 22:21:46< hk238> this is a bit off topic but I've this 'delusion' that 'the russians' have something against me and cause trouble which includes things like hacking the computer or doing things online. Not very credible. But that seems like the type of project I wouldn't want to get into even if it was plausible in this situation. :D 20180920 22:23:56< hk238> speaking of which has there been any 'suspicious activity' about the wesnoth servers that someone might have taken note of? I'm sorry it's so silly. :D 20180920 22:34:35<+wesdiscordbot> Yes it's silly 20180920 22:34:56<+wesdiscordbot> So I'm not going to address that question even though I'm qualified to do so 20180920 22:38:25< hk238> sorry I didn't mean to seriously ask something like that, it was more like humor 20180920 22:38:33-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev 20180920 22:47:39-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180920 22:56:03<+wesdiscordbot> Hmm, if I gather what you are talking about, Drakes in my games seem to always have an objective advantage 20180920 23:07:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-umc-dev 20180920 23:19:11< hk238> how come? 20180920 23:20:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 246 seconds] 20180920 23:29:50-!- sevu [~sevu@p5485508D.dip0.t-ipconnect.de] has joined #wesnoth-umc-dev 20180920 23:36:21-!- sevu [~sevu@p5485508D.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20180920 23:38:54-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180920 23:56:17-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has quit [Quit: Leaving] 20180920 23:56:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-umc-dev 20180920 23:56:59-!- gfgtdf [~Daniel@x4e34250c.dyn.telefonica.de] has joined #wesnoth-umc-dev --- Log closed Fri Sep 21 00:00:42 2018