IRC logs for #openttd on OFTC at 2009-12-03
⏴ go to previous day
00:00:12 * Chrill hugs frosch123 for saving the day
00:02:04 <Zuu> Ideally it would be nice to have that one on Bananas.
00:02:27 <frosch123> write your own in 5 minutes and upload it :p
00:02:49 <Zuu> I'm a total noob when it comes to newGRF coding! :-)
00:03:08 <Dred_furst> use pikkabird's old wagons with new cargos grf
00:03:13 <frosch123> but actually "old wagons, new cargos" is more fool-proof
00:03:32 <frosch123> though i do not know whether it adds all vehicles, or only those carrying some cargo
00:03:44 <Dred_furst> it has all the vehicles
00:03:47 <Dred_furst> I loaded it ingame
00:03:57 <Dred_furst> (with my grf) and everything is there
00:04:05 <fjb> Hm, I have a C problem again: I have typedef struct A which contains a pointer to B and typedef struct B which contains a pinter to A. How do I solve that recursive typedefs?
00:04:50 <Zuu> Can you do forward declarations in c?
00:04:50 <frosch123> then you need a forward declaration before the typedef
00:05:00 <frosch123> e.g. "struct A;" or "struct B;"
00:05:20 <Rubidium> typedef struct Foo A; typedef struct Bar { Foo a; } B; struct Foo { Bar b; }; ?
00:05:38 <frosch123> c also has the impressive construct of "typedef struct Atag { ... } A;"
00:05:55 <frosch123> which declares the struct as A, but makes it available as Atag inside the struct :p
00:06:04 <CIA-4> OpenTTD: rubidium * r18389 /trunk/src/ (roadstop.cpp smallmap_gui.cpp): -Fix: some minor documentation alignment issues
00:06:15 <fjb> C is sometimes very strange.
00:06:24 <frosch123> iirc the "typedef" has to appear at the real declaration, not in the forward
00:06:35 <Zuu> frosch123: Is A an invalid value for Atag, or can ju just use the same?
00:06:46 <frosch123> you can also use the same
00:07:04 <frosch123> but one is only known inside the struct, and one only outside :p
00:21:10 <Rubidium> frosch123: the good old days when the coding style was: typedef VehicleTypes { VEH_INVALID = 0x0, VEH_TRAIN = 0x10, ... } VehicleType;
00:21:55 <Eddi|zuHause> what's the coding style now?
00:22:11 <Rubidium> enum VehicleType { ... };
00:22:12 <frosch123> hmm, i would have to look that up in c specs, to understand the "VehicleTypes"
00:22:58 <frosch123> Eddi|zuHause: it's more a c/c++ issue, than a style issue
00:23:30 <frosch123> hmm, i have only c++ specs on my desktop
00:24:28 <Zuu> Is it a new feature that you can move around the main window in the main menu?
00:25:58 <Rubidium> yes, lets qualify it as a feature
00:26:31 <frosch123> well, i guess i do not know c good enough
00:26:48 <frosch123> no idea, in which context "Birds" is used instead of "Bird"
00:27:42 <Rubidium> me neither, but apparantly some MSVC failed on it
00:27:50 <frosch123> "Tab size is 2 spaces. Never use spaces as indentation at the beginning of the line." <- does not parse either
00:28:36 <frosch123> oh, i guess it means that the example is created with tab size 2 :o
00:29:23 <Rubidium> tab size is more or less irrelevant I guess; I reckon the intention was that with if (...\n\t\t... it was nicely aligned or so
00:32:12 <fjb> Stupid DSL... But the forward declaration worked.
00:32:30 <frosch123> ah, seems like variables can be declared either by "enum Birds bird;" or "Bird bird;"
00:33:16 *** Eddi|zuHause has joined #openttd
00:33:36 <Zuu> And at some point we might get enum classes too. But lets not start counting down yet. :-p
00:35:49 <Zuu> There is quite some nice things in the c++0x. Though due to the size of it one can not be sure that it happens anytime soon.
00:36:42 <frosch123> hmm, enum classes, i remember i needed them once, and was disappointed it did not work
00:41:44 <frosch123> yeah, enum forward declaration and specification of underlying type \o/
00:42:18 <frosch123> however, it does not explcitly mention, whether you can define static methods and/or operators
00:43:11 <Zuu> You mean static methods/operators that make use of the enums?
00:43:27 <frosch123> declared in the scope of the enum class
00:43:45 <Zuu> Oh, I would be surprised if that was possible.
00:43:48 <frosch123> or default constructors etc
00:44:03 <Zuu> But that would indeed be an interesting possibility.
00:44:09 <frosch123> well, if you have strongly typed enums, you need conversion operators
00:44:29 <Rubidium> hmm... do I see a replacement for SimpleEnumT in that FAQ?
00:45:15 <frosch123> Zuu: e.g. ottd has some macro to declare postfix increment for enums
00:46:10 <frosch123> oh, and of course that article does not mention enum inheritance
00:55:09 *** DorpsGek has joined #openttd
00:55:09 *** ChanServ sets mode: +o DorpsGek
00:55:31 <Rubidium> so still half a dozen years before we can actually start using it in e.g. OTTD
00:56:31 <Zuu> Yea, MSVC will probably as always take its time to get settled with the new standard. And we will get new inconsintencies between compilers.
01:03:08 *** Rubix`` has joined #openttd
01:04:01 <Rubidium> ooh... very few servers :)
01:05:16 <Zuu> That is indeed not many. And there is only a few servers that do not have any company on them. Though the client counts are quite low.
01:07:31 <Rubidium> well, it's more the masterserver that got rebooted
01:15:49 *** Rhamphoryncus has joined #openttd
01:32:52 *** KenjiE20|LT has joined #openttd
02:10:20 *** ezracooper has joined #openttd
02:14:10 *** Eddi|zuHause2 has joined #openttd
03:16:32 *** zodttd2 is now known as zodttd
04:22:24 *** DaleStan has joined #openttd
05:31:37 *** eQualizer|dada is now known as eQualizer
07:10:39 *** Cybertinus has joined #openttd
07:41:50 *** Polygon has joined #openttd
07:43:27 *** MizardX has joined #openttd
07:46:51 *** Terkhen has joined #openttd
07:48:35 *** JVassie^ has joined #openttd
08:10:48 *** XSlicer has joined #openttd
08:24:52 <CIA-4> OpenTTD: peter1138 * r18390 /trunk/src/video/sdl_v.cpp: -Fix (r17776): [SDL] Reinstate pointer update on 'idle' loop.
09:02:22 *** zodttd2 has joined #openttd
09:11:04 *** fonsinchen has joined #openttd
09:57:04 *** bartaway is now known as bartavelle
09:57:25 *** Eddi|zuHause2 is now known as Eddi|zuHause
10:07:03 *** Terkhen has joined #openttd
10:16:43 <planetmaker> anyone knows how I can teach awk to print every field in a line _except_ the first one?
10:18:12 <bartavelle> yup, anything but awk
10:19:16 <planetmaker> well... But I basically want what renum does except the syntax parsing
10:19:25 <planetmaker> e.g. number certain lines
10:19:58 <planetmaker> in my case it's basically real sprites (they match /sprites/ ) and some recolour sprites where I hope to get away with /*/
10:21:03 <bartavelle> i find it more productive to use perl after the problem is complex enough to warrant a look at awk or sed manpage
10:21:10 <bartavelle> saves time in the end
10:21:25 <bartavelle> but this doesn't help you
10:25:26 <planetmaker> well... not directly indeed. I've no clue about perl, but little about awk :-)
10:25:39 <bartavelle> sed -e 's/^[^x]*x//' filename
10:25:43 <bartavelle> where x is your separator
10:25:46 <bartavelle> for the first question
10:26:20 <bartavelle> I'm not sure this helps as I have no clue about the renum command
10:29:19 <planetmaker> skipping all different lines
10:29:39 <planetmaker> those lines which get numbered need their first number (the wrong line numbers) removed
10:29:42 <bartavelle> not printing the other lines is what you mean by skipping ?
10:29:45 *** Chruker has joined #openttd
10:29:54 <planetmaker> Printing them as is
10:30:01 <bartavelle> ok, just removing the numbers
10:30:08 <planetmaker> changing the numbers :-)
10:32:54 <bartavelle> does that behaves like you expected ?
10:42:35 *** ChanServ sets mode: +v DorpsGek
11:00:29 *** frosch123 has joined #openttd
11:43:47 <planetmaker> bartavelle, thanks. How do I invoke perl with that, though?
11:44:15 <bartavelle> perl file.pl yourinput
11:44:21 <bartavelle> or perl file.pl < yourinput
11:44:28 <bartavelle> or with | perl file.pl
11:50:13 <planetmaker> cool. Seems to do the job. Thanks :-)
11:53:09 <DaleStan> planetmaker: The perl script looks good, but if it goes wrong, and if you can get away with //@@LINT OFF as one of the first lines, NFORenum not lint your file. But it might insist on a sprite 0, whether you like it or not.
11:54:27 <planetmaker> I think I don't want @@LINT OFF as I subsequently want these files parsed by nforenum
11:54:39 <planetmaker> Basically I want to beautify the base set files
11:54:52 <planetmaker> Currently they have a wild collection of arbitrary sprite numbers
11:55:02 <planetmaker> Which makes finding particular sprites a pain.
11:55:52 <planetmaker> But thanks for that tip - might come in handy at other places :-) I understand it correct that LINT OFF disables correctness checking then?
12:07:35 <DaleStan> -l- (or the long form: --lint=off) should work, then. NFORenum will insist on adding a header whether you like it or not, though. And yes. Turns off the checking completely.
12:11:02 *** KenjiE20 has joined #openttd
12:12:21 <planetmaker> cool. Thanks. I don't mind the typical NFO header - those files have that anyway.
12:13:53 <planetmaker> hm... but is there a way to tell renum not to stumble about lines like
12:14:34 <planetmaker> 762 sprites/pcx/trains/toyland_railwagons.pcx 150 72 09 16 20 OFF_X_EW OFF_Y_EW
12:14:48 <planetmaker> where there definitely IS an error in nfo terms?
12:15:12 <planetmaker> (but which I want to preserve; thus it should treat it as if it was correct)
12:18:38 *** ChanServ sets mode: +v tokai
12:29:40 *** ChanServ sets mode: +v tokai
12:33:14 *** dihedral has joined #openttd
12:33:53 *** Ammler is now known as Guest1113
12:34:03 *** Hirundo has joined #openttd
12:34:09 *** planetmaker has joined #openttd
12:34:13 *** planetmaker is now known as Guest1115
12:35:47 *** XeryusTC has joined #openttd
12:39:49 *** roboboy has joined #openttd
12:43:03 *** Guest1115 is now known as planetmaker
12:45:29 * planetmaker wonders: will it now be possible to add together more than the 8? 16? road stops to a HUGE station?
12:45:52 <planetmaker> Like train stations aren't limited in size by anything but the station spread either.
13:09:18 *** fonsinchen has joined #openttd
13:13:05 <Phantasm> Uhm.. Max speed of last vehicle entering the station gives rating boost.. But the rating % given for the boost is 0% to 17 %. So, is the maximum rating from top speed gained already by train of 259 km/h speed? So that no further speed addition gives any benefit. And as for airplanes that should give slowest airplane the max bonus already, right?
13:14:14 <frosch123> planesspeed is not necessarily km/h
13:15:25 <frosch123> case VEH_TRAIN: t = Train::From(u)->tcache.cached_max_speed; break;
13:15:26 <frosch123> case VEH_ROAD: t = u->max_speed / 2; break;
13:15:28 <frosch123> case VEH_SHIP: t = u->max_speed; break;
13:15:29 <frosch123> case VEH_AIRCRAFT: t = u->max_speed * 10 / 129; break; // convert to old units
13:16:09 <frosch123> so maybe "last_speed" is in units of "8 mph" for aircraft
13:16:22 <Phantasm> I wonder why road vehicle speed is divided by 2...
13:16:39 <Phantasm> Well, at least it makes it so that road vehicles never ever give speed boost to rating.
13:16:42 <frosch123> the speed units are all different
13:17:11 <Phantasm> Well, what are the speed units then?
13:17:11 <frosch123> int GetDisplaySpeed() const { return this->cur_speed / 2; }
13:17:36 <frosch123> every vehicleclass has its own GetDisplaySpeed
13:17:54 <frosch123> which returns the speed in kmish/h unints
13:18:21 <Phantasm> Ok. So, road vehicles and trains use the real km/h for the rating calculation. How about ship and aircraft?
13:18:25 <frosch123> "last_speed" uses the original units, which can be found e.g. in newgrf specs
13:19:13 <Phantasm> I don't have the sources.
13:20:05 <Phantasm> I don't have the sources != I couldn't get the sources.
13:20:20 <blathijs> The man has a point :-)
13:21:00 <Phantasm> Ok, so ships use doubled speed for station rating.
13:27:06 <Phantasm> So so.. 1 % unit rating boost for every {train&road 10.24|ship 5.12|air 132.096} km/h above {train&road 85|ship 42.5|air 1096.5} km/h.
13:27:59 <frosch123> which is generally spoiled by wagon speed limits
13:28:25 <Phantasm> Is it taken from wagon or engine max speed limit?
13:28:50 <frosch123> case VEH_TRAIN: t = Train::From(u)->tcache.cached_max_speed; break; <- that is the minimum of all max_speed of the train
13:29:38 <Phantasm> Ok, so theoretical lowest limit is taken.
13:30:19 <Phantasm> But if the train were to be too heavy for it to achieve the max speed or for other reasons wouldn't ever achieve it, it would still get bonus for the theoretical lowest limit.
13:30:49 <frosch123> which might be fun with andy's log raft, where speed decreases while loading :p
13:31:18 <Phantasm> Isn't train at still while loading?
13:31:58 <Phantasm> Speed decrease from load level perhaps?
13:32:34 <Phantasm> How far away from town center does statue give the 10 % boost?
13:32:55 <Phantasm> Yes, so speed decrease from load level.
13:33:13 <Phantasm> The vehicle is still when it is being loaded - while loading.
13:33:15 <Eddi|zuHause> frosch123: but isn't that basically the same as in TTDPatch where freight trains have higher speed limit when empty?
13:33:47 <frosch123> no idea, i do not know such details of ttdp
13:33:50 <Phantasm> Normal OpenTTD without any newgrf etc doesn't have wagon speed limits?
13:35:04 <frosch123> if (Company::IsValidID(st->owner) && HasBit(st->town->statues, st->owner)) rating += 26; <- it does not depend on the distance at all
13:35:24 <glx> Phantasm: it has, but default wagons don't
13:35:26 <frosch123> just click with the landquery tool on the station sign's tile to get the local authority
13:35:40 *** lewymati has joined #openttd
13:36:10 <Eddi|zuHause> frosch123: what if the station sign moved?
13:36:18 <Phantasm> So, station sign tile with no local authority doesn't get benefit. :/
13:36:31 <frosch123> Eddi|zuHause: or a new town is funded? :p
13:37:06 <Phantasm> New towns don't get funded on OpenTTD without newgrf?
13:37:32 <Eddi|zuHause> i thought it was just "town which the station derived its name from", and has nothing to do with local authority
13:37:47 <glx> it's not a newgrf feature
13:37:57 <frosch123> Eddi|zuHause: good point
13:38:29 <frosch123> you are right, the station does not change when funding new towns or moving the station sign, so the statue does not change either
13:39:41 <Phantasm> So, does statue affect even if there is no local authority but only the name from town far away?
13:40:04 <frosch123> yes, it is the name of the town in the stationname, independent of distance
13:41:18 <Phantasm> I would assume custom names don't affect? ;)
13:42:00 <frosch123> just click on "default name" :p
13:48:28 <Phantasm> Meh.. For some reason I'm getting a feeling that maglevs are only good for lowering running costs.. ;P
13:48:33 *** zodttd2 is now known as zodttd
13:49:05 <Phantasm> Same for monorail.. ;P
13:49:49 <Phantasm> Or well, in non-temperate there isn't asiastar so monorail has real value.
13:50:05 <Phantasm> Up from the 160 max speed of turner turbo to the above 255 of station rating bonus limit.
13:51:37 <Phantasm> Well.. Running costs as well as managing time (needs less track as a single pair of tracks can haul some 40 000 units of items per month on maglev 2).
13:52:26 <Phantasm> Huge effort for building a good station system for loading and unloading (as well as some for depots) but very little effort for making suitable tracks on the actual route.
13:53:40 <Phantasm> Around 10 days for maglev 2 to load goods, move 128 squares and unload goods. (2 engines, 26 cars)
13:55:09 *** ChanServ sets mode: +v tokai
13:55:35 <Phantasm> Given that the payment value drop is negligible on tims of less than around 50 days for entire route. And for not so easily spoilable goods even longer time is fine. Of course with routes significantly over the limit of default map size there is difference.
13:56:38 <frosch123> ok, at least "max_speed" is stored in the savegame, so no desync for the log raft
13:57:59 <frosch123> however, it keeps the high speed when empty for the whole loading process
13:58:35 <frosch123> (not worth changing)
13:59:47 *** ezracooper has joined #openttd
14:00:47 *** Belugas has joined #openttd
14:00:47 *** ChanServ sets mode: +o Belugas
14:05:15 *** Cybert1nus has joined #openttd
14:06:00 <Phantasm> Maglev accelerates (and brakes) faster than other trains further easing the running costs. Less trains needed for entire route. And more trains can travel the single pair of tracks.
14:09:39 *** Terkhen has joined #openttd
14:12:07 <Phantasm> Though, train running costs are so negligible that it probably isn't worth the cost of buying new engines.
14:36:56 *** worldemar has joined #openttd
14:42:20 *** Dred_furst has joined #openttd
14:42:53 *** Guest1113 is now known as Ammler
14:59:42 *** Progman has joined #openttd
15:13:46 <DorpsGek> TrueBrain: I don't recognize you.
15:14:00 <DorpsGek> TrueBrain: The operation succeeded.
15:14:02 <DorpsGek> TrueBrain: The operation succeeded.
15:14:04 <DorpsGek> TrueBrain: The operation succeeded.
15:14:12 <DorpsGek> TrueBrain: The operation succeeded.
15:14:14 <DorpsGek> TrueBrain: Commit by peter1138 :: r18390 trunk/src/video/sdl_v.cpp (2009-12-03 08:24:39 UTC)
15:14:15 <DorpsGek> TrueBrain: -Fix (r17776): [SDL] Reinstate pointer update on 'idle' loop.
15:14:49 <Rubidium> a 10 point forfit for you for stating the obvious myth!
15:23:12 *** Coco-Banana-Man has joined #openttd
15:27:45 <CIA-4> OpenTTD: frosch * r18391 /trunk/src/ (gfx.cpp spriteloader/grf.cpp): -Fix (r0): (Invalid) GRFs could trigger invalid reads.
15:28:57 <Rubidium> petern: the bot didn't quite recover from last night's power dip
15:31:47 *** Gremnon has joined #openttd
16:13:11 *** HerzogDeXtEr has joined #openttd
16:20:53 <Rubidium> cause val isn't changed?
16:21:36 <Rubidium> hmm, or am I making a stupid comment here?
16:22:02 <fjb> but (val & AT91_SPI_SR_ENDRX) is not 0.
16:22:50 <fjb> And I tried it also without the !, which obviouly also never ends.
16:23:12 <Rubidium> are you sure it is that snippet that causes the problem and not something that calls that snippet in a loop?
16:24:01 <fjb> I am sure. It hangs there. gcc bug?
16:24:36 <Rubidium> looks too obvious of a bug to not be noticed; what version are you using?
16:26:07 *** oskari89 has joined #openttd
16:27:04 <Rubidium> what's the definition of that constant?
16:27:06 <fjb> Hm, you were right. The loop really ends. But where is the never ending loop around it then? Thank you for the hint.
16:31:59 <SmatZ> (val & AT91_SPI_SR_ENDRX));
16:32:05 <SmatZ> you aren't casting it to long
16:32:13 <SmatZ> so it may be printing garbage from stack
16:33:01 <fjb> It is int, which is the same as long on that machine.
16:33:19 <fjb> But an explicit cast could not hurt portability.
16:33:58 <fjb> But then, on another machine the whole thing will not work anyway. It is part of a SPI driver.
16:35:09 <bartavelle> that kind of behavior should not happen
16:35:19 <bartavelle> smaller data types should be promoted
16:35:20 <SpComb> has there been any effort to document the tick-based/date-based nature of OpenTTD's various behaviours?
16:35:34 <SpComb> that is, which actions are date-based, which actions are tick-based
16:35:44 <fjb> As Rubidium hinted the loop indeed ends and there must be another loop somewhere around it.
16:36:04 <bartavelle> (was talking about that casting statement)
16:36:29 <petern> bartavelle, not as va args list
16:36:33 * fjb also likes uint32_t and uses it where ever possible.
16:37:23 * fjb goes searching for a loop.
16:40:22 <Rubidium> just do an assert in that loop and see what gdb says
16:42:34 <bartavelle> or "man backtrace" if you are into printf debugging, it will let you print a stack trace
16:42:42 <Eddi|zuHause> hm... very bad news...
16:42:48 <Eddi|zuHause> apparently somebody stole my tuba...
16:43:00 <Eddi|zuHause> along with my friend's car around it...
16:46:23 *** LordAzamath has joined #openttd
17:01:16 *** Rhamphoryncus has joined #openttd
17:04:06 *** Dred_furst has joined #openttd
17:07:46 <SpComb> 4.2K, touches under 10 lines of code
17:10:14 <Eddi|zuHause> SpComb: that's fine, but it doesn't touch any of the problematic side-features like having running costs/year exceed the buying price, exploding production etc.
17:11:01 <SpComb> it's maximum benefit with minimal changes
17:11:22 <SpComb> the next step would be to chart out how those various algorithms work, and then figure out what needs to be changed to be tick-based, and what needs to be date-based
17:12:08 <SpComb> nothing like running costs/production actually changes, the only thing that changes is the difference beteween ticks and months/days
17:12:36 <Eddi|zuHause> <SpComb> the next step would be to chart out how those various algorithms work, and then figure out what needs to be changed to be tick-based, and what needs to be date-based <-- of course, everybody said that exact same phrase for over 3 years now ;)
17:13:15 <SpComb> but changing the DAY_LENGTH is one thing that you'd have to do in any case
17:15:06 *** bartavelle is now known as bartaway
17:15:47 <Eddi|zuHause> SpComb: imho you should start with non-gameplay-alternating things that can go into trunk providing the flexibility to improve on them... e.g. replacing DAY_TICKS with a static inline function
17:16:01 <Eddi|zuHause> and then convince a dev to include that ;)
17:16:35 <frosch123> [18:33] <SpComb> but changing the DAY_LENGTH is one thing that you'd have to do in any case <- nope
17:17:03 <Eddi|zuHause> SpComb: anyway, the last time i used a daylength patch, it had problems with overflow in the saveload code for "when next AI starts"
17:17:23 <SpComb> those need to be looked at
17:18:04 <SpComb> anyways, what it's meant to be is just a better version of Sacro's daylength patch
17:18:38 <Eddi|zuHause> because 2years*365days/year*74ticks*daylength easily exceeds 65535
17:18:47 *** worldemar has joined #openttd
17:22:35 <SpComb> frosch123: why would you not want to change DAY_LENGTH?
17:23:23 <frosch123> you could as well also run the economy and esp. newgrfs in some virtual time, and only apply the factor when printing dates or introducing engines
17:23:59 <SpComb> things like running cost just need to be measured in the same unit as train movement is
17:25:03 <frosch123> well, running costs in the gui would then only apply to 1/2 year, or 1/4 year, but the ratio between income and cost would be maintained
17:25:29 <SpComb> and for example, if you change DAY_LENGTH, it doesn't affect how much you get paid for cargo delivery, because cargo ages every x ticks
17:26:19 <SpComb> industry production is currently x units / 255 ticks
17:26:46 <SpComb> but running costs are currently in actual years
17:29:17 *** Grelouk has joined #openttd
17:35:12 <SpComb> but similar to chrissicom's daylength patch
17:36:09 *** worldemar has joined #openttd
17:41:29 <Eddi|zuHause> imho, both production and delivery prices should be scaled down by daylength
17:41:45 <Eddi|zuHause> in such a way, that the yearly profit stays the same
17:43:20 <Eddi|zuHause> the town growth and the rating decay must also be looked at
17:44:31 <Eddi|zuHause> the problem with scaling down income is that you need a smaller currency unit than 1£
17:45:02 <Eddi|zuHause> all this causes huge waves, which is why no daylength patch has reached trunk quality...
17:45:10 <SpComb> that's the debate, myes
17:47:10 <SpComb> and the main thing to avoid is spreading 'daylength' code out into everything else
17:47:57 <Eddi|zuHause> SpComb: you won't achieve anything like this...
17:49:42 <SpComb> the only thing I've achieved so far is simplifying part of the code from older daylength patches
17:50:59 <Eddi|zuHause> SpComb: with daylength patch you basically have three problems: 1) you need to touch too much code, 2) you need a useful specification of the behaviour, 3) everybody wants the feature to behave differently
17:52:16 <SpComb> you need to a) figure out what's tick-based and what's time based b) abstract the code such that it doesn't need to know how many ticks there are in a day
17:52:32 <SpComb> and given, a) is a matter of opinion in many cases
17:53:18 <SpComb> vehicles move at a certain speed, and the date advances at a certain speed, everything else is measured in relation to either of those
17:54:22 <Belugas> ho ho... i have a desire to try to fix something in OpenTTD... well... fix... big word...
17:54:23 <fjb> I found the surrounding loop. And I have a hint why it never terminates. The best debugging tool is an oscilloscope.
18:01:19 <frosch123> yeah, bugs cannot stand the ray
18:05:16 *** lewymati has joined #openttd
18:12:53 <Dakkus> I am completely lost on how I should install cargodist.
18:13:09 <Dakkus> I am running the newest nightly on linux i386.
18:13:28 <Dakkus> Could anyone help me get my addiction back?
18:13:36 <SpComb> download patch, download appropriate version of trunk, read wiki, compile
18:13:47 *** worldemar has joined #openttd
18:16:39 <planetmaker> alternatively: search the corresponding thread and download a binary which suits you
18:16:57 <glx> I guess linux binaries are rare on the forum
18:20:43 <Dakkus> So, I have tried this git thing.
18:20:53 *** Polygon has joined #openttd
18:20:59 <Dakkus> It always seems to hang in the same place, resulting in:
18:21:25 <Dakkus> Cannot obtain needed object 0c3d44822083645bdaaeb796ddf0f15da6bd1c76
18:21:25 <Dakkus> while processing commit 2229cb53c11498c25090bfe06ea36c16b1e13c43.
18:21:45 <Rubidium> is that from fickfoo?
18:22:30 <Rubidium> then there's not much 'we' can do about it because fonso/fonsinchen isn't here at the moment
18:22:33 <Dakkus> Ok, apparently zoo, not foo.
18:22:47 <Dakkus> If somebody could just throw me with the files.
18:23:03 <Dakkus> I can then hunt the appropriate nightly of ottd.
18:24:17 <Dakkus> Should I then download all those many files one-by-one.
18:24:36 <Rubidium> only trunk-cargodist.diff I tihnk
18:25:20 <Dakkus> Installing the cargodist is one of the wordt UI disasters of all mankind :D
18:25:27 *** Brianetta has joined #openttd
18:30:01 <Dakkus> 's just, normally you don't really need to do something like this.
18:31:23 <fjb> Patches are not for ordinary users.
18:31:36 <Rubidium> that's because you want something that isn't released as something stable/finished
18:35:09 <Belugas> heheheh... random tree setting doe snot mean random type of trees..simply random placement...
18:39:30 <Eddi|zuHause> anybody got a heightmap of central europe(-ish)?
18:45:18 <CIA-4> OpenTTD: frosch * r18392 /trunk/src/pbs.cpp: -Fix (r13956)[FS#3345]: [YAPP] Trains on bridges were not found, when searching for the origin of a reservation. (Hirundo)
18:45:30 <CIA-4> OpenTTD: translators * r18393 /trunk/src/lang/ (5 files):
18:45:30 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
18:45:30 <CIA-4> OpenTTD: traditional_chinese - 2 changes by josesun
18:45:30 <CIA-4> OpenTTD: german - 3 changes by planetmaker
18:45:32 <CIA-4> OpenTTD: italian - 1 changes by lorenzodv
18:45:32 <CIA-4> OpenTTD: portuguese - 10 changes by JayCity
18:45:34 <CIA-4> OpenTTD: romanian - 22 changes by kkmic
19:00:11 *** |Jeroen| has joined #openttd
19:15:16 <fjb> Never read the errata section, it is scary.
19:16:52 <Eddi|zuHause> is that anything like knowledgbase entries for windows updates? :p
19:18:26 <fjb> Don't know. I never read knowledge base entries for Windows updates.
19:19:45 *** Alberth has joined #openttd
19:22:30 <Dakkus> Hmm. Sometimes it happens that mothers call.
19:22:52 <Dakkus> Anyway, so, how do I merge the .diff file to the actual source code?
19:23:22 *** Terkhen has joined #openttd
19:23:22 <Rubidium> Eddi|zuHause: doesn't windows update's expert thingy link to KBs?
19:23:56 <Eddi|zuHause> i haven't updated my windows in years ;)
19:24:11 *** Biolunar has joined #openttd
19:24:48 <Eddi|zuHause> fjb: well, basically they read like "fix exploitable buffer overflow/code injection"
19:25:58 <fjb> The erratas are more scaring.
19:30:54 <Alberth> Dakkus: with a patch program usually
19:31:21 <Alberth> Dakkus: for SVN diffs you can also use tortoisesvn, i have heard
19:31:57 <planetmaker> trunk. not nightly
19:32:21 <Rubidium> because nightlies are snapshots of trunk taken every 24 hours... and trunk isn't updated once every 24 hours but every time a developer commits something
19:33:04 <Dakkus> Since when is in develepment supposed to really mean that the product is not ready to be shipped?
19:33:15 *** Grelouk has joined #openttd
19:33:29 <Alberth> Dakkus: I have been running trunk only for years ;)
19:33:30 <Dakkus> Would be so nice if the diffs were against nightlies.
19:34:00 <Dakkus> Or even better, if there was a cargodist for a release.
19:34:04 <fjb> Patches are not for ordinary users.
19:34:42 <Dakkus> That's why it would be nice if something readier or easier could be figured out.
19:35:23 <Alberth> Patching against a random revision *is* easier ;)
19:35:29 <fjb> It will be easier when developing is done. Then the code is stable.
19:35:29 <Dakkus> Not really understanding much about actual developing, although I do know about programming, I wonder why so many other non-ready things can be just downloaded and installed with the OTTD internal tool, but this one can not.
19:37:40 <fjb> You can load a halve ready song on your mp3 player, but you have to take your solder iron to put a bigger display on it.
19:37:42 <Alberth> makes little sense, most of our users don't have a compiler at their system, and without it, there is nothing you can do with a .patch file
19:38:26 <Dakkus> Ah well. Maybe cargodist is not such a crucial thing for some other people :)
19:38:29 <Alberth> also, almost all patches are broken in some respect, that's why they are still patches instead of being integrated in trunk
19:38:48 <Dakkus> I was constantly playing ttd from 1995 to the beginning of 2009.
19:39:03 <Dakkus> Then I got bored of some stuff and tried simutrans.
19:39:11 <Dakkus> ..which was lacking some other stuff.
19:39:24 <Dakkus> But, now with cargodist I seem to have the Perfect Game.
19:39:42 <Dakkus> Just, installing cargodist has been made a tad bit overly difficult..
19:39:49 <Alberth> it should keep you happy for the next decade :)
19:40:18 <Dakkus> (By not doing anything to help installing it, which is of course acceptable. A developer doesn't have to make a really public release if he doesn't want to)
19:40:34 <Dakkus> Alberth: I believe so ;)
19:40:53 <Alberth> A developer may not have the platform you have, for instance
19:40:55 <Dakkus> (And my girlfriend unhappy)
19:41:42 <Dakkus> Eveh if he himself doesn't, many other able developers do.
19:41:57 <Dakkus> But hey, to underline: I am not really complaining about how people are doing thigs.
19:42:00 <Alberth> 'what linux' is a better description, there are about 40-50 distributions
19:42:15 <Dakkus> Instead, I am complaining of the destiny being evil to me.
19:42:36 <fjb> Why should other developpers care for what you demand instead of developing their stuff further (which will make many more people happy beside you).
19:42:55 <Dakkus> I am not trying to see that someone is guilty for there not being an easier way. People are doing stuff on their free time and can't be forced to anything :)
19:43:23 <Dakkus> Alberth: Well, openttd.org has a thing called "generic linux binary".
19:43:24 <Alberth> building a patched OpenTTD at a Linux system is dead easy
19:43:44 <Dakkus> Making one version of the patch against the latest release or a predefined nightly would make things easier.
19:43:44 <fjb> Instead of complaining you could start to learn.
19:44:07 <Dakkus> Too much stress in life.
19:44:30 <fjb> Too much stress to helt people unwilling to learn.
19:44:49 <Dakkus> That's precisely why I am not complaingin about the developers, but rather about the cruelty of life.
19:45:22 <Dakkus> I have no problems accepting that just like I have no time for developing this part of OTTD, no other people have, either.
19:45:42 <fjb> So you say we should not listen to you? That is an easy to full fill wish.
19:46:10 <Dakkus> Yeah, nobody should not listen to me if they don't want to :)
19:46:28 <planetmaker> or you could really learn these 5 easy steps or so.
19:46:47 * Dakkus already loaded the page
19:47:32 <Dakkus> I think I'll just patch something and publish the source in the thread.
19:49:13 <Dakkus> Ha! Found a diff made against something that had also become a nightly! :)
19:50:45 <Dakkus> Now there's no need to install SVN, which would eat up quite a part of the few tens of megs that I have free on my SSD and that I really need for my swap.
19:51:16 <Dakkus> I think I will also uninstall git. It ate up almost 9 MB.
19:57:58 *** fonsinchen has joined #openttd
19:58:51 <Eddi|zuHause> you should really consider compiling on a "real" computer ;)
19:59:57 <Dakkus> Can't compile anything on this computer, because there is no compiler and no disk space for installing a compiler.
20:00:17 <Xaroth> what kind of pc is that?
20:00:50 <Dakkus> I am pretty much out of money, so this was the only thing I could afford and I really needed a computer of some kind to read my email.
20:01:58 <Dakkus> Filesystem Size Used Avail Use% Mounted on
20:01:58 <Dakkus> /dev/sda1 3.5G 3.2G 109M 97% /
20:02:16 <Dakkus> Well, I could of course try installing g++ and then uninstall it after compiling ottd...
20:03:28 <Dakkus> After this operation, 37.0MB of additional disk space will be used.
20:16:43 <Dakkus> Wheww! Got through the dependencies and still have some 20 MB of space free.
20:17:01 <Dakkus> After the make I'll see if things start working and if they do, I can get playing.
20:17:23 <Dakkus> Oh, and in between of course remove g++, sdl and their dependencies.
20:20:16 *** HerzogDeXtEr has joined #openttd
20:20:42 <fjb> And be aware of the bugs in older cargodist releases.
20:28:52 *** thermal2008 has joined #openttd
20:29:43 *** Chris_Booth has joined #openttd
20:30:39 <thermal2008> Hi, when playing openttd I noticed the sawmill only accepts wood from the center tile. Some of the other industries accept their items from any graphic square. is that correct?
20:31:35 <Alberth> apparently, that is how the industry is coded.
20:32:16 <thermal2008> ya, just wondering if it was a bug.
20:32:31 <thermal2008> the old grf were used
20:33:40 <Dakkus> /tmp/ccHPX2vf.s:6309: Fatal error: can't write depot_gui.o: No space left on device
20:33:46 <Alberth> afaik 'New' only means it is extended with additional stuff since the original version
20:34:02 <Alberth> Dakkus: remove the IRC program, takes way too much space :p
20:35:15 <thermal2008> there is 8 tiles for the sawmill, and it accepts wood from the center. I don't believe that is consistent with the other industries
20:35:41 <Alberth> you are allowed to believe that :p
20:35:47 <frosch123> thermal2008: use the "land area information" tool to test which tiles accept
20:36:01 <Alberth> you can also change it by making a new NewGRF for it :)
20:36:14 <frosch123> you need to collect 8/8 acceptance inside the station catchment
20:38:01 <thermal2008> i understand, I tested using land area information. The houses accept passengers, and one of the squares accept wood
20:38:10 <thermal2008> i didn't know it was that detailed
21:05:57 <Chris_Booth> has anyone seen the client list in lastest nightly (r18387)
21:06:16 <Chris_Booth> is that accidental or have it been broken?
21:06:26 <Chris_Booth> it is impossible to use
21:08:29 <frosch123> what's wrong with it?
21:08:46 <Chris_Booth> you cant read the names on it
21:09:02 <Chris_Booth> as it is the wrong dimentions
21:10:00 <frosch123> yeah, it does not resize
21:12:46 <petern> hmm, when not using autorail, placing horizontal tracks to the right requires the pointer to be nearly off the next tile in some cases
21:13:00 <petern> and dragging to the left selects the next tile too early
21:16:52 <SpComb> Dakkus: compiling OpenTTD will take up a lot of disk space
21:17:34 <frosch123> hmm, how useful, loop over all clients to collect the longest name, and then throw the value away :p
21:19:03 <SpComb> Dakkus: but if you want to use development code, you need to be a developer :)
21:19:06 <SpComb> ...or a lazy windows user
21:21:16 <teeone> 250MB is alot of space?
21:21:43 <Eddi|zuHause> is there a python module for solving simple 3D equation systems?
21:22:28 <Eddi|zuHause> i mean, i can program that within half an hour, but the question is if i am faster searching for that ;)
21:23:38 <SpComb> teeone: if you have a 4GB "SSD", yes, or if you keep a dozen compiled versions of OpenTTD around
21:24:30 <teeone> SSD's are starting to come down
21:24:41 <teeone> eyeing the 120GB one when it gets a lil cheaper
21:28:16 * planetmaker wonders how it looks like, if a super star destroyer comes down :-P
21:28:54 <SpComb> 80GB of SSD should be enough for anyone
21:29:12 <teeone> not really ;) not ifyou want to install games to it
21:29:12 <SpComb> assuming you can sensibly move stuff between it and a normal disk
21:29:16 <planetmaker> [22:17] <frosch123> hmm, how useful, loop over all clients to collect the longest name, and then throw the value away :p <-- lool. Don't tell me you do it in OpenTTD ;-)
21:29:39 <planetmaker> SpComb: 640kByte should be enough RAM for anyone :-P
21:29:52 <frosch123> planetmaker: it has been like that for several 100 revisions
21:30:01 <frosch123> and _you_ did not notice
21:30:22 * planetmaker was busy with OpenGFX :-P Does that count?
21:30:26 <SpComb> planetmaker: it would be people wrote good code!
21:30:27 <Eddi|zuHause> don't blame me, i never play online...
21:30:47 <SpComb> I only play co-op online with some friends
21:30:50 <frosch123> and some random #-guy turns around, and complains the nightly is broken :p
21:31:07 <planetmaker> SpComb: I can easily imagine zillions of apps which won't fit in there with their data stack ;-)
21:31:14 <planetmaker> regardless of the code quality
21:31:52 <teeone> didnt the old commodore64 have 64kb of ram
21:33:29 <frosch123> Eddi|zuHause: you see, your guesses are quite bad recently
21:34:06 <Eddi|zuHause> hey, it only means i'm not a prophet after all
21:35:09 <planetmaker> nice, Rubidium :-)
21:35:17 <frosch123> and now sit down, and increase the 64k vehicle limit till tomorrow
21:37:13 <petern> (although i didn't bother setting it up)
21:37:21 <Rubidium> yeah, that would probably help
21:37:33 <Rubidium> although the ^ and v images are still too big
21:50:54 <Zuu> Non OpenTTD-question: Why do g++ complain about:
21:50:56 <Zuu> std::set<std::string>::iterator i;
21:50:56 <Zuu> Of course it will fail at runtime, but why does it complain about a const assignment even if a non const_iterator is used?
21:57:12 <Alberth> sets need constant values most likely
21:58:07 <Zuu> Hm, makes sense actually. Well I guess I have to use something else than a set then.
21:58:27 <Zuu> MSVC of course have no problem with it. :-)
21:58:52 <Zuu> Or well it has a problem, it does not complain about things that are not okay according to the standards.
21:59:16 <Alberth> those are called 'enhancements' :p
22:08:50 *** TheMask96 has joined #openttd
22:29:05 *** Chris_Booth has joined #openttd
22:34:02 <Dakkus> SpComb: Luckily only some of the space had to be on the internal HD. I am installing the game on a memory stick, anyway. The actual problem was with the dependencies, but being dev dependencies, they can be removed when the program's installed.
22:42:57 *** KenjiE20 has joined #openttd
22:46:33 <teeone> openttd uses 0.02% of my cpu while im playing it..thats incredible
22:46:46 <Zuu> Nice, automake "forgot" to generate some rules.. :-)
22:47:21 *** Chris_Booth is now known as Guest1170
22:47:22 *** Chris_Booth has joined #openttd
22:53:40 *** ChanServ sets mode: +v Belugas
23:13:26 *** Chris_Booth has joined #openttd
23:27:35 *** Rubix`` has joined #openttd
23:29:17 <Dakkus> My Openttd functions and the cargo now has meaningful destinations.
23:30:00 <Dakkus> Unfortunately publishing the patched source was not possible, because of missing hard drive space for the tarball...
23:30:14 <Dakkus> But still, I am very content and shall keep playing for another decade.
23:39:06 <SpComb> publishing patched source is kind of silly
23:39:27 <dihedral> it's kind of silly not to even have 3mb of space left :-D
23:39:46 <SpComb> that too, but it's more understanable
23:39:59 <SpComb> e.g. student user quotas on my uni's system are a whooping 200MB
23:40:18 <SpComb> about half of which goes to your firefox profile
23:41:15 <dihedral> even on those you have /tmp for creating the tar
23:41:20 <dihedral> and then you can upload it somewhere
23:42:06 <SpComb> but it really sucks if you're trying to develop some medium-size C++ project
23:42:23 <SpComb> (+dep libs with debug syms)
23:42:28 <fjb> But who cares for the patched source of cargodist from October?
23:42:51 <SpComb> people who don't want to install svn
23:44:21 * SpComb had a go at fixing vehicle running costs for daylength
23:44:26 <SpComb> which isn't very important in the end
23:44:45 <SpComb> I think I'll try and find a way to slow down town growth, and then playtest with that myself
23:58:12 *** markj0nes has joined #openttd
23:59:58 *** CrazyPhoton has joined #openttd
continue to next day ⏵
