IRC logs for #openttd on OFTC at 2011-10-04
⏴ go to previous day
04:22:08 *** DayDreamer has joined #openttd
04:56:24 *** Eddi|zuHause has joined #openttd
06:08:50 *** Cybertinus has joined #openttd
06:28:26 *** Br33z4hSlut5 has joined #openttd
06:52:04 *** norbert79 has joined #openttd
06:56:01 <Elukka> norbert79, i finished my coal :P
06:56:43 <norbert79> Elukka: Lokes lovely, well done... What did you use in the end?
06:57:26 <Elukka> sand, paint, glued on a piece of cardboard, crumpled paper under it to keep it up (the coal tubs can be opened from the bottom)
06:58:00 <norbert79> Nice. Looks like filled up for real
06:58:34 <norbert79> I wonder though how colored sand could have worked...
06:59:13 <Elukka> well, i still have to solve the ballast issue
07:04:26 <Elukka> gonna take a bit more experimenting to see if painted sand can yield a good enough result
07:07:13 <norbert79> What about ball-shaped chewing gums cut in half?
07:07:28 <norbert79> and glue on the paper
07:07:39 <norbert79> but on it's bottom side
07:55:44 *** Brianetta has joined #openttd
07:58:17 <Kogut> well, my cargo cult coding failed
08:01:29 <Kogut> reusing existing code with understanding how it works
08:01:53 <Kogut> reusing existing code without understanding how it works
08:02:34 <Kogut> It is possible to compile it, but it is *not* working
08:04:33 <Kogut> well, I will try to copy also this line, there is similar bit shift
08:05:43 <appe> i tried to mend some cargo thingy grf
08:06:13 <appe> and botched it completely
08:07:03 <Kogut> well, last year I even managed to create sth working. But for unknown reason openttd always crashed on exit.
08:07:34 <Kogut> now I want to create path that will be included into trunk
08:07:51 <Kogut> as my AI needs additional function
08:09:54 <Kogut> "The term cargo cult programmer may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or if it is required in its new position."
08:09:56 <appe> haha, you know you have been playing to much ttd when you wonder why there is no train in the wiki logo.
08:15:14 <Kogut> well, now sth changed, ais are unable to build ANY waypoint
08:15:48 <norbert79> Kogut: Maybe understanding the basics would help a bit :)))
08:16:33 <Kogut> my original plan is to post not working patch to show that I tried sth
08:16:51 <Kogut> and mybe sth competent will fix (=do) it...
08:16:53 <norbert79> I am just saying.. Think about it: you spend as much time just by copying the code and use "try error"; yet this time could be used for spending some time understanding basics :)
08:17:39 <Kogut> openttd src is over 50 MB
08:17:54 <norbert79> Sure, but there are development pages also available :)
08:20:45 *** Progman has joined #openttd
09:06:24 *** Brianetta has joined #openttd
09:39:05 *** ben_ is now known as Sacro_Work
09:39:27 *** Sacro_Work is now known as SacroWork
09:44:18 <dihedral> SacroWork ... that sounds like an ass load to do :-P
09:47:30 <norbert79> ass-load... You know, when you transport attractive women
09:50:25 <appe> this is the old water tower of ronneby, sweden
09:50:39 <appe> someone just bought it, and is now restoring it to an apartment
09:53:40 <norbert79> appe: Won't be if you want to move in with your furniture
09:54:01 <norbert79> appe: or would like to take a walk to a nearby store buying some groceries :)
09:56:27 <appe> it has an elevator installed
09:57:00 <appe> and a person that can afford fixing that place up can also afford some special furniture ;)
09:58:36 <norbert79> Just heard: "Beertransport is the most attractive sport on earth..."
10:03:56 *** KenjiE20 has joined #openttd
10:15:33 <MNIM> what are you, a north west german?
10:16:06 <norbert79> I could be an austrian too :)
10:17:10 <MNIM> dunno, never heard that used in austria.
10:17:17 <MNIM> then again, Ive never been in austria. :P
10:35:19 <norbert79> MNIM: Do you know "New Kids"? Am just being curious then "Nitro" will come out...
10:35:49 <MNIM> haven't seen anything of the movies or anything, though
10:35:54 <norbert79> Nice... Being a fan too... Just can't await. Was promised for December
10:36:29 <norbert79> MNIM: I have found some on-stage pictures, dunno if it was Nitro or Turbo
10:38:15 *** michi_cc has joined #openttd
10:38:15 *** ChanServ sets mode: +v michi_cc
10:38:45 *** michi_cc has joined #openttd
10:38:45 *** ChanServ sets mode: +v michi_cc
10:40:17 <norbert79> MNIM: Let's hope the reason of having no news around the movie is because of secrecy, and not because it's on hold...
10:43:19 *** michi_cc_ has joined #openttd
10:52:44 *** michi_cc_ has joined #openttd
10:54:59 *** michi_cc_ has joined #openttd
10:55:22 <Eddi|zuHause> great, now we also have invincible engines!
10:56:10 <norbert79> appe: used to be a Dutch TV series, in 2010 there was also a seperate movie
10:56:18 <norbert79> Eddi|zuHause: Wait, what? Why?
10:56:46 *** michi_cc_ is now known as michi_cc
10:56:52 <norbert79> Eddi|zuHause: Wasn't the option for breakdowns not enough? Or why?
10:57:10 <appe> but "nitro" and "turbo" sounds pretty darn german.
10:57:34 <planetmaker> invincible. Great :-)
10:57:40 <norbert79> appe: Well, they love old Hardcore, and Scooter, so yeah, tiny bit related to Germany too
10:57:43 <planetmaker> Thomas the tank engine?
10:58:23 <norbert79> Eddi|zuHause: "This means no tottering trains. Great isn't it?" No, it isn't... I am starting to think, that people starting losing the main point here...
10:59:42 <norbert79> Eddi|zuHause: You know what? We should eliminate finance at all, since why to bother about it, everyone gets rich in a flash anyway
10:59:48 <norbert79> Eddi|zuHause: </sarcasm>
11:00:02 <Eddi|zuHause> why tell me that?
11:00:14 <norbert79> I am just ranting, don't take me too serious
11:00:59 <norbert79> I just dislike the way how people just started eliminating key functions, the main concept of the game
11:02:10 <planetmaker> which key function was eliminated?
11:03:04 <V453000> I dont see why is the invisible engine a bad thing. The only thing it does is adding some extra depth and options to the game, and if it could add some even further depth, why not. Nobody is forced to use it
11:03:42 <planetmaker> V453000, _invincible_ is the word there in the last posting ;-)
11:04:13 <planetmaker> norbert79, but I don't see how an _invisible_ engine removes a key function of the game ;-)
11:04:16 <V453000> oh well :) I guess we all know what he meant
11:04:46 <norbert79> planetmaker: I doubt it's about the invisible one... But I might be wrong here
11:05:09 <V453000> what else would it be about
11:05:11 <norbert79> planetmaker: Getting confused to be honest seeing the topic's name
11:06:02 <norbert79> planetmaker: being invisible and being invincible are two separate things in my vocabulary :)
11:06:04 <V453000> he just thought it is the original usage I suppose :)
11:06:23 <Kogut> @planetmaker - is it possible to raise error message/information window/print sth to console output from random openttd function?
11:06:28 <V453000> I think the relation to invisible engine newgrf is obvious
11:06:44 <V453000> but still, how would even an invincible engine remove key functions of the game?
11:08:26 <Eddi|zuHause> Kogut: like "DEBUG(misc, 0, "blah %d", 12345)
11:08:47 <Kogut> And it will print message to console?
11:09:26 <Eddi|zuHause> to the "out-game" console by default, and when you set "developer 2" also to the in-game console
11:10:07 <Eddi|zuHause> Kogut: for a "dirty" patch, you can also simply use printf
11:10:30 <Kogut> I tried ctrl-f, but I found many, many instances of calling this function instead of definition
11:10:52 <Terkhen> Kogut: in mingw/msys, text will only appear in the console if you run configure with the --enable-console option
11:10:52 <Kogut> second parameter is priority of error message?
11:11:34 <Terkhen> check the definition of the DEBUG macro
11:11:56 <Eddi|zuHause> first parameter is a category, second a debug level, third is the message, fourth, fifth, etc. are parameters to the message like in printf
11:11:56 *** Biolunar has joined #openttd
11:12:56 <Eddi|zuHause> so if you have "DEBUG(ai, 3, "blah")", then it will only show the message if you start with "openttd -d ai=3" or so
11:13:32 <Kogut> "when you set "developer 2" also to the in-game console" - is it #def somewhere in random .cpp file? Or maybe setting from config file?
11:13:57 <Eddi|zuHause> "developer 2" is a command you enter in the ingame console
11:14:27 <Eddi|zuHause> dunno if there's a config setting for it
11:15:58 <norbert79> Eddi|zuHause: Maybe the allow_developer
11:16:44 <Yexo> "developer" is an alias for "set developer"
11:16:58 <Kogut> 2 hours to *find* function that I should change
11:17:18 <Kogut> to allow AIs use ctrl click during waypoint construction
11:17:26 <Yexo> which means that "developer 2" is the same as "set gui.developer 2" which is the same as changing the setting "developer" in the "[gui]" section int he config file
11:17:56 <Yexo> Kogut: isn't that CmdBuildWaypoint?
11:18:09 <Yexo> or rather, the AI API function that calls that one?
11:18:40 <Kogut> and even managed to add second parameter
11:18:53 <Kogut> but I missed sth as it changed nothing
11:20:54 <Kogut> AI can call AIRail::BuildWaypoint with two parameters, but my cargo-cult-coding failed here - "StationID waypoint_id" is ignored
11:21:27 <Kogut> by the way, how bitfields are better than normal parameters
11:26:22 <Yexo> easy to transmit over the network in a general way
11:27:15 <Yexo> parameters are not randomly ignored
11:31:20 <Kogut> Now I think that maybe second parameter should be changed
11:31:27 <Yexo> AIStation::IsValidStation will always return false for WaypointID
11:32:13 <Yexo> you should call AIBaseStation::IsValidStation instead
11:32:30 <Yexo> or actually AIWaypoint::IsValidWaypoint
11:33:01 <Yexo> and this diff will never be excepted
11:33:11 <Yexo> you can't add or remove paramters to functions
11:33:31 <Yexo> which means you have to change the name of the function and provide the old function in the bin/ai/compat_*.nut scripts for backwards compatibility
11:35:19 <Kogut> wait, is it impossible to reload function in squirrel?
11:35:33 <Yexo> what do you mean by reload?
11:37:08 <Yexo> default parameters are supported, but not for C++ functions
11:38:12 <Kogut> I like rivers in default world generator
11:44:56 <Kogut> due to ctrl+f navigation I missed doxygen comment above the CmdBuildRailWaypoint function
11:50:45 <Kogut> @Yexo in CmdBuildRailStation comment there is info ("p2 = (bit 16-31) - station ID to join (NEW_STATION if build new one)")
11:50:53 <Kogut> in CmdBuildRailWaypoint there is nothing like this
11:51:18 <Kogut> but it is possible to create separated waypoint
11:52:32 <Kogut> I see it - it is in "custom station id" part of bifield
11:57:22 <Yexo> waypoints are not stations
11:59:12 <Kogut> @Yexo - what about AIRail::BuildRailWaypointTileRectangle (now there is BuildRailWaypoint and RemoveRailWaypointTileRectangle). Unfortunately it will require to provide also "Rectangle" part
11:59:52 <Kogut> as AIRail::BuildRailWaypointTileRectangle(tile, tile, waypoint_id)
12:00:09 <Kogut> or maybe AIRail::BuildRailWaypointCtrl ?
12:01:03 <Yexo> BuildRailWaypointRectangle is fine with me
12:01:47 <Yexo> StationID station_to_join = GB(p2, 16, 16); <- from CmdBuildRailWaypoint
12:01:54 <Yexo> so it's p2 bits 16 to 31
12:02:12 <Yexo> which is not documented above the function
12:02:46 <Kogut> so "INVALID_STATION << 16" should be replaced by "(AIWaypoint::IsValidWaypoint(waypoint_id) ? waypoint_id : INVALID_STATION) << 16"
12:04:10 <Yexo> but don't forget to set bit 1 in p1 if station_id != AIStation::STATION_JOIN_ADJACENT
12:16:03 <Kogut> @Yexo - BuildRectangle - is it supposed to behave in the same way as normal interface? (all or nothing, possible to drag only perpendicular to tracks, square must be one tile wide)
13:06:38 <Eddi|zuHause> in an nml-switch, how can i achieve something like "4,7,10,13,16: return dummy_zzzd3;" without copy-pasting myself silly?
13:08:36 <planetmaker> you can't. you'll have to duplicate the lines
13:08:55 <planetmaker> each random number needs one. Except if you use a range
13:09:30 <Eddi|zuHause> honestly, that's silly.
13:10:02 <Eddi|zuHause> planetmaker: and something's wrong with your makefile. it doesn't recognize changes in _any_ pnml file anymore without a make clean
13:10:21 <Eddi|zuHause> gnml files are fine, though
13:11:04 *** TWerkhoven has joined #openttd
13:11:31 *** Kurimus has joined #openttd
13:15:50 <Eddi|zuHause> hm... Henschel-Wegmann-Zug doesn't reach top speed... might need to tweak air drag
13:17:31 <Eddi|zuHause> top speed is 175, on practical use it typically reached 160 travel speed, but ingame it only reaches 136
13:19:17 <Belugas> planetmaker! hello you :)
13:19:32 <Eddi|zuHause> but it's nice how the purchase menu lists both passenger and mail capacity
13:26:34 *** rhaeder has joined #openttd
13:55:55 *** Adambean has joined #openttd
14:14:51 *** Brianetta has joined #openttd
14:20:46 <planetmaker> Eddi|zuHause, I can't confirm your statement "pnml files don't trigger a recompile". All tests I ran during re-write and everything I test now works as it should
14:20:52 <planetmaker> you must be doing something strange
14:22:29 <Eddi|zuHause> planetmaker: happened twice now with different files, i had an error during compiling, fixed it, and it still complained about the same error
14:23:54 <Eddi|zuHause> planetmaker: try with cargo_definitions.pnml, move one of the cargos to the end of the list (should fail with bitmask entry > 31), and then move it back
14:25:28 *** mikethete has joined #openttd
14:59:30 <tompaw> I have a problem with mouse pointer in osx build of 1.1.3. It acts... weirdly. Outside openttd window small mouse movements are translated into pointer movements correctly. In openttd it looks like there's some movement 'treshold' that I have to achieve to get a pointer movement.
14:59:42 <tompaw> Not sure if I explain it in a way anyone understands :P
15:00:20 <planetmaker> I think I understand you. But ... I can't confirm that issue
15:00:36 <planetmaker> any special hardware or settings wrt mouse sensitivity?
15:04:19 *** supermop has joined #openttd
15:04:42 <tompaw> Everything at default.
15:05:18 <tompaw> Mouse looks a little "lagged" in openttd window anyway. Not sure why.
15:05:27 <tompaw> Is there any setting I can change?
15:06:20 <planetmaker> hm, not that I'm aware of
15:06:25 <planetmaker> which osx do you use?
15:06:57 <planetmaker> and which graphics card?
15:08:08 <tompaw> Well, it's a dual-gpu mac book pro, so intel hd 3000 and radeon hd 6750m
15:08:21 <tompaw> That might be the thing - I'm not sure if openttd enables the radeon gpu successfuly.
15:08:41 <peter1138> openttd isn't 3d, so...
15:08:43 <planetmaker> openttd doesn't really make use of any gpu
15:08:56 <tompaw> Why the question then? :-)
15:09:18 <planetmaker> but... they might handle the 2D stuff and the colour depth differently well...
15:09:59 <norbert79> planetmaker: Knowing Macs in general I think something high end, so that mustn't be the issue, imo
15:10:17 <norbert79> planetmaker: What if SDL related?
15:11:01 <norbert79> Oops, bus arrival soon, must go... later
15:11:11 <planetmaker> then it wouldn't be a mac...
15:12:27 <planetmaker> hm, sorry, tompaw, there's no quick fix for that. Nor did I actually notice that on my lion install so far
15:12:47 <planetmaker> there are issues, but I've not seen that one
15:13:00 <tompaw> planetmaker: ok, thanks for your help. Maybe it's me getting too paranoid but now I tried it on a touchpad and I really think there's like 0.00001ms lag
15:13:30 <tompaw> you know what I mean, not actually 0.00001ms ;-)
15:13:38 * planetmaker could now talk about computers usually working with 1ms resolution ;-)
15:14:06 <planetmaker> anyway, time for sports.
15:14:40 <tompaw> The other issue I noticed is when I clicked on 'full screen' the whole thing went black.
15:14:58 <tompaw> Sound was working, but screen was totally dead, only thing I could do was power off and on.
15:15:04 <tompaw> (not using full screen since then :P)
15:21:15 <CIA-2> OpenTTD: truebrain * r22989 /trunk/src/ai/api/ai_object.hpp: -Fix: AIController uses protected members of AIObject, so make them friends (instead of doing it implicit via AIInstance). This fixes all compile errors with clang-2.9
15:30:52 <mikethete> the usage of signals for me is forgen
15:37:48 <peter1138> tompaw, alt-enter ;P
15:39:34 <tompaw> peter1138: didn't work :P
15:40:04 <michi_cc> Might be Ctrl or Cmd on OS X instead of Alt.
15:54:00 *** valhallasw has joined #openttd
16:11:47 <michi_cc> Eddi|zuHause: Do you really need 61+62 of your proposed 6x vehicle vars separately, or 64 be enough?
16:12:25 <Eddi|zuHause> i think 61 and 62 can be removed
16:12:47 <michi_cc> And for 64 you wrote on the forum about possible using vehicle relative values, would they be better and how would those look like?
16:15:52 <Eddi|zuHause> well, a "simple" coordinate translation, with the vehicle's travel direction as x axis (+ is forward), y is sideways (+ is left), and z is vertical (+ is up)
16:16:00 <Eddi|zuHause> but i don't know if that's really necessary
16:17:00 <Eddi|zuHause> you get problems with scaling the vehicles travelling diagonally
16:17:09 <Eddi|zuHause> so probably just ignore that statement
16:18:27 <Eddi|zuHause> what i'm currently thinking of is using the x/y/z coordinates to somehow change the anchor point of the current wagon's sprite to match the one of the previous or next vehicle
16:18:46 <Eddi|zuHause> so i can split up the long wagon sprites in two
16:19:01 <Eddi|zuHause> and both being drawn synchronously
16:19:46 <Eddi|zuHause> without the ability to adjust the anchor point, i can only sensibly do that for straight rails
16:21:08 <michi_cc> What was your intention with 63? Hiding in wormholes?
16:21:44 <Eddi|zuHause> like bit 7 in var64
16:21:59 <Eddi|zuHause> so 63 can be removed, too
16:22:58 <Eddi|zuHause> what i also still need is all values that change the appearance of the referenced wagon (capacity, load, cargo, subcargo, randomization, ...)
16:23:29 <Eddi|zuHause> because the dummy vehicle must replicate these same decisions
16:24:56 <Eddi|zuHause> how does randomization even work?
16:29:45 <Eddi|zuHause> statistics of the day: airport munich responsible for 10% of CO2 emissions for whole of bavaria
16:32:30 <Eddi|zuHause> the VS_HIDDEN bit can also be used to switch on lights when part of the train is in a tunnel :)
16:34:59 <michi_cc> Capacity (and everything changeable by CB36) is a no go I think, too much unpredictable behavior with circular references.
16:35:30 <Eddi|zuHause> then "fraction of load to capacity"
16:35:42 <DorpsGek> michi_cc: frosch123 was last seen in #openttd 20 hours, 52 minutes, and 32 seconds ago: <frosch123> do the houses move from time to time?
16:36:35 <Eddi|zuHause> or we can't use loading stages
16:36:51 <Eddi|zuHause> at least for wagons > 8lu
16:40:40 <Kogut> How GB function works? Again, I failed to find definition :(
16:45:52 <Kogut> @planetmaker How GB function works?
16:46:11 <Yexo> Kogut: core/bithmath_func.hpp
16:46:23 *** Progman has joined #openttd
16:54:02 *** Brianetta has joined #openttd
16:56:42 *** DayDreamer has joined #openttd
17:05:18 <Eddi|zuHause> need some creative way to suppress this warning: "src/DRG/61.gnml", line 57: Block 'DRG_61cb_articulate_switch' is not referenced, ignoring.
17:07:20 <Kogut> funny thing, I am (again) unable to load any website
17:07:20 <Yexo> Eddi|zuHause: wait for (or implement yourself) nml #3106
17:14:25 <Eddi|zuHause> Terkhen: it's an autogenerated block, and currently this is the only engine that overrides it
17:15:51 <Eddi|zuHause> Yexo: that's not quite what i meant
17:16:11 <Eddi|zuHause> Yexo: i meant suppress for this special instance, get all other warnings as usual
17:16:56 <Terkhen> change the autogeneration script so you can add something to entries to ignore them
17:17:07 <Eddi|zuHause> michi_cc: might it be possible to make certain variables unavailable during cb36?
17:17:39 <Eddi|zuHause> Terkhen: yeah, but i said "creative" :)
17:18:01 <Terkhen> nml #3106 or not paying attention to it then :P
17:20:18 <MNIM> Oops. Seems I forgot to include ECS wood vector in this game
17:21:18 <b_jonas> can you recommend me vehicle replacement newgrfs that keep the game on about the same difficulty as the standard (ttd) vehicles? I'm interested in temperate climate.
17:23:04 <b_jonas> (at least, same difficulty for rail. it could be easier for other modes of transport.)
17:23:16 <b_jonas> I tried a replacement set but I got much weaker trains.
17:24:58 *** Alberth has joined #openttd
17:24:58 *** ChanServ sets mode: +o Alberth
17:25:25 <b_jonas> hmm, I should convert this network to maglev
17:26:40 *** z-MaTRiX has joined #openttd
17:27:45 <Pinkbeast> jonas> 2cc has adjustable costs so you can get them about where you want, but most replacement sets are at least a bit harder.
17:30:08 <b_jonas> a bit harder is no problem, but what I tried wanted to be based on real engines and seemed much harder
17:30:33 <b_jonas> adjustable costs won't give me an enjoyable games if the trains are very slow
17:30:52 <b_jonas> I mean, I'd like them about as fast as the ttd trains
17:32:27 <b_jonas> hmm, by the way, which newgrf replaces monorail (or maglev) with narrow rails?
17:32:53 <b_jonas> that's a separate question, narrow rail trains might not be what I want in difficulty
17:33:21 <Pinkbeast> Well, speed changes over time, I'm not sure the default trains are appreciably faster.
17:33:36 <b_jonas> Pinkbeast: oh, it wasn't 2cc I tried
17:33:40 <Pinkbeast> For example before 1934 the only default locomotive is 40mph.
17:33:57 <b_jonas> I tried Japanese trains I think, which seemed to have slower trains in the same time compared to ttd trains
17:34:45 <Pinkbeast> Then you have the 70mph Jubilee and 80mph (!) A4 until 1954.
17:35:14 <Elukka> well... train sets do tend to go with roughly real speeds
17:35:44 <Elukka> not sure they're slow though?
17:37:13 <Eddi|zuHause> there are easily huge speed differences if you take the maximum speed of the engine, or the speed they usually travelled at
17:37:47 <Elukka> true... incidentally, what are we doing for cets?
17:38:05 <b_jonas> it's okay if they start slow, but they should eventually get faster: this includes not only the SH40 and Asiastart, but eventually the monorails and maglevs.
17:38:13 <Pinkbeast> Whereas (for example) UKRS1 has 95mph Pacifics in 1924, UKRS2 similar, NARS the 110mph 4-6-4 in 1930, I forget what 2cc has but it sure beats 40mph before 1934... so I'm not sure why you (jonas) say the default trains are faster.
17:38:44 <b_jonas> wait, let me load that game
17:39:01 <Elukka> dbset uses the max speeds and the streamlined br 05 is the ultimate passenger locomotive for the longest time, which is kinda odd
17:39:13 <Pinkbeast> What you _can't_ do in most addon sets is throw heavy freight around the map at passenger speeds.
17:39:25 <Pinkbeast> But that's down to wagon speed limits.
17:40:00 <b_jonas> probably that, and also train power
17:40:12 <Eddi|zuHause> for all except express passenger trains, which will likely get some severe running cost penalty
17:40:42 <Pinkbeast> Nope; you can add more train power by multiheading but wagon speed limits are a hard limit (except this weird thing they do in 2cc)
17:41:23 <Pinkbeast> Also in most addon sets if you ignore tractive effort you will have problems whereas with default trains it's a non-issue
17:41:49 <Elukka> my dream openttd game right now involves a completed CETS, FIRS and a more playable YACD :P
17:41:50 <b_jonas> that was my problem with the ttdpatch set too: the monolev trains are good for passenger, but don't like heavy cargo
17:42:17 <Pinkbeast> Heavy freight on maglevs is faintly absurd
17:42:32 <Eddi|zuHause> Elukka: and then add in more height levels, flexible bridges, ...
17:43:20 <Eddi|zuHause> ones where you can build signals, curves, switches, stations, etc. on
17:43:53 <Pinkbeast> If you're going to do that to wormholes, do it to tunnels first. There's a lot less drawing involved. :-)
17:44:00 <b_jonas> even diagonal bridges would be pretty cool
17:44:20 <b_jonas> and I'd swap the ability to build signals under bridges to the ability to build signals on bridges any day
17:44:23 <Elukka> okay, if we're gonna get silly-awesome let's throw in multi aspect signals too :P
17:44:27 <b_jonas> because signals under bridges are difficult to see
17:44:39 <b_jonas> multi-aspect signals? what are those?
17:44:46 <Eddi|zuHause> and sensible timetable management
17:45:13 <CIA-2> OpenTTD: translators * r22990 /trunk/src/lang/ (latvian.txt malay.txt):
17:45:13 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:13 <CIA-2> OpenTTD: latvian - 38 changes by Parastais
17:45:13 <CIA-2> OpenTTD: malay - 32 changes by rionix88
17:45:19 <Elukka> doesn't seem like that patch is very alive, unfortunately
17:46:02 <Eddi|zuHause> that's all Rubidium's fault
17:46:27 <Eddi|zuHause> oh, you meant the signals, not the timetables
17:46:37 <b_jonas> Elukka: thanks for the link
17:48:00 <Pinkbeast> Prototypical signalbox operation in the early years would be interesting too (but much of this signalling stuff is not really viable with current OTTD train numbers and volumes)
17:48:11 <b_jonas> I'm also very happy you've finally added the diagonal landscaping and diagonal dynamite to the official tree
17:49:21 <Pinkbeast> jonas> UKRS1 might be what you want; unlike many addon sets, it does have a reasonable selection of futuristic trains.
17:49:24 <Elukka> YACD goes a lot towards more sensible freight volume and, in general, more realistic transport
17:49:32 <Elukka> i just don't think it's very playable in its current state
17:49:43 *** KenjiE20 has joined #openttd
17:49:50 <Elukka> UKRS1 has a futuristic steam train! :P
17:49:54 <Pinkbeast> But train _length_ creates a lot of problems with junctions and signalling.
17:50:09 <Pinkbeast> Two, there's an entirely hypothetical Wardale 604
17:50:21 <b_jonas> Pinkbeast: thanks for the hint
17:51:03 <Pinkbeast> But you're stilll going to get freight moving slower because of wagon speed limits (and the lower speeds on freight locomotives)
17:51:16 *** mahmoud has joined #openttd
17:51:47 <b_jonas> slower freight could make sense if the cargos were also balanced that way
17:52:00 <b_jonas> but then faster trains is cooler, so I say screw realism
17:52:17 <Pinkbeast> Well, by and large, they are; the payment dropoff over time for eg coal is much lower than for mail/passengers.
17:52:23 <Eddi|zuHause> train set can alter the decay rate of cargo
17:52:46 <b_jonas> Pinkbeast: sure, but it's easier to collect lots of passengers than lots of coal
17:53:35 <b_jonas> well, I could try one of these sets I guess
17:54:02 <b_jonas> if I have to run multiple slower but cheaper freight trains, that could force me to build better rail networks earlier
17:54:11 <Pinkbeast> I dunno about realism, but having a mix of fast and slow trains and a mix of locomotives is more interesting.
17:56:16 <b_jonas> how about other modes of transport? I gather you recommend the Heavy Equipment Set for road?
17:56:44 <b_jonas> what about planes and ships? obviously I use them less often, but if there's a good set, I could still consider it
17:56:58 <Pinkbeast> Slower but often longer; the UKRS1 (for example) freight locos are more powerful than default locos, at least until you're doing silly stuff like moving coal with a "T.I.M."
17:57:46 <Pinkbeast> HEQS is a bit more special-purpose chrome, I use it, but I mostly use eGRVTS for general use, along with the Generic Tram Set.
17:58:05 *** frosch123 has joined #openttd
17:58:18 <Pinkbeast> FISH and Sailing Ships if you're starting early (although FISH's broken introduction dates render Sailing Ships less useful).
17:58:24 *** Chris_Booth has joined #openttd
17:59:20 <b_jonas> Pinkbeast: okay, thanks for the recommendation
17:59:26 <b_jonas> I think I'll try this in the next game
17:59:52 <supermop> where could i get the grafics sources for the ogfx stations?
18:00:04 <Pinkbeast> UKRS1 starts in 1921, not 1930, and the other sets mentioned have something for you then as well.
18:00:22 <b_jonas> as for starting early, well, that depends on the train set
18:00:43 <Elukka> i use long vehicles 4 for road vehicles (with HEQS thrown in)
18:00:57 <Elukka> they're generally better than vanilla road vehicles
18:02:24 <Pinkbeast> If you want earlier than that you can theoretically start in 1830 with UKRS2 but that's a hard row to furrow
18:02:37 <b_jonas> ah right, long vehicles, I forgot that
18:02:49 <b_jonas> I don't need to start early
18:04:34 <Pinkbeast> Well, do start in '21 with UKRS1, you'll miss out on some early loco changes otherwise.
18:05:10 <Pinkbeast> Also do beware that it (like many other real-world sets) includes some shunting engines which in the world of OTTD are basically totally useless.
18:05:26 <b_jonas> so? the default set includes some useless engines too
18:05:34 <b_jonas> I don't mind useless engines much if I also get useful ones
18:05:48 <Pinkbeast> Really? It's been an age since I played default.
18:05:59 <b_jonas> but futuristic trains sounds good
18:06:19 <Rubidium> Eddi|zuHause: why is it my fault?
18:06:45 <Pinkbeast> Oh, there's a UKRS1 addons grf as well, you'll want that.
18:07:09 <Pinkbeast> ... especially if for some unaccountable reason you like the Merchant Navies ahem
18:07:45 <b_jonas> well, not completely useless, just not so good as the other trains. I usually skip SH8P, Manley-Morel, SH125, and Dash.
18:08:09 <b_jonas> SH8P is the closest to useless
18:08:15 <b_jonas> and there are useless airplanes
18:08:33 <b_jonas> but I'm not too good in planes, so I don't know much about that
18:09:34 <Pinkbeast> Hang on, why's the 8P useless? It's faster than anything else in '54.
18:10:06 <b_jonas> hmm wait, maybe the 8P is not useless. I'm confused now
18:10:21 <Pinkbeast> Likewise the Class 43, er, 'SH125' is faster than anything else.
18:10:21 <b_jonas> I can't remember their statistics. that's sad
18:11:17 <b_jonas> well, the SH125 doesn't get much play with me because the UU37 and Floss47 are still good until the absolutely cool SH40 is introduced.
18:11:55 <Pinkbeast> The SH40 is slower and only marginally more powerful than the 125s...
18:12:03 <b_jonas> but it's more reliable
18:12:17 <b_jonas> the SH40 remains supported until quite late
18:13:08 <Pinkbeast> But anyway... none of these engines is as useless as eg a UKRS1 Diesel Shunter (strictly from the POV of making money)
18:13:26 <b_jonas> sure, I admit none of them are really useless
18:14:02 <V453000> I believe sets like 2cc have much more useless engines than the original set if you want to argue that original set has not enough engines "usable"
18:14:07 <b_jonas> I've probably used each of the temperate trains at least once
18:14:23 <V453000> and whether 2cc set has more useful engines than original is also questionable
18:14:28 <b_jonas> hey, I'm not saying that
18:14:35 <b_jonas> the original set has plenty of usable trains
18:14:43 <b_jonas> I'd just like some variety
18:14:46 <V453000> what is the problem then :)
18:14:49 <b_jonas> and possibly more useful choices
18:14:57 <V453000> UKRS is the best train set for that then
18:15:04 <V453000> you get choices for all game long
18:15:17 <V453000> dont forget the addon as you were also suggested to do :)
18:16:27 *** HerzogDeXtEr1 has joined #openttd
18:17:48 <Elukka> i found with YACD shunters are sometimes useful
18:18:09 <Elukka> i'd love 2cc if it wasn't for the odd multiple unit vs locomotive balancing
18:19:50 <Pinkbeast> Speaking of trains, I'm off to catch one, if that dickhead Philip Hammond hasn't got rid of them all. Goodnight!
18:20:54 <V453000> I think the multiple unit trains get quite nice, but what I hate is that it takes trains XYZ, takes their real life parameters as goes for XYZ, and imports them in the game. This results in things like getting very strong engines in 1935 which get replaced in ... 1970? Which is why I think original engines are quite good, you upgrade engines relatively often
18:24:48 <appe> does the cost of trains stop when they are in depot?
18:31:32 <Alberth> trying it would be the simplest, I think.
18:31:54 <Alberth> NewGRFs can do pretty much anything, so there is no single rule that covers all
18:46:40 <Eddi|zuHause> looks interesting
18:48:08 <Eddi|zuHause> so how do i set a register in nml?
18:51:08 <Eddi|zuHause> michi_cc: you sure a whitelist of callbacks is better than a blacklist?
18:52:20 <michi_cc> Whitelist is shorter right now. I don't really expect that many new vehicle callbacks in the future though.
18:52:46 <b_jonas> good thing this oil network is relatively isolated from other tracks in most places. would be difficult to convert otherwise.
18:55:37 *** Hyronymus has joined #openttd
18:58:45 <Yexo> Eddi|zuHause: STORE_TEMP(value, register) in the expression part of a switch-block
19:00:38 *** JVassie has joined #openttd
19:01:01 *** supermop_ has joined #openttd
19:11:55 <michi_cc> Eddi|zuHause: Both patches slightly updated, reload
19:16:08 *** Prof_Frink has joined #openttd
19:24:57 <z-MaTRiX> who uses linux here?
19:30:39 <FHerne> Me, but Windows as wll
19:32:38 <FHerne> Who here uses Mac OS classic?
19:34:53 <Eddi|zuHause> about as many people as win 3.1
19:35:31 <b_jonas> hey, I am using win3.1 specifically to run ttdpatch (and a few other games)
19:36:18 <b_jonas> though I don't run ttdpatch often with openttd working so well
19:37:51 <b_jonas> okay, so I'll need some junction here
19:38:04 <b_jonas> hmm, would a single pair of rails be enough?
19:38:26 <Eddi|zuHause> what do you need win 3.1 for to run ttdpatch?
19:38:46 <b_jonas> Eddi|zuHause: dunno, it doesn't seem to work if I start it right from DOS. probably a problem with the emulation of the video card.
19:39:02 <b_jonas> I might be able to get it to work with a different emulator, but that would be more work.
19:40:13 <b_jonas> Maybe I should try it in dosemu, that seems to be better in the video card front.
19:40:30 <b_jonas> I'm using bochs for most emulation stuff, but also have dosemu working.
19:41:24 <Eddi|zuHause> what happened to dosbox?
19:42:00 <b_jonas> ah, maybe it's dosbox? I keep confusing this stuff
19:42:13 <b_jonas> what on earth is dosemu then?
19:42:49 <b_jonas> yep, they're different
19:43:16 <b_jonas> like I said, I'm using Bochs for running most stuff. I tried qemu but I didn't like it.
19:44:15 <Rubidium> you should try hercules ;)
19:44:35 <Rubidium> OpenTTD works pretty well under hercules
19:44:38 <b_jonas> which hercules? the historical video card?
19:44:50 <Rubidium> nah, the S390 emulator
19:45:40 <b_jonas> openttd compiled to what architecture works on that?
19:46:07 <Rubidium> yes, I even used it as multiplayer server for a while
19:46:08 <b_jonas> also, I don't need an emulator for OpenTTD. it runs fine natively.
19:46:29 <b_jonas> (natively on amd64 linux that is)
19:47:48 * Rubidium is still waiting for a proper x32 environment ;)
19:49:53 <Rubidium> applications running in a 32 bits address space with amd64 instructions/registers
19:50:17 <b_jonas> is that MS-speak? they're using "x64" instead of "amd64"/"x86_64" and I never understood why
19:50:37 <b_jonas> oh, you mean 32 bits address space on amd64 architecture?
19:50:52 <b_jonas> yes, that's technically possible, but it's hard to get C libraries and compiler support for it.
19:51:02 <b_jonas> some other people would like it.
19:51:09 * Prof_Frink wants an 86-bit processor.
19:51:23 <b_jonas> I don't much care, I'm fine with 64-bit address space if the compiler works well.
19:51:33 *** Hyronymus is now known as Guest12539
19:51:37 *** Hyronymus has joined #openttd
19:52:23 <appe> what on earth did i just do to my game?
19:52:36 <Alberth> you posted it on a weird website?
19:53:10 <TWerkhoven> you can only load one at a time
19:53:25 <Rubidium> you're using an unsupported version of OpenTTD?
19:53:33 <Alberth> or rather, 'should' :)
19:53:33 <TWerkhoven> so firs, or ecs or opengfx+ industries
19:53:36 *** gelignite has joined #openttd
19:53:45 <TWerkhoven> you seem to have tried ecs and opengfx+ industries together
19:57:29 <z-MaTRiX> hm i only have linux
20:05:27 <supermop_> is there a set of graphic sources easily available for ogfx?
20:06:26 <CIA-2> OpenTTD: rubidium * r22991 /branches/1.1/ (8 files in 5 dirs): (log message trimmed)
20:06:26 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
20:06:26 <CIA-2> OpenTTD: - Fix: Old TTO/TTD savegames could get non-stop via orders upon savegame
20:06:26 <CIA-2> OpenTTD: loading, even when those orders did not exist back then. This 'conversion'
20:06:26 <CIA-2> OpenTTD: feature is something for TTDPatch and old OpenTTD savegames [FS#4716] (r22914)
20:06:26 <CIA-2> OpenTTD: - Fix: The icon would (almost) never be shown for SDL builds [FS#4617] (r22910)
20:06:28 <CIA-2> OpenTTD: - Fix: The name of the heightmap glitches in the 'play heightmap' window (r22902)
20:08:21 <supermop_> ill have to look at it at home,
20:08:34 <Alberth> it doesn't go anywhere :)
20:09:07 <supermop_> i am a bit bothered by the lack of buffers, so i thought last night of throwing together a few sprites
20:09:33 <supermop_> including buffers under the big roof
20:11:00 <peter1138> coded by some random guy
20:11:04 <supermop_> thats for orig. gfx though i thought
20:11:48 <supermop_> i usually use japan stations, but even there, there are no buffers under roofs
20:12:04 <CIA-2> OpenTTD: rubidium * r22992 /branches/1.1/ (12 files in 4 dirs): (log message trimmed)
20:12:04 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
20:12:04 <CIA-2> OpenTTD: - Fix: [NewGRF] Crash when accessing vehicle var 44 for a non-front aircraft [FS#4781] (r22946)
20:12:04 <CIA-2> OpenTTD: - Fix: Calculate the size of the start/stop vehicle button correctly (r22941)
20:12:04 <CIA-2> OpenTTD: - Fix: [OSX] Various MacOSX 10.7 issues causing OpenTTD to not work [FS#4751] (r22921, r22895, r22893, r22889)
20:12:06 <CIA-2> OpenTTD: - Fix: [NewGRF] Properties for feature 0x05 were not zeroed for each NewGRF,
20:12:08 <CIA-2> OpenTTD: thus waterfeatures could glitch when the properties were set by a previous
20:12:16 <peter1138> i tend to mix & match anyway
20:12:32 <supermop_> so if i can make somthing that looks ok for ogfx, maybe someone would code it as a first pass at ogfx+ stations
20:12:38 <peter1138> shame there's no decent passenger stations apart from mb's
20:12:43 <peter1138> which aren't banana'd
20:13:05 <supermop_> japanese ones are ok at serving as generic urban stations
20:13:19 <b_jonas> supermop_: industrial stations has some buffers
20:13:29 <supermop_> but it should be a challenge to create more
20:14:08 <supermop_> i'd love to create a station set that is along the lines of my sheds in style, but i cannot expect someone to code that for me
20:14:45 <b_jonas> there's also this "urban stations" that I haven't tried yet
20:15:28 <Alberth> hmm, station coding is going to be a problem as NML does not have station support afaik
20:15:52 <CIA-2> OpenTTD: rubidium * r22993 /branches/1.1/ (10 files in 3 dirs):
20:15:52 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
20:15:52 <CIA-2> OpenTTD: - Fix: The savegame description and loading of savegames would crash with savegames from a patched stable (which did not bump the savegame version) [FS#4778] (r22958, r22957)
20:15:52 <CIA-2> OpenTTD: - Fix: Guard from reading outside the silly name list (r22955)
20:15:52 <CIA-2> OpenTTD: - Fix: [NewGRF] Properly limit the length of strings in a choice list (r22952)
20:15:54 <CIA-2> OpenTTD: - Fix: [NewGRF] Do not call CB 32 for disaster, effect vehicles or aircraft shadows/rotors (r22947)
20:18:15 <CIA-2> OpenTTD: yexo * r22994 /trunk/src/object_cmd.cpp: -Fix [FS#4775]: tile was cleared before the object-placement callback was run, resulting in possible differences in test and exec run
20:18:43 <supermop_> do all ogfx+ projects need to be in nml?
20:19:20 <supermop_> i just wrapped up MLSS in nfo, but its really simple
20:19:39 <Alberth> given that Terkhen and planetmaker are active there, I'd guess yes, but you have to ask them
20:20:21 <supermop_> i may just draw a few things and offer them up incase anything ever happens with it
20:20:22 <michi_cc> Eddi|zuHause: Are those two patches something you can work with?
20:20:48 <Alberth> maybe it pushes NML forward too :)
20:22:13 <planetmaker> supermop_: there's no strict language requirement for OpenGFX+ projects. But... nfo newgrfs eat too much time for me personally - thus I'd not start one anymore :-)
20:22:47 <CIA-2> OpenTTD: rubidium * r22995 /branches/1.1/ (21 files in 5 dirs):
20:22:47 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
20:22:47 <CIA-2> OpenTTD: - Fix: [NoAI] Do not return ERR_UNKNOWN when the vehicle would become too long (r22988)
20:22:47 <CIA-2> OpenTTD: - Fix: Draw buoy sprite without outline on the map, fix minor issues with original graphics (r22974, r22973, r22971, r22962)
20:22:47 <CIA-2> OpenTTD: - Fix: [NewGRF] Strip newlines from NewGRF strings that should not have newlines, e.g. the NewGRF's name [FS#4769] (r22970)
20:23:18 <planetmaker> you're thinking about stations, or what?
20:23:32 <supermop_> well no one is pointing out glaring problems with mlss right now so i might spend a little time drawing some ogfx buffers, low platforms etc
20:24:25 <supermop_> i want to draw some things like buffers, buffers under the big roof, etc for ogfx+ style
20:25:45 <supermop_> i noticed that the little station building is a bit different in arctic than temperate, so maybe I'll draw a different big roof for arctic too? one that looks more gilded age than victorian?
20:26:06 <supermop_> assuming arctic means 'north america'
20:26:14 <planetmaker> Hm... different stations for climates might be nice :-)
20:26:32 <planetmaker> iirc arctic was agreed to somewhat resemble canadian
20:26:53 <supermop_> hence the turbotrain i guess
20:26:57 <Eddi|zuHause> michi_cc: i have not looked deeper into it yet, but it does seem to make sense
20:27:25 <michi_cc> Do look deeper, please. I want to hit commit soon :)
20:27:41 <planetmaker> might be one of the reasons, yes ;-)
20:27:45 <supermop_> a big train shed that looks like its from York station in Yorkshire looks out of place in a mountain town
20:29:08 <supermop_> conversely, i moved to yorkshire shortly after i started playing tto, and york station made me think 'whoa they actually did build things like this...'
20:29:40 <supermop_> anyway i dont want to get too ambitious
20:31:18 <Eddi|zuHause> <supermop_> i usually use japan stations, but even there, there are no buffers under roofs <-- i once had a lengthy discussion with MB about buffers under newstation roofs
20:31:18 <b_jonas> by the way, the train pathfinder seems to be working quite well on multiple lines. I thank to whoever made it so good.
20:32:53 <b_jonas> hmm, so with standard trains, maglevs are pretty good on slopes, right? I can make them go up the hill here
20:36:42 <CIA-2> OpenTTD: yexo * r22996 /trunk/src/command.cpp: -Fix: make sure temporary storage is cleared before test and exec runs for DoCommands so NewGRF callbacks can't change the result between the runs
20:37:10 <Eddi|zuHause> michi_cc: how impatient are you? 1 hour, 1 day, 1 week? :)
20:38:24 <supermop_> i guess its ok, because the roof hides the lack of a buffer, but its annoying if you want two colinear bay platforms
20:47:33 *** Progman has joined #openttd
20:51:18 <Eddi|zuHause> michi_cc: well in that case, i can tell you with quite some certainity that it compiles :p
21:06:44 *** TWerkhoven[l] has joined #openttd
21:08:23 *** Brianetta has joined #openttd
21:11:54 <b_jonas> I am using buffers in many stations in this game, and they look nice. I sometimes omit them though, when including them would cause an in-game disadvantage to me.
21:14:31 <Elukka> i'm a fan of how CHIPS adds them automatically
21:15:04 <supermop_> I think the look a bit cramped at the end of the tile in chips
21:16:49 <Eddi|zuHause> but you can't allow entering only half a tile, to have more room for the buffer
21:17:00 <Eddi|zuHause> either full tile, or nothing
21:18:16 <b_jonas> buffer graphics probably should be drawn accordingly, with the raised bumper part at the edge of the square
21:18:38 <b_jonas> you do have a lot of unused space behind buffers in real life too, for safety reasons
21:19:36 <Eddi|zuHause> yes, but sacrificing a full tile for eye candy purposes is sometimes too limiting
21:19:54 <Eddi|zuHause> especially because the (currently existing) buffers often cannot be placed on slopes
21:20:34 <b_jonas> yep, it can be limiting when you're cramped in space or when local authorities are picky
21:20:52 <b_jonas> however, it helps that they count as station squares in collecting cargo
21:21:03 <b_jonas> no wonder, for part of the square is platform where passengers can wait
21:21:58 <b_jonas> hmm, by that logic, buffet station tiles should attract extra passengers -- but that's a different game, roller coaster tycoon
21:25:14 <supermop_> Station waiting room decreases decay rate?
21:28:46 <Eddi|zuHause> that is currently not implemented
21:30:58 <b_jonas> supermop_: only if you pay the high maintainance cost to keep it clean.
21:34:50 <supermop_> can the station coverage area for a tile change via newgrf?
21:35:30 <CIA-2> OpenTTD: michi_cc * r22997 /trunk/src/ (newgrf_engine.cpp vehicle_base.h): -Feature: [NewGRF] Allow access to other vehicles in the vehicle chain in VarAction 2.
21:35:37 <CIA-2> OpenTTD: michi_cc * r22998 /trunk/src/newgrf_engine.cpp: -Add [FS#2521]: [NewGRF] Act2 var 0x62 to get curvature/position difference to the n-th vehicle in vehicle chain.
21:35:43 <CIA-2> OpenTTD: michi_cc * r22999 /trunk/src/video/ (12 files in 2 dirs): -Codechange: Allow changing the blitter during the running game.
21:35:48 <CIA-2> OpenTTD: michi_cc * r23000 /trunk/ (6 files in 3 dirs): -Feature: Base graphics sets can now specify a preferred blitter which OpenTTD uses to decide which blitter to load.
21:35:54 <CIA-2> OpenTTD: michi_cc * r23001 /trunk/src/ (gfxinit.cpp newgrf.cpp newgrf_config.h): -Feature: [NewGRF] Automatically switch to a 32 bpp blitter on NewGRF indication.
21:35:59 <CIA-2> OpenTTD: michi_cc * r23002 /trunk/src/newgrf_gui.cpp: -Add: Extend palette information in the NewGRF GUI with the 32 bpp state.
21:37:34 <Eddi|zuHause> why 62 and not 62`
21:38:07 <Eddi|zuHause> oh, you renamed the other to 61
21:46:19 <michi_cc> frosch didn't like 7A as it is vehicle specifiy, so it moved to 61
21:48:55 <Hirundo> How do var 61 and 7B interact?
21:50:35 <Hirundo> And how about 5F, to get the random bits of another vehicle?
21:54:09 <michi_cc> 5F doesn't work, but FA and FB carry the same information and work.
21:54:47 <Eddi|zuHause> why does 5F not work?
21:55:32 <michi_cc> Because it uses another code path where changing the vehicle pointer is non-trivial.
21:56:09 <michi_cc> 7B should work, 61 takes registers 0x10E and 0x10F exactly to avoid conflict.
21:58:35 <frosch123> instead of 5f you can also use varact type 84
21:59:10 <frosch123> well random act type 84
21:59:55 <Hirundo> I thought, you disliked random act2 type 83/84 :-)
22:00:40 <frosch123> they are definitely stupid
22:01:37 * Hirundo ponders ditching random_switch from NML
22:01:47 <Eddi|zuHause> now what's still missing is the "extra callback info" for gui-sprites
22:01:54 <frosch123> you need something for rerandomisation
22:02:34 <frosch123> Eddi|zuHause: noone answered whether it is a good idea to split so many cases, or whether it will just cause trouble for new windows
22:02:56 <Eddi|zuHause> frosch123: i'm really uncertain about that
22:03:13 <Hirundo> I know, but it might be nice to separate rerandomization from actual use, as it allows hiding the whole CB 0x01 mess
22:03:25 <Eddi|zuHause> frosch123: _i_ certainly don't see the need, but that is only my personal view
22:03:42 <frosch123> you could add special effects for the preview sprite
22:03:59 <frosch123> and not show that messy stuff as in the purhcase list
22:04:42 <Hirundo> currently having multiple callbacks use independent sets of random bits makes CB01 a major PITA to get right
22:04:57 *** JVassie has joined #openttd
22:05:34 <Hirundo> So basically you'd specify a list of (trigger mask, random bits) tuples for rerandomization
22:06:07 <Hirundo> perhpas do (trigger mask, random bits, callback) to allow deciding via callback to rerandomize yes/no
22:06:13 <frosch123> rerandomisation is kind of hard to do in callbacks
22:08:06 <Hirundo> I guess noone tried hard enough yet, else there'd be complaints in the NML forum topic :-)
22:10:35 <Eddi|zuHause> i hate konsole. in _every_ place, "copy" is the second entry in the context menu. only in konsole it's the first (because "cut" is left out). so naturally i'm always clicking the wrong entry...
22:12:45 <CIA-2> OpenTTD: michi_cc * r23003 /trunk/src/video/sdl_v.cpp: -Fix (r22999): Missing semicolon.
22:12:54 <Yexo> Hirundo: it'd be impossible to get rerandomization right if we ditch random_switch
22:16:09 <b_jonas> heh, the game keeps founding new oil refineries on the map edge that doesn't have water
22:18:59 <Eddi|zuHause> it's a silly requirement anyway
22:25:34 *** supermop_ has left #openttd
22:27:07 *** PeanutHorst has joined #openttd
23:03:45 *** supermop_ has joined #openttd
23:13:42 <supermop_> i dont see a .pcx for ogfx on the devzone
23:17:33 <michi_cc> Maybe you should look for a PNG file instead.
23:18:15 <supermop_> do i have to grab a tar and uncompress it?
23:21:38 <planetmaker> supermop_: grfcodec reads png just fine. No need to use the unhandy pcx files
23:22:35 <supermop_> hmm, the only station sprite i see in there is the little house
23:27:29 <planetmaker> not all sprites there are use anylonger, but stations iirc are. Or from infra06.png. Dunno.
23:27:35 <planetmaker> And now really 'good night' :-)
continue to next day ⏵
