--- Log opened Tue Aug 28 00:00:28 2018 20180828 00:22:29-!- minzbonbon [~min@meta23.net] has quit [Ping timeout: 268 seconds] 20180828 00:32:18-!- minzbonbon [~min@meta23.net] has joined #wesnoth-dev 20180828 01:33:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180828 01:35:54< irker804> wesnoth/wesnoth:master Jyrki Vesterinen c59ae5204a Pofix: fix incorrect removal of a space AppVeyor: All builds passed 20180828 02:13:58<+wesdiscordbot> @mattsc I think the sequential x, then y setting would move it off 20180828 02:15:13<+wesdiscordbot> @Vultraz How? If (x1,y1) and (x2,y2) are on the map, then all combinations of x's and y's (there really are only 4) are on the map too, aren't they? 20180828 02:15:53<+wesdiscordbot> I can't remember now 20180828 02:16:05<+wesdiscordbot> maybe it had to do with the unit ending up in places it shouldn't in the interim 20180828 02:16:36<+wesdiscordbot> Well, that's the problem with occupied hexes that I mention above, but that is not moving them off the map. 20180828 02:17:02<+wesdiscordbot> Moving them onto impassable terrain in the interim is not a problem. 20180828 02:19:14<+wesdiscordbot> i can't remember 20180828 02:19:30<+wesdiscordbot> all I remember is celmin telling me setting x, then y, could be problematic 20180828 02:19:39<+wesdiscordbot> perhaps it might place a unit on top of another? 20180828 02:20:09< celticminstrel> I don't remember either. 20180828 02:20:18<+wesdiscordbot> No, it doesn't. But it won't work if there's a unit on the interim position. 20180828 02:20:19< celticminstrel> But placing a unit on top of another certainly would be a problem. 20180828 02:20:28<+wesdiscordbot> As in, it simply won't do it. 20180828 02:20:37< celticminstrel> Really? Okay then. 20180828 02:20:56<+wesdiscordbot> So, yes, I agree that using x,y is problematic, just not for the reason stated on the wiki. 20180828 02:21:02<+wesdiscordbot> I'll change that. 20180828 02:21:31< mattsc> celticminstrel: yeah, that’s at least what 1.15 currently does (I tried). 20180828 02:22:22< mattsc> Not sure if that’s intended behavior. 20180828 02:23:49< mattsc> Well, just tested, the behavior in 1.14 is the same, so at least it’s not because of 1.15 still being only partially operational. 20180828 02:25:13< mattsc> “the behavior” = if you try to put a unit onto an occupied hex by changing the coordinates of the Lua proxy unit (whether this uses x, y, or loc), the unit is not moved 20180828 02:26:02< mattsc> There’s no error message in that case, it just fails silently (which is probably ok) 20180828 03:08:23-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180828 03:44:33< irker804> wesnoth/wesnoth:1.14 josteph e4e3483598 Lua Console: Print an error message when AppVeyor: All builds passed 20180828 03:55:36-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] 20180828 04:46:29<+wesdiscordbot> @mattsc there's also the possibility someone was using a non-rectangular map, such as A New Land's 20180828 06:41:33< irker804> wesnoth/wesnoth:1.14 josteph d823a01dea Liberty S3: Play orcish war drums AppVeyor: All builds passed 20180828 06:49:22-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180828 06:55:43-!- valdar [~atarocch@93.56.164.28] has quit [Ping timeout: 268 seconds] 20180828 08:17:48< irker804> wesnoth/wesnoth:1.14 josteph 6cf33447b3 Choose Your Faction: Paper over layout i AppVeyor: All builds passed 20180828 08:52:16-!- valdar [atarocch@nat/redhat/x-xoxmlgnzqplmdcqm] has joined #wesnoth-dev 20180828 10:22:47< irker804> wesnoth/wesnoth:1.14 Gregory A Lundberg 007ea8443f Fix error: no previous declaration AppVeyor: All builds passed 20180828 10:51:31< irker804> wesnoth: Gregory A Lundberg wesnoth:1.14 500c329fa1a1 / src/ (color.hpp map/location.hpp): Fix error: missing noexcept https://github.com/wesnoth/wesnoth/commit/500c329fa1a1933c780149c76339dbbc94ffd6c1 20180828 10:51:32< irker804> wesnoth: Gregory A Lundberg wesnoth:1.14 133254e3afec / src/server/server.cpp: Fix error: no previous declaration https://github.com/wesnoth/wesnoth/commit/133254e3afec71effa0cddab72c99b811c968b5a 20180828 10:58:13< irker804> wesnoth: Gregory A Lundberg wesnoth:master 3826c263b1ac / src/ (color.hpp map/location.hpp): Fix error: missing noexcept https://github.com/wesnoth/wesnoth/commit/3826c263b1ac203c5487c1a81000c3111bda263b 20180828 10:58:15< irker804> wesnoth: Gregory A Lundberg wesnoth:master 616ae9b47285 / src/server/server.cpp: Fix error: no previous declaration https://github.com/wesnoth/wesnoth/commit/616ae9b47285fd84c458efbe72df18c540a14a0e 20180828 11:52:12< irker804> wesnoth/wesnoth:1.14 Gregory A Lundberg 27e5d2bcf4 Fix error: no previous declaration AppVeyor: All builds passed 20180828 12:36:06-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180828 12:36:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180828 12:42:27<+wesdiscordbot> I have a case of an [modification] and an [era] using the same macros, and as they are in the same add-on, they are in the same macro namespace, and redefine the macros. Works, besides leaving a lot of warnings about macro redefinitions, which may be shut up by nesting each of the 100 macros in an #ifndef foo. 1.13 introduced a [resource] tag, which can be loaded with [load_resource]. I guess use of that may cause 20180828 12:42:28<+wesdiscordbot> preprocessing only once, does someone know if that assumption is correct? 20180828 12:47:15<+wesdiscordbot> @Vultraz The "technical map" is still rectangular and you can place units on void terrain and the like just fine. 20180828 12:47:24<+wesdiscordbot> true 20180828 12:48:01<+wesdiscordbot> maybe the map borders were meant with off-map 20180828 12:48:46<+wesdiscordbot> @sevu But that then applies to the full move as well as the individual ones. 20180828 12:49:00<+wesdiscordbot> Anyways, doesn't really matter. We agree that it's not good to use the individual coordinates. I'll adjust the wording on the wiki a little. 20180828 12:51:31<+wesdiscordbot> @sevu What I mean is: if the individual coordinate move would place the unit on a border, so would the 2-dim move; so it doesn't matter. 20180828 12:55:21<+wesdiscordbot> If you want to move from one hex next to the border to a 2 moves away other hex next to the border, then there are two "possible" moves, one correct one and one over the border hex. 20180828 12:56:59<+wesdiscordbot> Why is the second one not "correct"? (And by the way, moving a unit onto a border hex does not work; I tried that too.) 20180828 12:57:46<+wesdiscordbot> We are talking about placing units using Lua here, not actually moving them. 20180828 13:00:40<+wesdiscordbot> I' don't know if you can place units on the border hex with lua, and what happens if you do – I had a problem with it in WML, the unti was then just not spawned. It's how I understood the text from the wiki. 20180828 13:02:26<+wesdiscordbot> @sevu. You cannot. But even if it were possible, my point about two (by x/y) vs. one (but loc) still stands. If the first move by one coordinate gets you onto the border, then the full move is also on the border. So you have the problem either way. 20180828 13:05:13<+wesdiscordbot> What was toe problem with two x/y? Somehting else than that you first change x and have an in between state unit y is changes? 20180828 13:10:00<+wesdiscordbot> I see, the possible coordinates would always be not on the border 20180828 13:14:16<+wesdiscordbot> @sevu yeah. But even so, the problem is that the intermediate hex might be occupied, which also interferes with the move. So using two moves can be problematic. 20180828 14:52:30-!- irker804 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20180828 14:53:50-!- valdar [atarocch@nat/redhat/x-xoxmlgnzqplmdcqm] has quit [Ping timeout: 244 seconds] 20180828 15:45:54-!- gfgtdf [~chatzilla@x4e32c084.dyn.telefonica.de] has joined #wesnoth-dev 20180828 15:47:49< gfgtdf> sevu: [load_resource] won't help your with macros, , it works very similar to [modification] except that its invisible to the user. 20180828 15:55:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180828 15:55:24-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180828 16:12:59-!- gfgtdf [~chatzilla@x4e32c084.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.9.0/20180621064021]] 20180828 16:23:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180828 16:23:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180828 16:46:56-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180828 16:47:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180828 16:52:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180828 16:52:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180828 16:55:20-!- irker787 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20180828 16:55:20< irker787> wesnoth/wesnoth:1.14 Gregory A Lundberg 133254e3af Fix error: no previous declaration AppVeyor: All builds passed 20180828 17:20:42-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180828 17:37:59<+wesdiscordbot> For the wesnoth-umc-dev repository: http://wesnoth-umc-dev.ai0867.net/index.php / https://sourceforge.net/projects/wesnoth-umc-dev/ is under the gpl? 20180828 17:38:21<+wesdiscordbot> Is it correct that if not specifed in a specific add-on, that add-on is under GPL v2 20180828 17:39:19<+wesdiscordbot> I don't remember 20180828 17:41:44<+wesdiscordbot> some add-ons don't have it in their directory, but on SF it say license is GNU GPLv2, and it say as a requirement for adding something on the website: "All content allowed inside the repository must be distributable, modifiable and reusable under a license conforming to the Open Source Definition; to reduce complexity, we recommend the GNU General Public License, versions 2 or 3. In the case of music, sounds, graphics 20180828 17:41:45<+wesdiscordbot> and other binary resource files, as an special exception to the GNU GPL, the “source code” of those files is considered to be the files themselves." 20180828 17:43:17<+wesdiscordbot> Yeah sounds about right. 20180828 17:44:48<+wesdiscordbot> ok, thanks 20180828 18:40:13<+wesdiscordbot> Something seems to be different about macros and the [ressource] tag. I made some texting and wrote an example add-on, but I did not fully understand yet what is happening and what should be happening. 20180828 18:42:03<+wesdiscordbot> Thesis 1) Macros defined within the same add-on are availaible everywhere, also meaning what has been defined in an [modification] is in an [era] availaible. true/false? 20180828 18:42:24<+wesdiscordbot> False. 20180828 18:42:57<+wesdiscordbot> A new preprocessor context is created for each data/add-ons/ADDON_NAME/_main.cfg. 20180828 18:43:19<+wesdiscordbot> (Obviously this does not apply if you forcefully include an add-on from another's context.) 20180828 18:43:41<+wesdiscordbot> I was not clear, I mean everywhere within the add-on 20180828 18:43:53<+wesdiscordbot> instead of "everywhere" 20180828 18:44:19<+wesdiscordbot> A macro that is defined remains defined until the next #undef or until the parent context is destroyed. 20180828 18:45:00<+wesdiscordbot> This does mean that it can only be used after it's defined, following the preprocessor's substitution and reading order. 20180828 18:45:33<+wesdiscordbot> e.g. this is not valid code: {A} #define A #enddef 20180828 18:45:51<+wesdiscordbot> But this is: #define A #enddef {A} 20180828 18:46:00<+wesdiscordbot> (Even across file substitution boundaries.) 20180828 18:47:33<+wesdiscordbot> I think this holds no longer true since... 1.12 at least? At least it turned out that the order in which way I source the macros in _main.cfg did not matter 20180828 18:48:21<+wesdiscordbot> It's still true. 20180828 18:48:44<+wesdiscordbot> You are either getting duplicate definitions somewhere (which the engine will warn you about since 1.13.x), or your macro substitutions are delayed. 20180828 18:49:04<+wesdiscordbot> This is legal code: #define A {B} #enddef #define B #enddef {A} 20180828 18:49:11<+wesdiscordbot> Because the substitution of B is delayed. 20180828 18:49:30<+wesdiscordbot> so, it does work, but takes longer/more ressources? 20180828 18:49:45<+wesdiscordbot> Only once a macro is substituted do its nested substitutions (whether they be file or macro substitutions) are resolved. 20180828 18:50:34<+wesdiscordbot> I believe there's only one interpretation for each of the things I said above. 20180828 18:50:56<+wesdiscordbot> Either the code is invalid or it isn't and each case presents you with valid or invalid code. 20180828 18:53:18<+wesdiscordbot> Incidentally a trivial way to test preprocessor macro definitions is to couple #ifdef/#ifndef with #warning or #error. 20180828 18:53:30<+wesdiscordbot> sounds lika an idea 20180828 18:53:35<+wesdiscordbot> would you expect this to work: https://bpaste.net/show/3817d44fe13d (which doesn't, unless you swap the two tags) 20180828 18:54:05<+wesdiscordbot> You typed [ressource] 20180828 18:54:31-!- gfgtdf [~chatzilla@x4e32c084.dyn.telefonica.de] has joined #wesnoth-dev 20180828 18:54:41<+wesdiscordbot> Unless the documentation is incorrect and the person who implemented this didn't know how to spell resource, the correct spelling is [resource]. 20180828 18:55:14<+wesdiscordbot> Also in this case the issue is beyond the scope of anything I said. 20180828 18:55:43<+wesdiscordbot> I was talking strictly about the WML preprocessor. In this particular example you've got local code consumers involved. 20180828 18:56:04<+wesdiscordbot> Namely, whatever it is that reads [era] and [resource] (which may be two entirely unrelated pieces of code). 20180828 18:56:25<+wesdiscordbot> If they're processed by the same consumer, odds are that the order does matter. 20180828 18:57:30< gfgtdf> the order in which [era] and [resource] appears does nto matter 20180828 18:58:03<+wesdiscordbot> Other than that, [unit_type], [scenario/multiplayer/tutorial/test], [side] (unconfirmed, don't quote me on this one), and [terrain_graphics] relative to [terrain] are essentially the only cases where consumers are not going to complain if you declare something that depends on something that hasn't been seen yet. 20180828 18:58:50<+wesdiscordbot> what do you mean by consumer? the tags like [unit_type]? 20180828 18:59:10<+wesdiscordbot> I'm calling consumer any piece of code (whether it be C++ or Lua) that reads WML. 20180828 18:59:15<+wesdiscordbot> Parsed WML. 20180828 18:59:30<+wesdiscordbot> (Instances of the config class ready for use.) 20180828 19:00:50<+wesdiscordbot> For example, the code that sets up a scenario consumes WML (in particular the [scenario/multiplayer/tutorial/test] array from the parsed tree that the game loader code spits out). 20180828 19:02:15<+wesdiscordbot> You could call it an "interpreter" but that word is better used exclusively with the events engine. 20180828 19:02:35<+wesdiscordbot> Everything else is essentially just reading a description serialized as WML. 20180828 19:03:03<+wesdiscordbot> Whilst the events engine actually runs its input (which includes both WML and Lua). 20180828 19:06:28<+wesdiscordbot> I thought so far that things would be as simple as having an preprocessor and sth. wich runs preprocessed WML. So... [unit_type], [terrain_graphics] , [...] and the events engine run the preprocessed wml as code, while everything else seed the preprocessed WML as data/textfile and reads from it? 20180828 19:06:57<+wesdiscordbot> *reads 20180828 19:07:42<+wesdiscordbot> The events engine is literally the only thing that runs its input. 20180828 19:08:18<+wesdiscordbot> Everything else is descriptions and whether order matters varies from place to place. 20180828 19:08:54<+wesdiscordbot> In all cases Wesnoth reads a WML tree resulting from parsing the preprocessor's output. 20180828 19:09:12<+wesdiscordbot> okay 20180828 19:11:24<+wesdiscordbot> So, the code from before, even with correct English, writing resource. it's the _main.cfg, besides is a 2 line file,example.cfg , with the macro definition, no other add-ons. Depending on swapping the tags I get an error or nor about the macro missing 20180828 19:11:25<+wesdiscordbot> https://bpaste.net/show/830dd26ea8ac 20180828 19:15:22< irker787> wesnoth/wesnoth:master Gregory A Lundberg 616ae9b472 Fix error: no previous declaration AppVeyor: All builds passed 20180828 19:21:43<+wesdiscordbot> Can someone reprocude it? I'm rebuilding right now, as I got an error when clicking on »load« 20180828 19:22:14<+wesdiscordbot> example.cfg probably defines the relevant macro? 20180828 19:23:00<+wesdiscordbot> exactly, and as #define IMPORTANT_MACRO #enddef 20180828 19:23:11<+wesdiscordbot> There you have it. 20180828 19:23:25<+wesdiscordbot> I mean, that ties in with what I already explained about the preprocessor. 20180828 19:23:33<+wesdiscordbot> A macro does not exist until it's defined. 20180828 19:26:48<+wesdiscordbot> makes sense… 20180828 19:28:07<+wesdiscordbot> Thanks for the help 😃 20180828 19:33:29<+wesdiscordbot> I thought you were talking about the resource not being defined, not the macro. 20180828 19:33:44<+wesdiscordbot> Otherwise the answer would've been much shorter. :p 20180828 19:35:18-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds] 20180828 19:43:09-!- stikonas_ is now known as stikonas 20180828 20:43:11-!- valdar [~atarocch@93.56.164.28] has joined #wesnoth-dev 20180828 21:20:26-!- travis-ci [~travis-ci@ec2-54-157-196-205.compute-1.amazonaws.com] has joined #wesnoth-dev 20180828 21:20:27< travis-ci> gfgtdf/wesnoth#1238 (1.14 - b83e43a : gfgtdf): The build was broken. 20180828 21:20:28< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/421753863 20180828 21:20:28-!- travis-ci [~travis-ci@ec2-54-157-196-205.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180828 22:15:50-!- irker787 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20180828 22:32:03-!- irker408 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20180828 22:32:03< irker408> wesnoth/wesnoth:master mattsc 2bf56be5fc Micro AIs: simplify unit variable handli AppVeyor: All builds passed 20180828 23:52:45-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180828 23:54:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] --- Log closed Wed Aug 29 00:00:29 2018