Log for #openttdcoop.devzone on 19th March 2010:
Times are UTC Toggle Colours
00:11:30  <Hirundo> Hmm.. patch queues trigger some horribly inefficient recompiling on MSVC
00:19:08  <Rubidium> odd; it seems to be quite reasonable with that
00:21:05  <Webster> Latest update from devactivity: Infrastructure Sharing - Feature #704 (Closed): DeleteVisibleTrain use signal buffer <> || Infrastructure Sharing patches - Revision 8: [feature #704] DeleteVisibleTrain now uses the signa... <> || Infrastructure Sharing patches - Revision 7: Update to trunk r19456 <>
00:21:12  <Hirundo> Problem is that going back and forth in the queue modifies various header files or even the project file
00:21:36  <Rubidium> then use ccache :)
00:21:43  <Rubidium> but MSVC doesn't have that
00:22:59  <Hirundo> cygwin probably has, but openttd won't compile there
00:23:45  <Rubidium> yeah... never got cygwin working properly in my VM, so never even tried to get OpenTTD compile in it
00:25:02  <Ammler> mingw/msys?
00:25:24  <Rubidium> that works
00:25:41  <Rubidium> (with some ancient version of mingw)
00:26:13  <Ammler> well, at least the version documented here should work
00:26:40  <Rubidium> 1.0.10, right?
00:27:12  <Ammler> yes
00:27:23  <Ammler>
00:28:06  <Ammler> I used wiki last time but that is now a year ago
00:28:26  <Rubidium> lovely... 1.0.10 works, but probably not on Windows 6.x. 1.0.11 probably works on Windows 6.x but has a totally broken patch
00:30:13  <Ammler> he, there was 5 years no release
00:30:34  <Ammler> almost 6
00:32:14  <Rubidium> xmms is more fun :)
00:32:24  <Rubidium> releasing 1.2.11 1211 days after 1.2.10
00:35:24  *** KenjiE20|LT has joined #openttdcoop.devzone
00:35:29  *** KenjiE20 has quit IRC
00:40:27  <Hirundo> Rubidium: Is there any specific reason why memcmp/memset are generally used instead of MemCmpT/MemSetT ?
00:41:55  <Rubidium> is "time" specific enough?
00:45:03  <Hirundo> It's not just in 'legacy' code IIRC
00:45:12  <Rubidium> memcmp/memset are there for a long "time", MemCmpT and MemSetT only for a short "time". The person that had the "time" to introduce the templated functions apparantly did not have the "time" to finish it.
00:46:47  <Hirundo> memset(&AirportSpec::specs, 0, sizeof(AirportSpec::specs)); <- I guess this is pretty recent code :)
00:48:15  <Rubidium> yeah, but "copied" from industries or so
01:07:16  <Webster> Latest update from devactivity: Infrastructure Sharing - Feature #5: Split patch <> || Infrastructure Sharing - Feature #4 (Closed): revert #define SL_IS <> || Infrastructure Sharing patches - Revision 9: Feature: Separate expense types for sharing costs an... <>
01:08:27  <Hirundo> Rubidium: Given that public airports may be coming into trunk, would a patch for be of any use?
01:22:46  <Webster> Latest update from devactivity: Infrastructure Sharing - Feature #670 (Closed): Basic version <>
02:51:40  *** KenjiE20|LT has quit IRC
06:32:53  *** Seberoth has quit IRC
07:20:42  *** ODM has joined #openttdcoop.devzone
08:35:39  *** ODM has quit IRC
08:38:50  *** ODM has joined #openttdcoop.devzone
08:59:34  *** Doorslammer has joined #openttdcoop.devzone
09:08:41  *** DJNekkid has quit IRC
09:35:27  *** DJNekkid has joined #openttdcoop.devzone
10:04:47  *** Doorslammer has quit IRC
10:43:58  <Webster> Latest update from devactivity: OpenGFX - Bug #669 (Closed): Recolor: remove magic brown <> || OpenGFX - Bug #668: bubble generator building stage <> || OpenGFX - Support #678: Rewrite <> || OpenGFX - Bug #77 (Closed): town building misalignment <>
10:45:58  *** ODM has quit IRC
11:01:32  *** KenjiE20 has joined #openttdcoop.devzone
11:32:06  <Webster> Latest update from devactivity: OpenGFX - Bug #668: bubble generator building stage <> || OpenGFX - Bug #668: bubble generator building stage <> || OpenGFX - Bug #668: bubble generator building stage <>
11:37:42  *** Doorslammer has joined #openttdcoop.devzone
12:41:25  <Ammler> <-- planetmaker: 100& done :-)
12:46:53  <Hirundo> Rubidium: Given that public airports (attached to industries) may be coming into trunk, would a patch for  be of any use?
12:47:43  <Rubidium> I'm not quite sure about that
12:48:41  <Hirundo> It's in the newgrf ports branch, as far as I can see
12:48:59  <Rubidium> you're talking about adding 112 bytes to a 24 byte structure
12:49:35  <Hirundo> My patch would add a pointer and a byte per cargo packet
12:49:45  <Rubidium> which easily means adding 8 MiB to (loaded) savegame size
12:50:03  <Hirundo> Effectively storing the 'history' of the packet in a singly linked list
12:50:40  <Rubidium> 65535 packages is easily reached (openttdcoop reached it within hours)
12:51:08  <Hirundo> I know, the limit is set to 1M for a reason
12:51:42  <Rubidium> linked lists with packet history are easily exploited by ferrying cargo back and forth thus causing a denial of service attack
12:51:44  <Webster> Latest update from devactivity: OpenGFX - Bug #781: farm hedges not properly aligned <>
12:52:44  <Hirundo> DoS as in - emptying the packet history pool?
12:53:29  <Rubidium> well, more like filling the pool
12:54:12  <Hirundo> Right, that's what I meant
12:55:26  <Hirundo> Could limit the history to 1 entry per company, though, so if I transfer back and forth, the distance gets added to the existing entry (up to UINT32_MAX)
12:59:46  <Rubidium> even then, how fair is it to use the transported distance? It makes it much easier to screw another (smaller) company by slowing the cargo delivery significantly/letting it take a huge detour on your end; e.g. if A moves it 95% of the way and then B moves it back 200% before finally delivering it, then B gets ~80% of the income, A only 20%. In this case A is being seriously screwed
13:00:28  <Rubidium> because either their income comes much much later, or because income gets removed later on
13:01:06  <Rubidium> also what in the case where cargo packets are 'lost'? Either by huge queues at station or by crashing/selling! vehicles?
13:02:32  <Hirundo> When it's lost, just delete the history along with them, I wouldn't share it between packets since memory management would become extremely fishy
13:03:12  <Rubidium> but gets the previous transporter paid for their work?
13:03:38  <Hirundo> No
13:04:29  <Hirundo> That would be unfair (nothing is ever delivered) and trivially exploitable, I think
13:04:33  <Rubidium> so by just leaching off a reasonably large share of you competitors almost finally delivered cargo you can let them pay for the transport but they never see the money
13:05:50  <Hirundo> And that competitor will soon decide to deliver their cargo to a different location
13:06:25  <Rubidium> *if* they can find out where the cargo gets "stolen"
13:07:04  <Rubidium> the whole "moving cargo between companies" opens a huge can of worms
13:07:24  <Rubidium> and almost every way is exploitable
13:08:37  <Hirundo> Regarding transported distance, currently the location where a *company* picks up cargo and drops it is counted, so moving back and forth won't help without at least one competitor to aid you
13:09:24  <Hirundo> 'Currently' = in the patch
13:11:01  <Hirundo> Even then, the total payment does not change, so you can't become an instant millionaire, but getting more than your 'fair share' is hard to prevent
13:11:02  <Rubidium> okay, imaging A picking up oil in the south of the map with a ship, going very slowly (and cheaply) to the north of the map, moving the cargo to a shared station. Then another company ships the oil in a maglev to the other side of the map. Both cover roughly the same distance. How is the payment going to be done?
13:11:34  <Hirundo> roughly 50/50 then
13:11:36  <Ammler> I don't understand, why you care about companies exploit each other
13:12:36  <Hirundo> In any case, exploitation will be more work (moving cargo around costs money, too) than in the current system, where everyone but the last is only paid fake money
13:13:08  <Rubidium> true
13:13:41  <Rubidium> but saying you "fix" the problem when you just change the problem's characteristics slightly isn't that useful I'd say
13:14:59  <Hirundo> I agree, no solution is better than a half-assed solution
13:15:30  <Hirundo> Then again, how to measure 'fair share'?
13:17:23  <Hirundo> The transfer mechanism as-is is basically broken
13:18:52  <Rubidium> when staying within a single company it's not that broken, at least concerning final payment
13:19:53  <Hirundo> I wouldn't call the 'feeder share %' setting a nice solution for the transfer troubles
13:20:18  <Rubidium> when multiple companies are moving cargo then any transfer mechanism that doesn't have some sort of prearranged contract about how the payment is going to be split, what happens if payments are less and such (i.e. how losses are split)
13:21:31  <Rubidium> Hirundo: the partial payments/feeder share are there *purely* for making it possible to reach a 1000 performance points.
13:22:17  <Hirundo> In this case, prearranged contract = 'each gets a share proportional to transported distance'
13:22:20  <Webster> Latest update from devactivity: OpenGFX - Revision 370: Change [#820]: splitted logos <>
13:22:21  <Rubidium> well, and a bit to give an estimate-ish of how vehicles are doing without having to resort to those contracts needed to split the profit/loss
13:24:24  <Rubidium> Hirundo: but what with losses
13:24:45  <Rubidium> that's the whole point that is most exploitable
13:24:56  <Hirundo> Which losses? I have never received negative money when doing final delivery
13:25:13  <Rubidium> Hirundo: but *what* if final delivery never happens?
13:25:56  <Hirundo> Then no-one gets any money
13:26:18  <Rubidium> but shouldn't the company losing the money be punished for that?
13:26:35  <Rubidium> s/money/cargo/
13:26:44  <Hirundo> When a station is used by multiple companies, who is the one to blame?
13:27:24  <Rubidium> the company dropping the cargo there
13:27:48  <Rubidium> hmm, although... yes... that could be exploited too
13:28:05  <Hirundo> dumping thousands of pax into rural stations?
13:28:57  <Rubidium> which comes back to the point that moving cargo between companies is a huge can of worms
13:29:32  <Rubidium> with many many possible exploits that will annoy people on multiplayer games
13:30:29  <Hirundo> I think that general market mechanics would work quite well
13:31:01  <Hirundo> i.e. players will not cooperate with others that try to claim a bigger share
13:31:23  <Rubidium> Hirundo: in 99% of the cases, yes probably. But the 1% of the cases where someone exploits it ruins the game for everyone
13:31:51  <Rubidium> e.g. the "free money" exploit with shares, it easily spoils the game for all players
13:32:32  <Hirundo> When the total payment, that is, the total amount of money injected into the game, when that doesn't change....
13:33:12  <Ammler> Rubidium: you really think, it is possible to make "infra sharing" in competive way?
13:33:31  <Hirundo> Then I don't see how people could suddenly make millions at the expense of others, without deducting money from their bank accounts
13:34:12  <Rubidium> Hirundo: but they can make people lose lots of money without a simple way of seeing where the problem happens
13:35:05  <Hirundo> The problem I imagine is this...
13:35:24  <Hirundo> Company A brings pax to public airport / station
13:35:39  <Hirundo> Company B transfers it to the other side of the map for no reason
13:35:49  <Hirundo> Company C transfers it back to the same public airport
13:36:04  <Hirundo> There, company A delivers it to town
13:36:31  <Hirundo> Now Company B/C get a large share (altough the total sum is quite small) and Company A gets almost nothing
13:36:47  <Rubidium> Company A brings pax to public station, Company B brings pax to private station just to rot there
13:37:15  <Rubidium> both companies get nothing, but B knows that and pays a small price for making company A lose more money
13:38:16  <Hirundo> Yes, but how to distinguish bene- and malevolence ?
13:39:42  <Rubidium> that's the problem, or actually the problem is that there is malevolence
13:40:19  <Rubidium> OpenTTD would be a lot simpler code-wise if we didn't need to check for all "bad" behaviour that totally ruins the joy of many on MP servers
13:40:27  <Hirundo> Fixing the problems that started with Eve's Apple is not in our league, I fear
13:41:57  <Hirundo> Also, we ought to remember that nobody is forced to use the public stations in any way
13:43:37  <Rubidium> true, though... a "simpler" solution would be to disallow transferring on public stations
13:45:41  <Hirundo> I don't think that would be as 'simple' as it looks
13:45:57  <Hirundo> How to handle unload orders when the station doesn't accept the goods?
13:46:41  <Rubidium> then you opt for not being paid; that's the whole point of forcefully unloading. You want to get rid of the cargo
13:47:16  <Hirundo> So all the cargo is sent into /dev/null?
13:50:27  <Rubidium> well, I rather not have public stations at all... but Chris already spoiled that
13:53:59  <Hirundo> See:
13:54:36  <Rubidium> having written down something does not mean it's going to happen
13:54:41  <Hirundo> This seems implemented in newgrf ports (at least prop 25 exists)
13:57:01  <Rubidium> what might be a good idea is to, when cargo moves between companies, pay a certain share of the then already gathered 'profit' to the previous company. Then if 'B' doesn't deliver he gets fined for it. It should also prevent companies from moving cargo the wrong way. The final payment is based on the total distance and the different vehicle's roles in it.
13:57:43  <Rubidium> which then splits based on the distance actually moved
13:59:22  <Rubidium> no idea whether it really works, but it should give some incentive to not lose cargo/move cargo the wrong way over vast distances
13:59:27  <Hirundo> Should paying the already gathered 'profit'  happen when a) a new vehicle picks the cargo up or b) the old vehicle drops the cargo
14:00:03  <Rubidium> picking up
14:00:33  <Rubidium> otherwise you get money by just dropping cargo on a far away station to let it rot
14:00:43  <Hirundo> That's what I was thinking
14:02:05  <Hirundo> Doesn't the last company make a negative profit here
14:02:29  <Hirundo> Since he has to pay his predecessor, but only receives a part of the final payment in return
14:03:32  <Rubidium> A moves 100 tiles, gets paid 100
14:03:38  <Rubidium> B moves 50 tiles, gets paid 50
14:04:10  <Rubidium> C moves 50 tiles, final deliver: total distance 100 tiles, payment: 100
14:04:40  <Rubidium> A returns 50 to C, B returns 25 to C, C gets paid 100
14:05:27  <Rubidium> although, in reality you will only pay a percentage, say 50% beforehand
14:05:51  <Rubidium> so, A moves 100 tiles, should be paid 100, gets 50 (from B)
14:06:09  <Hirundo> "the wrong way" <- I think this may be difficult to define
14:06:39  <Hirundo> A transports cargo to other side of the map, B transports it back to al location near its orgin and delivers
14:06:50  <Hirundo> Now A might make negative money, despite good intentions
14:07:54  <Rubidium> the income doesn't get negative with my system (except for the company losing cargo)
14:08:56  <Webster> Latest update from devactivity: OpenGFX - Revision 371: Change [#820]: splitted toyland <>
14:09:41  <Hirundo> Hmmm... I have to think about it
14:12:35  <Hirundo> Are these 'temporary payments' dependant on time taken?
14:24:42  <Webster> Latest update from devactivity: OpenGFX - Feature #820 (Closed): Base files splitting <>
14:54:02  <Rubidium> Hirundo: I'd say they're depending on time, so you should probably be able to tell: I only accept cargo for which I pay at most XYZ. The primary reason for this preliminary payment is getting an incentive to actually deliver the cargo.
14:56:05  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 658: Change: tidied up defines for Power Plant closure c... <>
14:56:18  <Hirundo> This may be getting a bit complicated
15:06:43  <Hirundo> I was trying to find out how simutrans handles this, but it does not support multiplayer :(
15:19:45  <andythenorth> @seen FooBar
15:19:45  <Webster> andythenorth: FooBar was last seen in #openttdcoop.devzone 9 weeks, 4 days, 22 hours, and 39 seconds ago: * FooBar says bye!
15:27:19  <Ammler> andythenorth: create a ticket in the tracker and assign or watch him
15:27:28  <Ammler> he is around email wise
15:58:27  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 660: Change: tidied some unfinished initialisation code ... <> || FIRS Industry Replacement Set - Revision 659: Change: set Power Station protected months to 30 <>
16:14:00  <andythenorth> Ammler: is there a devzone project for the makefile system?
16:17:25  <Ammler> yes
16:17:38  <andythenorth> I need glasses :o
16:17:45  <Ammler>
16:18:27  <Ammler> afaik, you mainly just need to copy those files and configure Makefile.config
16:18:36  <andythenorth> the projects page could use some formatting love...but I guess life is too short for that :)
16:19:04  <Ammler> you mean the DevZone in general?
16:20:06  *** ODM has joined #openttdcoop.devzone
16:20:27  <Ammler> might be worth to read
16:24:56  <andythenorth> Ammler: I added a couple of tickets for pm when he gets back :)
16:29:08  <Webster> Latest update from devactivity: Example NewGRF Project - Feature #846 (New): Show up errors better: hide "Loading sprites....pcx"... <> || Example NewGRF Project - Bug #845 (New): Make got slow :| <>
16:34:29  <Ammler> andythenorth: I add you a easy patch for #846
16:34:39  <Ammler> hmm, no
16:34:50  <Ammler> wouldn't work for the compile farm...
16:35:10  <Ammler> but what is bad about "make | tee" ?
16:35:29  <Rubidium> or use make | less
16:36:01  <Ammler> oh, tee isn't a "core" tool?
16:38:13  <DJNekkid> andythenorth: is it only powerplant numbers you want?
16:38:29  <andythenorth> DJNekkid: powerplant versus other secondary industries
16:38:53  <andythenorth> Ammler: make | tee *nearly* works
16:38:59  <andythenorth> but I lose the renum output which *is* useful
16:39:11  <andythenorth> i.e. I need to see the renum errors
16:39:22  <andythenorth> it helps keep them off the compile farm :P
16:39:41  <Ammler> he?
16:39:51  <DJNekkid> andythenorth: total numbers will do, or do you want some "fancy" graph?
16:39:52  <Ammler> that shouldn't happen, hmm
16:40:13  <andythenorth> DJNekkid: a chart would be's easier to see the trend visually
16:40:15  <Ammler> it should use both "channels"
16:40:45  <Ammler> indeed
16:40:51  <Ammler> it does use only stdout
16:40:56  <andythenorth> make | less is rather excitingly cryptic
16:41:59  <Ammler> well, that needs to run it completely until you get output
16:42:34  <DJNekkid> bah, problem is ... cant sort by date, as that sorts by jan1 -> 31 dec and not YYYY-MM-DD
16:42:54  <DJNekkid> or actually
16:43:24  <Ammler> best would be, dalestan would have used the patch from rubi
16:43:29  <Ammler> with -s
16:43:57  <Rubidium> grfcodec | less should not show the loading/progress stuff
16:44:18  <Ammler> Rubidium: but you need to wait until it is finished...
16:44:22  <Webster> Latest update from devactivity: Example NewGRF Project - Feature #846: Show up errors better: hide "Loading sprites....pcx" outpu... <>
16:45:05  <Ammler> I changed my post :-)
16:45:10  <Ammler> as tee is bad
16:53:40  *** DJNekkid has quit IRC
16:54:59  <Ammler> might it be possible, the Makefile can't handle "-1 sprites/pcx/extra/extra-gui+-.pcx 0 0 09 10 10 0 0" ?
16:55:09  <Ammler> issues with my silly filename?
16:56:55  <Ammler> make bundle_tar works
16:57:03  <Ammler> but make (all) doesn't
16:57:22  <Ammler> Majonaise!
16:59:37  *** DJNekkid has joined #openttdcoop.devzone
16:59:40  <Webster> Latest update from devactivity: Example NewGRF Project - Feature #846: Show up errors better: hide "Loading sprites....pcx" outpu... <>
17:00:03  <DJNekkid> andythenorth:
17:00:25  <DJNekkid> as you can see...
17:00:29  <DJNekkid> some "works" and some dont
17:00:33  <DJNekkid> whatever works is :)
17:01:58  <andythenorth> DJNekkid: looks like power plants are closing less than other secondary industries
17:02:12  <DJNekkid> no
17:02:13  <andythenorth> not sure how many were there at game start though!
17:02:32  <DJNekkid> thoose numbers are the total left
17:02:38  <andythenorth> ok
17:02:45  <andythenorth> hmm
17:02:56  <andythenorth> I think I need it to be a time series
17:03:13  <DJNekkid> i can, if you want, find how many opens totally, and closeds totally
17:03:46  <DJNekkid> any industry you want specifically?
17:04:11  <andythenorth> power station, cement plant, textile mill
17:05:18  <DJNekkid> no tex mills close
17:06:04  <DJNekkid> 158 in 1920, and another 27 opens
17:07:52  <andythenorth> wonder if we can fix the dates with a regex or something
17:07:59  <andythenorth> then we could plot the timeseries
17:08:49  * andythenorth doesn't do regex
17:08:52  <andythenorth> find and replace?
17:10:04  <DJNekkid> find and replace all possible 365 dates and all 40 years?
17:10:20  <andythenorth> DJNekkid: are you using terkhen's output, or your own?
17:10:28  <DJNekkid> terkhen
17:10:44  <andythenorth> DJNekkid: if you do find and replace on 'st ' and 'th ' and 'nd ', excel will then recognise the dates
17:10:57  <DJNekkid> yea, perhaps
17:11:03  <andythenorth> just tested it :)
17:11:35  <Ammler> sed...
17:12:04  <andythenorth> Ammler: would you do that for me? :)
17:12:16  <andythenorth> output is here
17:12:16  <andythenorth>
17:12:17  <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - Development (at
17:12:51  <DJNekkid> i can give you a better .txt
17:13:00  <Ammler> yeah, let DJNekkid do it
17:13:07  <Ammler> I have no idea, what you need :-)
17:16:53  <Ammler> andythenorth: there is already a excel sheet on the forums
17:17:17  <andythenorth> is that the one that uses 'Open-crash-office'
17:17:18  <andythenorth> ?
17:18:24  <Rubidium> any "office" ought to be used only at the "office" because there the problem of crashes/incompatabilities is for your boss
17:18:35  <DJNekkid> thoose powerplants are WIERD!
17:18:45  <Rubidium> wierd is weird too
17:19:05  <DJNekkid> or that!
17:19:08  <DJNekkid> either way...
17:19:18  <DJNekkid> LOTS of them close 1st mars 1920
17:20:05  <andythenorth> DJNekkid: that is by design, but might be seen as a bug
17:20:18  <DJNekkid> oki...
17:20:27  <DJNekkid> 1/3rd of all closes are on that date
17:21:00  <DJNekkid> total 93 closes, 36 of them 1st mars 1920
17:22:26  <DJNekkid>
17:23:34  <DJNekkid> andythenorth: ^^
17:23:51  <andythenorth> thanks
17:35:26  <DJNekkid> andythenorth: and regarding powerstations, ALL of them close 1st of a month
17:35:32  <andythenorth> yup
17:35:34  <DJNekkid> and the created ones are inbetween
17:35:34  *** frosch123 has joined #openttdcoop.devzone
17:35:54  <andythenorth> 1st of month is probably the only place I can close them reliably
17:36:08  <andythenorth> being able to 'close now' would be quite useful
17:36:25  <andythenorth> hi frosch123
17:36:52  <frosch123> evening :)
17:38:03  <andythenorth> in the absence of ponies, I may be training donkeys "|
17:38:04  <andythenorth> :|
17:39:13  * andythenorth designing production code => eyes bleed 
17:40:19  <andythenorth> frosch123: any chance of changing industry closure to 'close now', rather than waiting a month?
17:42:25  <frosch123> iirc it closes on start of next month, not after a month
17:42:37  <frosch123> and i guess it is for the news message
17:42:53  <frosch123> (in case they are not delayed that much)
17:43:22  <andythenorth> if 03 80 is returned to the monthly production change cb in May, the industry will close in June (or so it seems)
17:43:30  <andythenorth> and that's what the spec also says :)
17:43:50  <andythenorth> It would be useful to me if the production change cb could 'remove now'
17:44:08  <frosch123> hmm, yes, in TTD the random production change callback is also called on the 1st
17:44:51  <frosch123> well, then reject cargo and draw some remants :p
17:45:35  <andythenorth> frosch123: this is my one remaining blocker for preventing waves of industry closure
17:46:00  <andythenorth> dunno if you saw this:
17:46:07  <andythenorth> but it has one conceptual flaw :|
17:51:52  <DJNekkid> andythenorth:
17:51:59  <DJNekkid> andythenorth:
17:52:00  <DJNekkid> ^^
17:52:23  <DJNekkid> want more? :P
17:52:45  <andythenorth> can you do that for other secondary industry?
17:54:09  <DJNekkid> sure!
17:54:15  <DJNekkid> im planning to do it for all of them :P
18:00:51  <frosch123> i guess the number of random changes should depend on number of industries or so
18:01:15  <frosch123> instead of mapsize
18:01:28  <andythenorth> in the game code?  or my code?
18:01:35  <frosch123> in the game
18:01:46  *** DJ_Nekkid has joined #openttdcoop.devzone
18:01:59  <DJ_Nekkid> got disconnected...
18:01:59  <andythenorth> would seem more 'correct'
18:02:05  <DJ_Nekkid> witch ones do you want?
18:04:02  <Rubidium> Sabrina!
18:04:25  *** DJNekkid has quit IRC
18:21:23  *** Frankr has joined #openttdcoop.devzone
18:51:20  <Webster> Latest update from devactivity: World Airliners Set - Revision 636: Changed A380 NFO to Meet Coding Tables, Running Costs and Pax... <> || 32bpp-extra - Bug #847 (New): Coast tiles <>
18:52:52  *** Seberoth has joined #openttdcoop.devzone
19:00:32  *** Frankr has quit IRC
19:00:58  *** Frankr has joined #openttdcoop.devzone
19:02:07  <Ammler> andythenorth: did you try now make | less ?
19:03:45  <andythenorth> trying it now
19:05:43  <andythenorth> Ammler: no error reporting
19:05:54  <andythenorth> also an annoying need to now press 'q' after running make :)
19:06:15  <andythenorth> It seems like it would be simple to either:
19:06:25  <andythenorth> (a) mask out the 'loading' lines from grfcodec
19:06:42  <andythenorth> or (b) modify grfcodec with a switch to suppress those lines (it may even have one already)
19:07:06  <andythenorth> shall we wait for pm to return?
19:12:06  *** Doorslammer has quit IRC
19:20:31  <Ammler> andythenorth: it doesn't have one
19:20:43  <Ammler> it does automatically detect, if output is pipe or console
19:20:44  <andythenorth> oh well
19:20:56  <Ammler> that is why less works, at least here
19:22:33  <Ammler> planetmaker: isn't able to fix that, that would be a task for dalestan
19:27:14  <Seberoth> Hi folks
19:51:41  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 661: Fix: stupid mistake in Accept Only template - used ... <>
20:05:52  <DJ_Nekkid> andythenorth: new pic for you
20:06:14  <DJ_Nekkid> andythenorth:
20:07:18  <andythenorth> thanks
20:07:21  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Feature #828 (Closed): Rethink Power Station consumption <>
20:08:11  <andythenorth> DJ_Nekkid: I've updated the forum post....all the charts confirm each other.  I've made tweaks, Terkhen is running new tests ;)
20:15:36  <DJ_Nekkid> andythenorth: why not make a simple grf with like 3 or 4 industries
20:15:50  <DJ_Nekkid> then set some extremes on the closeures and stuff
20:15:57  <andythenorth> DJ_Nekkid: that's a good idea.
20:16:09  <andythenorth> I've only applied the closure code to power station so far
20:16:16  <andythenorth> I should try it on the other industries soon
20:16:24  <DJ_Nekkid> but isnt 2 months quite fast?
20:16:26  <DJ_Nekkid> i mean
20:16:33  <andythenorth> That was just for testing.
20:16:38  <DJ_Nekkid> oki :)
20:17:03  <andythenorth> For most industries the 'protected period' will be 10 years, or it might scale with map size
20:17:19  <DJ_Nekkid> a grf can read map size?
20:17:25  <andythenorth>
20:19:06  <DJ_Nekkid> but yes, make an industry grf with only a handfull, and then make similar calculations
20:19:19  <DJ_Nekkid> makes it lots easier to interpret the data, then on 15 different ones...
20:21:13  <DJ_Nekkid> with all industries in thoose txtfiles fed into an openoffice excelsheet it took more then 600mb
20:21:27  <DJ_Nekkid> atleast with my inbetween calculations and stuff
20:25:31  <andythenorth> roujin has made a lua script to handle the output :)
20:26:39  * andythenorth has the most recent post on far too many of the forums and is embarassed :o
20:28:59  <DJ_Nekkid> hehe ... i know the feeling
20:38:02  <Webster> Latest update from devactivity: OpenGFX - Revision 372: Docs: deanoymize some nicks <>
21:09:10  *** Seberoth has quit IRC
21:10:04  *** Seberoth has joined #openttdcoop.devzone
21:23:56  <Webster> Latest update from devactivity: OpenGFX - Revision 373: Doc: wrap readme at 80 chars <> || FIRS Industry Replacement Set - Bug #316: Conflicting industry types <>
21:40:16  <Webster> Latest update from devactivity: OpenGFX - Revision 374: Doc: update changelog to 0.2.2 <>
21:45:03  <Ammler> I am ready, if pm joins...
21:45:06  <Ammler> :-)
22:02:43  <Rubidium> would it make sense to reference the tracker tickets/revisions to the changelog like OpenTTD does?
22:06:23  <Ammler> actually, I don't know why we removed those references...
22:36:32  *** ODM has quit IRC
22:43:04  <Seberoth> I need a good IRC Client for Linux^^
22:43:09  <Rubidium> irssi!
22:43:23  <Seberoth> Wow, that was fast^^
22:44:09  <Rubidium> but then... it's quite likely that you don't think it's a good irc client
22:44:53  * KenjiE20 prefers weechat > irssi
22:45:23  <Rubidium> does that support in-situ upgrading?
22:45:27  <Rubidium> i.e. without disconnecting?
22:45:30  <KenjiE20> yes
22:45:33  <DJ_Nekkid> xchat?
22:45:50  <KenjiE20> xchat is weird
22:46:15  <DJ_Nekkid> not more wierd then mIRC
22:46:20  <DJ_Nekkid> (for windows=
22:46:20  <KenjiE20> true
22:46:32  <PeterT> mIRC sucks
22:46:39  <PeterT> XChat > mIRC
22:46:39  <KenjiE20> it's still weird though
22:46:46  <PeterT> That it is, that it is
22:46:55  <DJ_Nekkid> so ... what makes an irc client good, or bad, or wierd?
22:47:14  <KenjiE20> ease of use / features I guess
22:47:16  <PeterT> depends of personal preference
22:47:19  <KenjiE20> and personal pref
22:47:20  <Seberoth> Weechat looks nice
22:47:25  <KenjiE20> weechat is nice
22:49:53  <Ammler> DJ_Nekkid: use the client made for your WM
22:50:23  <KenjiE20> does fluxbox HAVE a client?
22:50:25  <KenjiE20> :P
22:50:31  <Ammler> !s/use/try/
22:50:52  <KenjiE20> s/fluxbox/your minimal wm of choice/
22:51:39  <Rubidium> yeah, then weechat/irssie are the client of choice for the "screen" WM
22:51:58  <Ammler> indeed
22:52:03  <KenjiE20> :D
22:52:37  <Ammler> well, you don't use KDE, else you wouldn't ask.
23:01:47  *** Seberoth has quit IRC
23:13:31  <DJ_Nekkid> *wants his new "CD"-players to arrive soon!*
23:31:17  <Ammler> CD players?
23:31:23  <Ammler> do they still exist?
23:31:50  <PeterT> are we using "CD" as a shortening for CargoDist?
23:34:46  <DJ_Nekkid> DJ CD-players
23:35:26  <DJ_Nekkid>
23:38:53  <frosch123> "CDJ" is a nice name :)
23:44:36  <DJ_Nekkid> yup
23:44:52  <DJ_Nekkid> all mixers from pioneer are "DJM-number" :)
23:44:58  <DJ_Nekkid> headsets are "HDJ"
23:45:00  <DJ_Nekkid> etc
23:48:28  <PeterT> Ammler: Looks like OGFX has some competition (
23:48:30  <Webster> Title: Transport Tycoon Forums • View topic - Canadian Theme Pack [Introduction] (at
23:56:18  <DJ_Nekkid> andythenorth: sleeping yet?
23:57:38  <DJ_Nekkid> andythenorth:
23:57:49  <andythenorth> DJ_Nekkid: nearly sleeping
23:58:08  <andythenorth> interesting
23:58:18  <andythenorth> we'll see what happens tomorrow!
23:59:35  <DJ_Nekkid> btw, the mass closeure of the PPs now were 1st august, not 1st mars

Powered by YARRSTE version: svn-trunk