IRC logs for #openttd on OFTC at 2011-08-19
⏴ go to previous day
00:09:03 <Eddi|zuHause> pjpe: penalties for npf and yapf are separate, they also have separate settings
00:09:25 <Eddi|zuHause> pf.yapf.* and pf.npf.*
00:09:50 <Eddi|zuHause> pjpe: i think there are more up-to-date speedsignal patches
00:12:17 <pjpe> i kinda want something to do but i'm not really sure what
00:16:16 *** lessthanthree has joined #openttd
01:37:18 <pjpe> eddi you wouldn't know if yapf takes in to account newgrf track speed limits already would it?
02:25:55 *** rhaeder1 has joined #openttd
04:17:51 <planetmaker> pjpe: track speed limits are taken into account such that too low speed limits are penalized
04:19:27 <pjpe> are there any plans to just include speed limit signals in trunk?
04:19:33 <pjpe> it seems like a rather simple inclusion
04:19:40 <pjpe> and people have been doing patches for it for years
04:20:39 <planetmaker> though interestingly I don't see a related yapf setting...
04:21:27 <planetmaker> I know of no such immediat plans to include speed signals
04:21:37 <planetmaker> I'm not sure about easy either ;-)
04:22:44 <pjpe> it seemed like 70% of the one i was looking at was making it buildable and guis and such
04:23:01 <pjpe> and then a short section for adding cost to the path if it encounters the signal
04:28:54 <planetmaker> ah... there it is, only within signal look-ahead distance: extra_cost += YAPF_TILE_LENGTH * (max_veh_speed - max_speed) * (4 + tf->m_tiles_skipped) / max_veh_speed;
04:56:22 *** Eddi|zuHause has joined #openttd
05:49:14 <KittenKoder> Houston, we have a problem.
05:52:06 <KittenKoder> I used the 9-8 template from OGFX, though the engine doesn't fill the sprite area it hangs over a few pixels in game .... then engine is 33 pixels tip to tip, the template from OGFX is 36 pixels.
05:54:02 <planetmaker> and the problem is...?
05:54:18 <KittenKoder> So it's not a problem?
05:54:44 <planetmaker> the only judge is how it looks ingame
05:54:45 <KittenKoder> It's okay if the sprites hang out a couple pixels in the information screen?
05:55:03 <KittenKoder> Everywhere else it looks great. LOL
05:55:04 <planetmaker> well, up to you :-)
05:55:20 <planetmaker> make special purchase list sprites or purchase list alignment, if you like
05:55:52 <KittenKoder> Not on the purchase list, that's fine to, it's the information dialog with the train itself.
06:01:54 *** Biolunar has joined #openttd
06:05:25 <planetmaker> well... if you use 9/8 the train has to be longer than the game was designed for
06:06:35 <KittenKoder> I know there are 9/8 trains in other sets .... just never noticed any such effect in that dialog.
06:06:47 <KittenKoder> Perhaps I'm just being too critical of mine.
06:16:21 *** Br33z4hSlut5 has joined #openttd
06:17:31 <planetmaker> the game engine can only deal with 8/8 at most. Everything longer is... stretching the boundaries
06:19:09 <KittenKoder> Well, it's only a few pixels, literally, not a few wide, just a few pixels on the pointed tip.
06:19:23 <KittenKoder> ^_^ I like pointy trains.
06:20:07 <KittenKoder> But if it's not something that's a huge matter then I'll just ignore it for something like a few pixels.
06:21:07 <KittenKoder> It gets cropped by the depot dialog, looks a bit odd but not horrible, I was just worried that it would be a huge deal if it happened.
06:36:35 *** Cybertinus has joined #openttd
06:51:17 *** DayDreamer has joined #openttd
06:55:58 *** andythenorth has joined #openttd
06:58:27 *** LordAro has joined #openttd
07:03:01 * andythenorth has lost eddi's algorithm for handling FIRS supplies
07:03:07 <andythenorth> it was 80% convincing
07:09:51 <pjpe> this p1sim looks really cool
07:09:57 <pjpe> too bad it will never be in a form people will want to really play
07:14:29 <planetmaker> andythenorth: re supplies. You seem to bring it up again and again it seems to remove them or more generally to throw over the whole ecnomy concept of FIRS. I'm not sure that's a sane approach
07:15:58 <planetmaker> I was honestly kinda taken aback a bit when I saw that discussion (again) yesterday
07:18:33 <andythenorth> well...the decision remains open ;)
07:19:19 <andythenorth> it's not a 0.7 decision
07:19:26 <planetmaker> as well one can decide to drive with 100km/h into a tree
07:19:33 <andythenorth> but it might need to be a change in 0.8
07:19:42 <andythenorth> supplies are currently flawed
07:19:56 <planetmaker> I feer much so that without supplies I'll loose interest
07:20:00 <andythenorth> but I think the solution is likely a change of algorithm, as per v and eddi suggestions
07:20:27 <planetmaker> as without supplies it's just default industries. Nothing new or different anymore
07:21:08 <andythenorth> maybe I should branch, remove them, and play a test game
07:21:34 <planetmaker> just tell me: what would be different to default industries then?
07:21:42 <andythenorth> more cargos, more industries
07:21:44 <planetmaker> except some graphics and cargo names?
07:22:19 <andythenorth> less code to maintain - all of the primary behaviour would be provided by openttd
07:22:29 <planetmaker> so... what 2ccTS is for trains FIRS would be for industries
07:22:33 <andythenorth> removing them is not something I want to do
07:22:38 <andythenorth> but it might be the right thing
07:22:46 <andythenorth> like when you have your teeth drilled
07:23:10 <planetmaker> Well, it's not the right thing
07:23:21 <planetmaker> They make sense both economically and game-play wise IMHO
07:23:42 <andythenorth> I think they deserve one more round of trying to improve the algorithm
07:23:49 <andythenorth> before throwing the baby out with the bath water
07:23:53 <planetmaker> what's wrong about the current one?
07:24:03 <andythenorth> it's unsatisfying
07:24:06 <planetmaker> I really fail to see it as failure
07:24:09 <andythenorth> people find it weird
07:24:25 <planetmaker> it's something they don't know
07:24:33 <KittenKoder> I like the 2ccTS.
07:24:50 <planetmaker> so they cry for what they know which is the same scheme as default industries
07:25:20 <KittenKoder> Default industries are boring.
07:25:51 <andythenorth> planetmaker: we could introduce different behaviour switching via parameter :P
07:25:55 <andythenorth> that would be fun to maintain
07:26:09 <andythenorth> already there is part of that :P
07:26:53 <KittenKoder> I have not seen any problems with 2ccTS and FIRS mixed, though I hate the NARS set .... after 1970.
07:27:05 <planetmaker> ach... I'll stop arguing. It should be obvious that supplies are THE unique selling point
07:27:38 <KittenKoder> I like the round chains, it adds something that makes the game more fun.
07:27:47 <andythenorth> I think there's nothing new to say that hasn't been said....so
07:27:57 <andythenorth> let's leave it until (a) we've tried a different algorithm
07:28:07 <andythenorth> and (b) it's clear what's happening with YACD
07:28:08 <planetmaker> but I'll grumble. Because if we now cut it down to "we just provide some new graphics and do nothing else" I feel my work on conversion to NML somewhat wasted
07:28:22 <planetmaker> c) ignore yacd. It's not there yet
07:28:39 <andythenorth> b == c in my brain
07:29:00 <andythenorth> there's no point changing the FIRS behaviour against an unknown YACD target
07:29:01 <planetmaker> yes, thus do not judge supplies by how you use them in yacd games
07:29:12 <andythenorth> planetmaker: FORK! :D
07:29:50 <planetmaker> I'd most probably not do that
07:30:07 <planetmaker> I'd keep playing what I have and ignore newer versions
07:30:11 <KittenKoder> Oooh ... will there be more complexity to FIRS soon?
07:30:25 <andythenorth> define complexity?
07:31:19 <planetmaker> similar to how on our servers seldom new versions of 2ccTS are used. The new ones just have too many pointless vehicles
07:31:48 <KittenKoder> Speaking of which, I need to get the latest 2ccTS.
07:31:55 * andythenorth wonders why ENSP isn't machinery already
07:32:04 <andythenorth> there's no gameplay reason
07:32:33 <planetmaker> "engineering supplies" is a clear indicator of "this helps machinery work"
07:32:43 <andythenorth> it would come to the same if reduced analytically? Deliver "stuff" for production increase
07:32:46 <planetmaker> like lubricants, screws, parts, engineers
07:32:55 <andythenorth> 'machinery' or 'engineering supplies' are just labels?
07:33:15 <planetmaker> for different boxes
07:33:46 <planetmaker> I really like there being three "... supply" cargos. It's clear. Immediately.
07:33:57 <planetmaker> I don't have to read anything. I just know: ship it to improve
07:34:13 <planetmaker> and that is conceptionally a _very_ good point
07:34:43 <andythenorth> so every time we poke at ENSP, it holds up ok
07:34:43 <planetmaker> it's one of the points IMHO where ECS vectors come short: it has similar cargos. But it's totally not obvious
07:34:57 <andythenorth> more clearly defined though
07:35:17 <planetmaker> the ENSP? Yes, they are more clearly defined
07:35:29 <andythenorth> no ECS is more clearly defined
07:35:49 <KittenKoder> Aha! I finally figured out the whole acceleration stuffs .... enough to make trains anyway.
07:35:58 <planetmaker> so? you want to make ecs2?
07:36:00 <KittenKoder> I never liked ECS.
07:36:14 <andythenorth> I want to not make something that confuses people
07:36:15 <planetmaker> ecs is great actually
07:36:36 <planetmaker> andythenorth: and exactly that's the strong point of ??SP cargos: they create clarity
07:36:41 <andythenorth> although tbh my iphone confuses me, and everybody loves those
07:36:55 <KittenKoder> 1. mines closing even when supplied .... in a game where 1 year actually is 1 year would be fine but something like TTD .... blech.
07:37:17 <planetmaker> they might be a bit fuzzy wrt what they constitute specifically in RL - but that's unimportant. And also an advantage
07:37:22 <planetmaker> one can ship many great cargo sprites
07:37:25 <andythenorth> the iphone is a strange thing - but that's a whole other story :P
07:37:42 <KittenKoder> 2. ECS doesn't work for me anymore for some reason, I can only get one subset at a time, can't enable all the GRFs for it at once.
07:38:03 <planetmaker> e.g. replacing FMSP by fertilizer is the worst of the choices... and makes it boring, cuts imagination etc
07:38:18 <andythenorth> might be worth kicking at FMSP in other ways though
07:38:27 <andythenorth> I've yet to play a game where FMSP are really working
07:38:39 <andythenorth> but this might be related to production code, not the cargo
07:38:47 <planetmaker> Well, I still like V's suggestion on how to treat primary boost via supplies
07:39:04 <andythenorth> yeah - so changing the algorithm might be the next step in the design process
07:39:04 <planetmaker> Thus higher output levels require coninued and higher supply input
07:39:14 <andythenorth> FMSP suffer a different issue
07:39:17 <planetmaker> with non-rigerous consideration
07:39:24 <planetmaker> of lower and upper boundaries
07:39:50 <planetmaker> what does it suffer?
07:40:13 <andythenorth> (1) it's often a PITA to build routes to farms
07:40:23 <andythenorth> with 2 outputs and 1 input, three road stops are needed
07:40:37 <andythenorth> and there has to be enough road to handle blocking while loading
07:40:55 <andythenorth> so it can be boring to build those kind of routes (and looks bad)
07:41:02 <andythenorth> a farm ends up surrounded by concrete
07:41:23 <andythenorth> (2) farms are very low production, so the amount of cargo out is not worth the trouble
07:42:39 <planetmaker> mostly 1 - though 2 can be considered a challange, too. And 3 road stops for low output is no issue, too
07:43:55 <andythenorth> 1 is made worse because it amuses me to allow farms on very steep slopes :P
07:44:14 <andythenorth> if a player uses a flat map it won't be an issue
07:44:22 <KittenKoder> Actually, the farm system is relatively cool IMO.
07:44:30 <Muxy> gday boys & girls (if any)
07:44:31 <pjpe> this p1sim thread is the strangest but most enthralling thing i've ever read
07:44:42 <KittenKoder> Sorry, coding while trying to contribute to the discussion.
07:45:03 *** Belugas has joined #openttd
07:45:03 *** ChanServ sets mode: +o Belugas
07:45:38 <KittenKoder> But I like the complexes that FIRS makes you create, that's half the fun.
07:46:03 <planetmaker> andythenorth: that is still no issue IMHO. I never found a farm to not be within catchment area
07:46:08 <pjpe> one of his reasons for using java is he can use some random library to render 2d sprites in opengl?
07:46:12 <Muxy> does someone report trouble with the servers list on the web site ?
07:46:42 <andythenorth> at the start of the game FIRS industries are very 'flat' - all industries of type x have same production
07:46:51 <planetmaker> again broken, Muxy?
07:47:04 <KittenKoder> Java doesn't play nice with OGL, pjpe ... just an FYI.
07:47:43 <pjpe> don't look at me i'm not writing up this stuff
07:47:47 <KittenKoder> But that's mostly because Sun-Oracle can't pick a library.
07:48:19 <KittenKoder> Technically, it could work, but you have to install a bunch of secondary stuff and those are just .... *shudder* ... messy.
07:48:26 <pjpe> it's just that picking a language because a random library lets you render 2d sprites with opengl does not sound like the greatest reason
07:48:43 <KittenKoder> That's a horrible reason, I agree.
07:48:44 <Muxy> 1.1.2 servers are not displayed, and links given does not all the time display the concerned server
07:48:58 <planetmaker> well, andythenorth, there you have then with random initial production your first NML coding experience ;-)
07:49:23 <KittenKoder> I code Java primarily because everyone uses different OSes and the apps I make have to work on ... well ... almost anything with minimal effort.
07:49:59 <dihedral> KittenKoder, you code java...?
07:50:13 <KittenKoder> I like Java because of the language syntax and conventions.
07:50:22 <dihedral> you have any running projects?
07:50:28 <KittenKoder> Java is not nearly as bad as people think.
07:50:41 <KittenKoder> I have one public project that I haven't ditched out of boredom.
07:50:44 <dihedral> and at least you know what's consuming all your resources :-P
07:51:31 <KittenKoder> The chat server is actually a Python script, but the client was the show off app, someone dared me to, so I did it in 2 weeks from scratch, no extra libraries.
07:51:33 <pjpe> that site is straight out of 1997
07:51:38 <dihedral> are you interested in an openttd related java project?
07:51:45 <KittenKoder> I'm not all that creative with layouts.
07:52:04 <KittenKoder> dihedral, the problem is that I'm not that good working on teams.
07:52:31 <dihedral> so far, possibly not
07:53:00 <dihedral> + the aim is to manage everything by plugins ;-)
07:53:01 <KittenKoder> I'm a small potato coder who just happened to get a few clients that needed a cheap alternative to Seattle's megacorp teams.
07:53:32 <KittenKoder> Wow, did you find someone willing to do a plug-in architecture for Java?
07:53:48 <dihedral> KittenKoder, i am just making use of spi
07:54:07 <dihedral> have a look at the projects joan, grapes, and berries on dev.openttdcoop.org
07:54:20 <dihedral> they are maven2 projects
07:54:56 <KittenKoder> Plug-in architecture development for Java is a nightmare, really, it was not meant to include it when they created it and so Oracle has inherited a mess and no one wants to help them develop it.
07:56:12 <KittenKoder> About the most help I could be is interface development though, honestly .... multimedia code is not something I'm great at, thus why all my attempts are making games fail.
07:56:48 <dihedral> it runs in a terminal
07:57:04 <KittenKoder> Then ... not really my area of practice. ;)
07:57:11 <dihedral> joan provides the network communication with openttd
07:57:36 <dihedral> grapes creates the plugin handling and openttd related handling, the rest is done with plugins
07:58:28 <KittenKoder> I'm a GUI coder, I make fancy looking web interfaces for people to connect to their databases with pretty little displays so they can tell what's going in and coming out.
07:59:08 <KittenKoder> For hobby, I design graphics ... in 3D ... not well I might add.
07:59:48 <KittenKoder> As you can see from my website, I also tend to not bother updating unless there's a good reason.
08:00:43 <KittenKoder> Woohoo! I got the Martian designed armored transport maglev done ... comparable to the 1980's trains ....
08:02:48 <KittenKoder> But one question for anyone who knows: What is cargo_subtype in something like "switch(FEAT_TRAINS, SELF, sw_icm_te, cargo_subtype)", I can only find the information for defining it in the docs.
08:08:18 <planetmaker> it is a number or what you define it to be
08:15:54 <KittenKoder> Wait, no ... I think you misunderstood the question (likely because I suck at wording).
08:16:17 <KittenKoder> I mean, what values does cargo_subtype itself get?
08:17:23 <KittenKoder> I think I just figured it out though, it's like a specific refit value.
08:17:36 <KittenKoder> Defined by each train.
08:18:13 <KittenKoder> Okay .... why do I keep staying up so late doing this?
08:18:49 <peter1138> anyone played with drbd/pacemaker?
08:20:21 <KittenKoder> Okay, one last question ... how does the 2ccTS get those cool icons to show in the purchase list?
08:20:43 <peter1138> they're part of the vehicle
08:21:00 <Terkhen> yes, you can define the buy menu sprite separately and they just add more stuff to it besides the vehicle
08:21:18 <KittenKoder> Oooh, neat trick and easy to do.
08:22:30 <KittenKoder> So I can use theirs to?
08:22:52 <planetmaker> if you release your stuff under GPL, yes
08:23:46 <planetmaker> i.e. just respect the license
08:23:50 <KittenKoder> I may not be a conformist ... but I do like symbolic icons to look the same.
08:47:09 <KittenKoder> Okay .... how did they get the name over far enough to make room?
08:47:58 <planetmaker> leading spaces most probably
08:48:30 *** andythenorth has joined #openttd
08:48:45 <KittenKoder> Nope, not in the strings file at least.
08:50:47 <KittenKoder> Though it might be in the nfo files. >.<
08:51:06 <KittenKoder> How do you append strings to variable ones in NML?
08:52:21 <planetmaker> I've not tested it: push a string into a temporary storage: STORE_TEMP(string(blah), 256)
08:52:30 *** Brianetta has joined #openttd
08:52:39 <planetmaker> and then display a string which reads "blubber {STRING} blah bluh"
08:52:53 <planetmaker> not sure it works or whether it works in any way
08:52:57 <Terkhen> there is an example in ogfx-industries
08:53:11 <Yexo> but not everywhere, not all strings allow you to have {STRING} codes
08:53:24 <KittenKoder> Well, not talking about that case, like when defining the name of something. "Something" + VALUEFROMLNG
08:53:52 <Yexo> KittenKoder: please provide a clearer example. When would you want to do that?
08:54:01 <KittenKoder> Like in here: name: string(STR_ICM_NAME);
08:54:13 <KittenKoder> Properties block of the train.
08:54:17 <Yexo> you can't do it at all there
08:54:30 <Yexo> you'll have to define "Something ICM" as string in the language file
08:54:51 <Yexo> future work in nml might allow something like that, but that's for later
08:54:56 <KittenKoder> ;) That's what I was asking.
08:55:09 <KittenKoder> I'm just not that good at asking the right questions.
08:55:30 <planetmaker> a skill even more important than answering questions, though ;-)
08:55:34 <KittenKoder> Yeah, a concat function would be nice.
08:56:15 <Yexo> I think for the purchase list that openttd will just move your strings to the right when the image gets bigger
08:56:30 <Yexo> not completely sure, but worth a try before you start to mess with adding spaces in front
08:57:10 <planetmaker> I'd have assumed it does... alas
08:57:14 <KittenKoder> Even tried adjusting offsets, but that does nothing also.
09:00:25 <staN> i have a problem using NARoads grf in multiplayer, they simply won't get upgraded from dust to tarmac
09:00:43 <Yexo> that's expected behavior
09:01:07 <Yexo> in multiplayer GRFs can easily cause desync if they have different information on clients and on the server
09:01:29 <Yexo> as such some variables are not completely correct, when a grf ask for "current year" it gets "year the game started" instead
09:01:39 <staN> i see, so there's no workaround?
09:01:44 * andythenorth ponders playing a game that isn't YACD
09:01:59 <andythenorth> working on FIRS, but playing YACD is misleading
09:02:45 <KittenKoder> The spaces worked .... but it's a messy method. >.< Oh well.
09:02:54 <staN> so when starting mp game in say 1970 it would show tarmac both on client and server right?
09:03:00 *** Progman has joined #openttd
09:03:51 <Yexo> in singleplayer you can notice the same effect: the roads won't actually change until you save and reload the game
09:03:53 * staN ponders manipulating start date in savegame :P
09:04:45 <planetmaker> you don't need to manipulate the start date. IIRC the grf has a parameter.
09:06:26 <Yexo> try "set starting_year 1970" in the console
09:06:44 <Yexo> after that you'll have to save/reload the game to actually see the effects
09:06:51 <staN> so manipulating the parameters in save game, well i coouuld try that, but read bad things about that :)
09:07:15 <staN> Yexo: ah thanks, will try that
09:07:50 <Yexo> hmm, if that works in mp (and I think it does) I just found a new way to desync games
09:08:56 <planetmaker> aren't server-side settings communicated to clients
09:09:08 <Yexo> yes, but grfs aren't reloaded when you change a setting
09:09:28 <Yexo> so start server (load grfs), change starting year, client joins, sees new starting year and loads grfs with that value
09:09:38 <planetmaker> yeah, I just need more tea :-)
09:09:44 <Yexo> the fix is simple: don't allow to change that value in a running mp game, like similar variables
09:11:11 <planetmaker> and why doesn't xchat allow to re-order the channel list? :S
09:13:23 <KittenKoder> Ironically, I decided to make my own icons. >.<
09:17:19 <staN> another question, is there a list of some kind of all decoupled waggons in depots a company has, and in which depots they lurk?
09:17:42 <Yexo> unless it was added very recently: no
09:18:33 <staN> i had to change 'allow multiple grfs' mid-game, it told me to get rid of all vehicles in game first
09:18:45 <staN> i had to find out the hard way that waggons are vehicles too :)
09:18:58 <staN> and search every single depot for a lost waggon
09:19:26 <staN> maybe it should say all vehicles and waggons, don't know how much of a vehicle a wagon is lol
09:23:36 <Rubidium> isn't the start date a 'new game' only setting? (or SE)
09:25:01 <planetmaker> lol. There's no 'need to allow multiple vehicle grfs mid-game' ;-)
09:28:51 <staN> well when playing with ecs and nars after 1920 or 1930 suddenly default waggons started to appear, i tried starting a game with the same grfs but that mutiple thing turned off and they weren't there...so i figured i would need to turn it off in my running game...
09:29:45 <staN> after spending quite some time searching lost waggons :D
09:38:39 <staN> i think a list of all depots, like there is for stations would have helped a tad :)
09:39:37 <KittenKoder> Actually, though why you wound up doing it seems ... odd, a depot list would be a nice feature addition.
09:39:38 <planetmaker> staN, you've been using OpenTTD in a sort-of debug mode. It's not an end-user action which you performed by changing that setting on a running game
09:39:57 <planetmaker> it's not meant to be changed
09:40:31 <planetmaker> you basically changed the engine of a car while driving at 100km/h on the highway
09:41:46 <Rubidium> pff... you can reboot the engine of a spaceship when it goes at warp 5+
09:41:49 <staN> went ok :), but yeah i see your oint
09:42:13 <KittenKoder> A depot list that also tells what type it is.
09:42:25 <planetmaker> Rubidium, restart != exchange hardware ;-)
09:42:31 <KittenKoder> Though I'm past those days of mass conversion ....
09:42:35 <planetmaker> I can safely turn off my car's engine at 100km/h, too
09:43:07 <Rubidium> planetmaker: restart as in reflashing the motor management ;)
09:43:52 <KittenKoder> Pswhaw .... my dad can replace break pads going 100km/h
09:43:57 <KittenKoder> There, beat you all!
09:46:39 <Rubidium> ah well, I could do it while moving a a few hundred km/s!
09:46:42 <planetmaker> now, that'd be interesting, Rubidium :-)
09:47:08 <planetmaker> hm... what's your reference frame there?
09:47:34 <staN> earth rotation around the sun?
09:47:35 <planetmaker> 30 for Earth vs. sun
09:47:50 <planetmaker> about 20 of the sun vs. local standard of rest
09:48:06 <planetmaker> and only 200 of the sun vs. milkyway's centre
09:48:23 <Rubidium> planetmaker: local cluster of galaxies
09:48:32 <planetmaker> :-) remains about the only option
09:49:08 <Rubidium> although sun vs milkyway would work as well
09:49:24 <Rubidium> just didn't know whether I could simply sum all the speeds
09:49:37 <Rubidium> as they arguably are vectored differently
09:49:45 <planetmaker> well, one can't really... but 200 vs. 20 doesn't matter anymore ;-)
09:50:19 <Rubidium> no, but 300 + 200 or 300 - 200 makes quite a difference
09:50:54 <planetmaker> well. All those rotational motions are periodic ;-)
09:51:16 <planetmaker> thus it'll average out
09:52:45 <Rubidium> so if I time it right I can do it at roughly 500 km/s ;)
09:53:40 <peter1138> yeah, i read that MW is moving at around 580 km/s
09:54:47 <planetmaker> I always wonder whether the cosmic microwave background is not a, but the reference frame...
09:55:18 <planetmaker> it'd somewhat contradict the theorem that there's no special reference frame anywhere
09:55:45 <peter1138> and that's 0.1% of c
10:13:19 *** Biolunar has joined #openttd
10:16:06 *** sla_ro|master has joined #openttd
10:28:37 <KittenKoder> Is there something about the sprite_id that should be changed for multiple trains in a GRF?
10:30:02 <KittenKoder> The first one is showing up but the second one I added is not.
10:31:20 <planetmaker> uhm... spriteID is not an array
10:31:44 <planetmaker> and for a new train most likely should have the value SPRITEID_NEW_TRAIN or how that is called
10:32:20 <KittenKoder> Yeah, I did that, it's just SPRITE_ID_NEW_TRAIN
10:32:44 <KittenKoder> Which means I'm back to page zero. >.<
10:34:08 <planetmaker> look at the example which is shipped with nml
10:35:39 <KittenKoder> Yeah, that's how I figured it out.
10:35:54 <KittenKoder> But as I said, it's all fine but the second train I added isn't showing up in game.
10:36:01 <KittenKoder> No errors reported though.
10:36:21 <KittenKoder> So I'm at a loss and grabbing at straws for possible things I did wrong.
10:36:55 <planetmaker> good thing that you verbosely share the code with us so that we have an easy time without guessing in the dark
10:38:36 <KittenKoder> It's just a bother doing all that most times ... just this time I am going to have to.
10:41:16 <KittenKoder> I'm now thinking I screwed up on the cargo classes thing.
10:42:11 <KittenKoder> Aaah, yes, I missed part of the documentation.
10:45:30 <KittenKoder> That didn't help.
10:46:12 <planetmaker> missing an essential property often is the reason
10:46:43 <KittenKoder> They're all there though.
10:50:07 <KittenKoder> Okay, now it's working. That was really odd.
10:50:57 <Terkhen> when something really strange is happening, I usually forgot to copy the grf to ~/.openttd :P
10:51:42 <KittenKoder> It may have copied wrong .... I just don't know. >.<
10:53:19 <KittenKoder> Erm ... messed up the tractive effort massively. >.<
11:17:07 <KittenKoder> Okay, two trains done ....
11:17:37 <KittenKoder> I think I have the hang of this finally.
11:18:02 <KittenKoder> Now time to practice the hard part.
11:19:04 *** Hirundo_ has joined #openttd
11:19:24 *** SmatZ is now known as Guest6374
11:19:25 *** ChanServ sets mode: +o SmatZ
11:19:34 *** ^ekipS^ has joined #openttd
11:19:38 <KittenKoder> Figured out the coding for multi-units and basic engines, worked out a decent sprite template system, and a very simple Makefile ....
11:19:58 *** |Terkhen| has joined #openttd
11:20:16 *** Ammller has joined #openttd
11:20:58 *** V4530000 has joined #openttd
11:21:13 *** V4530000 is now known as V453000
11:21:13 *** Hirundo_ is now known as Hirundo
11:21:28 *** XeryusTC has joined #openttd
11:21:48 *** Ammller is now known as Ammler
11:22:18 *** pm is now known as planetmaker
11:22:18 *** ^ekipS^ is now known as ^Spike^
11:22:28 *** |Terkhen| is now known as Terkhen
11:22:29 *** DJNekkid has joined #openttd
11:22:43 <LordAro> why is openttdcoop.org so unreliable? :3
11:37:55 <planetmaker> sorry, LordAro.... our hypervisor has some issues...
12:10:58 *** XeryusTC has joined #openttd
12:18:31 <Ammler> LordAro: not everyone likes how I abuse it to play around :-)
12:19:48 <Ammler> anyway, please tell your issue with it, just watching parts/joins doesn't help
12:24:33 <planetmaker> thanks, Eddi|zuHause
12:32:37 <LordAro> Ammler: my issue with it is the part/joins ;)
12:33:11 <planetmaker> LordAro, the VM running the bouncer of course also goes down when the hypervisor reboots...
12:33:57 <LordAro> how do you get a openttdcoop.org 'address' anyway? i've always wondered that... :)
12:35:39 <Eddi|zuHause> you make a charitable donation :p
12:36:21 <Ammler> yes, if you buy something there, I might be responsible to keep it up
12:36:29 <Ammler> now everything is free and I don't :-P
12:36:49 <planetmaker> it's meant for the members of #openttdcoop and I'd say for regular DevZone users
12:37:21 <Ammler> for users with even more unreliable connections as we have :-P
12:41:38 <LordAro> (if i understood whatever you were talking about :P )
12:43:48 <LordAro> hmmm... how to convert a 'const char*&' to 'const char*' ?
12:44:35 <Yexo> that's really all we can say without you providing more context
12:45:44 *** sla_ro|master has joined #openttd
13:09:14 *** andythenorth has joined #openttd
13:15:58 *** douknoukem has joined #openttd
13:34:38 *** Prof_Frink has joined #openttd
13:37:20 <LordAro> make that a 'char* const&' -> 'const char*' -- the char* const& is 'part' of a char array (char *readme_text_lines[MAX_README_LINES];)
13:40:45 *** Adambean has joined #openttd
13:42:47 *** HerzogDeXtEr has joined #openttd
13:45:06 <LordAro> its not... "the char* const& is 'part' of a char array" and "(char *readme_text_lines[MAX_README_LINES]; )" are separate
13:57:32 <Rubidium> context oh padawan ;)
13:58:24 <Rubidium> the actual code that triggers the error +- at least 3 lines
13:58:38 <Rubidium> and everything that it references
14:08:31 <Eddi|zuHause> what he means is: SHOW US THE WHOLE DAMN PATCH, MAN!
14:13:36 *** TWerkhoven has joined #openttd
14:31:45 <Belugas> naaa... don't show us, we all do uderstand it's top secret stuff ;)
15:28:34 *** sla_ro|master has joined #openttd
15:35:46 *** |Jeroen| has joined #openttd
16:13:08 *** supermop_ has joined #openttd
16:17:32 <aditsu> hi, what can I do against a player who is stealing my resources?
16:18:11 <glx> you are just transporting it
16:18:55 <aditsu> so he can just come when I grew the production to maximum, and take half of it or so, making my trains lose money?
16:19:24 <planetmaker> you can provide better service, though
16:19:25 <aditsu> that doesn't seem fair to me
16:19:34 <planetmaker> what's unfair there?
16:19:49 <planetmaker> it's not your industry
16:20:14 <planetmaker> you could of course play on a server where the server rules state that such "stealing" is not allowed
16:20:24 <aditsu> well, I take a coal mine and carefully bring it from 40 to 2295 production over a long time, then he just comes and takes the profit and damages my business
16:20:27 <planetmaker> and where there are actually admins around to enforce that
16:20:33 <glx> if you have 2 stations for this industry with good service he won't get anything
16:21:29 <aditsu> hm.. so I should make another station?
16:21:36 <aditsu> and have better service?
16:22:00 <planetmaker> yes. And build a statue, if you haven't
16:22:15 <aditsu> I have statues, he doesn't :)
16:22:27 <planetmaker> then he can't get half of your cargo
16:22:38 <planetmaker> it's split according to "service level"
16:23:13 <Yexo> aditsu: if you really don't like any competition play on another server that A) has an active admin and B) doesn't allow competing for cargo
16:23:49 <aditsu> I didn't know it was generally allowed
16:23:59 <Eddi|zuHause> why wouldn't it be?
16:24:22 <Yexo> generally there are no rules at all
16:24:42 <Yexo> of course there are some guidelines that most people adhere to, but even that can only be enforced when there is an active admin around
16:25:06 <supermop_> gah ring cycle is so expensive
16:25:56 <Eddi|zuHause> a flat cycle would be awkward
16:26:31 <supermop_> the worst seats are $400
16:26:45 <supermop_> thats for the whole cycle, but still
16:29:10 <aditsu> hm.. my 2nd station doesn't seem to get anything
16:29:22 <aditsu> or is it too late to make it?
16:29:58 <Eddi|zuHause> only the two stations with the highest rating get anything, all others get nothing
16:31:40 <glx> LordAro: what's the exact message ?
16:31:54 <aditsu> Eddi|zuHause: so if there are already 2 stations, and I make another one, how can I get its rating up?
16:32:11 <Eddi|zuHause> aditsu: you can't
16:32:23 <aditsu> ok so it's too late then
16:32:26 <Eddi|zuHause> (or by transferring cargo to it)
16:34:20 <glx> LordAro: *this->readme_text_lines[this->num_lines] = *src; <-- that's wrong
16:35:14 <glx> hmm no it's just weird :)
16:35:15 <aditsu> oh wait, it transported something
16:35:33 <LordAro> glx: so it is, that's just 1 character, is it not?
16:36:47 <glx> hmm I don't see where you allocate space for the array
16:38:20 <LordAro> no, i do for readme_text though, but i guess that's not enough :)
16:39:39 <glx> anyway you could just do this->readme_text_lines[this->num_lines] = src; on newline, and replace \n and \r with \0
16:40:41 <glx> btw free(this->readme_text_lines) with no malloc is a bad idea too :)
16:44:02 <glx> especially for char *readme_text_lines[MAX_README_LINES];
16:47:54 *** andythenorth has joined #openttd
16:48:57 <aditsu> oh cool, now I have 2 stations with better rating :)
17:07:38 <KittenKoder> How dare you help them, glx!
17:08:42 <aditsu> I have another question.. there's a button to get the last message/news report, but it doesn't seem to use the message settings, it just shows the last unfiltered message, is there a way to just show the last message that was displayed to me?
17:09:24 <KittenKoder> You can display a list of all the last messages.
17:10:13 <KittenKoder> Use Message History, it doesn't actually show the messages, it just shows a list of their titles.
17:10:14 <aditsu> oh yeah, but on a large map, it's pretty hard to find what I want among all the industry reports
17:10:40 <LordAro> glx: i know, i'm not sure how to free char arrays :)
17:10:41 <aditsu> the list is not filetered either
17:10:45 <KittenKoder> Currently that's the only option.
17:10:59 <planetmaker> aditsu: I fear the answer is "we eagerly await your patch" as it has not yet a meaningful filter
17:11:30 <aditsu> planetmaker: I'm talking about filtering based on the message settings
17:11:47 <KittenKoder> We eagerly await your patch.
17:12:00 <planetmaker> aditsu: that doesn't change my answer ;-)
17:12:19 <planetmaker> the message settings define what is displayed where. But should not kill other messages in the overall history
17:12:39 <planetmaker> but the view of the overall history could get a filter like "only this" "only that" "according to news filter"
17:12:53 <aditsu> don't be TOO eager or you might get disappointed ;)
17:14:04 <aditsu> but if I happen to find some time, I might look at the code
17:15:03 <KittenKoder> I think a lot of players like it as it is enough to not be that eager.
17:15:52 <KittenKoder> But a lot of low demand options added to a product can often become high demand after the patch.
17:16:34 <planetmaker> aditsu: I don't expect anything. But sometimes it helps to give ideas on what / how a patch would (from my POV) fit the game
17:16:57 <planetmaker> there are unfortunately(?) orders of magnitude more ideas than time devoted to developing ;-)
17:19:11 <KittenKoder> Real life can slow the progress of open source.
17:19:53 *** Alberth has joined #openttd
17:19:53 *** ChanServ sets mode: +o Alberth
17:26:07 <aditsu> heh that guy started buying exclusive rights
17:27:10 * Alberth didn't buy such rights at all
17:28:20 <Alberth> Terkhen thus also did not buy them :)
17:38:37 <Zuu> When adding a new file, shall the $Id and @file comments be created or are they created by the version control system?
17:39:42 <Zuu> Including all information that is available in other files?
17:40:26 <Zuu> Though, I don't know who will commit the patch etc. :-)
17:42:06 <Terkhen> IIRC those are filled automatically, but I don't know the details
17:42:30 *** beijingguy has joined #openttd
17:42:59 <Zuu> I'll just leave them as is for now and let that be delt with later on.
17:43:21 <Zuu> Although, I do edit the file comment.
17:44:01 <Alberth> Zuu: the @file is static, the $Id$ will be expanded automagically
17:44:56 <Zuu> Alberth: So I should just have a comment: /* $Id$ */ at the top and the vcs will expand that?
17:45:27 <CIA-2> OpenTTD: translators * r22759 /trunk/src/lang/ (dutch.txt swedish.txt unfinished/persian.txt):
17:45:27 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:27 <CIA-2> OpenTTD: dutch - 2 changes by Bennievv
17:45:27 <CIA-2> OpenTTD: persian - 224 changes by Peymanpn
17:45:27 <CIA-2> OpenTTD: swedish - 13 changes by Zuu
17:45:31 <Alberth> subversion will, if you set 'svn:keywords' to 'Id'
17:46:03 *** frosch123 has joined #openttd
17:53:11 *** supermop_ has joined #openttd
17:55:51 <Ammler> on hg, this is not needed
17:56:07 <Ammler> but there is a extension keysomething
17:58:45 *** valhallasw has joined #openttd
17:59:13 <Rubidium> Ammler: so you need to install something extra, instead of enabling something
17:59:25 <Rubidium> Ammler: and how can you tell it to not do it?
17:59:39 <Alberth> Could be. I used $Id$ extensively in the past, but nowadays I don't care much for it
17:59:49 <Ammler> Rubidium: because you do not need it, it is just a 3rd party extension
18:00:20 <Rubidium> Ammler: say I want it on some files, but don't want it to happen on some other files in the same repository
18:00:39 <Rubidium> e.g. because they contain a $Id$ style token that must not be changed
18:01:01 <Ammler> Rubidium: well, first you should explain why you should need it on hg :-)
18:01:19 <Ammler> what is it useful for?
18:01:39 <Alberth> Ammler: I don't want my .png file with $Id$ expanded
18:02:00 <Ammler> Alberth: I meant, why do you want does key substitions at all?
18:02:24 <Rubidium> Ammler: because if you then make a tarball you get the version in the files, so based on a source tarball you can determine the used version
18:03:06 <Ammler> yep, that is for svn, why do you need it for hg?
18:03:08 *** douknoukem has joined #openttd
18:03:22 <Rubidium> e.g. to figure out the version of some OpenTTD tarball, like the 1.0.0 made by someone else
18:03:31 <Ammler> that is the whole reason, hg does not care about
18:04:10 <Alberth> Ammler: how is the vcs of relevance for determining the revision of a file?
18:04:23 <Ammler> Alberth: on hg, you can simply run hg log <file>
18:04:56 <Ammler> well, you don't use a tarball to work with
18:04:56 <Alberth> in an environment without a hg clone nearby?
18:05:02 *** st-15308 has joined #openttd
18:05:14 <Alberth> that's why you want it in the file itself
18:05:36 <Ammler> as said, for those guys insist on it, can use the extension
18:06:47 <Rubidium> Ammler: if I get the files from nml and dump them in a git repository. How can you tell me the version. Imagine for this instance that I tag it 1.0.0
18:07:37 <Ammler> Rubidium: again, you don not use the tarball
18:07:38 <Rubidium> in this case I'll actually be using the source files of r1625
18:07:49 <Ammler> you convert the hg repo
18:07:58 <Rubidium> Ammler: I don't, you don't... other morons will
18:08:09 <Ammler> and you care about those?
18:08:13 <Eddi|zuHause> andythenorth: what's the meaning of the strike-through?
18:08:29 <andythenorth> silly formatting :(
18:09:11 <Rubidium> Ammler: yes, I do when they start claiming that their 1.0.0 build from a particular source tarball fails. It's pretty useful to be able to tell it's the source of some trunk nightly from half a year before 1.0.0
18:09:32 <andythenorth> Eddi|zuHause: this solution uses a stockpile but hides it from the player for various reasons
18:09:47 <andythenorth> it's much discussed in the 'other' channel :P
18:09:51 <Rubidium> but then I guess you have not had the pleasure of people mutilating your work and shipping it as their own
18:10:07 <Ammler> Rubidium: but that is svn, where you have it
18:12:47 <Rubidium> LordAro: I applied the diff and the error I get isn't quite what you were talking about
18:13:55 <Rubidium> the important bit there being: "no known conversion for argument 6 from TextDirection to StringAlignment"
18:15:47 <Rubidium> LordAro: easiest solution: remove the last two parameters. They have default values which are fine in your case
18:20:12 <LordAro> Rubidium: i can't have been reading the error messages carefully :) fixed
18:20:42 <LordAro> oh, and how would i get rid of the 'NULL in arithmatic' warning?
18:21:01 <Rubidium> you are comparing a character to NULL
18:21:08 <Rubidium> you want to compare it to '\0'
18:24:58 <LordAro> compling... segfault (or similar hear i come! :)
18:25:15 <LordAro> *(or similar) here :3
18:25:33 <Alberth> you crash the compiler? :p
18:26:58 <Alberth> hard at work, I see :)
18:27:32 <LordAro> yeah... i got a bit bored with minecraft multiplayer :)
18:28:15 <LordAro> "Segmentation fault (11)" <-- told you!
18:33:24 <KittenKoder> My eyez! Zee gogglez ... zey do nuthzing!
18:33:55 <KittenKoder> J/K .... I didn't actually look. :p
18:36:20 <Eddi|zuHause> LordAro: err... wtf? "*src"?
18:36:37 <Yexo> LordAro: you're never allocating space for readme_text_line
18:37:22 <Eddi|zuHause> LordAro: always do explicit comparisons in these things
18:38:36 <Alberth> LordAro: readme_text_lines is part of the Window struct, you should not free such data
18:38:37 <Eddi|zuHause> LordAro: so, below "this->readme_text = MallocT<char>(filesize + 1);" you should probably do the same thing with readme_text_lines
18:39:05 <Yexo> it makes more sense to let readme_text_lines point to lines within this->readme_text
18:39:07 <Alberth> Eddi|zuHause: no, in the window struct is fine, it needs conversion to a smallvector later
18:39:09 <Yexo> no need to allocate more data
18:39:23 <Alberth> Yexo: that was the idea
18:39:34 *** Kurimus has joined #openttd
18:39:54 <Yexo> that does require editing the this->readme-text arrow in-place to remove unprintable characters, and not while copying it (currently to random memory)
18:40:00 <LordAro> Alberth: then i've got completely confussled :L
18:40:18 <Eddi|zuHause> "GetReadmeChar" is probably misnamed ;)
18:40:22 <Alberth> LordAro: where do you initialize readme_text_lines such that line182 becomes true?
18:40:51 <Yexo> it is, but GrfHasReadme is too
18:40:54 <Yexo> from that name I'd expect a bool as return value
18:41:31 <LordAro> Alberth: is shouldn't, more of an assert really
18:41:46 <Eddi|zuHause> what i would do is just loop through readme_text, replace all \n with \0 and record their locations as beginning of next line...
18:42:09 <Alberth> LordAro: when the functionality of a function changes, the name should change accordingly
18:42:21 <Alberth> Eddi|zuHause: you got the idea :)
18:42:48 <Alberth> Eddi|zuHause: although it should also strip non-printable characters in the same sweep
18:42:56 <Alberth> but combining can be done later
18:43:43 <Eddi|zuHause> so readme_text_lines[0] = readme_text, for (char blah) { if (blah = '\n') { blah = '\0'; readme_text_lines[index++] = blah+1;}
18:46:48 <Eddi|zuHause> LordAro: doing *src++ within the loop is probably evil
18:48:02 <Alberth> KittenKoder: be gentle, it's his first program
18:48:24 <KittenKoder> Consider my comment as a lesson then. :p
18:48:42 <KittenKoder> hard to type more than that though when I was nomming my burger.
18:52:02 <KittenKoder> c++ .... you could make use of the default string library.
18:53:31 <KittenKoder> Arrays are a challenge for beginners, in c/c++
18:54:01 <Alberth> but it also has to fit openttd style somewhat
18:54:25 <KittenKoder> You mean OTTD uses c++ but no c libs?
18:55:15 <Alberth> it started in assembly, was decoded to C, and now c++ gets introduced where useful
18:55:28 <KittenKoder> Aaah, the slow migration.
18:55:35 <Alberth> so there is still a lot of C-ish code
18:56:07 <KittenKoder> >.< Are there still macros?
18:56:19 <Alberth> especially at the critical path it is highly optimized
18:56:31 <Alberth> oh sure, lots of #define s :)
18:56:40 <planetmaker> lots and lengthy :-)
18:56:48 <KittenKoder> #define is used for more than just macros. :p
18:56:55 <Alberth> but not for constants any more, mostly
18:56:57 <Terkhen> you don't like macros? you shouldn't look at pnml projects then :P
18:57:03 <KittenKoder> Though technically, they are macros I guess.
18:57:39 <KittenKoder> Terkhen, I don't like macros, mostly because of the syntax for them, also because it's being phased out of even c now.
18:57:55 <KittenKoder> Templating is the new macro. :p
18:58:17 * Alberth keeps his m4 program well hidden
18:59:08 <KittenKoder> They just haven't gotten c or c++ templates able to completely replace macros, so they will likely stick around. However, I have written a LOT of programs (utility apps) that have never needed one macro. :p
18:59:30 <KittenKoder> So it is possible to avoid, just takes a LOT of adjusment.
18:59:45 <KittenKoder> But meh, I'm rambling.
18:59:59 <Alberth> using them sanely is the key, just like gotos :)
19:00:26 <KittenKoder> ... and for a beginner, his code is actually clean.
19:01:29 * andythenorth has discovered some....issues with rivers
19:01:30 <KittenKoder> It's readable and CamelCase is used well.
19:01:59 <Alberth> lots of copy/paste, and some gentle pushes from me :) but code style is by himself though
19:02:11 <KittenKoder> Though, there's a few old school syntax in there.
19:02:48 <KittenKoder> Then he's got a good mentor-ish.
19:03:41 <KittenKoder> I think most of the old school naming convention is from the copy-pasta though.
19:04:26 <KittenKoder> However a lot of new c coders these days (the leet ones) are vehemently defending it. >.<
19:04:39 <Yexo> well, while LordAro is some ways is new, he's been writing squirrel code for at least 2 years now, so he's not exactly completely new anymore
19:04:42 <KittenKoder> Buffering next Futurama.
19:05:02 <KittenKoder> That's the language I was going to look up.
19:05:54 <KittenKoder> Okay, I like it already.
19:06:11 <KittenKoder> "squirrel's syntax is similar to C/C++/Java etc... but the language has a very dynamic nature like python/Lua etc... " <- pure epic win
19:06:28 <Alberth> it's a quite nice scripting language
19:06:33 <Yexo> the implementation of the language is not so nice
19:07:02 <KittenKoder> It's amazing that there are entire games coded in scripting languages now. LOL CPUs are uber now.
19:07:18 <KittenKoder> It's Euphoria ....
19:07:27 <KittenKoder> A cross-platform Euphoria ...
19:07:46 <KittenKoder> "local array=[ 1, 2, 3, { a = 10, b = "string" } ];" <- Euphoria array.
19:09:03 <KittenKoder> The difference is the syntax varies, but otherwise, the more I look at it, it's what Euphoria was suppose to become, at least what the author promised it was going to be but never got there.
19:09:51 <KittenKoder> Bookmarked for later reference, now ... what was it that was coded with it that I had heard of?
19:10:38 <Yexo> squirrel? OpenTTD uses it for AIs
19:11:25 <KittenKoder> I was pondering taking a try at making an AI for OTTD at some point.
19:11:50 <KittenKoder> First I want to get a handle on this NML stuff, to me it's completely new.
19:17:36 <Alberth> Euphoria feels a bit like lua to me, although I have not much experience in lua
19:18:15 <Alberth> (and none in Euphoria :) )
19:18:30 <KittenKoder> It was awesome back when it was young, but then it just .... stopped going anywhere.
19:20:08 <KittenKoder> Especially because it was only Windows.
19:20:33 <KittenKoder> Well, that wasn't why, it was because it was made specifically to work with Windows.
19:22:50 <andythenorth> so this rivers grf currently doesn't support snow transition
19:23:03 <andythenorth> and I don't fancy drawing support for transition
19:23:30 <andythenorth> and unrelated, my palette is bork-bork, but I'll figure that out :P
19:23:36 <Ammler> not really necessary for this tiny bit of shore, is it?
19:23:53 <Rubidium> andythenorth: I don't think that missing transition will be a huge issue ;)
19:24:08 * Alberth tries to apply LordAro s patch, and fails
19:24:18 <Rubidium> maybe (much) later, when the rivers are flowing it's something to look back at
19:24:26 <andythenorth> I really don't want to draw it :)
19:24:29 <Ammler> Alberth: from paste service?
19:24:56 <KittenKoder> What does the rivers GRF do?
19:24:58 <Ammler> use hg import instead patch
19:25:02 <Alberth> after clicking 'raw' and 'download' yes
19:25:07 <Rubidium> andythenorth: it's not as noticable as the rail tracks ;)
19:25:51 <Ammler> afaik, the paste service does cut the empty end lines
19:26:53 *** JVassie has joined #openttd
19:27:03 <andythenorth> do rivers freeze up above snowline?
19:27:19 <Rubidium> andythenorth: they don't
19:27:21 <planetmaker> hardly, andythenorth
19:27:33 <Rubidium> maybe the edges a bit ;)
19:27:34 <planetmaker> or siberia wouldn't have rivers ;-)
19:27:55 <planetmaker> and boats running on ice would look very funky
19:28:39 <andythenorth> vehicle-aware routes!
19:28:45 <andythenorth> snow, sand, foliage
19:29:27 <Ammler> LordAro: you should git diff format (might not be the issue, Alberth has)
19:30:18 <Alberth> interestingly, 'patch' broke on trunk, but 'hg import' did not.
19:30:42 <Prof_Frink> Feature request: Glaciers
19:31:15 <Prof_Frink> (New disaster: Train falls down crevasse)
19:50:09 <glx> <Yexo> the implementation of the language is not so nice <-- yeah squirrel source is horrible
19:51:41 *** beijingguy has left #openttd
19:55:30 * Zuu digs into the issue of why airport types are reported as available while they clearly shouldn't be that.
19:55:57 <Zuu> Apart from that I think I have a workable implementation of AIAirportTypeList :-)
19:58:36 <Zuu> Oh well, the AIAIrportTypeList works fine, just that it will give eg. airport type 40 which internally in OpenTTD has "IsAvailable()" reporting true which is clearly not correct.
20:02:41 <Zuu> I guess the GUI just don't display those airports.
20:04:02 <Zuu> The DoCommand-thing have some extra checks apart from IsAvailable(), so hopefully you can't cause trouble by passing an undefined airport to a server. :-)
20:04:09 <LordAro> Alberth: so what do i need to do to the patch that i'm not understanding?
20:05:10 <Alberth> Eddi|zuHause had several good lines
20:06:03 *** Brianetta has joined #openttd
20:08:23 <Alberth> LordAro: you should initialize every piece of data before use, in this case, readme_text_lines in particular
20:08:50 <Alberth> and since you don't malloc that data, you should also not free it
20:09:56 <Zuu> Soo boring... building airport type 40 does not do anything more than building a small airport :-p
20:10:00 <Alberth> DrawString at line 184 expects a line without \n and ending in \0
20:10:22 <Alberth> Zuu: some safe fallback ?
20:11:05 <Zuu> It could also be that the dumy airport is a small airport.
20:11:52 <Alberth> line 232 is simply wrong, you should not copy characters using the readme_text_lines pointers
20:11:54 <Zuu> Or that the NewGRF airport type IDs are small airports by default if they are not overriden.
20:12:21 <Alberth> the former sounds more likely
20:12:47 <LordAro> Alberth: ok, but how would i malloc readme_text_lines? i surely can't do "this->readme_text_lines = MallocT<char>(filesize + 1);" ?
20:13:13 <Alberth> LordAro: don't malloc it, it is fine as-is
20:13:24 <Zuu> There is a specific concept of "overriding" an airport. That concept is not what I was refering to, which is why I substituted "overriden" to "changed".
20:13:26 <Yexo> the dummy airport is not the small airport
20:14:02 <LordAro> Alberth: wait, what? i thought i had to malloc it
20:14:16 <LordAro> oh no, wait. to free it i have to malloc it, which isn't necessary :)
20:14:27 <Zuu> As far as I can see the spec-array (which goes up to 127) is zeroed with memset and then the specs for type 0 to 9 is set used data in OpenTTD.
20:14:30 <Alberth> LordAro: no, I said that you should not free things you don't malloc
20:14:41 <Zuu> After that I the NewGRF stuff kicks in.
20:15:09 <LordAro> Alberth: that line has been deleted :3
20:15:18 <Yexo> Zuu: and the memset should make sure "enabled" is false
20:15:30 <Yexo> which is the first thing AirportSpec::IsAvailable checks
20:16:20 <LordAro> [20:04:38] <Yexo> well, while LordAro is some ways is new, he's been writing squirrel code for at least 2 years now, so he's not exactly completely new anymore <-- yes :) but with squirrel you don't have to bother about silly things like pointers or type changes :)
20:16:20 <Zuu> Yet IsAvailable() returns true for type 19 to 127 in my tests (with latest OpenGFX+ Airports loaded)
20:16:36 <Zuu> I've had similar issues without that NewGRF loaded.
20:16:55 <Yexo> if that's true there is a serious bug somewhere
20:17:04 <Zuu> Somehow that NewGRF have made type 11-18 non-available.
20:17:06 <Alberth> The trick is that readme_text_lines points to data in readme_text (the first character of each line, in fact)
20:17:27 <LordAro> but i'm still not sure how to do that :/
20:17:33 <Zuu> Yexo: That's the bug I'm trying to find. :-)
20:18:01 <Yexo> Zuu: that sounds the wrong way around
20:18:11 <Yexo> loading OpenGFX+Airports should make types 11-18 valid
20:18:14 <Alberth> LordAro: do you understand what readme_text_lines[0] should contain ?
20:18:43 <Zuu> AFAIK OpenGfx+Airports only provide one airport yet which is available as id 10.
20:18:57 <Zuu> That one is reported as buildable.
20:19:08 <LordAro> Alberth: i'm not so sure...
20:19:14 <Zuu> In 1950 the following are buildable: 0, 10 and 19 to 127.
20:19:33 <Zuu> 10 is a 180 degree rotated small airport.
20:19:53 <Yexo> Zuu: IIRC it provides snowy versions of all airports
20:20:08 <Yexo> which version do you have?
20:20:26 <Alberth> LordAro: suppose I have text "abc\ndef\0" what should be in readme_text_lines[0] ? (and [1] ?)
20:20:31 <Yexo> a rotation does not imply a separate id
20:20:44 <Yexo> so id 10 should be the overriden small airport (both normal rotation and the rotated version)
20:21:20 <Zuu> Oh, yes 10 is both rotations.
20:21:25 <Yexo> also id 0 is the default small airport, as soon as it gets overriden by a newgrf id 0 should be disabled
20:21:28 *** Phoenix_the_II has quit IRC
20:22:43 <Zuu> Hmm, the compatibility layer will need to have access to some function that can translate 0 to 10.
20:23:26 <Yexo> Zuu: AirportSpec::Get(0)->GetIndex() will return 10
20:23:34 <Yexo> Alberth: that's the grf-local id
20:23:50 <Yexo> it mapped to the first free id openttd has, which happens to be 10
20:24:08 <Alberth> ah, forgot about that one
20:24:08 <Yexo> you can have multiple newgrfs using id 0 locally and they won't conflict
20:24:15 <Zuu> Yep, and that will have to be available to the compat nut files. Preferable without making it available to API 1.2?
20:24:39 <Yexo> why does squirrel need it?
20:24:54 <Zuu> Because old AIs will still rely on 0 being the small airport.
20:24:55 <Yexo> can't you access all properties of id 10 through id 0?
20:25:10 <LordAro> Alberth: 0 = 'abc\0' and 1 = 'def\0', i guess, but i don't know how to get the right characters into the right chars
20:25:12 <Zuu> Not if you make 0 unavailable.
20:25:41 <Zuu> hmm, though maybe a twist can be made where information is available for 0, but it is not buildable.
20:25:46 <Alberth> LordAro: correct, except "abc\ndef\0" is not moved.
20:25:55 <Yexo> LordAro: try to find some general explanation about pointers
20:26:16 <Zuu> Since that distinction of airport types already exist although the naming of IsValidAirport really should be IsAirportBuildable.
20:26:38 <Yexo> Zuu: make IsAirportInformationAvailable return true but IsValidAirportType return false?
20:27:07 <Yexo> hmm, that's not exactly how IsAirportInformationAvailable behaves now
20:27:40 <LordAro> Alberth: so the string becomes 'abc\0def\0' ?
20:28:01 <Zuu> hmm, no that will not do it.
20:28:06 <Yexo> Zuu: main question: do we actually want to convert the 0 to 10 transparently?
20:28:25 <Yexo> since id 10 might be an override of the small airport that only provides a 90 degree rotation but not the original rotation
20:28:45 <Yexo> that will throw old AIs that make assumptions about the airports off as well
20:28:47 <Zuu> For compat 0.7 to 1.1 we must translate 0 to 10 transparently or all existing aircraft AIs will break.
20:28:48 <Alberth> LordAro: thus if readme_text = "abc\ndef\0", your code needs to do the equivalent of readme_text_lines[0] = readme_text + 0; readme_text[3] = '\0'; readme_text_lines[1] = readme_text + 4;
20:29:04 <Yexo> existing aircraft AIs will only break when an airport newgrf is loaded
20:29:14 <Yexo> and we can't prevent breaking them in all situations
20:29:22 <Alberth> LordAro: and then indeed readme_text is "abc\0def\0"
20:29:27 <Yexo> you can write a very small newgrf that does nothing but disable the original airports
20:29:56 <Zuu> So you are right, the best is probably to make overriden airports simply unavailable and not provide any translation.
20:29:59 <LordAro> Alberth: that helps enormously... i think :L
20:30:38 <LordAro> now, how to 'automate' the '+0' and '+4'...
20:31:06 <Alberth> it is the index in readme_text at the start of the array, or directly after a \n
20:31:19 <Yexo> Zuu: care to share your patch so I could test the problem with the incorrect IDs being valid?
20:34:03 <andythenorth> palette issues are really boring :P
20:34:59 <Alberth> load in gimp, load new palette?
20:36:03 <Zuu> It requires the patch that I will send you just in a moment.
20:40:55 <Yexo> Zuu: that AI will keep busy-looping without any sleep as soon as the signlist is empty
20:41:05 <Yexo> the //Keep alive lines are never reached
20:43:33 <Zuu> Yexo: You are right, the keep alive is there as a base from another test AI.
20:43:54 <Zuu> As well as the valuator function that is not used.
20:44:34 <CIA-2> OpenTTD: alberth * r22760 /trunk/src/newgrf.cpp: -Fix (r19459): Also free allocated depot tables.
20:45:57 <Zuu> That test AI is ment as a workbench for testing my work on the airport API.
20:46:56 <Yexo> it's not a big problem or anything, just wanted to mention that your AIController.Sleep(1) is inside the inner loop while it should be outside
20:47:17 <Yexo> every call to BUildAirport will make the AI sleep for the rest of the tick already
20:50:30 <Zuu> You are right. Especially as it now slows down a debug build of OpenTTD when there are no signs.
20:54:12 <Yexo> Zuu: IsAirportInformationAvailable contains a bug
20:54:20 <CIA-2> OpenTTD: planetmaker * r22761 /trunk/src/viewport.cpp: -Fix (r22708): Make invisible signs un-clickable (Zuu)
20:54:48 <Yexo> AirportSpec::Get(index) first checks if index is a valid airport, if not it assumes it was valid before and it will return the substitute type as previously indicated by the newgrf
20:54:53 <Yexo> which due to the memset is 0
20:55:03 <Yexo> hence it'll return the AirportSpec* of the small airport, which is enabled
20:55:15 <Yexo> so AirportSpec::Get(type)->enabled will be true even for invalid types
20:55:34 *** beijingguy has joined #openttd
20:59:11 <Zuu> planetmaker: thanks for commiting :-)
21:03:42 <frosch123> Yexo: have you seen fs#4702?
21:04:40 <Yexo> yes, your patch looks good, although I'd change the wording somewhat
21:05:02 <Yexo> something like: "If a station sign would be on this tile, the servicing quality of the station would influence the rating of the town"
21:05:35 <Yexo> since your new sentence has the same problem as the original one, it's unclear that it's only about the station sign, not whether the tile is part of a bigger station
21:06:15 <Zuu> Hmm, what if AirportSpec::Get(index) would only return the substitute airport if the type that index refer to is enabled? Otherwise 0 (null).
21:06:45 <Yexo> but if the type the index refers to is enabled there is no reason at all to return the substitute airport
21:06:49 <frosch123> Yexo: btw. do you have an idea why ai_company.hpp.sq gets updated?
21:07:07 <frosch123> the functions are reordered and there is a template more
21:08:23 <frosch123> the reordering actually matched the hpp, so that is fine
21:08:34 <frosch123> but the additional templates confuse me :p
21:08:51 <Zuu> Yexo: I see now, that propose would likely disable the override NewGRF feature.
21:09:00 <Yexo> probably the last person to update the hpp file didn't update the .hpp.sq correctly
21:09:18 <frosch123> ah, they are added because of the additional enum
21:10:55 <Yexo> my guess: I took the patch from Morloth for r22584 including the changes to .hpp.sq file which he probably made manually
21:14:26 <Zuu> I guess the most clean solution to the AI airport issue is to set more sane defaluts to the >= 10 airport specs than just all-zero.
21:14:33 <Yexo> Zuu: a fix requires thinking about what OpenTTD should do when an airport newgrf is unavailable, and I'm currently not able to think clearly enough for that :p
21:14:53 <CIA-2> OpenTTD: frosch * r22762 /trunk/src/ai/api/ai_company.hpp.sq: -Fix (r22584): Update ai_company.hpp.sq
21:17:35 <Zuu> I think for airports >= 10, that has not been defined by an NewGRF should not be available. I now think that setting substitute ID to AT_INVALID would be good.
21:18:33 <CIA-2> OpenTTD: frosch * r22763 /trunk/src/ai/api/ (ai_station.hpp ai_tile.hpp ai_town.hpp): -Fix [FS#4702]: Clarify the meaning of AIStation::IsWithinTownInfluence(), AITile::IsWithinTownInfluence() and AITown::IsWithinTownInfluence().
21:19:11 <CIA-2> OpenTTD: frosch * r22764 /trunk/src/ai/api/ (ai_changelog.hpp ai_tile.cpp ai_tile.hpp ai_tile.hpp.sq): -Add: [NoAI] AITile::GetTownAuthority().
21:19:14 <Zuu> Yexo: That looks good. I haven't worked enough with the internals with respect of NewGRFs yet, but your code makes sense.
21:19:46 <Yexo> that seems to work when no newgrfs are loaded
21:20:28 <Yexo> with opengfx+airports loaded both 0 and 10 are reported as buildable, which is not correct
21:20:38 <Zuu> I read your code after the || as: when a airport type does not refer to a NewGRF
21:21:12 <Yexo> it's basically that: when this type has ever been defined by a newgrf (doesn't matter whether it has valid data now or not)
21:21:38 <Zuu> Leaving it up to the NewGRF to provide sane data.
21:22:19 <Zuu> After all there is lots of room for NewGRFs to provide insane data ;-)
21:22:54 <Yexo> the idea was good, but the code wasn't
21:23:02 <Yexo> it worked, but not in all cases
21:23:11 <Yexo> still this is more a quickfix than a good solution
21:23:19 <Yexo> need to think more about AirportSpec::Get()
21:23:35 <Zuu> Still, I'm interested why type 11 to 18 are reported as non-available but not those 19 and above. (with OpenGFX+Airports)
21:26:41 <Zuu> Could be that there is some code in that NewGRF that defines dummy airports for the other types. Especially since 11 to 18 is exactly the same amount as 1 to 8 (the unavailable default airports)
21:26:58 <Yexo> types 11 to 18 are non-buildable due to their year requirements
21:27:24 <Yexo> types 19 and above are so invalid that AirportSpec::Get() will actually return the AirportSpec from their substitute, which is the default airport due to zeroing the array
21:27:30 <Yexo> s/default airport/small airport
21:27:35 <Yexo> the small airport is actually buildable ;)
21:28:03 <Yexo> opengfx+airports defines more than just the small airport
21:28:12 <Yexo> it redefines all default airports with snowy versions
21:28:16 <Zuu> that's what I didn't think of first.
21:28:41 <Yexo> for me (in 1960) airports 0, 1, 10, 12 and 19+ are buildable
21:28:53 <Zuu> Only considered the small one as it got a rotation, but the snowy versions of course also requires to be defined.
21:56:10 *** JVassie has joined #openttd
22:05:29 *** beijingguy has left #openttd
22:20:50 * Zuu just discovered that you can insert a patch in the queue, not just adding new ones at the end
22:27:05 *** Phoenix_the_II has joined #openttd
23:50:36 *** DanMacK has joined #openttd
23:52:33 *** ar3k is now known as ar3kaw
continue to next day ⏵
