IRC logs for #openttd on OFTC at 2010-03-18
⏴ go to previous day
00:00:48 <Eddi|zuHause> we call that an "Extrawurst"
00:01:56 <Eddi|zuHause> it's figuratively :)
00:02:41 <Eddi|zuHause> if you want to blame someone for needing special treatment you say about him "he needs an extra sausage"
00:03:06 <Eddi|zuHause> in this case the ubuntu users
00:04:29 <Eddi|zuHause> the phrase generally has a negative connotation
00:04:44 <Rubidium> the word "ubuntu" too
00:07:32 <andythenorth> who likes maths?
00:07:58 <Pikka> where did this rc3 come from? :P
00:09:02 <andythenorth> an xy co-ordinate of an industry is unique, so I should be able to use that as a unique offset for closure period
00:09:09 <andythenorth> I don't think it will work though :)
00:09:16 <Rubidium> Eddi|zuHause: ofcourse I meant Cantor :)
00:09:20 <andythenorth> or at least, not a good idea
00:09:37 <Pikka> andy: I use xy as the quasi-random value for setting estimated resources :)
00:09:42 *** Rubidium sets mode: +o Yexo
00:09:49 <Rubidium> Yexo: why haven't you updated the topic yet?
00:10:09 <andythenorth> Pikka: does that mean industries at one end of the map get more resources?
00:10:14 *** Eddi|zuHause has joined #openttd
00:10:16 <Eddi|zuHause> andythenorth: there exist functions for that, for example trees or railtypes
00:10:41 * Pikka checks exactly what formula I use
00:11:09 *** Coco-Banana-Man has quit IRC
00:11:11 <Eddi|zuHause> andythenorth: it should be trivial to expose similar pseudorandom values to industries
00:12:48 <Rubidium> it's just some bit magic being done on their tile indices
00:13:19 <andythenorth> that can probably be done in nfo, without any trunk change
00:13:29 <andythenorth> I don't know how, but I figure it's possible
00:13:46 <Pikka> ah, actually I don't use the xy, I use the low nibble of the manhattan distance to nearest town
00:14:21 * andythenorth returns to pondering var 67 :)
00:14:33 <Rubidium> Yexo: getting ops when you already have ops is kinda difficult
00:14:34 <Pikka> which gives me a random number between 0 and 15
00:14:46 <Yexo> Rubidium: I just figured that out :)
00:14:53 *** Yexo changes topic to "0.7.5, 1.0.0-RC3 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | UTF-8 please | No Unauthorised Bots | English only"
00:14:57 *** Rubidium sets mode: +v Pikka
00:15:11 *** DorpsGek sets mode: -o Yexo
00:15:36 <Yexo> but my hostmask changed again, so DorpsGek didn't autorecognize me either
00:15:52 <Yexo> so after my first @op I was (again) finding out how to login to dorpsgek
00:17:21 <Yexo> Rubidium: no mention of the music project this time?
00:20:16 <Nite> Has anyone thought of some modification so that only cargo that has been transportet * tiles gets payed?
00:20:52 <Yexo> how does that differ from the current behavior?
00:21:10 <Nite> it differs because rigbnt now it gets payed
00:21:20 <Yexo> current payment is between the station signs
00:21:36 <Yexo> there is no easy way to prevent that
00:21:57 <Yexo> if you pay between source and destination industry/city then you can still beam the cargo around
00:22:03 <Nite> true - what i mean it would be nice if you could set a minimum distance cargo has to travel to get payed at all
00:22:16 <Yexo> and how are you going to measure that?
00:22:20 <Eddi|zuHause> Nite: in case you calculate payment according to distance travelled by the vehicle, then how do you prevent hauling cargo back and forth across the whole map, to an industry 10 tiles away from the source?
00:22:32 <Yexo> the cargo has "moved" between the 2 station signs, and that could be 100 tiles with a large station spread
00:23:22 <Nite> well back and forth would at least be travelled (why would you do that?)
00:23:24 <Eddi|zuHause> Yexo: well, that would be "easy", just count the distance in "vehicle_enter_tile"
00:23:51 <Yexo> Nite: you would do that to get payed more for the same cargo
00:23:52 <Eddi|zuHause> Nite: to get more payment out of the same cargo, same as "beaming"
00:24:23 <Eddi|zuHause> you're simply trading for a different kind of abuse
00:24:36 <Nite> it wouldnt prevent the back and forth but it would prevent real "beaming" (= no track built at all)
00:25:28 <Nite> right now it is calculated how far a cargo travelled by distance between stations i guess?
00:25:50 <Nite> if so it could stay the same
00:26:34 <Nite> do not get payed if stations are not * tiels away - isnt that simple?
00:26:45 <Eddi|zuHause> Nite: you can theoretically make it distance between industries, but that wouldn't prevent "beaming" either
00:27:17 <Eddi|zuHause> Nite: as Yexo explained, stations can be 100 tiles apart and still be next to each other
00:27:17 <Yexo> <Nite> do not get payed if stations are not * tiels away - isnt that simple? <- no, then I'll just beam an extra time so the first and last stations are far enough apart
00:28:22 <Yexo> easiest solution is making the maximum station spread small
00:28:37 <Eddi|zuHause> 12 tiles should be enough for anybody :)
00:28:39 <Yexo> and even better is a server with an admin that enforces rules that disallow this
00:29:11 <Nite> then someone would say "if the spread is small i just bould more stations"
00:29:15 <Eddi|zuHause> 12 tiles station spread is still a huge area
00:29:35 <Nite> i was talking about 12 (coincidently)
00:29:39 <Eddi|zuHause> Nite: yes, any measurement you take against this, can be circumvented
00:30:47 <Eddi|zuHause> Nite: it will always require a human saying "this does not look right... let's ban this guy"
00:31:36 <Nite> since that would be the solution to everything it would need no gameplay mechanic at all ...
00:32:01 *** ChanServ sets mode: +v tokai
00:32:12 <Rubidium> there is no simple and effective way to prevent 'cheating'
00:32:43 <Rubidium> is it cheating when you transfer cargo on a 64 tile wide contiguous station?
00:33:02 <Eddi|zuHause> oh man... this is so tempting...
00:33:14 <Rubidium> if a train enters on platform 1 and transfers to a train on platform 64... that'd be "beaming" too, right?
00:33:36 <Nite> beaming is when the train hardly travels at all
00:33:38 <Eddi|zuHause> statement by HIM: "a complete industry set is in development, please don't ask when it will be ready" :p
00:34:13 <Eddi|zuHause> Nite: but there is no objective measurement of "hardly"
00:34:14 <glx> Rubidium: even better if there's nothing between platform 1 and platform 64
00:34:30 <Rubidium> Eddi|zuHause: RTM... when eastern and pentecost are one the same day?
00:35:42 <Eddi|zuHause> Rubidium: oh, that is good, i'll use that :)
00:35:42 <Nite> platform 64 would at least be a "travel" (with "hardly i eman X = variable :-P)
00:36:18 <Rubidium> Eddi|zuHause: it's a Dutch proverb/saying of some sorts :)
00:38:06 <Eddi|zuHause> incidentally, although both are moving holidays, the distance between both is constant :)
00:38:53 <Rubidium> oh, it's easter not eastern :)
00:39:10 <Eddi|zuHause> well, it works in german as well :)
00:39:27 <Nite> the idstances between industreis (destinations) simply need to be bigger so beaming would be more hassle than connecting with treck ... *thinking*
00:39:31 <Eddi|zuHause> although i know such phrases more with christmas and new year
00:39:52 <Yexo> Nite: as I said before, then you could still beam 2 or 3 times
00:39:59 <Yexo> still easier then building the complete track
00:40:08 <Yexo> just lower the maximum station spread to 4
00:40:12 <Nite> yeah but not 100 times - what i mean with distance
00:40:48 <Nite> you cant play with spread 4 becaus industreis simply produ#ce too much
00:41:08 <Eddi|zuHause> that's still easier than managing 100 trains on a congested line
00:41:39 <CIA-6> OpenTTD: yexo * r19449 /trunk/src/station_cmd.cpp: -Codechange: pay for every airport tile build, not for every tile in the rectangle where the airport is build
00:42:13 <Nite> i doubt that 100 beaming trains would be eassy to handle
00:42:29 <Yexo> you wouldn't need 100 beaming trains
00:42:47 <Yexo> if you have station spread set to 12 or so and you normally would need 100 trains I'm quite sure you can do with only 20beaming trains
00:43:08 <Rubidium> why use trains? Use ships... way more effective
00:43:13 <Nite> wati what i initailly meant beaming is not payed - not impossible
00:44:30 <Nite> so if none of the beaming stations is far enough would the cargo sitll be calced between the first and the last?
00:44:31 <Eddi|zuHause> Rubidium: but you can't join two docks
00:44:50 <Rubidium> Eddi|zuHause: good point
00:44:58 <Rubidium> half ship half train then :)
00:45:30 <Rubidium> although... if transfers were to be slightly rewritten
00:45:48 <Rubidium> for "leg" payment loading location - unloading location
00:46:09 <Nite> what happen if i brutally set leg payment to zero?
00:46:31 <Yexo> Nite: you'd still get the same total income, but only the final train gets profit
00:46:44 <Eddi|zuHause> Nite: you get full payment at the end
00:46:54 <Rubidium> for final payment: min(sum of legs payments (including last), payment original source - destination)
00:46:58 <Eddi|zuHause> this is how the original game worked
00:47:22 <Nite> ic only some trains would be in red bot the last even more in the black ...
00:47:35 <Yexo> Rubidium: now that is an interesting idea
00:48:20 <Eddi|zuHause> Rubidium: so you don't store the location of the station sign, but the location where the loading happened?
00:48:43 <Yexo> station sign is still needed for the "payment original source - destination" part
00:49:22 <Nite> should lead to: only the longest of the tavels count - everything else not payed at all
00:49:38 <Rubidium> we already store the loading station and loading xy
00:49:52 <Eddi|zuHause> but this only solves half the problem, you still have the option of doing a 100 wagon train that just turns around between two 1 tile stations
00:50:18 <Rubidium> Eddi|zuHause: ever looked at the loading penalty for that?
00:50:21 <Nite> loading would take very long though
00:50:26 <Yexo> Eddi|zuHause: yes, but that train will take so long to load/unload that that's not really a problem
00:50:48 <Eddi|zuHause> hm, i have not actually tried this :)
00:50:50 <Rubidium> unloading_time += (overhang * unloading_time) / 8;
00:51:10 <Rubidium> and that ignores the initial <<= 1 because there is overhang
00:51:20 <Eddi|zuHause> Rubidium: is that also if only the first wagon has cargo at all?
00:51:26 <Rubidium> that number is 40 for non-overhang
00:51:41 <Nite> then you would only need a one wagon train
00:52:07 <Eddi|zuHause> Nite: the point is that by simply turning around, the train travels 50 tiles
00:52:24 <Eddi|zuHause> which takes 0 time
00:53:03 <Nite> so first xy of cargo is stored and when its accepted by destination the complete destination is calced - am i right?
00:53:55 <Nite> would mean how far a train travels is ignored at all
00:54:24 <Eddi|zuHause> but i think the whole transfer system has a wrong approach
00:54:44 <Eddi|zuHause> i'm just not sure how to model a right approach
00:55:29 <Eddi|zuHause> two scenarios where the transfer calculation horribly fails:
00:55:41 <Eddi|zuHause> transferring source->train->ship->destination
00:55:53 <Eddi|zuHause> results in huge loss for the ship, because it is slower than the train
00:56:41 <Eddi|zuHause> transferring city->main-station->next main-station->city [especially in cargodist] can also result in huge loss, because the last leg of the travel may go backwards
00:56:46 <Yexo> the main problem there is that when the train transfers the cargo to the station no prediction of the rest of the travel can be made
00:57:15 <Yexo> that second problem is less since we have a percentage for the leg paymets
00:57:38 <Nite> (maybe some cargo -dest or -dist or -dust whatever will help soon)
00:57:40 <Eddi|zuHause> yes, but it's only cosmetic, it doesn't solve the actual problem
00:57:48 <Yexo> and the same problem holds: it's impossible to predict how the cargo will travel when it arrives at the main station
00:58:10 <Eddi|zuHause> "realistically", the payment for long distance and for local transport should be completely separate
00:58:10 <Yexo> cargodest won't help with that
00:58:22 <Nite> true could always travel through 100 beaming stations
00:58:40 <Yexo> althouth with cargodest/dist it's easier to predict the direction, it's not foolproof as cargo can still be transferred the wrong way
00:59:53 <Nite> clearly it is already calculated how much a transferring train gets payed in the end
01:00:15 <Eddi|zuHause> my suggestion was: at game start there is a full network of "walking" cargo with low speed and capacity. you can provide transport that is faster than the generic network, and parts of the cargo will travel this way. that makes a basic level of competing without having actual competitors
01:00:23 <Eddi|zuHause> but then you can pay each leg individually
01:00:41 <Eddi|zuHause> as "unfair" transportation will just result in the cargo using the generic network
01:00:54 <Nite> still you could beam faster than teh "walking"
01:01:11 <Eddi|zuHause> Nite: i'm completely not talking about "beaming"
01:01:30 <Eddi|zuHause> Nite: we already established hat this can not be solved.
01:02:20 <Yexo> Eddi|zuHause: Rubidiums suggestion earlier might work
01:02:31 <Yexo> <@Rubidium> for final payment: min(sum of legs payments (including last), payment original source - destination) <- that one
01:02:48 <Eddi|zuHause> Yexo: no, that can't solve either of the scenarios
01:02:59 <Nite> thx thats what i wanted to get to
01:03:24 <Yexo> Eddi|zuHause: it doesn't solve the problems you mentioned, but it does solve the "beam gets a lot of money" problem
01:03:25 <Eddi|zuHause> oh, you're talking about beaming again...
01:03:47 <Nite> if all legs where subtracted you would end up in the red when beaming (!)
01:03:52 <Yexo> a walking network is interesting, but a lot of work to code
01:04:12 <Yexo> you'd probably end up coding cargodest/cargodist first :p
01:04:24 <Nite> the subtraction of legs would be maybe easier to code
01:04:27 <Eddi|zuHause> well, yes, it can't work without destinations...
01:05:14 <Nite> btw when you are not talking about antibeming - what then?
01:05:42 <Eddi|zuHause> i'm talking about transferring in general
01:05:53 <Yexo> Nite: see "<Eddi|zuHause> but i think the whole transfer system has a wrong approach" and the next few minutes
01:05:55 <Nite> well it works fien in general
01:06:13 <Eddi|zuHause> no, it does not.
01:06:35 <Eddi|zuHause> ships and road vehicles are heavily penalised for their low speed
01:06:37 <Nite> you can transfer as you like - what does not work here
01:06:54 <Eddi|zuHause> so intermodal transfer is "unfair"
01:07:23 <Eddi|zuHause> while it completely denies the fact that it's not possible to drive a train into the town center, or across ocean
01:07:23 *** Progman has joined #openttd
01:07:47 <Nite> you should transfer because you need it (because of landscape/the map) not because it is so lucrative
01:07:52 <Eddi|zuHause> and so payment across sea or within cities must obey other rules than simple time/distance
01:08:19 <Eddi|zuHause> no, it should be especially lucrative because it's so difficult
01:08:34 <Nite> it is possible to drive a trian everywhere
01:08:44 <Nite> rellay whatr are you talking about?
01:09:36 <Yexo> Eddi|zuHause: you have some nice idea, but I think it's way too much work to implement
01:10:46 <Nite> im not looking for a rewrite of the transfer sys at all - it simply works
01:11:02 <Nite> BUT it makes beaming possible while still getin g paid
01:11:38 <Eddi|zuHause> Nite: the problem with transfer is: any transfer will make you earn less money than direct transport
01:12:05 <Nite> that is not a problem that is good!
01:12:32 <Eddi|zuHause> no, that is a problem, because it encourages point-to-point lines instead of balanced networks
01:13:14 <Nite> a network is not only balanced if you get payed more
01:13:28 <Nite> it is when cargo flows ...
01:13:47 <Nite> and tath cargo flows better with beaming should be penalized
01:14:23 <Eddi|zuHause> you with the beaming again...
01:14:48 <Nite> i knbow you talking bout something else ...
01:15:04 <Nite> but yes i talk about beaming because it annoys me
01:16:08 <Nite> your idea would even encourage beaming (again)
01:16:38 <Nite> still i liked rubidiums idea
01:19:00 <Nite> i also talked about teh non transfer beaming ... i know you dont care eddi
01:37:17 *** Wizzleby has joined #openttd
01:40:23 <Nite> well i thought about beaming recently
01:41:05 <Nite> and i think making short distance deliveries significantly less paid would help.
01:47:21 <Pikka> but what does that do to genuine short-distance routes?
01:52:44 <fjb> But is not the distance between the station signs counted?
01:53:58 <fjb> And short distance routes would really suffer. They are quite common in games startig early in the 19th century.
01:54:28 <Nite> with short i mean really short - as short as a station
01:54:51 <fjb> But when "beaming" the station signs are usually still way apart, but the stations are really large, so the games does not see short routes.
01:55:42 <fjb> You can easily have 30 tiles long stations.
01:56:08 <Nite> i think thats where i clash with others
01:56:12 <fjb> With a station sign at opposite ends that gives more than 60 tiles.
01:56:36 *** snorre_ is now known as snorre
01:56:43 <Nite> true and you should get very littel "cash" for that
01:57:00 <Nite> what is "long" or "short" line
01:57:39 <fjb> But the game can not decide how much a vehicle travels between the stations. It only sees the distance between the station signs.
01:57:50 <Nite> if a sataion can be 12 tiels long tna a rout ten times tath should just bring in littel money
01:58:26 <fjb> I have often routes shorter than 60 tiles. Often only 5 or 6 tiles with bus or tram networks in towns.
01:59:11 <Nite> i know it gets more problematic with (inner city) pax
01:59:28 <fjb> My coal trains are often about 16 tiles long. So that is the minimum lenghts of a station.
01:59:45 <Nite> but at the moment you can "win the game" with the most ridiculous entworks
02:00:01 <fjb> Now the will make every route which is shorter than 16 tiles useless.
02:00:35 <fjb> TTD is always easy to win with the right settings (e.g. total flat map).
02:00:36 <Nite> and i think it would be kewl to make such a line useless
02:01:02 <fjb> That would discourage most road vehicle traffic.
02:01:11 <Nite> keep in mind transfer station could still be usefull but only to get the cargo to the long route
02:01:52 <fjb> Then build a long route in the mountains with horse carriages in the first game year. Have fun.
02:02:30 <Nite> i know it wont work but horse carriages are more of a (good !) gimmick anyway
02:03:05 <fjb> Did you ever start a game in 1821? They are no gimmick then.
02:03:55 <Nite> further such a feature should off course be variable/configurable - so you can have your early days, wait forever, games
02:03:58 <fjb> They are your only road vehicles for the next 70 years.
02:04:26 <Nite> and yes i did star most last games at 1930 (nars)
02:04:33 <fjb> The the people who love beaming switch that fearture off.
02:04:55 <Nite> iam mostly reffering to trains
02:05:09 <fjb> TTD is not a train only game.
02:05:18 <Nite> as for pax - pax in towns would be mostly for growing it
02:05:26 <fjb> And most beaming I have seen with road vehicles.
02:05:49 <Nite> trains ARE the most fun by far
02:06:19 <Nite> you are right beaming happens with rvs often
02:06:41 <Nite> yes they are if it would be voted
02:06:43 <fjb> In my actual game I have about 30 trains and 450 road vehicles.
02:07:35 <Nite> 30 trains is laughably sry ;)
02:07:49 <Jolteon> Trains are incredibly tedious.
02:07:53 <Jolteon> I usually don't bother with them.
02:08:13 <fjb> If you would vote for rail station layouts most people would vote for the roro station layout from the wiki. But that does not tell you what creative people do.
02:09:43 <fjb> See, everybody has a vehicle type he likes or dislikes. And it is not always the same.
02:10:02 <Nite> trains is teh most intresting all others are support - you cant be very crative with ships airplanes - only with rv's and mostly TrAiNs
02:10:07 <Jolteon> I must admit, when playing multiplayer, i am such an airplane whore.
02:10:33 <fjb> You can be really creative with all of them.
02:11:06 <Nite> send airplane from a to b - wait build new airport - repeat. very creative.
02:11:12 *** De_Ghosty has joined #openttd
02:11:25 <Nite> thats wyh many servers are no air - especially competition servers
02:11:27 <fjb> Did you ever see a game with many channels and ships? Ships are great for coal, iron ore and other stuff like that.
02:12:09 <Nite> off course they are great but tt would not suceed without the trains part ...
02:12:13 <fjb> It becomes creative with cargodist. Have fune with planes if you are not creative.
02:12:46 <Jolteon> Nite: thats why I do it.
02:12:58 <Jolteon> No brain powered required.
02:13:00 <Nite> cargodist and planse muist really be nice.
02:13:02 <Jolteon> Trains annoy me to hell and back.
02:13:05 <fjb> I often have games where road vehicles generate the most income (especially with UKRS).
02:13:07 <Jolteon> So much planning, and effort.
02:13:36 <Jolteon> and with a bit of good going, it's so easy to make the most profit on the server from using planes only
02:14:09 <Nite> wht i want at the momant is a game you cant chaet by ridiciolous station setups that are just exploiting glitches
02:14:30 <Jolteon> What annoys me are those that build an airport or train station, then hog the entire town by placing bus stops links to the airport
02:14:39 <Jolteon> so it's impossible for anyone else to get any real stuff from the town
02:15:00 <fjb> You can always cheat. Cheating is a social problem. Solving social problems with technical solutions never works.
02:15:10 <Nite> tahts a case of who comes first often
02:15:36 <Nite> yes but exploiting is not exactly chaeting
02:15:59 <fjb> Nobody can "hog" a town. Make a better service and you will get the cargo/pasengers.
02:16:01 <Nite> and the better the balancig/mechanics get the fewer glictch xploiting you have
02:16:43 <Nite> (blocking however will most likely never be defeted by an algorhytm/mechanic)
02:16:51 <fjb> Making one class of transports unusable is no good solution.
02:17:48 <Nite> but it wouldnt be unusable - a short support line would be just that, but no moneyamaker.
02:18:09 <fjb> Only allowing really long routes does not solve anything. Make the stations 100 tiles large and you pribit small maps at all.
02:18:46 <Nite> noone play with 100 tiels stationspread
02:19:12 <Nite> but true larger maps with further appart sources/destenations solve a lot
02:19:34 <fjb> Sure? People who love beaming would set it that high.
02:19:55 <fjb> But large maps can get boring.
02:20:32 <Nite> i know finding glitches as beaming is fun too
02:20:49 <Nite> but agaion in many serious games beaming sucks
02:20:58 <fjb> Somebody (I think Rubidium) showed a very busy very small map a while ago here. Really interesting.
02:22:19 <fjb> If you play multiplayer beaming can be prohibited by server rule. Who beams gets kicked. If you play singleplayer play like you like. Let others play their style.
02:23:36 <Nite> in really busy maps that is a lot of work for the admin
02:24:17 <fjb> Usually players are also looking if others are cheating.
02:24:30 <Nite> still i see that good maps with far apart industreis solve most
02:24:41 <fjb> Beaming is usually obvious.
02:25:22 <Nite> but its hard to forbid it completely
02:26:17 <Nite> because sometimes you need all the sattionspread for a simple transfer - and then - this should not be paid een be a t a cost
02:27:01 <fjb> beaming: Placing to very lage stations near ech other (not building the full station, but only 2 tiles with a big gap in between) and have a vehicle travel only the very stort distance between the neares tiles of the two stations.
02:28:32 <fjb> Nobody need a big station spread. You can always feed with road vehicles. So why not making the station spread only one tile?
02:29:15 <Nite> station spread = station size
02:30:39 <Nite> so you need normal station size (8 - 14 quite common)
02:30:42 <fjb> Ok, you need that with long trains or train stations with airports.
02:31:14 <fjb> 14 tiles is short for a cargo main line station.
02:31:29 <fjb> but 14 tiels is long for a tram route.
02:32:20 <Nite> after all making shourt routes unprofitable should always be an option - freely configurable like most new features (too many to name)
02:32:36 <fjb> You like to play with trains on long routes on big maps. Others don't. So don't force them to your stily.
02:33:32 <fjb> But even on the same server other people will not prefer your style and happily build bus networks.
02:34:55 <fjb> And with cargodist much traffic likes short distances.
02:34:55 *** DaleStan has joined #openttd
02:36:00 <Nite> i said just taht - no forcing but another great option!
02:36:38 <fjb> Cargodist also effectively kills companies with only a few airports cluttered over the map.
02:37:05 <Nite> that many including me would like
02:37:44 <Nite> i only knew cargodEst never was on a cargodist server
02:37:55 <fjb> I see that that option only forces everybody to play your style as long as it is active. You still can beam the distance of the largest allowed station.
02:39:02 <Nite> yeas and you should beam but dont get paid, and yes a gain it is a personal favour, and no i will not force you to play like that with a gun on your neck ... ;)
02:39:52 <fjb> You will not get money when not playing your stile with that oprion active.
02:40:18 <fjb> That is kind of forcing, but ok, you have the option not to play at all.
02:41:04 <fjb> And with the not unusual allowed station size of 20 tiles you can still beam 40 tiles.
02:41:18 <Nite> anyopne can still play tto if not liking new options styles
02:41:59 <Nite> please stop feeling forced ...
02:42:00 <fjb> Your option does not solve the beaming problem, it only forces all players to play your style.
02:42:45 <fjb> Tell me other option tham your style do players have with that game option active?
02:42:50 <Nite> and in this "style" it woudl be solved htat beming has a much smaller role
02:43:47 <fjb> I could even with that option make a beaming chain.
02:44:01 <Nite> you have no option than build nice looking long creative lines.
02:44:08 <Nite> the beaming chain had to come :)
02:45:00 <fjb> Only long train lines. That may plaese you, but is by far not really creative.
02:45:18 <fjb> And the beaming chain kills you whole idea.
02:45:57 <fjb> I have never seen a player using beaming but not making a chain.
02:48:02 <fjb> You can prohibit beaming only by disallowing stations which have disconnected parts together with disallowing large stations.
02:48:14 <Nite> best idea still was rubidiums: total income subtracted by leg leg profit
02:48:18 *** DaleStan has joined #openttd
02:49:12 <Nite> i have just seen a player beaming to neigborhood without a chain, thats what startet all of this
02:49:41 <Nite> comes even moer clear that good placing of industry on map does a lot ...
02:49:55 <fjb> That was a beginner at beaming. Or early in the game.
02:51:41 <fjb> Short distance road vehicle (or even train) traffic can also be very creative.
02:52:22 <Nite> no it wasnt a beginner, but yes early game
02:54:02 <Nite> what was disliked there was that the beaming tactics wa so much better "paid" than others with "beautiful" lines - leading to a rulo on that server
02:54:46 <fjb> A clear rule forbidding beamig would have solved that problem.
02:55:17 <fjb> And what beaitiful lines are is very argualble.
02:56:30 <Nite> well beaming are no lines at all so it cant be "beautiful lines"
02:57:12 <fjb> Live with beaming or count it as cheating.
02:57:38 <fjb> So it was cheating. That player deserves a warning. If he still does it kick him.
02:58:54 <fjb> So what brings a new option that enforces a special type of game but does not make beaming impossible or useless?
02:59:04 <Eddi|zuHause> <Nite> cargodist and planse muist really be nice. <-- cargodist and planes is hopeless... especially without passenger reduction
02:59:39 <fjb> Overfull planes or no passengers at all. :-)
02:59:57 <Nite> comes to my mind the real problem is less beaming but clusters of industreis that work together
03:00:38 <fjb> You need nearby industries early in the game.
03:00:39 <Eddi|zuHause> Nite: there's a setting for that
03:01:03 <Nite> yeah but not toooo nearby
03:01:04 <Eddi|zuHause> "same industries close" and "same industries in town"
03:01:09 <Nite> no there is no setting for that
03:01:45 <Nite> iam not meaning same industreis but industries that work together in same town and close together
03:02:09 <Eddi|zuHause> why is that a problem?
03:02:10 <Nite> too nearby = nearby as with same industreis
03:02:33 <Eddi|zuHause> you don't get a lot of profit from short distance traffic
03:02:43 <fjb> And really try a game with eGRVS and NARS 2 wich starts 1831. But better switch inflation of.
03:02:43 <Nite> that you can earn very much by having no track at all
03:03:14 <Nite> it is all about an ecs game and nars2 started 1930
03:03:22 <Eddi|zuHause> how many times can you give the same argument over and over again?
03:03:44 *** De_Ghosty has joined #openttd
03:03:49 <fjb> And it would be a game option to implement only for one special game.
03:03:52 <Nite> that ecactly is teh problem you DO get alot of profit from short distance traffic
03:04:10 <Nite> wrong not only for one game
03:04:48 <Nite> fjb you allways assume i am the only one not playing like you
03:05:02 <fjb> For the game the distance is not short. the distance is the distance between the station signs, not what the vehicle actually travels.
03:05:25 <Eddi|zuHause> Nite: please take a breath, and now imagine the solution from 3 hours ago were implemented. how is it still a problem for short distance transports?
03:05:38 <fjb> Nite: You always assume the I'm the only one not playing like you.
03:05:55 <Eddi|zuHause> ok, it was 2 hours...
03:06:21 <Nite> for some reason fjb is always contradicting :D
03:06:48 <Nite> what solution you mean ecactly?
03:06:53 <fjb> Because your idea does noct solve the annoying beaming in any way.
03:07:21 *** rhaeder has joined #openttd
03:08:51 <Nite> anyway i think teh options for similar industreis should also be available for Same type industries.
03:08:53 <fjb> Every distance shorted than 2 times largest station size would have to be unprofitable following your idea.
03:09:22 <Nite> yes something like that.
03:09:57 <fjb> So usually every distance shorter 40 tiles (or more 60 tiles at the servers I saw).
03:10:23 <Eddi|zuHause> Nite: newgrf industries can do that. so you can make an industry set resembling the original industries, but override the placement check
03:11:44 * fjb thinks that even 40 tiles is a nice long route early in the game.
03:12:02 <Nite> so in the end having same industries close but no working together industries close - or no industreis at all close
03:12:24 <Eddi|zuHause> fjb: imho, early industries need more tweaks. generally they should be smaller but more frequent
03:12:37 <Nite> well i cant mak a newgrf, is this possible with ecs?
03:12:54 <Eddi|zuHause> ECS has very insane placement rules
03:13:09 <Eddi|zuHause> i don't know the details, though
03:13:33 <Nite> ... likes and dislikes are really different i tink they shuld be big but not frequent ... :)
03:13:42 <fjb> Nite: No, learn to code. It is not that hard. At least not as hard as convincing us implementing your idea about making short routes totally wothless.
03:13:51 <Nite> didnt know htey had own placement rules
03:14:51 <Nite> suggesting is different from convincing btw
03:15:16 <fjb> You have to convince us if you want it implemented.
03:15:22 <Eddi|zuHause> Nite: they can be all sorts of things: "must be near a town with more than 1200 inhabitants", "must be near a town with fewer than 300 inhabitants", "must be near water", "must have 6 trees and 2 houses", "must be full moon on a wednesday", ...
03:16:02 <fjb> And I thing the idea is plain stupid because it does not solve the problem but is a burdon for players with a different style tham yours.
03:16:36 <Nite> (guess if someone offers fjb icecream he starts argueing why someone wants to convince and force him to eat iccream he dont likes instad of saying "not intrestet")
03:17:28 <Nite> (and it would be really stupid to make iceream becaus fjb dont likes it)
03:18:21 <DaleStan> Remind me again how old you are? Because even if you are three, acting like it is not generally productive in fora where we can so easily /ignore you.
03:18:28 <fjb> It's the other way round. I think everybody should be free to play his own stile. But you propose an option that would make all players play your style.
03:18:50 <Nite> ok so the industry placing seems to have enaugh options ...
03:21:08 <Nite> then very nture of an OPTION is exactly tath you are NOT FORCED to use it but can configure it the way you like. Like having many different sorts of icecreams.
03:22:14 <fjb> He doesn't understand it. I'm giving up.
03:22:52 <Nite> im NOOOOOOOT FOOOOOORCING you or anybody else ...
03:23:40 <Nite> who where you reffering to dalestan?
03:24:04 *** DanMacK has joined #openttd
03:26:04 *** rhaeder1 has joined #openttd
03:26:22 <Eddi|zuHause> the new guy who is talking about the same thing non-stop for three hours
03:27:20 <Rubidium> no, it's definitely me
03:27:25 <DaleStan> No. Your twin brother.</sarcasm>
03:28:12 <Eddi|zuHause> no, _I_ am napoleon.
03:29:08 <Nite> soemone must chat soemething here ...
03:29:22 <Eddi|zuHause> you realize it's 4:30 AM?
03:30:57 <Eddi|zuHause> that's funny... /whois can resolve mibbit addresses to the real IP. is that a new feature?
03:31:16 <Rubidium> DaleStan: is there a really good reason to upx pack grfcodec? It fails on the more exotic platforms like alpha, hppa and s390 (i.e. some of Debian's platforms)
03:33:04 <snorre> its not about making short routes totally wothless, but make the profit correspond to the longer ones, (or actually distance travelled)
03:33:13 <DaleStan> Though I could try to invent something about trying to improve UPX's support of the more exotic platforms.
03:33:42 <Eddi|zuHause> someone should ban these hysterics, they make life so difficult
03:33:46 <Nite> *wonders if fjb did just fool/troll around*
03:34:43 <Eddi|zuHause> insulting the regulars is surely a way to make an impression :p
03:35:00 <Eddi|zuHause> hysterical raisins.
03:35:51 <Rubidium> have you also seen his remarks regarding Makefile.common looking like it's not used?
03:36:20 <DaleStan> Doesn't sound familiar.
03:38:21 <DaleStan> No, Nite. "Talking in GIYF-ics" (Note also the spelling of "talking.")
03:43:21 <Rubidium> what the fuck is wtf?
03:47:02 <Nite> ok ok forgot to GI everythink i dont get in the first place ...
03:51:31 *** De_Ghosty has joined #openttd
04:02:23 *** roboboy has joined #openttd
04:16:14 *** De_Ghosty has joined #openttd
04:33:30 *** De_Ghosty has joined #openttd
04:42:57 *** De_Ghosty has joined #openttd
05:05:35 * Pikka wonders if opensfx has broken newsoundeffects property 0A override old sound? :o ... if that property ever worked in openttd?
06:12:42 <Pikka> spammin' up the olde forum suggestions...
06:56:03 *** Terkhen has joined #openttd
07:48:43 *** Cybertinus has joined #openttd
07:49:19 *** TheMask96- has joined #openttd
08:00:14 *** TheMask96- is now known as TheMask96
08:06:03 *** oskari89 has joined #openttd
08:37:33 <DJNekkid> there is no possible choise of 1.0.0 RC3 on bananas...
08:45:28 *** JVassie has joined #openttd
08:53:54 *** JVassie_ has joined #openttd
08:55:10 *** TheMask96 has joined #openttd
09:03:41 *** kannerke has joined #openttd
09:06:07 *** stagger has joined #openttd
10:13:38 <andythenorth> Pikka: brain fail. what's wrong with my var 67 check? :o
10:23:17 <andythenorth> hmm.. parameter should be dword, not byte?
10:23:26 <Eddi|zuHause> Pikka: i don't think that has been broken
10:30:06 <Pikka> hmm eddi.. it doesn't seem to be working for me, but maybe I'm doing something wrong.
10:31:48 <Pikka> andy: it's a type 89 so the ranges need to be dword sized, not byte sized.
10:32:20 <Pikka> 00 80 00 00 //lookat needs to be 00 80 \d0 \d0
10:32:34 <andythenorth> do, copy and paste fail
10:33:03 <Pikka> it's okay, happens to the best of us :P
10:33:06 <andythenorth> hard to type with a baby in one hand
10:47:41 *** HackaLittleBit has joined #openttd
10:51:18 *** rhaeder has joined #openttd
10:55:33 <andythenorth> "The return value has the format rrccdddd" - I want cc. I mask with \dx00FF0000 right?
10:56:48 <peter1138> or shift 16, mask with FF
10:58:28 <andythenorth> shift 16 is 2F (if another var triple follows)?
10:58:59 <HackaLittleBit> hello guys, I am trying to find additional info for the use of TIC TOC , I wan't to post in the forum but I would like to avoid double post :)
10:59:05 <peter1138> 16 was decimal, heh
10:59:39 <HackaLittleBit> can somebody help please
11:00:21 <peter1138> it's described in debug.h
11:00:36 <HackaLittleBit> only instuctions I found were in debug.h
11:01:16 <HackaLittleBit> So I thought to make a post to give additional usage info
11:01:26 <peter1138> what additional info would you need?
11:01:30 <peter1138> it tells you how to use it
11:01:52 <HackaLittleBit> I have been playing around last night
11:02:18 <HackaLittleBit> and for example resizing ow window influences results
11:02:46 <HackaLittleBit> I wan't to make post to facilitate for future post
11:03:17 <HackaLittleBit> I can post her first if you like
11:03:40 <HackaLittleBit> Hello everyone.
11:03:40 <HackaLittleBit> I just wanted to give some additional comments about how to use of TIC TOC with success.
11:03:40 <HackaLittleBit> The way of implementing TIC TOC is described in debug.h
11:03:43 <HackaLittleBit> Additional to that you have to do the following things to get consistent results.
11:03:49 <HackaLittleBit> 1. Prepare a game and save in "paused state".
11:03:51 <HackaLittleBit> 2. resize the game window in order to have space to put you mouse outside of the window.
11:03:53 <HackaLittleBit> 3. Close main window with the "X" in the top right corner so that the operating system
11:03:55 <HackaLittleBit> remember last screen size.
11:03:57 <HackaLittleBit> 4. Start the game and load your test game.
11:03:59 <HackaLittleBit> 5. Start game and move your mouse out of the window.
11:04:01 <HackaLittleBit> Important to know is that if you want to accelerate the game you have to do that "BEFORE"
11:04:03 <HackaLittleBit> you unpause the game and do this consistent.
11:04:05 <HackaLittleBit> 6. Try to avoid that external programs start up (like updating etc) because it will influence the results.
11:04:08 <HackaLittleBit> 7. Do not touch you PC until you are done. Do not resize the window etc. because again it will affect the results.
11:04:13 <HackaLittleBit> This was written for windows XP if anybody has suggestion or useful comments I will add them to this first post.
11:04:16 <peter1138> all bogus information
11:04:20 <Terkhen> HackaLittleBit: check the latest parts of the Improved acceleration for road vehicles thread
11:04:20 <HackaLittleBit> P.S. to the developers, It would be nice to have some tab characters in the output string in order to make facilitate loading in spreadsheet.
11:04:29 <HackaLittleBit> Hello everyone.
11:04:32 *** peter1138 sets mode: +b *!*Hans@87.196.211.*
11:04:32 *** HackaLittleBit was kicked by peter1138 (HackaLittleBit)
11:05:02 <andythenorth> peter1138: does this look right to you? \2sto 1A 20 \dx100 //store in register 100h
11:05:32 <peter1138> i have no idea, i never write nfo with anything other than hex
11:06:09 *** peter1138 sets mode: -b *!*Hans@87.196.211.*
11:06:29 <andythenorth> problem must be here then: 67 01 20 00FF0000 //get industry count
11:07:02 <peter1138> you should paste the full line, really
11:07:03 <DaleStan> You're storing in the third byte; are you sure that's what you wanted?
11:07:07 <Pikka> eh.. you should probably shift it like peter said
11:08:14 <DaleStan> ...(or maybe the second) ...
11:09:26 <Pikka> peter1138: wondering if opensfx has broken newsoundeffects property 0A override old sound? :o ... if that property ever worked in openttd? any ideas? D:
11:10:01 <peter1138> opensfx is just a different set of sounds
11:10:12 * andythenorth wins at var 67 (with much help!)
11:10:49 * Pikka wonders if it ever worked, then, or if I'm just doing it wrong
11:11:20 <andythenorth> Pikka: what are you seeing / not seeing?
11:11:20 <peter1138> you need to load the sound, then do the override
11:12:36 *** HackaLittleBit has joined #openttd
11:12:37 <Pikka> yes... I have the sounds going in with action 11, and then I set property 0a for one of them to \b14, which should be the level crossing sound? but it no workz.
11:14:12 *** KenjiE20 has joined #openttd
11:14:22 <peter1138> hmm, did you offset the id with 73?
11:15:35 <Pikka> yes, of course. I have new-newsounds working just fine in the same grf (in vehicle callbacks, for example), it's just the property 0a replacement that doesn't seem to be working.
11:17:44 <peter1138> hmm, apparently it's sound 12
11:18:46 <peter1138> 14 is train breakdown
11:20:34 <Pikka> where's the list? I was going off the sample.cat files
11:20:48 <Pikka> I couldn't find a list anywhere. :)
11:21:56 <peter1138> it's listed as ,...SND_0E_LEVEL_CROSSING,
11:22:41 <Rubidium> yeah, the IDs are genuinely mixed up
11:24:43 <andythenorth> Eddi|zuHause: I _might_ be close to your idea of limiting industry closure to 1 in a given time period :)
11:25:25 <peter1138> why do we have that?
11:25:38 <peter1138> is it the same in ttd?
11:26:26 <Rubidium> it's the same in 0.1.4
11:27:15 <peter1138> Pikka, so does it work with 14 in ttdp?
11:27:34 <Pikka> I don't know peter, a lot of the rest of the grf won't work in ttdp
11:28:23 <peter1138> it's possible that we should be mapping the id
11:36:55 <blathijs> planetmaker: Any chance the OpenMSX midi's could be tweaked to work completely with timidity+freepats? I'm getting a bunch of errors about unsupported instruments on each song. Not sure if that's a realy problem (I can't hear what's missing), but perhaps it's a matter of choosing a slightly different variant of some instruments?
11:42:08 <Ammler> blathijs: maybe you should post that in the tt-forums thread
11:42:21 <Ammler> or isn't that part of the composers?
11:44:44 <blathijs> Ammler: Dunno if the composers have access to timidity and freepats to check. I'll ask planetmaker first, since he appears to be coordinating openmsx :-)
11:44:51 <andythenorth> Eddi|zuHause etc.
11:45:22 <Ammler> blathijs: afaik, he only package it...
11:45:28 <Eddi|zuHause> the mime type is broken?
11:47:20 <blathijs> Hmm, seems openmsx also includes sampling plus material? That sounds weird for midi files..
11:47:29 <Ammler> blathijs: how can I see, which soundfont I am using?
11:47:39 <blathijs> Oh wait, it's dual licensed
11:48:25 <Ammler> yeah, the license is quite confusing...
11:48:50 <Ammler> pm likes to keep the option to chose the final license ;-)
11:49:04 <blathijs> Ammler: /etc/timidity/timidity.cfg should be able to tell you
11:49:06 <andythenorth> Eddi|zuHause: hmm....I missed some stuff out
11:49:37 <blathijs> Ammler: If you like to keep options open, just use the X11 license, or the WTFPL or something :-)
11:49:46 <blathijs> but GPL will do just fine :-)
11:50:04 *** ChanServ sets mode: +v tokai
11:50:08 <Ammler> blathijs: I fully agree with you. Tell that pm :-)
11:50:43 <peter1138> heh, timidity does not use soundfonts
11:51:07 <andythenorth> Eddi|zuHause: fixed
11:52:05 <blathijs> peter1138: Uh, what? I'm pretty sure it uses the freepats sound font here.
11:52:14 <peter1138> it uses freepats, it's not a soundfont though
11:53:00 <blathijs> What's the difference?
11:53:33 <peter1138> a soundfont is an sf2 file which contains all the samples
11:54:11 <peter1138> the pat files originated from the gravis ultrasound format
11:54:34 <peter1138> due to incredibly low memory only a few pats could be loaded at once
11:54:45 <peter1138> which is why they're separate files
11:57:20 <peter1138> freepats hasn't been updated since 2006
11:57:28 <peter1138> so it's quite likely that everyone has the latest version
11:59:13 <blathijs> peter1138: Yeah I saw that. One would have hoped freepats would be nearing completion after all this time, but instead development seems to have stalled...
12:00:19 <Ammler> suse package has quite some patches loaded with timidity
12:26:00 <HackaLittleBit> Rubidium: thanks :)
12:33:44 *** fonsinchen has joined #openttd
12:48:00 *** HackaBit has joined #openttd
12:54:35 *** HackaLittleBit has quit IRC
12:57:15 *** De_Ghosty has joined #openttd
13:22:57 *** Progman has joined #openttd
13:30:07 *** devilsadvocate has quit IRC
13:31:00 *** LadyHawk has joined #openttd
13:36:11 *** Biolunar has joined #openttd
13:36:15 *** fjb is now known as Guest1445
13:39:53 *** Chris_Booth has joined #openttd
14:02:05 <chungy> hey, is anybody aware of issues with the ipv6 services with openttd? It is very painful for me to browse the website or use the NewGRF in-game downloading service as the v6 connect just times out and I have to wait for it to fall back onto v4
14:03:18 <Rubidium> IPv6 seems to work fine
14:03:54 <Rubidium> what's usually the case is that you locally get an IPv6 and DNS resolves the IPv6 but there is no route from your IPv6 to the internet
14:04:34 <chungy> It's only an issue with OpenTTD though, I can reach other v6 sites just fine
14:09:10 <chungy> well it shows a 19th, 20th, and 21st hop by the time I pasted that ...
14:10:12 <Rubidium> so some routing-on-the-internet problem; not something we can fix :(
14:10:29 * peter1138 wonders if there's any ipv6 tunnel provider that will do bgp...
14:10:44 <Rubidium> I can reach your ipv6 google server
14:11:29 <chungy> well if you look at my irc hostname you can even ping6 me, should work fine
14:13:42 <chungy> ironically enough this actually works better on my laptop whose wifi driver totally hates anything ipv6 related (so I can only reach v4 from it)...
14:19:14 *** JVassie has joined #openttd
14:23:58 <Eddi|zuHause> in the german forum there's a feature request: conditional jump on timetable delay
14:25:13 <fjb> Bad busdriver leaving out stations when being late.
14:35:53 *** zachanima has joined #openttd
14:40:22 *** HackaBit has joined #openttd
14:42:16 *** Chruker has joined #openttd
14:56:08 *** FloSoft has joined #openttd
14:56:11 *** kannerke has joined #openttd
14:56:32 *** welterde has joined #openttd
14:57:00 *** LadyHawk has joined #openttd
14:57:55 *** Coco-Banana-Man has joined #openttd
15:14:05 *** Devedse has joined #openttd
15:20:51 <CIA-6> OpenTTD: yexo * r19450 /trunk/src/station_cmd.cpp: -Fix (r19197): animation callbacks for airport tiles where never called
15:21:08 <CIA-6> OpenTTD: yexo * r19451 /trunk/src/ (airport.h build_vehicle_gui.cpp table/airport_defaults.h): -Cleanup: remove some unused code
15:27:27 *** devilsadvocate has joined #openttd
15:43:09 *** stagger1 has joined #openttd
16:05:39 *** Chris_Booth is now known as Guest1457
16:05:41 *** Chris_Booth has joined #openttd
16:19:38 *** Rhamphoryncus has joined #openttd
16:27:57 *** Doorslammer has joined #openttd
16:35:06 <CIA-6> OpenTTD: rubidium * r19452 /trunk/src/ (lang/slovak.txt strings.cpp): -Change: plural type of Slovak (keso)
16:42:39 <HackaBit> Yexo: I saw it allready damned you were fast
16:53:07 <DorpsGek> andythenorth: I have not seen everyone.
16:53:24 <DorpsGek> andythenorth: seen [<channel>] <nick>
16:53:30 <DorpsGek> andythenorth: I have not seen the_light.
16:56:22 <fjb> What does "char[] string;" define?
16:57:14 <Rubidium> in that exact configuration in a struct?
16:57:36 <fjb> Don't know if that code is working.
16:58:35 <Rubidium> that's some sort of variadicly sized array (sized by the alloc of the struct)
16:58:42 <fjb> I just saw it while looking for a solution to have variable lenght structs.
16:58:46 <Rubidium> it must be at the end of the struct
16:59:02 <fjb> That is what I'm looking for.
17:03:09 <fjb> I will make a big, red cross in the calendar the day you do not do that.
17:10:08 *** Grelouk has joined #openttd
17:10:17 *** |Jeroen| has joined #openttd
17:11:38 *** frosch123 has joined #openttd
17:28:16 <DJNekkid> TrueBrain: isnt Bananas your work? There is no 1.0.0 RC3 option one can set on newgrf max/min versions
17:31:23 <TrueBrain> so .. you are trying to tell me I do a bad job, or how should I read this? :)
17:31:58 <DJNekkid> i were just wondering if that were to be included sometime soon? :P
17:32:38 <TrueBrain> either wat, RC2 == RC3, BaNaNaS wise :)
17:33:03 <DJNekkid> You see ... NuTracks isnt compatible with RC2, but it is with RC3 :)
17:33:32 <TrueBrain> so you need to enter a custom value I guess ;)
17:33:39 <TrueBrain> as you can see, RCs and Betas are never part of the dropdown
17:33:45 <TrueBrain> in fact, RC2 will become RC3 will become 1.0.0
17:34:03 <TrueBrain> well, that last part is not true I guess ..
17:35:01 * DJNekkid is already confused, about 3 times :)
17:35:47 <TrueBrain> 1.0.0 will have the release flag set
17:36:03 <TrueBrain> (0x10000000 vs 0x108000000 (don't mind the tailing zeros, I am too lazy to count :p)
17:36:04 <Rubidium> you need to use the custom version and then the decimal newgrf version of RC3 as minimum
17:37:02 <TrueBrain> either way, DJNekkid, last time I explained to Rubidium how he can do the versioning, so I guess you should ask him about the rest ;)
17:37:26 <Rubidium> ohlala... 8 million bananas downloads... it's growing quicker ever week
17:37:54 <Ammler> i would assume, it is the same as you have in the nfo code...
17:38:02 <Rubidium> TrueBrain: he should just use the custom version thing
17:38:13 <DJNekkid> i guess i'll just set it to nightlies, and give a note, and when 1.0.0 hits the road, i'll edit it and set it to that...
17:38:54 <Ammler> hmm, but 1.0.0 will include RC2 :-)
17:39:09 <Rubidium> or no, if the 'release' bit is correct
17:40:05 <Yexo> 10004BF7 <- DJNekkid set that as custom version to have RC3 as minimum
17:43:48 <Ammler> confusing, why is RC2 in the version menu, but RC3 can't?
17:48:21 <fjb> Because you don't have to repeat mistakes? :-)
17:49:55 <Ammler> well, that is just GUI, internally those are saved "right" already, I would guess...
17:51:52 <DJNekkid> Yexo: 10004BF7 tell me:"invalid value"
17:52:02 <andythenorth> new route type: "flying air cushion vehicles"
17:52:07 <Ammler> DJNekkid: convert to dec
17:52:42 <Yexo> oh right, I forgot the custom field needs a decimal value
17:53:29 *** openttnoob has joined #openttd
17:54:59 <andythenorth> is there a quick way to compile if I've only changed a lang file?
17:55:29 <Rubidium> it should only recompile the language file
17:55:43 <Rubidium> telling you how to run strgen manually takes way way longer
17:55:57 <andythenorth> so 'make bundle' is not my friend in this case
17:56:16 <openttnoob> For installing opengfx/opensfx do I just toss them in a folder then install openttd in same folder?
17:56:35 <Rubidium> openttnoob: the data sub folder
17:57:02 <Rubidium> andythenorth: oh, you're using the bundled OS X binary... that complicates things even further
17:59:55 <Ammler> ah, that explains, why you had troubles to start openttd from console ;-)
18:01:08 <Ammler> andythenorth: afaik, bundling openttd isn't a requirement, you should be able tun "unbundled" openttd
18:01:37 <Rubidium> Ammler: should, yes... but Bjarni wrote/tested that part :(
18:02:15 <Ammler> pm does it that way...
18:03:20 <Rubidium> yeah, but... he said the lzo stuff worked and others said it didn't. So what works for one on OS X does not necessarily work for the others.
18:11:57 <HackaBit> peter1138 have a look at FS#3304 pls there you can see the result of my TIC TOC exercise
18:13:35 *** Terkhen has joined #openttd
18:15:24 <HackaBit> I have to go now to pick up the kids :), bye
18:20:17 <peter1138> that really fucking annoys me
18:37:27 *** waldtroll has joined #openttd
18:38:45 <CIA-6> OpenTTD: yexo * r19453 /trunk/src/ (aircraft_cmd.cpp airport.cpp airport.h): -Codechange: split getting the initial aircraft position to a new function
18:45:33 <CIA-6> OpenTTD: translators * r19454 /trunk/src/lang/ (6 files in 2 dirs): (log message trimmed)
18:45:33 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:33 <CIA-6> OpenTTD: czech - 3 changes by Hadez, TheLamer
18:45:33 <CIA-6> OpenTTD: frisian - 4 changes by Fopper
18:45:33 <CIA-6> OpenTTD: greek - 6 changes by fumantsu
18:45:34 <CIA-6> OpenTTD: hebrew - 2 changes by dnd_man
18:45:34 <CIA-6> OpenTTD: indonesian - 3 changes by prof
19:09:59 *** waldtroll has joined #openttd
19:12:59 *** ChanServ sets mode: +v tokai
19:34:28 *** ajmiles has joined #openttd
19:39:54 * andythenorth ponders something
19:40:10 <andythenorth> implement industry cb 14B for all the wrong reasons
19:40:26 <andythenorth> or leave something in place that might once in a blue moon blow up
19:40:51 <Eddi|zuHause> i thought you like blowing things up
19:41:03 <Eddi|zuHause> why do you do it so often, then? :)
19:41:03 <andythenorth> I like mentioning it on irc
19:41:31 <andythenorth> in this case the 'blow up' is rather limited in scope
19:41:42 <andythenorth> it might lead to an industry closing that shouldn't, or vice versa
19:42:18 <Yexo> what has cb 14B got to do with industry closing?
19:42:38 <Terkhen> people already complain when industries close normally
19:43:00 <andythenorth> Yexo cb 14B and 14C are the only industry cbs I can see that run when an industry is built
19:43:06 <Zuu> Yexo: Is there a keyword/global variable like "this" that refer to the library (main) class inside a library?
19:43:16 <andythenorth> (and I need to stick some values in a register when an industry is built)
19:43:20 <Zuu> Not the object, but the class type.
19:43:55 * andythenorth discovers cb 14A as well
19:44:07 <Zuu> I seem to need that, otherwise cyclic dependancies between my child classes will not work unless people put them at pre defined places in the global scope.
19:44:21 * andythenorth has a feeling those cbs might not be able to use registers / storage anyway, as the industry may not be built yet
19:45:21 * andythenorth decides to ship code that has potential for a weird edge cae
19:45:34 * andythenorth discovers a logical flaw in his thinking
19:46:01 <andythenorth> industries don't close immediately. grrr
19:46:14 <Zuu> Perhaps the best solution is just to put the "child" classes at global scope under a fairly unique name.
19:46:17 <andythenorth> this means the industry count idea is useless :|
19:46:26 * andythenorth returns to his drawing board
19:46:34 <Zuu> At least if you want to be 1.0 compatible.
19:46:40 <Yexo> andythenorth: if you use one bit of the persistant storage as flag "industry is initialized" then you can run the iniitalize code only the first time
19:47:17 <Yexo> Zuu: why do you need to access the name of the main class anyway?
19:47:50 <Zuu> Not the main class itself, but through its static members I can access the sub classes.
19:48:09 <Yexo> I fail to see the problem then
19:48:29 <andythenorth> Yexo: I can't see any good cb to run the initialisation though. Hmmm. Text window cb is probably run quite often?
19:48:33 *** ajmiles2 has joined #openttd
19:48:50 <Zuu> Hmm, is SuperLib a valid name of the main class type even if a library user has renamed it?
19:48:57 <Yexo> andythenorth: doesn't matter which callback it is, just run it in the first one that happens
19:49:13 <Yexo> text window cb is only run when the window is open
19:49:27 <andythenorth> Yup :) But I still have to choose which cb that is
19:49:39 <andythenorth> Probably just production cb I guess
19:49:47 <Yexo> andythenorth: why? just check for initialization bit before you check which cb it actually is
19:50:05 <andythenorth> Yexo: that is the kind of thinking that gets cookies
19:50:05 <Zuu> Hmm, how is then the problem non-existent?
19:50:34 <Yexo> Zuu: I never said it was non-existent, I just don't understand what you're trying to achieve so what the problem actually is
19:50:43 <Yexo> a small code example could help
19:54:43 *** Biolunar has joined #openttd
19:54:49 <andythenorth> Eddi|zuHause: your method for industry closure (don't allow more than one of same types to close within a certain period)....
19:55:02 <andythenorth> ...would work brilliantly, but I can't see a way to implement it :|
19:55:28 <andythenorth> I thought I had it, but I made a silly mistake
19:56:18 <Eddi|zuHause> it certainly would be easier with global registers
19:56:31 <andythenorth> as would many other things
19:56:40 <andythenorth> like....electricity :)
19:56:44 <Yexo> global registers are too prone to abuse
19:56:57 <Yexo> like an industry grf using the same global registers as a houses newgrf
19:56:58 <Eddi|zuHause> grf-local global registers
19:57:12 <andythenorth> Yexo: definitely grf-local
19:57:28 <andythenorth> an advanced varaction 2 to write grf parameters would do it
19:57:55 <andythenorth> hmmm....am I missing something obvious about offsetting industry counts by one additional month
19:58:09 * andythenorth reaches for a pencil
20:00:30 *** ajmiles3 has joined #openttd
20:00:47 <Yexo> Zuu: I see no way around that except splitting it in multiple libraries
20:01:40 * andythenorth offers the view that improved industry closure should be handled by the game, not crazy nfo
20:02:43 <Zuu> Which breaks cyclic dependencies. Which in my opinion is not an option. Then I rather put my sub-libraries under almost unique names at global scope.
20:02:58 <Ammler> andythenorth: how do default industries "close"?
20:03:08 <Yexo> Zuu: the superlib you uploaded at the forum doesn't have cyclic dependencies
20:03:24 <Eddi|zuHause> Ammler: 5 years protected and then close almost at the same time
20:03:41 <andythenorth> 'extinction wave'
20:03:45 <Yexo> Zuu: Tile dpends on Helper, Direction depends on both Tile and Helper
20:03:52 <Yexo> at least from what I've seen
20:04:04 <Zuu> GetTileRelative gives problem.
20:04:28 <andythenorth> Ammler extinction wave is what I'm trying to prevent, but can't because there is no fricking way to communicate between industries or any kind of global storage
20:04:36 <Yexo> Zuu: why? it's part of Direction and as I said Direction depends on Tile
20:04:43 <andythenorth> *and* industries don't close 'this month' but next :\
20:04:44 <Zuu> It was solved in the Utils.* libs by duplicating that function so that not Direction and Tile depend on each other in both directions.
20:05:04 <Zuu> Tile depends on Direction as well.
20:05:14 <Zuu> Because Tile needs GetTileRelative.
20:05:24 <Yexo> oh, Tile used Direction.GetAdjacentTileInDirection indeed
20:05:27 <Ammler> I didn't have that feeling, the only annoying part was that power plants don't close.
20:05:27 <Yexo> didn't see that the first time
20:06:10 <Eddi|zuHause> Ammler: if power plants were allowed to close, they'd close all the time because they don't produce anything
20:06:56 <andythenorth> Eddi|zuHause: I am planning to close power plants, but that's a side issue to the main show here
20:07:07 <Zuu> Its okay, its not easy to keep track of everything in someone else' code.
20:07:30 <Eddi|zuHause> andythenorth: yeah, that's possible if you make the protection period dependent on incoming cargo
20:07:45 <andythenorth> got working code for that
20:07:58 <andythenorth> this is frustratingly close to being good
20:07:59 <Eddi|zuHause> that's certainly not a problem :)
20:08:09 <Zuu> I think that if the choice is between requiring people to name the libs exactly like I do or not using _long_uncommon_name globaly then the later is better.
20:08:57 <Yexo> Zuu: a workaround like this works
20:09:23 <Yexo> it does put the classes in the global scope but under a prefixed names so they won't class with any other libs names or any global vars used in an AI
20:10:12 <andythenorth> Eddi|zuHause: my code (when debugged) will prevent industry closing in consecutive months...but
20:10:28 <andythenorth> not several industries of same type closing in same month
20:10:47 <Zuu> Yexo: Indeed that was my idea, to prefix the names by the library name.
20:11:11 <Zuu> If you want to go on extreme I can use sed to rename them to very very long names. :-)
20:11:31 <Yexo> prefixed with the lib name should be enough
20:12:49 <Zuu> Is require(..) just a plain inline include? Ie could I put the different sub libs in your workaround in different files and eliminate the need of a combine script?
20:12:51 <Yexo> the main library classes are renamed by openttd to _internalNA<number>, where <number> is just a counter on the number of libraries
20:13:00 * andythenorth holds his horse a minute
20:13:10 <Yexo> Zuu: it's not a plain include, but it should work
20:13:26 <Yexo> but enums might not work correctly as they are resolved compile time
20:13:52 <Yexo> first the main file is compiled, then executed (when a file is executed everything in the global scope is done and all requires are done)
20:14:02 <Zuu> Oh, yea the enums.. haven't been using them since I learned about the problems and then I've forgot about the problems with them. :-)
20:14:03 <Yexo> when a require() call is executed that file is compile
20:14:16 <Yexo> so you can't use an enum defined in a required file in main.nut
20:14:47 <Zuu> And not from another required file that gets required later by main.
20:15:15 <Yexo> if you do requir("a.nut"); require("b.nut"); then b.nut can use enums defined in a.nut
20:15:19 <Yexo> but not the other way around
20:17:00 <Zuu> Okay, then hopefully this is (conceptually) resolved then.
20:17:18 <DJNekkid> what would be a good eletrified narrow guage ID?
20:21:23 * andythenorth ummm why would the xy co-ordinate of an industry increment every few days? I've done something wrong haven't I :|
20:23:16 <Eddi|zuHause> something just dawned to me: Ubuntu is the AOL amongst the linuxes
20:24:09 * andythenorth sort of gives up on industry closure. bleargh
20:24:35 <Eddi|zuHause> that thought will probably be the cause of my nightmares for the next decade...
20:25:49 <Hirundo> andythenorth: There's nothing wrong, as long as your reference frame is moving at a constant rate with respect to the industry you're fine
20:26:27 <Zuu> I guess my task will then be to write a bit on the wiki about how to make a library :-D
20:29:10 * andythenorth looks at 'related objects'. Maybe there's something unique there
20:30:01 *** ajmiles has joined #openttd
20:30:27 <andythenorth> Town Index....that looks unique enough
20:30:53 <Eddi|zuHause> how should the town index be unique?
20:31:09 <andythenorth> unique *enough* :)
20:31:21 <Yexo> andythenorth: in openttd the town index is not limited to 0..69, it can even be bigger then 255
20:31:24 <DJNekkid> great work peter1138 (i assume), if the laying cost of a track is lower then removal cost, the removal wont bring in more money :)
20:31:45 <andythenorth> if there is more than one industry per town, then there remains a chance of them closing at the same time, but otherwise I can spread them using the town index
20:33:10 <peter1138> global registers are grf local, right?
20:33:23 <andythenorth> ummm....what global registers?
20:33:49 <andythenorth> the ones we have that are hidden somewhere, or the ones we're going to add :)
20:34:07 <peter1138> dunno, i skimmed a bit but didn't bothered reading it all :p
20:34:12 <Eddi|zuHause> they would need to be, if they existed...
20:34:22 *** Hyronymus has joined #openttd
20:34:24 <andythenorth> shall we make them exist?
20:34:27 <peter1138> also, registers should not be modifiable from gui callbacks
20:35:02 <Eddi|zuHause> but that's the same for industry persistent storage
20:35:21 <Yexo> peter1138: currently the persistent storage already breaks that (it can be modified from gui callbacks)
20:36:30 <andythenorth> how many global registers should we have?
20:37:06 <Rubidium> peter1138: no, global registers aren't grf local; they're cleared every tick/command though
20:37:07 <Eddi|zuHause> whatever number it is, people are going to complain :)
20:37:40 <Eddi|zuHause> Rubidium: the request is for persistent global registers :)
20:37:53 <peter1138> i don't even know what we're talking about now :D
20:37:56 <andythenorth> 16 would be enough for most newgrf purposes. dword sized. we can use crazy bit map stuff if we need to pack more in
20:38:33 <peter1138> industries alreayd have persistent storage don't they?
20:38:37 <peter1138> is that not usable?
20:38:43 <Rubidium> cause in like 2 days they want to be able to read/write in the global registers of another NewGRF
20:38:50 <andythenorth> it's perfectly usable.
20:38:52 <Eddi|zuHause> yes, they have, no, it can't be accessed from different industries
20:38:56 <andythenorth> it just doesn't solve the problem
20:39:08 <Rubidium> because the ECS stuff must be able to communicate with eachother and such
20:39:21 <Eddi|zuHause> Rubidium: that can never happen.
20:39:34 * andythenorth three suggestions
20:39:42 <andythenorth> 1. persistent global registers (grf local)
20:39:53 <andythenorth> 2. write to existing grf parameters with advanced varaction 2
20:40:01 <Eddi|zuHause> Rubidium: except you allow setting a GRFID as parameter for reading the variables
20:40:07 <andythenorth> 3. fix industry closure in the game and this might go away
20:40:38 <Rubidium> Eddi|zuHause: doesn't that like happen already?
20:41:02 *** zachanima has joined #openttd
20:41:37 <Eddi|zuHause> Rubidium: i don't know what you mean
20:43:52 <Rubidium> i.e. query the GRF ID associated with a given house
20:47:46 <andythenorth> forgive me for being a dumbass, offset 00 in 80+ variables....does give me *var 80* right?
20:48:51 <Yexo> except for vehicles where offset 10 is var 80
20:54:34 * andythenorth thinks "logical flaws be damned, first lets ship the fucker and see what works"
21:02:46 <CIA-6> OpenTTD: yexo * r19455 /trunk/src/ (23 files in 4 dirs): -Codechange: split all airport information in Station to a seperate class
21:03:46 <Belugas> better than fuck the shipper and ...
21:09:52 *** goblin_ has joined #openttd
21:09:59 *** welterde has joined #openttd
21:11:29 *** goblin_ has joined #openttd
21:23:33 * andythenorth spends an exciting 20 minutes watching the values of persistent storage change in 5 industry windows
21:23:45 <andythenorth> but in real time dammit, *real time*. Thanks Yexo :)
21:26:32 *** frosch123 has joined #openttd
21:28:51 <andythenorth> hmm. that's controversial :|
21:29:47 <andythenorth> I am using monthly production change cb at each industry to count other industries. An industry just closed. I'm getting a count of 4 at some industries and 5 at others
21:29:53 <andythenorth> not unexpected, but unhelpful :o
21:30:16 <andythenorth> or rather, unexpected, but I can see how that happens :|
21:34:18 <Eddi|zuHause> monthly cb is run in the tileloop, right?
21:34:40 <Eddi|zuHause> no, that does not make sense
21:36:36 <Eddi|zuHause> err... this "Sweeney Todd" movie is insane...
21:37:56 * andythenorth is looking for volunteers :)
21:38:07 <andythenorth> this is fun, but if anyone else wanted to help test...
21:38:11 * Rubidium volunteers andythenorth
21:39:15 <andythenorth> my code just closed a power station. the game then built a new one in the same town 9.9
21:40:38 <OwenS> andythenorth: Any reason your power stations are all bigger than normal?
21:41:24 <andythenorth> umm. they are standard layouts from default TTD. the industry window is *much* bigger
21:41:34 <andythenorth> which do you mean?
21:41:53 <OwenS> andythenorth: They contain moire units than the average TTD power station
21:43:10 <andythenorth> well this seems to work
21:44:30 <andythenorth> quite a few of you have been most helpful with this industry code :)
21:44:40 <andythenorth> notably Eddi|zuHause frosch123 and Yexo so thanks
21:44:46 *** V453000 has joined #openttd
21:45:01 *** Drunkzilla has joined #openttd
21:45:19 <andythenorth> and Rubidium and peter1138
21:45:27 <Drunkzilla> Hi, can I ask something? :)
21:45:42 <Eddi|zuHause> yes, but your free question just expired.
21:45:53 * andythenorth would also like to thank his mother, his teachers....
21:45:59 <Eddi|zuHause> next question is 10€
21:46:07 <Drunkzilla> So I'll continue.. send me your account number later :d
21:46:14 <Drunkzilla> Can I (and how) change *net_frame_freq?
21:46:14 <Rubidium> Eddi|zuHause: to pay to Georg Cantor?
21:46:44 <Drunkzilla> Is it hidden or renamed?
21:46:53 <Drunkzilla> I wouldn't be asking, if that parameter were there...
21:47:02 <Eddi|zuHause> frame_freq in [network] or something
21:47:34 <Drunkzilla> It's not in mine openttd.cfg :x
21:47:43 <Yexo> it should be under [network]
21:47:44 <Drunkzilla> Is it something newer?
21:48:00 <Rubidium> might be it doesn't show its "face" by default
21:48:10 <Drunkzilla> Maybe I have some older version? I started with installer of 0.7.5 .. and then newer versions just with .zip
21:48:26 <Zuu> IIRC the grf spec describes how the custom OpenTTD version at BaNaNaS work. Do someone know where at the ttdpatch.net wiki this is found. Searching the wiki for "version" is not of much help. :-(
21:48:27 <Drunkzilla> well.. I guess that I can just add that line?
21:48:37 <OwenS> Drunkzilla: [network]frame_freq
21:48:43 <Rubidium> Zuu: specs, action 7/9
21:48:44 <Zuu> Or if someone know the version string for 1.0 or nightly that is okay as well. :-)
21:49:18 <Yexo> Zuu: for nightly: revision number + 0x1100000
21:49:27 <Rubidium> I don't know the version string for 1.0.0 yet
21:49:36 <Drunkzilla> OwenS: thanks, but it really isn't there... Ctrl+f 'frame' or 'freq' and no results... eye check = no results
21:49:56 * andythenorth decides industry code is a mini-exercise in complexity theory for autonomous agents that can't communicate with each other
21:49:58 <Yexo> Drunkzilla: try "net_frame_freq" in the console
21:50:05 <Yexo> add a value after it to change it
21:50:15 <Zuu> Ok, but if I use the version string for the nightly version when 1.0 branch was created will that work when 1.0 is released and possible even now with RC3?
21:50:38 <Drunkzilla> Yexo: current value is 0 .. so I suppose OTTD know the value, but doesn't show in config..
21:50:40 <Yexo> all later versions will have a higher version number
21:51:09 <Yexo> Drunkzilla: then change it by doing "net_frame_freq 10" in the console and see if it then shows up in the config file
21:51:27 <Drunkzilla> its not in config.. but its changed in console
21:51:34 <Zuu> Is it correct to assume that the branch was created when the 1.0.0-beta1 tag was made? (that is 18623)
21:51:39 <Yexo> and if you exit openttd now and start it again?
21:51:59 <Yexo> Zuu: some days before RC1
21:52:01 <Eddi|zuHause> Zuu: the branch was before RC1
21:53:51 * andythenorth wants to post "boom" every time an industry closes in a sane way. Think you might kick me though :o
22:00:13 *** Drunkzilla has left #openttd
22:03:16 <Zuu> If I want to set 19008 as minimum revision. Shall I do Dec(Hex(19008) + x11000000)?
22:03:58 <Rubidium> you want it only for nightlies since r19008?
22:04:12 <Zuu> nightlies and stables since then.
22:04:59 <Rubidium> use 0x10000000h + 19008d
22:05:14 <Rubidium> because that means 1.1 and later
22:05:47 <Rubidium> and for bananas you want to convert that number to decimal
22:07:42 <andythenorth> Terkhen: could you tell me the version of OTTD and FIRS?
22:07:42 <Zuu> Thanks. If anyone is intrested it becomes 268454464 in dec.
22:08:03 *** Progman has joined #openttd
22:08:51 <Terkhen> OpenTTD r19454, FIRs r621
22:10:36 <andythenorth> Hmmm prop 24 for junkyard is 0
22:10:45 <andythenorth> (prop 24 is station name)
22:10:48 <andythenorth> "Setting this to zero disables "\80 Oilfield" and "\80 Mines" without adding any additional station name options."
22:11:24 <Zuu> :0 SuperLib has been downloaded once by me, but 4 times by others without there being any AI up until a minute ago that used it. :-)
22:11:30 * andythenorth wonders if it is a FIRS bug, or an OTTD bug, or a newgrf spec bug?
22:11:37 <Zuu> CluelessPlus has one download (me)
22:15:34 <andythenorth> it's five years since game start, and all the secondary industries die. *Except* my power plants. And I shall rule etc etc. :D
22:17:54 <Eddi|zuHause> andythenorth: small tip. make a savegame at 4 years 10 months, and make your tests from that.
22:18:19 <andythenorth> Eddi|zuHause: no real need, I control my own 'protection' period, and it's set to 1 month right now :)
22:44:05 *** goblin_ has joined #openttd
22:44:38 *** Adambean has joined #openttd
23:14:54 <CIA-6> OpenTTD: yexo * r19456 /trunk/src/ (airport.h newgrf_airport.cpp table/airport_defaults.h): -Codechange; increase the maximum number of airports
23:15:26 <CIA-6> OpenTTD: yexo * r19457 /trunk/ (12 files in 5 dirs): -Codechange: introduce AirportOverrideManager to keep track of airports if a newgrf can't be found
23:15:37 <CIA-6> OpenTTD: yexo * r19458 /trunk/src/saveload/airport_sl.cpp: -Fix (r19457): svn add the new file
23:16:01 <CIA-6> OpenTTD: yexo * r19459 /trunk/src/newgrf.cpp: -Feature: make some airport properties modifyable by newgrfs
23:17:40 <Yexo> Eddi|zuHause: min/max available year, catchment area, noise level and name
23:17:58 <Yexo> no new tile layouts, no new statemachines
23:18:44 <dih> still - it's heading a nice way ;-)
23:20:13 <Eoin> new airports made it to nightly?
23:20:31 <Zuu> So we can at least say that we got NewGRF influenced airports. :-p
23:20:33 <Eoin> i cant remember the technical name :P
23:20:48 <Zuu> Eoin: Not in the way you probably think.
23:21:06 <Zuu> NewGRFs can change a few properties of existing airports.
23:21:46 <Zuu> Well, don't be so disapointed. Give Yexo a high five for his work :-)
23:22:08 <Yexo> Eoin: just give me some more time :)
23:22:40 <Yexo> new tilelayouts / rotations for the default airports is now pretty easy to add
23:22:48 <Zuu> Exactly, as someone said "patchces are like wine - they need long time to become good"
23:23:53 <dih> Zuu, and some wine sucks :-D
23:24:02 <Eoin> and then its only a matter of time before NewAirports!
23:24:39 <Rubidium> Zuu: and once sour, you can't fix them?
23:25:18 <Zuu> (=hope that they can be fixed)
23:25:42 <Zuu> But maybe you need to rewrite them then.
23:27:24 <CIA-6> OpenTTD: rubidium * r19460 /trunk/src/pathfinder/npf/npf.cpp: -Fix [FS#3703]: [NPF] Crash when finding a waypoint before finding the closest depot
23:28:29 <Rubidium> Zuu: ah, the equivalent of making new wine :)
23:41:51 *** De_Ghosty has joined #openttd
23:42:24 <CIA-6> OpenTTD: yexo * r19461 /trunk/src/station_cmd.cpp: -Fix (r19355): p1 was still used in two places
23:59:13 *** Brianetta has joined #openttd
continue to next day ⏵
