Back to Home / #openttd / 2011 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2011-07-02

---Logopened Sat Jul 02 00:00:40 2011
00:53-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:54-!-Eddi|zuHause [] has joined #openttd
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
00:57-!-andythenorth [] has joined #openttd
01:08-!-andythenorth [] has quit [Quit: andythenorth]
01:54<@peter1138>hmm, brain fart
01:59-!-andythenorth [] has joined #openttd
01:59-!-andythenorth [] has left #openttd []
01:59-!-andythenorth [] has joined #openttd
02:01-!-andythenorth is now known as Guest648
02:01-!-andythenorth [~Andy@] has joined #openttd
02:09-!-Guest648 [] has quit [Ping timeout: 480 seconds]
02:19-!-andythenorth [~Andy@] has left #openttd []
02:32-!-sla_ro|master [~slaco@] has joined #openttd
02:49<@Terkhen>good morning
03:00-!-andythenorth [~Andy@] has joined #openttd
03:01-!-George [~George@] has quit [Read error: Connection reset by peer]
03:02-!-George [~George@] has joined #openttd
03:17-!-DayDreamer [~DayDreame@] has joined #openttd
03:19<@peter1138>i'm still having a brain-fart on angle changes
03:25<@peter1138>also i have a var called change_angle
03:25<@peter1138>and i keep typing it as changle_angle
03:26-!-Neon [] has joined #openttd
03:26-!-Amis [] has joined #openttd
03:29-!-KouDy [] has joined #openttd
03:34-!-Alberth [] has joined #openttd
03:34-!-mode/#openttd [+o Alberth] by ChanServ
03:34<andythenorth>changle_angle is nicel
03:35<@Alberth>moin andy
03:37*andythenorth wonders if YACD could tell an industry how much cargo was supposed to be delivered this month
03:38<andythenorth>if YACD could tell industry 'you require 42 crates of supplies for production boost'
03:38<andythenorth>then the problem is moved to YACD and I can consider keeping supplies
03:38<@Alberth>in a game where the program is not even able to make industries go away?
03:39<@Alberth>of course anything is possible, but the newgrf spec tends to get in the way, in my experience
03:40<@Alberth>(unfortunately, we cannot live without it)
03:40<andythenorth>it would be the correct solution though
03:40<andythenorth>demand is modelled by yacd
03:40<andythenorth>therefore yacd should take responsibility for notifying industry of its current demand
03:41<andythenorth>this is going to be a headache if towncontrol is used for towns to also model demand
03:41<andythenorth>there'll be no single controller of demand. big mess
03:41<@Alberth>yep, yet people think it is a good idea to have town control :(
03:42<@Alberth>imo the big problem is that there is no clear idea about what to do in newgrf and what in the program
03:42<@Terkhen>so either we use newgrf for everything or we use openttd for everything? :P
03:42<@Alberth>so peoples make messes at both sides
03:43<@Terkhen>yes, that's probably the issue
03:43<@Alberth>Terkhen: no, more like these and these kind of things are done in newgrf and other things in newgrf
03:44<@Alberth>eg global control should be in the game code imo
03:44<@Terkhen>it is a global issue
03:45<@Terkhen>town control is IMO tied tightly to newgrf stuff such as industries and houses... but when houses and industries were created as newgrf nobody thought how far this would reach
03:46<@Terkhen>I wouldn't mind a different implementation other than newgrf, but I can't think of a way that is newgrf dependent anyways
03:46<@Terkhen>the same already happens with AIs; many vehicle sets require explicit support
03:46<andythenorth>model demand + supply as a map feature - on a per-tile basis
03:46<andythenorth>have the game control that
03:47<andythenorth>whatever is on the tile has to respond appropriately
03:47<andythenorth>houses / industries can explicitly create a supply on a tile
03:48<andythenorth>only requires rebuilding the entire game and newgrf spec :P
03:48<@Terkhen>what I mean is: this issue started when newgrfs were adopted, and it is grown big now that both newgrf and ingame code allow to personalize a lot of stuff
03:49<@Terkhen>for the best way to solve it: I have sadly no clue
03:51<andythenorth>I have ideas but they'll never happen
03:51<andythenorth>due to stupid backward compatibility
03:51<andythenorth>which is inconsistently applied
03:52<@Terkhen>hmm... what do you mean?
03:52<andythenorth>it's ok for me to have to reset properties for every vehicle in HEQS, but some other thing can' be changed due to some 5 year old non-maintained grf that is inadequately licensed :P
03:52<andythenorth>basically it's know that I'll fix my stuff, whereas other people won't
03:52*andythenorth is short of sleep
03:54<andythenorth>anyway - my proposal would be
03:55<andythenorth>- take a red pen to a lot industry newgrf spe
03:55<@Terkhen>the only solution I can think about is remaking the newgrf specs in a way that they don't mess up with stuff they are not supposed to touch and make openttd work in "compatibility mode" with old stuff
03:55<andythenorth>- put supply and demand factors per cargo on each tile
03:55<andythenorth>- decide whether 'economy' should be in-game, newgrf, or some other (squirrel or similar)
03:55<andythenorth>- economy control then tied to some kind of possible goals framework
03:56<@Alberth>a script would be simplest, I think
03:57<@Terkhen>I agree, even for town control... but a script would need to take care of newgrf stuff
03:57-!-Cybertinus [] has joined #openttd
03:58<@Terkhen>for example, if I want to make town growth dependent on some new cargo, the script must be able to check if that cargo is really available or not
03:58<@Terkhen>is that feasible?
03:59<@Terkhen>hmm... I guess so, as long as the script has a cargo translation table too
03:59<Eddi|zuHause>the interface for that is town effect
03:59<Eddi|zuHause>it should not use cargos directly
03:59<andythenorth>the script would also need to be able to manipulate cargo payment rates
04:00<@Terkhen>what if I need to use a cargo that is not passengers, mail, food, water or goods?
04:01<andythenorth>town effect is dumb
04:01<@Terkhen>let me rephrase that: what if I need more than 5 town effects?
04:02-!-JVassie [] has joined #openttd
04:02<@Terkhen>we could add more valid town effects, of course, but the script needs knowledge of that too
04:02<@Terkhen>this is what I meant with "tied tightly to NewGRFs"
04:03<@Terkhen>although town control probably belongs in a script as part of goal scripts
04:03<Eddi|zuHause>we cam just define more town effects in the code. the only thing the script needs is a check whether a cargo for that effect exists
04:03<andythenorth>on this model industries could stop dicking around with acceptance
04:03<Eddi|zuHause>a candidate i once thought about was TE_ENERGY
04:04<andythenorth>acceptance is dictated by demand on the tile
04:04<andythenorth>demand = 0: no acceptance
04:04<@Alberth>Terkhen: why should you want > 5 town effects? we have many limits, like industry production/acceptance
04:04<andythenorth>although industry would have to reply to a script cb setting acceptance, so...meh
04:04*andythenorth ponders drawing a grid with accept / supply amounts on to test this
04:05-!-perk11 [] has joined #openttd
04:05<@Alberth>sleep is more useful probably
04:05<andythenorth>the various cargo dist versions would then manipulate the supply / demand
04:05<andythenorth>mostly the demand
04:05<andythenorth>the basic game would just have flat supply and demand, with no coupling between supply and demand
04:06<@Terkhen>hmmm... I could use only 5, yes
04:06<andythenorth>so the job of a cargo dist is then two things: (1) route cargo efficiently across the link graph (2) model demand
04:06<@Terkhen>but the point is that any changes on NewGRF specs could affect also scripts
04:07<@Terkhen>Alberth: we can continue this conversation once you are rested if you want :)
04:08<andythenorth>it might be better if newgrf industry was slightly less capable :P
04:08<@Alberth>You could do that, and you typically want that in eg a goal script. On the other hand, it should be possible to write a script that is independent of newgrf contents
04:09<andythenorth>currently the model is 'an industry set is responsible for *everything* it wants to change, game won't provide very much'
04:09<@Alberth>Terkhen: good, andy, you can sleep now :p
04:09<andythenorth>except the game provides two ways of processing cargo, both of which are problematic
04:09<andythenorth>and two economies
04:09<@Terkhen>oh, you meant andy :P
04:09*andythenorth has to go out and do baby shopping anyway
04:09*Alberth is in favor of simpler industry newgrfs
04:09*andythenorth is too
04:09<@Terkhen>andythenorth: this is what I meant with "yacd should take into account NewGRFs" :)
04:10<andythenorth>newgrf should be relatively dumber
04:10<@Terkhen>Alberth: I agree, scripts and newgrfs should be as less tied as possible
04:10<@Terkhen>but yes, newgrfs are too smart for that
04:11<@Terkhen>but if you make big changes to newgrf specs you lose newgrfs/compatibility with TTDPatch
04:11<andythenorth>ttdpatch is nearly dead
04:11<andythenorth>none of my newgrfs are patch compatible anyway
04:11<andythenorth>so I don't care
04:11<andythenorth>if that's bad - well life is short :P
04:11<@Alberth>if you don't, you get yourself stuck in a corner you never get out
04:11<@Terkhen>maybe, but many people use the newgrfs created for it
04:12<@Alberth>they can update the newgrfs, right?
04:12<@Terkhen>well, we don't have this issue with vehicle sets I think
04:12<@Alberth>and if the authors walked away, and left us with the mess, why should we get bothered by it
04:13<@Terkhen>what parts of the specs would cause problems with scripts exactly?
04:14<andythenorth>I need to think about how practical it would be to reduce industry / cargo / house spec
04:14<@Alberth>I think you should do 3 more steps back, and reconsider the goal of grfs, scripts and the program first
04:14<andythenorth>I'm out for a few hours anyway, I can think
04:14<@Terkhen>see you andythenorth
04:15<@Terkhen>grfs: define how in game items behave
04:15<andythenorth>the issue is where to draw the line between newgrf and script
04:15<@Terkhen>scripts: global behavior
04:15<@Terkhen>but my definition lacks ^
04:15<andythenorth>it's easy to say that industry provides tiles + graphics + animation
04:16<andythenorth>it's probable to say industry sets input / output cargos
04:16<andythenorth>what's difficult is things like production rates, secondary processing, closure
04:16<andythenorth>and things like cargo payment rates, house cargo production etc
04:16<@Alberth>imho, grfs define how the graphics look
04:17<Eddi|zuHause>i think we're way too far beyond that point already
04:18<andythenorth>the less control an industry has on logic, the more likely a script routes is to succeed
04:18<andythenorth>cleaner interface
04:18<@Terkhen>a script should not care about an industry's internal behavior IMO
04:20<@Alberth>Eddi|zuHause: static data such as properties would be fine too
04:20<andythenorth>Terkhen: moving all the (e.g.) production logic to a script might be viable though
04:20<andythenorth>newgrf would then ship with a default script maybe
04:21<andythenorth>not sure whether multiple scripts would be allowed per game
04:21<andythenorth>probably not
04:21<andythenorth>which is a problem, because then they're monolithic
04:21<@Terkhen>yes, it would be viable, my question is why do you need to move "individual industry behavior" from newgrfs to scripts
04:21<@Alberth>imo production logic is internal to the industry -> newgrf
04:21<andythenorth>because individual industry behaviour is one of the headaches
04:22<andythenorth>closure, production increase/decrease are the two really painful points
04:22<andythenorth>processing much less so
04:22*andythenorth -> out
04:22<@Terkhen>I agree that closure is one of the headaches
04:22<@Terkhen>see you later andythenorth
04:22<@Alberth>closure and increase/decrrease is a script or a game
04:22-!-andythenorth [~Andy@] has quit [Quit: andythenorth]
04:22<Eddi|zuHause>so you actually need a way to embed a script into the newgrf, as a replacement for varaction2-callbacks
04:23<@Alberth>you do?
04:23<@Terkhen>otherwise you need the script to know all individual industries in a newgrf, and give each one the intended behavior
04:23<@Terkhen>and then the script is tied to a specific industry newgrf
04:23<@Alberth>then you can just leave it as is, as you are then just moving the computations from newgrf to scripts, and gain nothing
04:24<@Terkhen>"some" of the internal behavior of industries might get in the way of scripts (I don't know what parts)
04:24<@Terkhen>but most of it should remain in the newgrf, as it is the one that defines the new industry types
04:25<@Terkhen>I know that opening/closure is a pain because of your patch, but I have not looked at the industry specs thinking on a script implementation
04:26<@Terkhen>but from what I remember now, stuff like production and so on should remain in the newgrf
04:27<@Alberth>production based on delivered cargo, sure
04:28<@Alberth>but policies regarding opening, closing, and perhaps 'free' production, are global, and do not belong in a newgrf. It doesn't have the global overview to make a sane decision
04:29<@Alberth>the whole town control is imho just an attempt to boraden the scope towards that overview, thus further blurring the border
04:29<@Alberth>(sorry, I am just ranting)
04:30<@Terkhen>don't worry, having this conversation was in my todo list before thinking the town control specs :P
04:31<@Terkhen>this is how I see the problem: a "clean" solution would require breaking existing industry and maybe house newgrfs
04:31<@Terkhen>and I'm not sure that's a good idea
04:31<@Alberth>why not?
04:31<@Alberth>eventually you have to do it, or you die
04:32<@Terkhen>lot of effort has been made in some of those newgrfs, and they could die because of something like this
04:32<@Alberth>or keep the mess forever, making everybodies life miserable
04:34<@Alberth>if they are open source, they will get updated
04:34<@Alberth>if they are not, they deserve to die, imho
04:36<@Terkhen>I still think that they should work somehow, even if the changes are made
04:36<@Terkhen>a compatibility mode or something like that
04:36*Terkhen is not sure
04:38<@Alberth>my point of view is probably too extreme, but you cannot have everything. Somewhen you need to decide to go left or right
04:39<@Alberth>if you do both, you always have to make compromises, and never get anything implemented really good
04:43<@Terkhen>knowing for sure what would break and what would not would help with a decision :P
04:51-!-Biolunar [] has joined #openttd
04:52-!-Progman [] has joined #openttd
04:56<@Alberth>Make a list of newgrf things that are bad, remove its support from some tool (grfcodec, or openttd, or so), and use your newgrfs with that tool. :p
04:57-!-amkoroew [] has joined #openttd
05:10<ccfreak2k>Alberth, can't make everyone happy.
05:10*Alberth agrees
05:14<@Alberth>It's a good description to express what I mean
05:31-!-Strid [] has quit [Quit: Konversation terminated!]
05:36-!-KritiK [] has joined #openttd
05:53-!-pugi [] has joined #openttd
06:01-!-Wizzleby [] has joined #openttd
06:01-!-Chris_Booth [] has joined #openttd
06:01-!-Wizzleby is now known as Guest662
06:04<__ln__>@seen Bjarni
06:04<@DorpsGek>__ln__: Bjarni was last seen in #openttd 13 weeks, 5 days, 10 hours, 42 minutes, and 38 seconds ago: <Bjarni> thanks
06:04-!-George [~George@] has quit [Read error: Connection reset by peer]
06:07<Eddi|zuHause>that's a totally boring "last words" entry...
06:11-!-George [~George@] has joined #openttd
06:13<caracal>finally read the docs and found out how to make trams work ... nice!
06:17-!-Strid [] has joined #openttd
06:29-!-Wolf01 [] has joined #openttd
06:33-!-JVassie_ [] has joined #openttd
06:38-!-frosch123 [] has joined #openttd
06:38-!-JVassie [] has quit [Ping timeout: 480 seconds]
06:39-!-Eddi|zuHause [] has quit [Remote host closed the connection]
06:43-!-Eddi|zuHause [] has joined #openttd
06:44-!-andythenorth [] has joined #openttd
06:51<JVassie_>whats the 'opposite' of substr()?
06:53-!-Brianetta [~brian@] has joined #openttd
07:08<MNIM>well no sheeeeet
07:15-!-HerzogDeXtEr1 [] has joined #openttd
07:21-!-HerzogDeXtEr [] has quit [Read error: No route to host]
07:23-!-andythenorth is now known as Guest666
07:23-!-andythenorth [~Andy@] has joined #openttd
07:24<CIA-2>OpenTTD: frosch * r22614 /trunk/src/newgrf_sound.cpp: -Fix [FS#4656]: If callback 33 returns a value out of range, no sound effect shall be played.
07:28-!-Guest666 [] has quit [Ping timeout: 480 seconds]
07:28<CIA-2>OpenTTD: frosch * r22615 /trunk/src/ (newgrf_sound.cpp newgrf_sound.h): -Codechange: The return value of PlayTileSound() has no purpose. Remove it and document the rest.
07:28-!-DayDreamer [~DayDreame@] has quit [Read error: Connection reset by peer]
07:29<andythenorth>extending the delivery window for supplies is an interesting and simple change
07:30<andythenorth>so instead of having to deliver every month, player has say...6 month
07:30<andythenorth>so in that case they get 1 production increase every 6 months
07:30<andythenorth>instead of chance of 6
07:30<andythenorth>the human mind is so dumb sometimes
07:30<andythenorth>proven endlessly in pyschological tests :P
07:31<andythenorth>players are worrying about the 1 delivery window they missed, and are prepared to accept a much worse outcome to avoid ever missing a window
07:31<CIA-2>OpenTTD: frosch * r22616 /trunk/src/ai/ai_gui.cpp: -Codechange: Fix typo.
07:32<Eddi|zuHause>andythenorth: that's why my proposal has a 12 months supply storage
07:32*andythenorth is bored of trying to design for stupid people who can't do basic maths
07:33<andythenorth>Eddi|zuHause: your proposal is at least implementable ;)
07:33<andythenorth>N would be tied to production multiplier
07:33<Eddi|zuHause>yes, roughly
07:34<andythenorth>I can do without storage entirely, and set a counter in a register
07:34<andythenorth>storage really just complicates the issue
07:34<andythenorth>I wish storage was removed from the spec :P
07:34<andythenorth>pikka probably doesn't
07:35<andythenorth>the storage is a stupid piece of failed spec
07:35<Eddi|zuHause>andythenorth: well, "storage" is exactly what you need so people don't worry about missing a window
07:35<andythenorth>i.e. I am being rude about stockpiling, not persistent storage
07:35<andythenorth>persistent storage is the correct answer :)
07:35<andythenorth>persistent storage + *total* control over industry window text
07:36<andythenorth>instead of some stupid strings I don't need, just because I have to enable production cv
07:36<andythenorth>cb /s
07:36<andythenorth>it's trivial to set a counter to 0 when supplies are received
07:36<andythenorth>increment the counter every month or so
07:36<andythenorth>set a maximum limit for the counter
07:36-!-Brianetta [~brian@] has quit [Ping timeout: 480 seconds]
07:37<andythenorth>make the limit variable according to parameter or some other means
07:37<Eddi|zuHause>doesn't sound like the right solution
07:37<andythenorth>it's approximately how it's done now
07:37<andythenorth>also same for secondary production combining
07:38<andythenorth>I ignore everything to do with the built in 'stockpiles' - they're of no use
07:38*andythenorth considers trying to patch industry window
07:38<Eddi|zuHause>oh, yes, that also needs a display which delivery multiplicator is currently active
07:38<andythenorth>yes it does
07:38<andythenorth>I am waiting on nml conversion then I'll add that - there's a ticket for it
07:39<andythenorth>accepting but ignoring supplies is interestingly evil
07:39<andythenorth>"the industry will use any supplies you give it, but not necessarily very efficiently"
07:39<andythenorth>"over-delivering supplies won't help, the workers will just use them having digger races"
07:43<@Alberth>you get production increase due to having happy workers :p
07:46-!-Brianetta [~brian@] has joined #openttd
07:47<andythenorth>Eddi|zuHause: what should N be?
07:47<andythenorth>the actual value of the production multiplier might be ok
07:47<Eddi|zuHause>possible, needs testing
07:47<andythenorth>and how does storage space change if N changes?
07:47<andythenorth>N * 12 is a moving target...
07:48<Eddi|zuHause>yes, that's intended. the more the industry needs, the higher the storage must be
07:48<andythenorth>ok so if I have 500t supplies stored, and production falls, what happens?
07:49<Eddi|zuHause>same as when delivering 1000t at once
07:49<andythenorth>some supplies are just sent to dev/null ?
07:49<Eddi|zuHause>yes, i think that's the best solution
07:50<Eddi|zuHause>but according to my suggestion production shouldn't decrease when 500t supplies are waiting
07:50<Eddi|zuHause>so the situation wouldn't occur
07:50<andythenorth>this is a good point
07:50*andythenorth can't do basic maths
07:52<andythenorth>so I would show consumption rather than requirement
07:52<andythenorth>in the texts
07:52<Eddi|zuHause>yes. "16t of supplies consumed per month, currently 48t in storage"
07:53<andythenorth>ok, so some players who want an increased chance of increase (bad sentence) if they deliver more supplies
07:53<andythenorth>those guys lose out?
07:54<andythenorth>and the limit should be configurable?
07:55<andythenorth>because that was needed last time stockpiling was tested
07:55<Eddi|zuHause>not sure... maybe
07:55<Eddi|zuHause>but "1 month" tends to be a little short
07:56-!-Moustachio [] has joined #openttd
07:56<andythenorth>Eddi|zuHause: I can't find any flaws with your method
07:57<Eddi|zuHause>that's the genious part ;)
07:57<andythenorth>I'm not sure what to do about storage limit
07:57<andythenorth>players hate them
07:58<andythenorth>if we're prepared to kill a kitten, I have an idea
07:58<andythenorth>limit should be N * M
07:58<andythenorth>where M is configurable, up to a stupid upper limit
07:59<Eddi|zuHause>N = (function of) production multiplier, M = parameter?
07:59<andythenorth>think so yes
07:59<andythenorth>@calc 65536/12
07:59<@DorpsGek>andythenorth: 5461.33333333
08:00<andythenorth>supplies delivery window: 1 month | 3 months | 6 months | 12 months | 5000 years
08:00<andythenorth>or so
08:01<@Alberth>your diggers have good quality :)
08:01<andythenorth>I think it's a nice way of catering for idiots who have no taste
08:01<andythenorth>steve jobs wouldn't bother :P
08:01-!-MNIM [] has quit [Ping timeout: 480 seconds]
08:01<andythenorth>but he doesn't have to read tt forums
08:04<@Alberth>you may have some more lower values, eg I can imagine 2 months to be interesting
08:04<@Alberth>+want to
08:04-!-glx [glx@2a01:e35:2f59:c7c0:45a5:3aa2:4558:622c] has joined #openttd
08:04-!-mode/#openttd [+v glx] by ChanServ
08:06<andythenorth>yes 2 months would make sense
08:16<andythenorth>Terkhen: Alberth the scripts / newgrf boundary is no clearer :P
08:20<@Alberth>without first defining what goes where, sure. You'd just rewrite current newgrf code to script code, and make no progress.
08:21*andythenorth wonders - is it even practical to talk of storing more stuff in map array?
08:24<@Alberth>why do you want to store cargoes in tiles?
08:24-!-Fuco [] has joined #openttd
08:25<andythenorth>I want to amounts for supply and demand
08:25-!-execat [] has joined #openttd
08:25<andythenorth>not sure why yet
08:25<andythenorth>think it might be interesting to explore
08:25<andythenorth>think it might interact interestingly with YACD and such
08:25<@Alberth>and let go of 8/8 ?
08:25<andythenorth>maybe, not sure
08:26<@Alberth>might be interesting
08:26<andythenorth>not really a formed idea yet, just a small thought
08:26<@Alberth>but it'd be static or not?
08:26<execat>Guys is there an alternate end to OpenTTD than buying out your opponent?
08:26<andythenorth>Alberth: that might depend on the script controlling the game...
08:26<execat>Out of several (~30) games I have played with my bro, it has happened just once.
08:27<Eddi|zuHause>execat: openttd has no end
08:27<andythenorth>currently basic game, all demand is pretty much 1 or 0
08:27<andythenorth>related things like payment rate are same for every tile
08:28<Eddi|zuHause>execat: the official goal is having the highest company rating (1000) in the year 2050
08:28<andythenorth>YACD implies a varying demand function, but it's a virtual implementation afaik
08:28<andythenorth>so YACD has to model demand as well as routing
08:28<andythenorth>really YACD could just handle routing
08:28<execat>Haha. The farthest we reached was 2020 before something or the other came up.
08:28<@Alberth>andythenorth: you can think about it by tile, and store the data in newgrf as long as it gets accessed by tile
08:28<andythenorth>and something else could model demand
08:29<andythenorth>this seems to be how YACDist is now approaching it...
08:29<andythenorth>practically constraints might be (a) storage amount needed and (b) is script language WAY too slow to do this
08:29<andythenorth>YACD already murders my battery
08:29<Eddi|zuHause>execat: most people make up their own goals, like "connect all industries" or "grow town to 200k inhabitants"
08:30<@Alberth>yeah, it might be a bit too detailed
08:30<andythenorth>possibly, but it seems like right direction
08:30<execat>Eddi|zuHause: We keep it to most profits and hightest company value.
08:31<@Alberth>and usually, I build a station right next to the industry so I cover all tiles anyways :p
08:31<andythenorth>YACD(Dist) + industry-cargo newgrf + town control = car crash
08:31-!-Moustachio is now known as MNIM
08:32<MNIM>I don't really play with goals... I just build beautiful tracks, bonus points if it turns profit :D
08:33<@Alberth>andythenorth: there are so many simple ways to spend huge amounts of CPU time :p
08:41-!-perk11 [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
08:43<andythenorth> @calc 2048*2048*32
08:43<andythenorth>@calc 2048*2048
08:43<@DorpsGek>andythenorth: 4194304
08:43<andythenorth>@calc 4194304*32
08:43<@DorpsGek>andythenorth: 134217728
08:44<andythenorth>@calc 134217728 / 1024
08:44<@DorpsGek>andythenorth: 131072
08:44<@Alberth>128K :)
08:47<andythenorth>Alberth: what problems did you run into with newgrf spec doing too much>
08:48<@Alberth>basically trying to decide things locally that should be decided globally
08:48<@Alberth>such as industry closure
08:49<CIA-2>OpenTTD: frosch * r22617 /trunk/src/ (5 files in 2 dirs): -Codechange: Add GameOptionsInvalidationData enum for data values for Window::OnInvalidateData() of windows with class WC_GAME_OPTIONS.
08:50<@Alberth>never encountered it myself, but stuff like costs also seem to have that problem
08:50<@Alberth>but perhaps that is even bigger
08:51<@Alberth>industry probabilities may also be one
08:51<@Alberth>but you need some form of indication, so I don't think you can throw it away
08:52-!-perk11 [] has joined #openttd
08:53-!-perk11 [] has quit [Read error: Connection reset by peer]
08:54<@Alberth>and the whole trouble with disabling other newgrfs is another biggie :p
08:54*andythenorth ponders
08:54<andythenorth>there's also town control and houses to think about
08:54<andythenorth>imo a house set should be really simple
08:54<andythenorth>and not have to deal with cargos
08:54<@Alberth>town control is a crater full of worms (rather than just a can)
08:55-!-goblin [] has joined #openttd
08:55<andythenorth>a town building should either accept cargos or not
08:56<andythenorth>brain ache :P
08:56<@Alberth>how are houses different from industry?
08:56<andythenorth>they don't have any production logic
08:56<andythenorth>just simple accept / produce
08:56<andythenorth>all accept/produce could be delegated to town control
08:56<@Alberth>ie just fixed production logic :)
08:57<andythenorth>and if town control wasn't newgrf, but a script...
08:57-!-fjb [] has joined #openttd
08:57<andythenorth>but a town might want to build certain kinds of building, which implies classes or such in newgrf
08:57<andythenorth>which is a horrible interface to maintain
08:57<andythenorth>although not impossible
08:57-!-Brianetta [~brian@] has quit [Ping timeout: 480 seconds]
08:58<CIA-2>OpenTTD: frosch * r22618 /trunk/src/ (settings.cpp settings_gui.cpp window_type.h): -Fix [FS#4653]: When changing difficulty settings over the network, do not just reopen the difficulty window if any game options window is opened; instead invalidate them properly.
08:58<andythenorth>this is all starting to look like python interfaces + adapters :9
08:59<@Alberth>just because we make no choices
08:59<andythenorth>soon we'll suggest duck typing :)
09:00<andythenorth>Alberth: lets just talk about industry closure
09:00-!-Devroush [~dennis@] has joined #openttd
09:00<andythenorth>how would a script control that?
09:01<@Alberth>currently in the industry code, I have industries too many of some kind, and I cannot kill them
09:02<@Alberth>one approach would be to say every now and then to one of those industries 'please go away'
09:02<andythenorth>ok so a simple script might have:
09:02<andythenorth>- a list of required probabilities
09:02<andythenorth>- a periodic processing loop
09:02<@Alberth>a different policy may be to watch what the player is doing, and build more industries of the same kind eg
09:02<andythenorth>- some logic to decide which instance to close when number of instances > limit
09:03<andythenorth>so it's similar-ish to AIs
09:03<andythenorth>one economy script might build more mines if a player transports a lot of coal for example
09:04<andythenorth>and it might want to control industry location?
09:04<andythenorth>things like cb28 should possibly be delegated to scripts
09:04<@Alberth>I'd consider that a map property
09:04<andythenorth>would an industry have any over-ride?
09:05<andythenorth>e.g. game wishes to build at location x, industry can allow / reject
09:05<andythenorth>similar to current code, but script controls location
09:05<@Alberth>that would render the script useless
09:05<@Alberth>I'd say the industry says what it likes to have, the script tries to provide
09:06<andythenorth>that's where I think duck typing will arise :P
09:06<@Alberth>you can have local checks, eg map slopes
09:06<andythenorth>tile checks are fine
09:06<andythenorth>and should be preserve of industry
09:06<andythenorth>they are isolated to that instance
09:06<@Alberth>but on the other hand, if it would state what it wants, the game can provide it
09:06<andythenorth>cb28 checks for neighbouring industry etc - these are hard to decide who should have final say
09:07<andythenorth>so the industry can decide or delegate?
09:07<@Alberth>the problem with newgrf logic is that it does not say why something was rejected
09:07<@Alberth>which makes planning trouble some
09:08-!-Yexo [] has joined #openttd
09:08-!-mode/#openttd [+o Yexo] by ChanServ
09:08<@Alberth>eg, if I know that some industry type becomes available 5 years from now, I can start making room today
09:08<andythenorth>I wonder if it would be impossible to decouple a script from a specific industry set
09:08<@Alberth>right now, the type just says 'no', and it can be for aby reason
09:09<@Alberth>depends on the quality of control that you want
09:09<andythenorth>ideally scripts would not be tightly coupled to specific newgrs
09:09<andythenorth>newgrfs /s
09:10<@Alberth>if you tailor the script with knowledge of the industries, or even with the map, you get better control
09:10<andythenorth>I don't know if full decoupling is realistic
09:10<andythenorth>especially wrt cargos / industries
09:10<@Alberth>at the cost of having a very specialized script
09:10<@Alberth>why not?
09:11<@Alberth>what special code should be in a script for eg FIRS?
09:11<andythenorth>depends how much of current newgrf spec is delegated to a script
09:11<andythenorth>lets try and figure it out
09:11<andythenorth>ok so a current problem is that often aluminium plants are built in FIRS during gameplay
09:12<andythenorth>the cause is usually that the available land for them is taken by the time they're available
09:12<andythenorth>so a script should try and solve that
09:12<andythenorth>the introduction dates are known
09:12<@Alberth>as in 'no good map slopes' ?
09:12<andythenorth>there is an alternative suggestion around terraforming, but ignore that for now
09:13<andythenorth>so the intro date is known, the industry size is known
09:13<andythenorth>what if you wanted to ensure supplying industries are also built around same time?
09:14<@Alberth>the script should make 'space' for the industry in a sense
09:14<andythenorth>would it also try and build the complementary industries in the chain?
09:15<@Alberth>any chain should be build from first to last imho, I don't see that as special for FIRS
09:15<andythenorth>so just go by date?
09:15<andythenorth>try and ensure at least one instance of each type?
09:15<andythenorth>(available type)
09:15<@Alberth>that's a minimum.
09:15<andythenorth>that works
09:16<@Alberth>to be useful you also want it somewhat nearby
09:16<andythenorth>so what if a player wants to script an economy with steel mills introduced in 1800
09:16<andythenorth>and have it work with ecs, pbi, firs, opengfx+
09:16<andythenorth>is that a step too far?
09:16<@Alberth>don't know
09:16<andythenorth>to make that work, script has to know about 'steel mills'
09:17<andythenorth>it's not implausible to label industry types similar to cargo types
09:17<@Alberth>you could have a list of cargoes instead
09:18<@Alberth>and the game/script can find the industries and the needed cargoes for supplying industries
09:18<@Alberth>cycles are a challenge then ;)
09:18<andythenorth>I think anything like that won't work well in a newgrf-independent way
09:18<andythenorth>that's why I wonder if newgrf-independent is a valid goal
09:19<@Alberth>I'd call it 'aim', rather than 'goal'
09:19*andythenorth has evil idea
09:20<andythenorth>any industry set also has a script accompanying
09:20<andythenorth>using strictly defined methods
09:20<andythenorth>any economy grf can over-ride those methods
09:20-!-Devroush [~dennis@] has quit []
09:20<andythenorth>economy grf / economy script /s
09:21<andythenorth>so the default FIRS behaviour might be 'try to locate industry x near why'
09:21<andythenorth>but the script could over-ride that, or leave it as FIRS requests
09:22<andythenorth>only one economy script
09:22<andythenorth>only one script per industry newgrf
09:23<@Alberth>having more than one script sounds quite complicated
09:23<@Alberth>ie I want to override FIRS but not ECS :p
09:25<andythenorth>ok so you have to write newgrf-specific code :P
09:25-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
09:25-!-sllide [] has joined #openttd
09:25<andythenorth>so maybe certain newgrfs are dependencies for a certain script
09:25<@Alberth>and it may be easier to keep that script in the newgrf :)
09:26-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
09:26<andythenorth>hmm maybe newgrf doesn't need an accompanying script
09:27<andythenorth>Alberth: only one script seems the way to go
09:27<andythenorth>*but* then an author has to write code for *everything* or it doesn't work
09:27<andythenorth>i.e. industries, towns, houses etc
09:28<@Alberth>you can split the script, of course
09:28<andythenorth>split to...?
09:28<@Alberth>different parts, ie it does not have to be one big file
09:29<andythenorth>well yes...
09:29<andythenorth>but presumably compiled to one script?
09:29<@Alberth>and you are not considering what the game code should do atm
09:29<andythenorth>probably the game code provides default / fallback behaviour
09:29<@Alberth>as in, you are moving a lot of current code into the script, I think
09:29<andythenorth>yes ideally :P
09:30<andythenorth>that would make industry_cmd.cpp less bad for starters
09:30<andythenorth>(moving the problem elsewhere)
09:30<andythenorth>I could stop having to think about things like 'does player have multiple industries per town enabled' :P
09:31<@Alberth>I think moving the whole code to a script is not progress
09:31<@Alberth>you just shift the whole problem to another part
09:31<andythenorth>ok lets rule that out for now
09:32<andythenorth>so what does a script usefully do - besides allow industries to close? :)
09:33<@Alberth>I don't know. I find the distinction between script and game code too unclear
09:33<andythenorth>me too currently
09:33<@Alberth>perhaps a script should be more about policies
09:34<andythenorth>so it's mostly returning allow / disallow?
09:34<andythenorth>rather than logic to try and run the game...?
09:35<@Alberth>policies in a script are more useful than in the game code :p
09:35-!-sliddy [] has joined #openttd
09:35<@Alberth>but coding some function is also a form of implementing policies
09:36<@Alberth>in particular, policies that the game code does not know about
09:36-!-sllide [] has quit [Read error: Connection reset by peer]
09:38<andythenorth>Alberth: I have run out of thinking :P
09:38<andythenorth>certainly a system that requires 80% of game logic to be reimplemented in script language is not good
09:38*Alberth nods
09:39<andythenorth>but a system that can't run any logic is not much use
09:39<@Alberth>you'll always have logic, otherwise you don't have a game.
09:40<@Alberth>currently it is all in the game code, which works, but is hard to change/extend
09:40<@Alberth>so people try to work around it by adding fancy newgrf features, or by hacking custom openttds
09:41<@Alberth>or trying to get patches applied to trunk :p
09:43-!-|Jeroen| [] has joined #openttd
09:45<andythenorth>fancy / baroque /s wrt newgrf features
09:45*andythenorth has questions but ideas
09:45<andythenorth>say there was some methods like town.grow(), industry.close()
09:46<andythenorth>and the script provided logic to handle those
09:46<andythenorth>and the script could also iterate items like towns and industries
09:46<andythenorth>so for i in town_list: if i.some_condition: i.grow()
09:46<@Alberth>I'd put those in game code, they are the primitives of the world
09:47<@Alberth>(the town.grow(), industry.close() functions)
09:47<andythenorth>ok - I defer to almost everybody else about good code practice
09:47<andythenorth>so the interesting question
09:47<andythenorth>I'm a script author
09:47<@Alberth>those primitives are the same whatever your policy
09:47<andythenorth>I call industry.close on a specific industry
09:47<andythenorth>do I win? or does the newgrf author?
09:48<andythenorth>seems to need either a cascading policy, or an auction of some kind
09:48<andythenorth>seems to me that the industry author should concede to the script
09:48<andythenorth>and industry authors who want to provide specific gameplay should also provide their own economy script
09:48<@Alberth>you'd specify what happens with the method of course :) but I'd say the script should win
09:48<andythenorth>the script should win
09:49<andythenorth>what should scripts have access to?
09:49<@Alberth>otherwise the script is useless
09:49<andythenorth>- *not* vehicles
09:49<andythenorth>- everything else?
09:49<@Alberth>why not vehicles? in prinicple anything may be useful
09:50-!-amkoroew [] has quit [Quit: Leaving.]
09:51-!-Progman [] has quit [Remote host closed the connection]
09:52<andythenorth>vehicles belong to player + AIs
09:52-!-amkoroew [] has joined #openttd
09:52<andythenorth>maybe useful to differentiate getter / setter methods
09:52<andythenorth>you'd allow script to have setter methods on players stuff? :o
09:53<andythenorth>could be evil
09:54<@Alberth>you should have inspection capabilities imho
09:54<andythenorth>there might be valid setters
09:54<andythenorth>- reliability
09:55<andythenorth>maybe costs, but they're already a giant can of worms
09:55<@Alberth>not on individual vehicles, but on the set as a whole perhaps
09:55<andythenorth>ceding costs to scripts would be really useful for balancing
09:55<andythenorth>a script could define that 3,000hp locomotives cost £xyz amount
09:56<andythenorth>but that's a distraction from economy :P
09:57<andythenorth>disasters should be scriptable :)
09:57-!-sliddy [] has quit [Ping timeout: 480 seconds]
09:59<@Alberth>hmm, this player is making to much money, let's destroy his factory :D
10:01<andythenorth>something like that
10:01<andythenorth>incidentally a bridge disaster would be witty :P
10:02<andythenorth>it would help if bridges were state machines as per eddi's suggestion
10:02<andythenorth>Eddi|zuHause: ^
10:02-!-Wolf01 [] has joined #openttd
10:02<@Alberth>didn't someone complain of the game eating batteries? :p
10:04<andythenorth>Alberth: how often does a script cycle? Is it every tick, every n ticks?
10:04<andythenorth>or does it specify event handlers?
10:04<andythenorth>or something else? I am out of my depth with such
10:04<@Alberth>every n ticks may be easier
10:04<andythenorth>my experience is limited to flash where all are possible + a crazy timeline
10:05<@Alberth>but n can be fairly large, as you control global goals
10:05<andythenorth>AIs must have solved that already?
10:05<@Alberth>ie checking the #industries once a month may be too often
10:06<@Alberth>it should be possible to do an AI-ish experiment by some hacking
10:07<@Alberth>you'll need some new primitives, mostly
10:13<andythenorth>some stuff might not be possible
10:13<andythenorth>like running a custom price calculation when a cargo is delivered
10:15<Eddi|zuHause>hm, so which one would you prefer? or
10:15<@Alberth>andythenorth: sounds like too detailed control imho, just setting a few parameters to steer the computation should be sufficient
10:16<andythenorth>cargo price calculation?
10:16<andythenorth>it's already possible in nfo, but not very useful
10:17<andythenorth>Eddi|zuHause: which one lets you go faster?
10:18<Eddi|zuHause>andythenorth: curve radiuses and platform length is about equal
10:18<@Alberth>but nfo has no global overview, so it's useless for economic control :p
10:19<Eddi|zuHause>everybody who attempted cargo price calculation in NFO died trying :p
10:19<andythenorth>and using town control storage for calculating delivery would be no better
10:19<andythenorth>it would be very edge-casey
10:19<andythenorth>even if it worked
10:19<andythenorth>Eddi|zuHause: which one distracts you less from making ottd commits?
10:20<Eddi|zuHause>err, i have never made ottd commits :p
10:20<andythenorth>well you should :)
10:21<@Alberth>perhaps s/commit/patche/ ? :)
10:22-!-KouDy1 [] has joined #openttd
10:24<andythenorth>Alberth: perhaps an example script might be the best initial spec? :o
10:24<andythenorth>like defining some method handlers and sample logic?
10:25<@Alberth>I would add some primitives to the AI api, and make a script as a first experiment
10:26<@Alberth>next to looking at what to drop from newgrf specs
10:26<andythenorth>I'll write some code for something else for 10 mins
10:26<andythenorth>then maybe look at newgrf scrpts
10:26<andythenorth>specs /s
10:26<andythenorth>my brain is not good with words today
10:26<andythenorth>minor sleep deprivation has same effect on cognition as drunkness
10:27<@Alberth>under the assumption that one should be able to play without scripts, changing newgrf specs would already cause major havoc :p
10:31<andythenorth>Alberth: it's a step change in spec
10:31<andythenorth>there would need to be retained a compatibility version I guess
10:32<andythenorth>each newgrf cb would need a switch :P
10:32<@Alberth>each one? argh!
10:33<caracal>this discussion is riveting, as i'm in the process of designing a game and it'll have scripting ... wish i understood more about newgrfs ;)
10:33<@Alberth>just switching to a new newgrf version would be easier :)
10:34<caracal>having dealt with them as a player, they seem like a real rat's nest, though
10:34<andythenorth>caracal: I would work on the basis of anything I suggest about implementation is likely wrong :P
10:34<+michi_cc>Eddi|zuHause: What's visible and what is covered? The second plan has more stuff in the middle where it might get difficult to rerail stuff.
10:34<caracal>i have some ideas about what i want, but it's all very early days yet
10:35<caracal>but i certainly want to avoid the sorts of issues you guys are grappling with right now
10:35<@Alberth>caracal: just give up the idea that you'll do it right. In other words, make sure you can move to a new version easily
10:35<caracal>that sounds right
10:35<andythenorth>Alberth: it would be something like a lookup table containing cb IDs where script should win? I dunno
10:35<caracal>for any software, in fact
10:36<@Alberth>I'd always let the script win for things it can do
10:37<CIA-2>OpenTTD: frosch * r22619 /trunk/src/ (company_gui.cpp gfx.cpp gfx_func.h):
10:37<CIA-2>OpenTTD: -Fix [FS#4662]: Consider the size of the vehicle sprite for the lineheight in
10:37<CIA-2>OpenTTD: the company GUI. This also makes the widget containing the sprite not skip
10:37<CIA-2>OpenTTD: drawing it, if the bounds of the widget are outside of the drawing area though
10:37<CIA-2>OpenTTD: the sprite actually needs drawing.
10:37<Eddi|zuHause>michi_cc: what's covered is still a little vague. what's on top of what is respected in the image, shorter sections are likely to become bridges, longer sections tunnels
10:38<+michi_cc>Eddi|zuHause: General comment about both: The track length between stations/switching points isn't very long, which means there won't many opportunities to showcase rolling stock, if that's something important to you
10:39<Eddi|zuHause>that's probably a valid point
10:39<Eddi|zuHause>i've had the same thought already
10:40<Eddi|zuHause>but the only real way to solve that would be to use a smaller scale ;)
10:41<Eddi|zuHause>(or get a larger room :p)
10:41<+michi_cc>What's the room it has to fit inside? A big rectangle is always a bit boring in my opinion.
10:42-!-amkoroew [] has quit [Quit: Leaving.]
10:43<+michi_cc>Scale, definitely. If I ever build a fixed layout it's definitely going to be N. (Try to get an inexpensive HO IC wagon in proper length scale...)
10:43*Alberth is afk for some time
10:44-!-supermop [] has joined #openttd
10:44-!-amkoroew [] has joined #openttd
10:45<supermop>good morning
10:48<@Terkhen>hi supermop
10:49<supermop>how's it going?
10:50-!-anujmore [] has joined #openttd
10:52<@Terkhen>not bad
10:54-!-execat [] has quit [Ping timeout: 480 seconds]
11:03<supermop>sory, just had to open up shop
11:04<andythenorth>Terkhen: thoughts on scripting?
11:05<@Terkhen>anything that requires rewriting most of the game is too much work for me :)
11:05<supermop>what would scripting be used for>/
11:08-!-anujmore [] has quit [Remote host closed the connection]
11:10<@Terkhen>supermop: affecting economy, creating goals, making stuff happen at certain dates and so on
11:10-!-Pulec [] has quit [Ping timeout: 480 seconds]
11:11-!-KouDy [] has quit [Ping timeout: 480 seconds]
11:12<supermop>that sounds hard
11:12-!-Pulec [] has joined #openttd
11:14<@Terkhen>indeed, specially as it conflicts with existing stuff such as the newgrf specs
11:16-!-Adambean [] has joined #openttd
11:26<supermop>why are NAS boxes so ugly and expensive
11:26<supermop>i could tolerate one or the other
11:28<supermop>and most seem to be loud
11:30-!-Strid [] has quit [Ping timeout: 480 seconds]
11:30-!-Strid_ [] has joined #openttd
11:52-!-bodis [] has quit [Remote host closed the connection]
12:06<caracal>huh ... clicking the bomb on a bus station, says "Can't clear the area, must demolish bus station first" ... well duh, that's what i'm trying to do!
12:06<caracal>what am i doing wrong?
12:07<+glx>is it yours ?
12:07-!-staN [] has joined #openttd
12:08<caracal>no competitors in this town at all, in fact
12:08<caracal>i built it without hitting ctrl to connect it to the adjacent airport, and so i want to get rid of it and build it right
12:09<caracal>oh, and ... is there a way to connect two *existing* stations? or must you always do that at build time?
12:09-!-Absolutis [] has joined #openttd
12:10<Absolutis>do you know about Bill S.978?
12:11<Absolutis>well, you can read about it here
12:11<Absolutis>and here:
12:11<+michi_cc>caracal: Drive through stop? That error is returned when you aren't allowed to remove the underlaying road, I admit it could be clearer though. You can still use the remove tool delete the station.
12:11<supermop>How would i read about something on a video?
12:11<Absolutis>well, but the second, as it is a blog post
12:12<caracal>yes, it's a drive-through ... but what "remove tool" are you referring to?
12:12<supermop>i guess it could be a video of slowly scrolling text
12:12<Absolutis>seemingly, the government of USA wants to make let's plays and speed runs etc. illegal.
12:12<supermop>it looks like a little bulzozer
12:12<supermop>on the far right of the construction toolbar
12:13<caracal>aha, greyed out until i select a road tool ... but then, it says "local authority won't permit" ... meaning removing the road, i assume
12:13<caracal>which i don't want to do, just the station
12:14-!-Zuu [] has joined #openttd
12:15<+glx>click on station then on bullbozer
12:16<caracal>nope ... dozer is greyed out in that case
12:16<+glx>station on the toolbar
12:17<caracal>ah, duh
12:17<caracal>whew, finally! well that was quite non-obvious, thanks for walking me through it!
12:18<Absolutis>i think pretty obivous
12:19<caracal>maybe to you
12:19<caracal>not to a dunce like me, clearly <g>
12:22<caracal>i've never used the remove tool before, which is probably why it didn't jump into my mind until i was physically dragged to it
12:22<caracal>makes sense in retrospect
12:22-!-Devroush [~dennis@] has joined #openttd
12:22<caracal>nice to know about, actually, as the Demolish tool destroys the road *and* the station, which is quite often *not* what i want
12:23-!-Zuu [] has quit [Ping timeout: 480 seconds]
12:23<supermop>yeah, its helpful for finer detail work,
12:23<supermop>like removing signals
12:24<caracal>eh, i still haven't figured out the whole signal thing ... generally just avoid complex rail lines
12:24<caracal>n00b, i know ;)
12:33-!-ar3k [] has joined #openttd
12:40-!-ar3kaw [] has quit [Ping timeout: 480 seconds]
12:42-!-Devroush [~dennis@] has quit []
12:46<CIA-2>OpenTTD: frosch * r22620 /trunk/src/ (order_cmd.cpp order_gui.cpp): -Change [FS#4651]: Enforce refit orders to be 'always go to depot' orders; service-only and stop-in-depot orders make no sense with refitting.
12:46-!-Pulec [] has quit [Ping timeout: 480 seconds]
12:48-!-Pulec [] has joined #openttd
12:59-!-ysangkok [] has joined #openttd
13:03<ysangkok>i am experiencing some weird display corruption issues...
13:03<ysangkok>with v 1.1.1
13:03<ysangkok>i read the FAQ, it didn't say anything about this
13:03<ysangkok>how do i get rid of this?
13:04-!-ar3k [] has quit [Quit: —I-n-v-i-s-i-o-n— 3.2 (July '10)]
13:04-!-Biolunar [] has quit [Quit: party!]
13:06-!-Absolutis [] has quit [Ping timeout: 480 seconds]
13:08<@Alberth>random guess, you are running full screen in windows?
13:08<@Alberth>and have the screen saver enabled?
13:09-!-Pulec [] has quit [Ping timeout: 480 seconds]
13:09<ysangkok>windows in linux
13:09<ysangkok>i think it only occurs when paused ... hmm
13:09<@Alberth>that's a new one :)
13:10<@Alberth>no idea. My linux doesn't do that, but I don't run a screen saver either
13:10<@Alberth>did you try a forum search?
13:10<ysangkok>will try now
13:11<ysangkok>i don't use screen savers
13:11-!-Pulec [] has joined #openttd
13:11<ysangkok>it's like a part of the screen stops getting updated (when it occurs)
13:11<ysangkok>i can see that because when i move the mouse around
13:12<ysangkok>it will disappear in a region
13:12<ysangkok>but if i move it back it's visible again
13:12<@Alberth>just in the openttd window or also outside it?
13:12<ysangkok>only in openttd
13:13<@Alberth>I have sometimes an update problem with gvim
13:13<@Alberth>but until now I thought it was something of gvim
13:13<ysangkok>i use intel graphics
13:14<@Alberth>the only thing I can think of is a sdl library problem
13:14<+glx>try 32bpp
13:14<ysangkok>i have display corruption in chrome sometimes, but i really think it's a chrome error
13:14<@Alberth>doesn't ring a bell, sorry
13:14<ysangkok>okay i will glx, thanks
13:14<ysangkok>but it's suspicious because i only see it when paused
13:15<ysangkok>and i played for lots of hours today
13:15<ysangkok>and it only just started now
13:15<ysangkok>so i think it might be related to my save game
13:15<@Alberth>you can try loading an earlier game if you still have one
13:16<@Alberth>or a different one
13:16<ysangkok>yeah i will
13:18-!-VaLeo_q [~Vadym@] has joined #openttd
13:19<VaLeo_q>hi all! tell me please, how can I change source branch to 1.1.1?
13:22<@Alberth>you want to check out the source code of 1.1.1 ?
13:22<@Alberth>or update to it
13:24-!-Pulec [] has quit [Ping timeout: 480 seconds]
13:24<VaLeo_q>ымт гзвфеу
13:24<VaLeo_q>svn update
13:24<VaLeo_q>it gives me latest version
13:24<Eddi|zuHause>you need to switch branches
13:24<Eddi|zuHause>to tags/1.1.1
13:25<VaLeo_q>$ svn update tags/1.1.1
13:25-!-Pulec [] has joined #openttd
13:25<@Alberth>svn switch svn://
13:26<@Alberth>update just changes revision in the current branch
13:26-!-Xrufuian [] has joined #openttd
13:26-!-Progman [] has joined #openttd
13:31<VaLeo_q>Alberth, Eddi|zuHause thank you! works well
13:32-!-perk11 [] has joined #openttd
13:32<@Alberth>not sure why you want it; changing that code is quite useless
13:33<@Alberth>(as soon as you change it, it is not 1.1.1 any more, and thus not compatible)
13:33-!-perk111 [] has joined #openttd
13:34-!-Wolf03 [] has joined #openttd
13:34-!-Wolf01 is now known as Guest689
13:34-!-Wolf03 is now known as Wolf01
13:35-!-amkoroew [] has quit [Quit: Leaving.]
13:36-!-sllide [] has joined #openttd
13:39-!-VaLeo_q [~Vadym@] has quit [Ping timeout: 480 seconds]
13:39<@planetmaker>he'll find out ;-)
13:39<@planetmaker>moin also
13:40-!-DayDreamer [~DayDreame@] has joined #openttd
13:40-!-Guest689 [] has quit [Ping timeout: 480 seconds]
13:40-!-perk11 [] has quit [Ping timeout: 480 seconds]
13:40-!-goblin [] has quit [Quit: leaving]
13:40<CIA-2>OpenTTD: frosch * r22621 /trunk/src/misc_cmd.cpp: -Fix: When asking the user to confirm an unsafe unpausing, there is no need to execute a command if 'no' is choosed. This also prevents crashing when clicking unpause while the confirm window is shown.
13:40<Chris_Booth>hi planetmaker
13:42-!-amkoroew [] has joined #openttd
13:45<andythenorth>hello planetmaker
13:45<blup>good day everyone
13:46<Chris_Booth>hi blup
13:46<Chris_Booth>howdy doody all
13:49<supermop>trying to decide if the increased cost per Gb is worth it to get a 2.5" based external drive, to be able to get a smaller physical size and lose the external power adaptor
13:50<@Alberth>buy a new computer :)
13:50<@Alberth>blup: FS#4665 is yours?
13:51<@Alberth>it's interesting
13:51<@Alberth>do you know how many windows could benefit from it?
13:52<supermop>computer is fairly new,
13:52<supermop>but i am paranoid about my work
13:52<blup>not much.. station list , bridge selection.
13:53<@Alberth>bridge selection?
13:53<@Alberth>afaik it already does what you want
13:53<blup>the patch is simply to prevent the station selection list to open everywhere ... but I decided to implement the feature more deeply into the window system so it can be reused in the future
13:53<@Alberth>yeah, that's good
13:55<@Alberth>I am not sure about using the center of the window. Typically, my mouse is on top of what I try to do.
13:55<blup>me neither
13:55<@Alberth>the bridge selection has some logic to avoid opening right over that
13:55-!-VaLeo_q [~Vadym@] has joined #openttd
13:56<blup>should've used the origin of the window like popup menus
13:56<@Alberth>what do you mean?
13:56-!-Pulec [] has quit [Ping timeout: 480 seconds]
13:57<@Alberth>I was wondering whether the window could get queried to give a position, or a widget where the mouse cursor should be inside
13:57<blup>window(0,0) try to be draw at _cursor.pos(x,y)
13:58<@Alberth>then you still have to move the mouse. the bridge selection places the first widget right under the mouse cursor
13:59-!-amkoroew [] has quit [Quit: Leaving.]
13:59<@Alberth>I was wondering whether you could add that to the generic system
13:59<blup>hmm .. true, but in the other hand ... it does not hide the tile where we clicked
13:59-!-bodis [] has joined #openttd
14:00-!-bryjen [~bryjen@] has joined #openttd
14:00<andythenorth>supermop: we use 2.5" drives for backup at work
14:00<andythenorth>they have upsides and downsides
14:00<@Alberth>I don't understand "does not hide the tile where we clicked", could you elaborate?
14:00<andythenorth>upside: they get used a lot because there is no hassle with cables + power adapters
14:01<andythenorth>downside: they're not reliable, which is an issue for a backup :P
14:01<andythenorth>the reliability is likely due to (a) form factor of case in the models we bought (b) the manner in which people walk around with them hanging out of their laptops by the cable
14:01-!-Pulec [] has joined #openttd
14:02<andythenorth>otherwise recommended
14:02<@Alberth>or do you mean it tries to stay out of the way where I am building a bridge? yes it does, and I think that's good, isn't it?
14:03<blup>sorry .. im still drinking my morning coffee
14:03<supermop>i thought they would be more reliable, as they would not be reliant on another power adaptor which might fail
14:03<@Alberth>oh, that's fine, I am not in a hurry :)
14:04<supermop>i really want a NAS with raid 5
14:04<supermop>but they are so ugly
14:04<supermop>and expensive
14:05<@Alberth>there are also some code style issues, should I put them here, or post them in the issue?
14:05<supermop>and building a box for freenas is also ugly (dont have room for an extra desktop), and going to be noisy/power hungry
14:06<blup>to place you into context .. on the servers I play, we have short games (3 hours), and to maximize delivery to pax/goods/mail ... we place stations (a and b) in this fashion: abababababab .. building this is already time consuming .. if we have to find the station selection list every time, it simply add more time
14:06<blup>that's why I was thinking of making that window opens at the cursor
14:06<@Alberth>me nods
14:07<blup>the idea of making the window open at _cursor.pos was simply to avoid hiding the tile where the user ctrl-place-the-station
14:07<blup>just to allow the player to be sure he's not placing the station at the wrong tile
14:07<blup>convenience thing
14:07<@Alberth>oh, your implementation also already stays out of the way? good
14:07<@Alberth>I didn't run it yet
14:08<blup>nope it is not ..
14:08<blup>I played a few games yesterday with ppl running the patches I released ... and this was the comment they gave me
14:08-!-andythenorth is now known as Guest691
14:08-!-andythenorth [] has joined #openttd
14:10<supermop>has anyone here used a drobo?
14:10<blup>nevertheless .. its a matter of second to modify it ... sadly .. I cannot update the patch .. just place a new one in the comments
14:11<@Alberth>you may want to check r21460 to see how the bridge selection computes coordinates
14:11<@Alberth>adding a new patch is fine
14:12<andythenorth>supermop: that's what we use at work
14:12<andythenorth>it's not great, but no NAS is
14:12<andythenorth>NAS just never quite works well in practice
14:12<andythenorth>nice idea
14:12<blup>k .. I'll fix that now
14:12<andythenorth>supermop: how much stuff do you have? Too much for Dropbox?
14:12<@Alberth>you may want to address some code style issues too
14:13<@Alberth>give me a moment to write them down
14:15-!-Guest691 [~Andy@] has quit [Ping timeout: 480 seconds]
14:16<supermop>Well, about 100 GB of music that i want somewhat protected (redundancy - all my CDs are about 500 miles away and dont want to rip them again), about 60-70 GB of photos, which need to be safe more than the music does, and then about 40 GB of work which would destroy my life if i lost it
14:16<supermop>all of that is on a 500 gb external now, which sort of failed a couple days ago
14:17<supermop>but somehow my computer was able to fix it
14:17<supermop>the music and a small subset of photos would be helpful to access from my ps3 as well
14:18<supermop>the work needs to be fairly local so that i can work on it in CS5 for my portfolio
14:18<supermop>but a remote back up would work as well
14:19-!-sllide [] has quit [Ping timeout: 480 seconds]
14:20<andythenorth>supermop: 1 or 2 of something like these:
14:21<supermop>im looking at these three
14:22<supermop>so far i dont plan on taking it off of my desk
14:23<supermop>but a 2.5 would let me if i wanted to
14:23<@Alberth>blup: perhaps you can put the bridge selection under the same mechanism too?
14:24<supermop>i could buy all of those cheaper on amazon, or walk around the corner at lunch to best buy to pick up the minimus or rikiki
14:25<xQR>is there any magic trick that makes the flyspray search work?
14:26<xQR>how does a search for "ADMIN_PACKET_SERVER_CLIENT_ERROR" not return this entry:
14:26-!-Mazur [] has quit [Ping timeout: 480 seconds]
14:27<xQR>oh, it's not showing closed entries by default -_-
14:30<xQR>been searching the problem in my code for an hour now, just to figure out that despite this bug being fixed before 1.1.1 release it didn't go into 1.1.1 :(
14:31<xQR>should have looked into 1.1.1 source code earlier
14:32<andythenorth>supermop: you don't want to keep your backup with your PC
14:32<andythenorth>I have anecdotes...
14:33<andythenorth>I once was leaving a room to go to see a film
14:33-!-H-land [] has joined #openttd
14:33<andythenorth>as I left a monitor caught fire
14:33<andythenorth>another time I went back to my room for keys I'd forgotten
14:33<andythenorth>and found a leak from the room above had just started dripping into the case vents on my mac
14:34<H-land>Question about the way distances between qu- oh my.
14:34<andythenorth>+ you've got the basics like theft and lightning strike
14:34<H-land>...Right, um. Distances between stations. Profit is calculated by how far your vehicles go, right?
14:35<H-land>So if I have two stations like twelvish tiles apart, five tile long stations with ore and a ore processing wossname, and I expand that ore accepting station to also take passengers, and make that seven tiles long and expand out so that the tip of the station were just nine tiles away from the mines' station...
14:35<@Alberth>blup: and you may want to verify that it works correctly in case of RTL (right-to-left languages).Eveything should be horizontally mirrored for those languages
14:36<H-land>Would there be any problem if the passenger tracks were inaccessable to the ore trains?
14:38-!-|Jeroen| [] has quit [Quit: oO]
14:46<@Alberth> says vehicle travel is not relevant for payment
14:46<@Alberth>otherwise, no problem. there is no need to connect all tracks to each other
15:05-!-ysangkok [] has quit [Quit: SIGXCPU]
15:05<CIA-2>OpenTTD: frosch * r22622 /trunk/src/economy.cpp: -Fix: When closing down companies their shares in other companies must be sold even if share trading is disabled at that point of time.
15:07<CIA-2>OpenTTD: frosch * r22623 /trunk/src/economy.cpp: -Cleanup: DoAcquireCompany() does not need to sell shares, ChangeOwnershipOfCompanyItems() already does that and it does it better.
15:13-!-andythenorth is now known as Guest695
15:13-!-andythenorth [~Andy@] has joined #openttd
15:14-!-goblin [] has joined #openttd
15:16<supermop>well I don't live in the UK, so theft isnt a big deal
15:16<supermop>but yeahmy apartment could easily burn down
15:16<supermop>but id be more worried about losing my bag with the HD in it
15:18-!-perk111 [] has quit [Read error: Connection reset by peer]
15:18-!-Guest695 [] has quit [Ping timeout: 480 seconds]
15:19-!-perk11 [] has joined #openttd
15:19-!-bryjen [~bryjen@] has quit [Quit: Leaving]
15:20-!-bryjen [~bryjen@] has joined #openttd
15:23-!-Mazur [] has joined #openttd
15:24-!-Pulec [] has quit []
15:25-!-goblin [] has quit [Quit: leaving]
15:30-!-Wolf01 [] has quit [Read error: Connection reset by peer]
15:30<@Alberth>@commit 22384
15:31<@DorpsGek>Alberth: Commit by rubidium :: r22384 trunk/src/network/network_server.cpp (2011-04-30 12:09:26 UTC)
15:31<@DorpsGek>Alberth: -Fix [FS#4585]: No client error packet was sent to the admin bots
15:31<CIA-2>OpenTTD: frosch * r22624 /trunk/src/economy.cpp: -Fix [FS#4654]: When closing an AI company the local player cheated to, we need to cheat him to another company.
15:31-!-Wolf01 [] has joined #openttd
15:34<@Alberth>xQR: it is listed in the 1.1.1-RC1 changelog
15:39-!-andythenorth [~Andy@] has left #openttd []
15:51-!-Zeknurn [] has quit [Read error: Connection reset by peer]
15:55-!-Zeknurn [] has joined #openttd
16:10-!-Amis [] has quit [Quit: *pop*]
16:14-!-Xrufuian [] has quit [Ping timeout: 480 seconds]
16:15-!-amkoroew [] has joined #openttd
16:19-!-Alberth [] has left #openttd []
16:24-!-Xrufuian [] has joined #openttd
16:38<xQR>which is probably why i thought it would be in 1.1.1 but apparently it isn't :/
16:43-!-andythenorth [~Andy@] has joined #openttd
16:44-!-andythenorth [~Andy@] has quit []
16:45-!-supermop_plus [] has joined #openttd
16:49-!-ar3k [] has joined #openttd
16:49-!-ar3k is now known as ar3kaw
16:51-!-weirdy [] has joined #openttd
16:51<weirdy>anyone around
16:52<weirdy>ohm, a supermop eh
16:52<weirdy>Well, I'll go ahead and ask...
16:53<supermop_plus>hmm it looks like andy is gone,
16:53<weirdy>Is there a way to disable the map from flooding from the edges?
16:53<supermop_plus>i just bought a hard drive
16:53<supermop_plus>raise it above sea level?
16:53<weirdy>With out having it above sea level, as in a setting or a console command or something
16:54<supermop_plus>in the editor?
16:54<weirdy>no, in a normal game
16:54<weirdy>It's just that I could do with using that one tile
16:54<supermop_plus>i dont think so
16:55<supermop_plus>is there already water on the edge of the map?
16:55<weirdy>Well, no, because it's freeform edges
16:55<weirdy>but when I lower the last tile on the edge of the map it floods
16:55<weirdy>which isn't very useful...
16:56<@Terkhen>good night
16:56<weirdy>It's a shame 'cause TTDP had the option to turn it off
16:56<Ammler>from where to flood it otherwise?
16:56<weirdy>That I'm not concerned about
16:56<Ammler>TTDP has nowater eges?
16:56<weirdy>It can do
16:56<weirdy>or could when I last used it
16:57<supermop_plus>you could build a square of canal, but then you still lose 1 tile of space
16:57<weirdy>I could really do with building right on the edge, nevermind
16:57<Ammler>why not rise it one tile?
16:57<Eddi|zuHause>what about just raising the map 1 tile?
16:57<supermop_plus>build on the edge above sea level
16:57<supermop_plus>yes, as above
16:58<Sylf>hehehe, 3 ppl, same idea
16:58<weirdy>How would I go about raising the entire map 1 level?
16:58<Ammler>he, not automatically, I guess
16:58<weirdy>Apart from the obvious
16:59<supermop_plus>does the whole map need to be the same level? or just the area around that part of the edge?
16:59-!-macee [] has joined #openttd
16:59<weirdy>What I'm trying to do is lay a junction with one two track line going under and across another two track line
17:02<supermop_plus>how is that going to work on the map edge?
17:02<weirdy>well, if I could lower the two most outer tiles without flooding it'd work brilliantly
17:02<Ammler>I guess, you need to provide an idea, how to flood water level else then from edge
17:03<Ammler>else someone could dry out the whole map
17:03<weirdy>IIRC in TTDP a ship depot would flood the tiles to the rear and rear l/r
17:03<weirdy>It'd be nice as a togglable feature at the least
17:04<weirdy>If I had the coding knowledge and motivation I'd do something about it
17:04<weirdy>alas, I don't
17:04-!-weirdy [] has quit [Quit: Hey ho]
17:04<Ammler>oh well, people can also just rise teh map
17:05-!-Pixa [~Pixa@] has joined #openttd
17:05<supermop_plus>maybe a really expensive 'sea' tile in the water contruction toolbar
17:06<Ammler>or river
17:07<Ammler>river on sealevel does flood
17:10<supermop_plus>and maybe an inverse canal tile
17:10<supermop_plus>tile of land that wont flood
17:10<Ammler>that you can make with canals
17:10<supermop_plus>water that borders it shows the little canal border
17:11<supermop_plus>not quite
17:11<supermop_plus>i one tile island at sea level requires 8 canal tiles and 1 tile of clear water
17:12<Rubidium>does anybody have a clue how to fix the issue some people seem to have with the new banner on the website breaking everything?
17:13<supermop_plus>buildable sea and river tiles could be useful for 'water types'
17:14-!-sllide [] has joined #openttd
17:14-!-DayDreamer [~DayDreame@] has quit [Quit: Leaving.]
17:20<CIA-2>OpenTTD: frosch * r22625 /trunk/src/saveload/vehicle_sl.cpp: -Fix (r22050)[FS#4642]: Do not zero the orders of disaster vehicles when converting savegames.
17:22<frosch123>noone seems to play with disasters :p
17:22<supermop_plus>maybe newgrfs for better disasters?
17:26<frosch123>Rubidium: weren't those issues only with alpha versions of firefox?
17:28<Rubidium>someone supposedly using chrome had the issue as well
17:30<supermop_plus>can one currently add disasters via newgrf?
17:30<frosch123>supermop_plus: newgrfs are an disaster themself
17:38<MNIM>I play with disasters, actually.
17:38<xQR>when i play it's always a disaster :/
17:38<supermop_plus>i would like to have a few more pervasive, less disastrous disasters
17:39<frosch123>like industry closure though being serviced? :p
17:39<frosch123>actually, did you set the difficulty setting "economy" to "fluctuating"?
17:40<frosch123>imo the biggest disaster in the whole game
17:40<xQR>oh yes ^^
17:42<xQR>and industry closure despite being serviced would actually fit in well, just let the disaster say their boss lost all the money speculating in stocks
17:42<xQR>or is that a too realistic scenario?
17:43<frosch123>maybe "production out sourced to the east" ?
17:43<xQR>has just the same problem that it's too realistic, thus boring :P
17:44<xQR>you can see that happen everyday when you look outside
17:44-!-macee [] has left #openttd []
17:44<frosch123>oh, you want "production out sourced to the west" ? :p
17:44<xQR>much better <3
17:44<xQR>and even more unlikely than the UFO attacks
17:44<xQR>i like it
17:51-!-Pixa [~Pixa@] has quit [Ping timeout: 480 seconds]
17:53-!-Adambean [] has quit [Quit: Gone fishing]
18:00-!-amkoroew [] has quit [Quit: Leaving.]
18:04-!-amkoroew [] has joined #openttd
18:21-!-frosch123 [] has quit [Remote host closed the connection]
18:26-!-Brianetta [] has joined #openttd
18:29-!-KouDy1 [] has quit [Quit: Leaving.]
18:32-!-Kurimus [] has quit [Ping timeout: 480 seconds]
18:37-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:40-!-bryjen [~bryjen@] has quit [Quit: Leaving]
18:50-!-staN [] has quit [Read error: Connection reset by peer]
18:56-!-Cybertinus [] has quit [Remote host closed the connection]
18:56-!-sla_ro|master [~slaco@] has quit [Quit: The Third Tiberium War -]
19:02-!-supermop [] has quit [Remote host closed the connection]
19:03-!-VaLeo_q [~Vadym@] has quit [Quit: Ухожу я от вас (xchat 2.4.5 или старше)]
19:04-!-sllide [] has quit [Ping timeout: 480 seconds]
19:07-!-supermop_plus [] has quit [Quit: supermop_plus]
19:22-!-amkoroew [] has quit [Quit: Leaving.]
19:28-!-bodis [] has quit [Remote host closed the connection]
19:35-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
19:37-!-Chris_Booth [] has quit [Remote host closed the connection]
19:38-!-ndujoe1 [] has joined #openttd
19:39<ndujoe1>a beginner, I have played the game on my computer some, wish now to observe multiplayer play to get a feel for the game itself online, instructions to do that ?
19:42-!-ndujoe1 [] has quit []
19:47-!-bryjen [~bryjen@] has joined #openttd
20:04-!-Progman [] has quit [Remote host closed the connection]
20:05<Eddi|zuHause>instruction #1: be patient.
20:08-!-douknoukem [] has quit [Read error: Connection reset by peer]
20:08<fjb>Time... what is time?
20:08-!-douknoukem [] has joined #openttd
20:18-!-Brianetta [] has quit [Quit: Tschüß]
20:22-!-KritiK [] has quit [Quit: Leaving]
20:47-!-perk11 [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
21:06-!-Devroush [~dennis@] has joined #openttd
21:19-!-Devroush [~dennis@] has quit []
21:53-!-ctibor [~quassel@] has quit [Ping timeout: 480 seconds]
21:56-!-JVassie [] has joined #openttd
22:01-!-JVassie_ [] has quit [Ping timeout: 480 seconds]
22:06-!-JVassie_ [] has joined #openttd
22:11-!-JVassie [] has quit [Ping timeout: 480 seconds]
22:22-!-bryjen [~bryjen@] has quit [Quit: Leaving]
22:26-!-rhaeder [] has joined #openttd
22:30-!-rhaeder1 [] has quit [Ping timeout: 480 seconds]
22:41-!-supermop [] has joined #openttd
22:42-!-bryjen [~bryjen@] has joined #openttd
22:44-!-fjb [] has quit [Remote host closed the connection]
22:54<caracal>waugh ... offer a subsidy, then the city fathers won't let me build there! wotta buncha maroons, screw 'em, i say
23:12-!-ctibor [~quassel@] has joined #openttd
23:21-!-supermop [] has quit [Quit: supermop]
23:25-!-ctibor [~quassel@] has quit [Ping timeout: 480 seconds]
23:48-!-ctibor [~quassel@] has joined #openttd
---Logclosed Sun Jul 03 00:00:42 2011