IRC logs for #openttd on OFTC at 2011-07-02
⏴ go to previous day
00:29:57 *** Optimus|lunar has joined #openttd
04:54:14 *** Eddi|zuHause has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
04:57:54 *** andythenorth has joined #openttd
05:59:18 *** andythenorth has joined #openttd
05:59:20 *** andythenorth has left #openttd
05:59:26 *** andythenorth has joined #openttd
06:01:43 *** andythenorth is now known as Guest648
06:01:43 *** andythenorth has joined #openttd
06:19:52 *** andythenorth has left #openttd
06:32:44 *** sla_ro|master has joined #openttd
07:00:12 *** andythenorth has joined #openttd
07:17:36 *** DayDreamer has joined #openttd
07:19:25 <peter1138> i'm still having a brain-fart on angle changes
07:25:19 <peter1138> also i have a var called change_angle
07:25:26 <peter1138> and i keep typing it as changle_angle
07:34:26 *** Alberth has joined #openttd
07:34:26 *** ChanServ sets mode: +o Alberth
07:34:32 <andythenorth> changle_angle is nicel
07:37:16 * andythenorth wonders if YACD could tell an industry how much cargo was supposed to be delivered this month
07:38:02 <andythenorth> if YACD could tell industry 'you require 42 crates of supplies for production boost'
07:38:15 <andythenorth> then the problem is moved to YACD and I can consider keeping supplies
07:38:43 <Alberth> in a game where the program is not even able to make industries go away?
07:39:41 <Alberth> of course anything is possible, but the newgrf spec tends to get in the way, in my experience
07:40:05 <Alberth> (unfortunately, we cannot live without it)
07:40:16 <andythenorth> it would be the correct solution though
07:40:20 <andythenorth> demand is modelled by yacd
07:40:41 <andythenorth> therefore yacd should take responsibility for notifying industry of its current demand
07:41:05 <andythenorth> this is going to be a headache if towncontrol is used for towns to also model demand
07:41:19 <andythenorth> there'll be no single controller of demand. big mess
07:41:46 <Alberth> yep, yet people think it is a good idea to have town control :(
07:42:36 <Alberth> imo the big problem is that there is no clear idea about what to do in newgrf and what in the program
07:42:55 <Terkhen> so either we use newgrf for everything or we use openttd for everything? :P
07:42:57 <Alberth> so peoples make messes at both sides
07:43:10 <Terkhen> yes, that's probably the issue
07:43:41 <Alberth> Terkhen: no, more like these and these kind of things are done in newgrf and other things in newgrf
07:44:04 <Alberth> eg global control should be in the game code imo
07:45:47 <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
07:46:16 <Terkhen> I wouldn't mind a different implementation other than newgrf, but I can't think of a way that is newgrf dependent anyways
07:46:36 <Terkhen> the same already happens with AIs; many vehicle sets require explicit support
07:46:51 <andythenorth> model demand + supply as a map feature - on a per-tile basis
07:46:56 <andythenorth> have the game control that
07:47:07 <andythenorth> whatever is on the tile has to respond appropriately
07:47:44 <andythenorth> houses / industries can explicitly create a supply on a tile
07:48:21 <andythenorth> only requires rebuilding the entire game and newgrf spec :P
07:48:35 <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
07:48:43 <Terkhen> s/personalize/customize/
07:49:11 <Terkhen> for the best way to solve it: I have sadly no clue
07:51:22 <andythenorth> I have ideas but they'll never happen
07:51:28 <andythenorth> due to stupid backward compatibility
07:51:44 <andythenorth> which is inconsistently applied
07:52:05 <Terkhen> hmm... what do you mean?
07:52:29 <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
07:52:51 <andythenorth> basically it's know that I'll fix my stuff, whereas other people won't
07:52:56 * andythenorth is short of sleep
07:54:49 <andythenorth> anyway - my proposal would be
07:55:04 <andythenorth> - take a red pen to a lot industry newgrf spe
07:55:16 <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
07:55:18 <andythenorth> - put supply and demand factors per cargo on each tile
07:55:42 <andythenorth> - decide whether 'economy' should be in-game, newgrf, or some other (squirrel or similar)
07:55:57 <andythenorth> - economy control then tied to some kind of possible goals framework
07:56:28 <Alberth> a script would be simplest, I think
07:57:22 <Terkhen> I agree, even for town control... but a script would need to take care of newgrf stuff
07:57:42 *** Cybertinus has joined #openttd
07:58:19 <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
07:59:07 <Terkhen> hmm... I guess so, as long as the script has a cargo translation table too
07:59:15 <Eddi|zuHause> the interface for that is town effect
07:59:23 <Eddi|zuHause> it should not use cargos directly
07:59:56 <andythenorth> the script would also need to be able to manipulate cargo payment rates
08:00:55 <Terkhen> what if I need to use a cargo that is not passengers, mail, food, water or goods?
08:01:07 <andythenorth> town effect is dumb
08:01:09 <Terkhen> let me rephrase that: what if I need more than 5 town effects?
08:02:18 *** JVassie has joined #openttd
08:02:27 <Terkhen> we could add more valid town effects, of course, but the script needs knowledge of that too
08:02:46 <Terkhen> this is what I meant with "tied tightly to NewGRFs"
08:03:15 <Terkhen> although town control probably belongs in a script as part of goal scripts
08:03:43 <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
08:03:50 <andythenorth> on this model industries could stop dicking around with acceptance
08:03:58 <Eddi|zuHause> a candidate i once thought about was TE_ENERGY
08:04:00 <andythenorth> acceptance is dictated by demand on the tile
08:04:10 <andythenorth> demand = 0: no acceptance
08:04:26 <Alberth> Terkhen: why should you want > 5 town effects? we have many limits, like industry production/acceptance
08:04:28 <andythenorth> although industry would have to reply to a script cb setting acceptance, so...meh
08:04:58 * andythenorth ponders drawing a grid with accept / supply amounts on to test this
08:05:19 <Alberth> sleep is more useful probably
08:05:28 <andythenorth> the various cargo dist versions would then manipulate the supply / demand
08:05:33 <andythenorth> mostly the demand
08:05:48 <andythenorth> the basic game would just have flat supply and demand, with no coupling between supply and demand
08:06:02 <Terkhen> hmmm... I could use only 5, yes
08:06:23 <andythenorth> so the job of a cargo dist is then two things: (1) route cargo efficiently across the link graph (2) model demand
08:06:36 <Terkhen> but the point is that any changes on NewGRF specs could affect also scripts
08:07:47 <Terkhen> Alberth: we can continue this conversation once you are rested if you want :)
08:08:22 <andythenorth> it might be better if newgrf industry was slightly less capable :P
08:08:44 <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
08:09:02 <andythenorth> currently the model is 'an industry set is responsible for *everything* it wants to change, game won't provide very much'
08:09:11 <Alberth> Terkhen: good, andy, you can sleep now :p
08:09:15 <andythenorth> except the game provides two ways of processing cargo, both of which are problematic
08:09:29 <andythenorth> and two economies
08:09:30 <Terkhen> oh, you meant andy :P
08:09:42 * andythenorth has to go out and do baby shopping anyway
08:09:44 * Alberth is in favor of simpler industry newgrfs
08:09:53 <Terkhen> andythenorth: this is what I meant with "yacd should take into account NewGRFs" :)
08:10:16 <andythenorth> newgrf should be relatively dumber
08:10:21 <Terkhen> Alberth: I agree, scripts and newgrfs should be as less tied as possible
08:10:29 <Terkhen> but yes, newgrfs are too smart for that
08:11:08 <Terkhen> but if you make big changes to newgrf specs you lose newgrfs/compatibility with TTDPatch
08:11:20 <andythenorth> ttdpatch is nearly dead
08:11:29 <andythenorth> none of my newgrfs are patch compatible anyway
08:11:40 <andythenorth> if that's bad - well life is short :P
08:11:40 <Alberth> if you don't, you get yourself stuck in a corner you never get out
08:11:52 <Terkhen> maybe, but many people use the newgrfs created for it
08:12:23 <Alberth> they can update the newgrfs, right?
08:12:41 <Terkhen> well, we don't have this issue with vehicle sets I think
08:12:43 <Alberth> and if the authors walked away, and left us with the mess, why should we get bothered by it
08:13:29 <Terkhen> what parts of the specs would cause problems with scripts exactly?
08:14:13 <andythenorth> I need to think about how practical it would be to reduce industry / cargo / house spec
08:14:15 <Alberth> I think you should do 3 more steps back, and reconsider the goal of grfs, scripts and the program first
08:14:25 <andythenorth> I'm out for a few hours anyway, I can think
08:15:41 <Terkhen> grfs: define how in game items behave
08:15:47 <andythenorth> the issue is where to draw the line between newgrf and script
08:15:47 <Terkhen> scripts: global behavior
08:15:55 <Terkhen> but my definition lacks ^
08:15:57 <andythenorth> it's easy to say that industry provides tiles + graphics + animation
08:16:08 <andythenorth> it's probable to say industry sets input / output cargos
08:16:21 <andythenorth> what's difficult is things like production rates, secondary processing, closure
08:16:34 <andythenorth> and things like cargo payment rates, house cargo production etc
08:16:37 <Alberth> imho, grfs define how the graphics look
08:17:55 <Eddi|zuHause> i think we're way too far beyond that point already
08:18:11 <andythenorth> the less control an industry has on logic, the more likely a script routes is to succeed
08:18:15 <andythenorth> cleaner interface
08:18:33 <Terkhen> a script should not care about an industry's internal behavior IMO
08:20:10 <Alberth> Eddi|zuHause: static data such as properties would be fine too
08:20:48 <andythenorth> Terkhen: moving all the (e.g.) production logic to a script might be viable though
08:20:57 <andythenorth> newgrf would then ship with a default script maybe
08:21:07 <andythenorth> not sure whether multiple scripts would be allowed per game
08:21:19 <andythenorth> which is a problem, because then they're monolithic
08:21:29 <Terkhen> yes, it would be viable, my question is why do you need to move "individual industry behavior" from newgrfs to scripts
08:21:44 <Alberth> imo production logic is internal to the industry -> newgrf
08:21:46 <andythenorth> because individual industry behaviour is one of the headaches
08:22:03 <andythenorth> closure, production increase/decrease are the two really painful points
08:22:06 <andythenorth> processing much less so
08:22:19 <Terkhen> I agree that closure is one of the headaches
08:22:24 <Terkhen> see you later andythenorth
08:22:27 <Alberth> closure and increase/decrrease is a script or a game
08:22:44 <Eddi|zuHause> so you actually need a way to embed a script into the newgrf, as a replacement for varaction2-callbacks
08:23:35 <Terkhen> otherwise you need the script to know all individual industries in a newgrf, and give each one the intended behavior
08:23:50 <Terkhen> and then the script is tied to a specific industry newgrf
08:23:54 <Alberth> then you can just leave it as is, as you are then just moving the computations from newgrf to scripts, and gain nothing
08:24:31 <Terkhen> "some" of the internal behavior of industries might get in the way of scripts (I don't know what parts)
08:24:59 <Terkhen> but most of it should remain in the newgrf, as it is the one that defines the new industry types
08:25:49 <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
08:26:28 <Terkhen> but from what I remember now, stuff like production and so on should remain in the newgrf
08:27:17 <Alberth> production based on delivered cargo, sure
08:28:21 <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
08:29:31 <Alberth> the whole town control is imho just an attempt to boraden the scope towards that overview, thus further blurring the border
08:29:40 <Alberth> (sorry, I am just ranting)
08:30:15 <Terkhen> don't worry, having this conversation was in my todo list before thinking the town control specs :P
08:31:06 <Terkhen> this is how I see the problem: a "clean" solution would require breaking existing industry and maybe house newgrfs
08:31:20 <Terkhen> and I'm not sure that's a good idea
08:31:37 <Alberth> eventually you have to do it, or you die
08:32:13 <Terkhen> lot of effort has been made in some of those newgrfs, and they could die because of something like this
08:32:13 <Alberth> or keep the mess forever, making everybodies life miserable
08:34:00 <Alberth> if they are open source, they will get updated
08:34:10 <Alberth> if they are not, they deserve to die, imho
08:36:40 <Terkhen> I still think that they should work somehow, even if the changes are made
08:36:45 <Terkhen> a compatibility mode or something like that
08:38:00 <Alberth> my point of view is probably too extreme, but you cannot have everything. Somewhen you need to decide to go left or right
08:39:13 <Alberth> if you do both, you always have to make compromises, and never get anything implemented really good
08:43:01 <Terkhen> knowing for sure what would break and what would not would help with a decision :P
08:51:03 *** Biolunar has joined #openttd
08:52:04 *** Progman has joined #openttd
08:56:04 <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
08:57:19 *** amkoroew has joined #openttd
09:10:15 <ccfreak2k> Alberth, can't make everyone happy.
09:14:28 <Alberth> It's a good description to express what I mean
10:01:11 *** Wizzleby has joined #openttd
10:01:30 *** Chris_Booth has joined #openttd
10:01:49 *** Wizzleby is now known as Guest662
10:04:41 <DorpsGek> __ln__: Bjarni was last seen in #openttd 13 weeks, 5 days, 10 hours, 42 minutes, and 38 seconds ago: <Bjarni> thanks
10:07:39 <Eddi|zuHause> that's a totally boring "last words" entry...
10:13:27 <caracal> finally read the docs and found out how to make trams work ... nice!
10:33:42 *** JVassie_ has joined #openttd
10:38:47 *** frosch123 has joined #openttd
10:43:15 *** Eddi|zuHause has joined #openttd
10:44:22 *** andythenorth has joined #openttd
10:51:20 <JVassie_> whats the 'opposite' of substr()?
10:53:30 *** Brianetta has joined #openttd
11:15:10 *** HerzogDeXtEr1 has joined #openttd
11:23:51 *** andythenorth is now known as Guest666
11:23:52 *** andythenorth has joined #openttd
11:24:46 <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.
11:28:24 <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.
11:29:48 <andythenorth> extending the delivery window for supplies is an interesting and simple change
11:30:07 <andythenorth> so instead of having to deliver every month, player has say...6 month
11:30:20 <andythenorth> so in that case they get 1 production increase every 6 months
11:30:26 <andythenorth> instead of chance of 6
11:30:35 <andythenorth> the human mind is so dumb sometimes
11:30:46 <andythenorth> proven endlessly in pyschological tests :P
11:31:16 <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
11:31:21 <CIA-2> OpenTTD: frosch * r22616 /trunk/src/ai/ai_gui.cpp: -Codechange: Fix typo.
11:32:27 <Eddi|zuHause> andythenorth: that's why my proposal has a 12 months supply storage
11:32:42 * andythenorth is bored of trying to design for stupid people who can't do basic maths
11:33:10 <andythenorth> Eddi|zuHause: your proposal is at least implementable ;)
11:33:43 <andythenorth> N would be tied to production multiplier
11:34:19 <andythenorth> I can do without storage entirely, and set a counter in a register
11:34:27 <andythenorth> storage really just complicates the issue
11:34:36 <andythenorth> I wish storage was removed from the spec :P
11:34:44 <andythenorth> pikka probably doesn't
11:35:00 <andythenorth> the storage is a stupid piece of failed spec
11:35:14 <Eddi|zuHause> andythenorth: well, "storage" is exactly what you need so people don't worry about missing a window
11:35:27 <andythenorth> i.e. I am being rude about stockpiling, not persistent storage
11:35:34 <andythenorth> persistent storage is the correct answer :)
11:35:48 <andythenorth> persistent storage + *total* control over industry window text
11:36:01 <andythenorth> instead of some stupid strings I don't need, just because I have to enable production cv
11:36:30 <andythenorth> it's trivial to set a counter to 0 when supplies are received
11:36:38 <andythenorth> increment the counter every month or so
11:36:46 <andythenorth> set a maximum limit for the counter
11:37:11 <andythenorth> make the limit variable according to parameter or some other means
11:37:21 <Eddi|zuHause> doesn't sound like the right solution
11:37:32 <andythenorth> it's approximately how it's done now
11:37:39 <andythenorth> also same for secondary production combining
11:38:01 <andythenorth> I ignore everything to do with the built in 'stockpiles' - they're of no use
11:38:21 * andythenorth considers trying to patch industry window
11:38:22 <Eddi|zuHause> oh, yes, that also needs a display which delivery multiplicator is currently active
11:38:48 <andythenorth> I am waiting on nml conversion then I'll add that - there's a ticket for it
11:39:18 <andythenorth> accepting but ignoring supplies is interestingly evil
11:39:37 <andythenorth> "the industry will use any supplies you give it, but not necessarily very efficiently"
11:39:59 <andythenorth> "over-delivering supplies won't help, the workers will just use them having digger races"
11:43:56 <Alberth> you get production increase due to having happy workers :p
11:46:22 *** Brianetta has joined #openttd
11:47:17 <andythenorth> Eddi|zuHause: what should N be?
11:47:27 <andythenorth> the actual value of the production multiplier might be ok
11:47:38 <Eddi|zuHause> possible, needs testing
11:47:45 <andythenorth> and how does storage space change if N changes?
11:47:55 <andythenorth> N * 12 is a moving target...
11:48:23 <Eddi|zuHause> yes, that's intended. the more the industry needs, the higher the storage must be
11:48:43 <andythenorth> ok so if I have 500t supplies stored, and production falls, what happens?
11:49:07 <Eddi|zuHause> same as when delivering 1000t at once
11:49:21 <andythenorth> some supplies are just sent to dev/null ?
11:49:37 <Eddi|zuHause> yes, i think that's the best solution
11:50:16 <Eddi|zuHause> but according to my suggestion production shouldn't decrease when 500t supplies are waiting
11:50:28 <Eddi|zuHause> so the situation wouldn't occur
11:50:43 <andythenorth> this is a good point
11:50:49 * andythenorth can't do basic maths
11:52:07 <andythenorth> so I would show consumption rather than requirement
11:52:42 <Eddi|zuHause> yes. "16t of supplies consumed per month, currently 48t in storage"
11:53:34 <andythenorth> ok, so some players who want an increased chance of increase (bad sentence) if they deliver more supplies
11:53:38 <andythenorth> those guys lose out?
11:54:55 <andythenorth> and the limit should be configurable?
11:55:06 <andythenorth> because that was needed last time stockpiling was tested
11:55:18 <Eddi|zuHause> not sure... maybe
11:55:41 <Eddi|zuHause> but "1 month" tends to be a little short
11:56:29 *** Moustachio has joined #openttd
11:56:52 <andythenorth> Eddi|zuHause: I can't find any flaws with your method
11:57:04 <Eddi|zuHause> that's the genious part ;)
11:57:47 <andythenorth> I'm not sure what to do about storage limit
11:57:51 <andythenorth> players hate them
11:58:19 <andythenorth> if we're prepared to kill a kitten, I have an idea
11:58:34 <andythenorth> limit should be N * M
11:58:46 <andythenorth> where M is configurable, up to a stupid upper limit
11:59:13 <Eddi|zuHause> N = (function of) production multiplier, M = parameter?
11:59:30 <DorpsGek> andythenorth: 5461.33333333
12:00:11 <andythenorth> supplies delivery window: 1 month | 3 months | 6 months | 12 months | 5000 years
12:01:15 <Alberth> your diggers have good quality :)
12:01:32 <andythenorth> I think it's a nice way of catering for idiots who have no taste
12:01:38 <andythenorth> steve jobs wouldn't bother :P
12:01:46 <andythenorth> but he doesn't have to read tt forums
12:04:21 <Alberth> you may have some more lower values, eg I can imagine 2 months to be interesting
12:06:00 <andythenorth> yes 2 months would make sense
12:16:23 <andythenorth> Terkhen: Alberth the scripts / newgrf boundary is no clearer :P
12:20:41 <Alberth> without first defining what goes where, sure. You'd just rewrite current newgrf code to script code, and make no progress.
12:21:22 * andythenorth wonders - is it even practical to talk of storing more stuff in map array?
12:24:37 <Alberth> why do you want to store cargoes in tiles?
12:25:16 <andythenorth> I want to amounts for supply and demand
12:25:26 <andythenorth> not sure why yet
12:25:32 <andythenorth> think it might be interesting to explore
12:25:46 <andythenorth> think it might interact interestingly with YACD and such
12:26:08 <andythenorth> not really a formed idea yet, just a small thought
12:26:21 <Alberth> but it'd be static or not?
12:26:25 <execat> Guys is there an alternate end to OpenTTD than buying out your opponent?
12:26:40 <andythenorth> Alberth: that might depend on the script controlling the game...
12:26:43 <execat> Out of several (~30) games I have played with my bro, it has happened just once.
12:27:15 <Eddi|zuHause> execat: openttd has no end
12:27:41 <andythenorth> currently basic game, all demand is pretty much 1 or 0
12:27:57 <andythenorth> related things like payment rate are same for every tile
12:28:09 <Eddi|zuHause> execat: the official goal is having the highest company rating (1000) in the year 2050
12:28:16 <andythenorth> YACD implies a varying demand function, but it's a virtual implementation afaik
12:28:27 <andythenorth> so YACD has to model demand as well as routing
12:28:37 <andythenorth> really YACD could just handle routing
12:28:39 <execat> Haha. The farthest we reached was 2020 before something or the other came up.
12:28:40 <Alberth> andythenorth: you can think about it by tile, and store the data in newgrf as long as it gets accessed by tile
12:28:48 <andythenorth> and something else could model demand
12:28:59 <andythenorth> this seems to be how YACDist is now approaching it...
12:29:32 <andythenorth> practically constraints might be (a) storage amount needed and (b) is script language WAY too slow to do this
12:29:38 <andythenorth> YACD already murders my battery
12:29:52 <Eddi|zuHause> execat: most people make up their own goals, like "connect all industries" or "grow town to 200k inhabitants"
12:30:31 <Alberth> yeah, it might be a bit too detailed
12:30:52 <andythenorth> possibly, but it seems like right direction
12:30:58 <execat> Eddi|zuHause: We keep it to most profits and hightest company value.
12:31:08 <Alberth> and usually, I build a station right next to the industry so I cover all tiles anyways :p
12:31:16 <andythenorth> YACD(Dist) + industry-cargo newgrf + town control = car crash
12:31:44 *** Moustachio is now known as MNIM
12:32:11 <MNIM> I don't really play with goals... I just build beautiful tracks, bonus points if it turns profit :D
12:33:04 <Alberth> andythenorth: there are so many simple ways to spend huge amounts of CPU time :p
12:43:32 <andythenorth> @calc 2048*2048*32
12:43:44 <DorpsGek> andythenorth: 4194304
12:43:52 <andythenorth> @calc 4194304*32
12:43:52 <DorpsGek> andythenorth: 134217728
12:44:10 <andythenorth> @calc 134217728 / 1024
12:44:10 <DorpsGek> andythenorth: 131072
12:47:37 <andythenorth> Alberth: what problems did you run into with newgrf spec doing too much>
12:48:44 <Alberth> basically trying to decide things locally that should be decided globally
12:48:52 <Alberth> such as industry closure
12:49:46 <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.
12:50:34 <Alberth> never encountered it myself, but stuff like costs also seem to have that problem
12:50:45 <Alberth> but perhaps that is even bigger
12:51:31 <Alberth> industry probabilities may also be one
12:51:58 <Alberth> but you need some form of indication, so I don't think you can throw it away
12:54:15 <Alberth> and the whole trouble with disabling other newgrfs is another biggie :p
12:54:29 <andythenorth> there's also town control and houses to think about
12:54:49 <andythenorth> imo a house set should be really simple
12:54:55 <andythenorth> and not have to deal with cargos
12:54:59 <Alberth> town control is a crater full of worms (rather than just a can)
12:55:56 <andythenorth> a town building should either accept cargos or not
12:56:23 <Alberth> how are houses different from industry?
12:56:31 <andythenorth> they don't have any production logic
12:56:36 <andythenorth> just simple accept / produce
12:56:51 <andythenorth> all accept/produce could be delegated to town control
12:56:53 <Alberth> ie just fixed production logic :)
12:57:00 <andythenorth> and if town control wasn't newgrf, but a script...
12:57:20 <andythenorth> but a town might want to build certain kinds of building, which implies classes or such in newgrf
12:57:27 <andythenorth> which is a horrible interface to maintain
12:57:43 <andythenorth> although not impossible
12:58:39 <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.
12:58:39 <andythenorth> this is all starting to look like python interfaces + adapters :9
12:59:27 <Alberth> just because we make no choices
12:59:43 <andythenorth> soon we'll suggest duck typing :)
13:00:25 <andythenorth> Alberth: lets just talk about industry closure
13:00:26 *** Devroush has joined #openttd
13:00:33 <andythenorth> how would a script control that?
13:01:29 <Alberth> currently in the industry code, I have industries too many of some kind, and I cannot kill them
13:02:04 <Alberth> one approach would be to say every now and then to one of those industries 'please go away'
13:02:14 <andythenorth> ok so a simple script might have:
13:02:21 <andythenorth> - a list of required probabilities
13:02:26 <andythenorth> - a periodic processing loop
13:02:36 <Alberth> a different policy may be to watch what the player is doing, and build more industries of the same kind eg
13:02:47 <andythenorth> - some logic to decide which instance to close when number of instances > limit
13:03:28 <andythenorth> so it's similar-ish to AIs
13:03:57 <andythenorth> one economy script might build more mines if a player transports a lot of coal for example
13:04:14 <andythenorth> and it might want to control industry location?
13:04:26 <andythenorth> things like cb28 should possibly be delegated to scripts
13:04:31 <Alberth> I'd consider that a map property
13:04:51 <andythenorth> would an industry have any over-ride?
13:05:04 <andythenorth> e.g. game wishes to build at location x, industry can allow / reject
13:05:13 <andythenorth> similar to current code, but script controls location
13:05:14 <Alberth> that would render the script useless
13:05:50 <Alberth> I'd say the industry says what it likes to have, the script tries to provide
13:06:04 <andythenorth> that's where I think duck typing will arise :P
13:06:18 <Alberth> you can have local checks, eg map slopes
13:06:25 <andythenorth> tile checks are fine
13:06:30 <andythenorth> and should be preserve of industry
13:06:36 <andythenorth> they are isolated to that instance
13:06:52 <Alberth> but on the other hand, if it would state what it wants, the game can provide it
13:06:53 <andythenorth> cb28 checks for neighbouring industry etc - these are hard to decide who should have final say
13:07:06 <andythenorth> so the industry can decide or delegate?
13:07:31 <Alberth> the problem with newgrf logic is that it does not say why something was rejected
13:07:41 <Alberth> which makes planning trouble some
13:08:08 *** ChanServ sets mode: +o Yexo
13:08:12 <Alberth> eg, if I know that some industry type becomes available 5 years from now, I can start making room today
13:08:40 <andythenorth> I wonder if it would be impossible to decouple a script from a specific industry set
13:08:45 <Alberth> right now, the type just says 'no', and it can be for aby reason
13:09:17 <Alberth> depends on the quality of control that you want
13:09:54 <andythenorth> ideally scripts would not be tightly coupled to specific newgrs
13:10:00 <Alberth> if you tailor the script with knowledge of the industries, or even with the map, you get better control
13:10:12 <andythenorth> I don't know if full decoupling is realistic
13:10:18 <andythenorth> especially wrt cargos / industries
13:10:33 <Alberth> at the cost of having a very specialized script
13:11:05 <Alberth> what special code should be in a script for eg FIRS?
13:11:20 <andythenorth> depends how much of current newgrf spec is delegated to a script
13:11:27 <andythenorth> lets try and figure it out
13:11:45 <andythenorth> ok so a current problem is that often aluminium plants are built in FIRS during gameplay
13:12:11 <andythenorth> the cause is usually that the available land for them is taken by the time they're available
13:12:24 <andythenorth> so a script should try and solve that
13:12:34 <andythenorth> the introduction dates are known
13:12:36 <Alberth> as in 'no good map slopes' ?
13:12:57 <andythenorth> there is an alternative suggestion around terraforming, but ignore that for now
13:13:22 <andythenorth> so the intro date is known, the industry size is known
13:13:49 <andythenorth> what if you wanted to ensure supplying industries are also built around same time?
13:14:13 <Alberth> the script should make 'space' for the industry in a sense
13:14:59 <andythenorth> would it also try and build the complementary industries in the chain?
13:15:09 <Alberth> any chain should be build from first to last imho, I don't see that as special for FIRS
13:15:17 <andythenorth> so just go by date?
13:15:27 <andythenorth> try and ensure at least one instance of each type?
13:15:33 <andythenorth> (available type)
13:16:03 <Alberth> to be useful you also want it somewhat nearby
13:16:15 <andythenorth> so what if a player wants to script an economy with steel mills introduced in 1800
13:16:24 <andythenorth> and have it work with ecs, pbi, firs, opengfx+
13:16:31 <andythenorth> is that a step too far?
13:16:55 <andythenorth> to make that work, script has to know about 'steel mills'
13:17:29 <andythenorth> it's not implausible to label industry types similar to cargo types
13:17:38 <Alberth> you could have a list of cargoes instead
13:18:12 <Alberth> and the game/script can find the industries and the needed cargoes for supplying industries
13:18:32 <Alberth> cycles are a challenge then ;)
13:18:37 <andythenorth> I think anything like that won't work well in a newgrf-independent way
13:18:54 <andythenorth> that's why I wonder if newgrf-independent is a valid goal
13:19:43 <Alberth> I'd call it 'aim', rather than 'goal'
13:20:03 <andythenorth> any industry set also has a script accompanying
13:20:17 <andythenorth> using strictly defined methods
13:20:28 <andythenorth> any economy grf can over-ride those methods
13:20:41 <andythenorth> economy grf / economy script /s
13:21:13 <andythenorth> so the default FIRS behaviour might be 'try to locate industry x near why'
13:21:32 <andythenorth> but the script could over-ride that, or leave it as FIRS requests
13:22:09 <andythenorth> only one economy script
13:22:17 <andythenorth> only one script per industry newgrf
13:23:14 <Alberth> having more than one script sounds quite complicated
13:23:32 <Alberth> ie I want to override FIRS but not ECS :p
13:25:03 <andythenorth> ok so you have to write newgrf-specific code :P
13:25:29 <andythenorth> so maybe certain newgrfs are dependencies for a certain script
13:25:38 <Alberth> and it may be easier to keep that script in the newgrf :)
13:26:29 <andythenorth> hmm maybe newgrf doesn't need an accompanying script
13:27:23 <andythenorth> Alberth: only one script seems the way to go
13:27:37 <andythenorth> *but* then an author has to write code for *everything* or it doesn't work
13:27:54 <andythenorth> i.e. industries, towns, houses etc
13:28:06 <Alberth> you can split the script, of course
13:28:45 <Alberth> different parts, ie it does not have to be one big file
13:29:09 <andythenorth> but presumably compiled to one script?
13:29:18 <Alberth> and you are not considering what the game code should do atm
13:29:39 <andythenorth> probably the game code provides default / fallback behaviour
13:29:47 <Alberth> as in, you are moving a lot of current code into the script, I think
13:30:04 <andythenorth> that would make industry_cmd.cpp less bad for starters
13:30:12 <andythenorth> (moving the problem elsewhere)
13:30:43 <andythenorth> I could stop having to think about things like 'does player have multiple industries per town enabled' :P
13:31:36 <Alberth> I think moving the whole code to a script is not progress
13:31:48 <Alberth> you just shift the whole problem to another part
13:31:59 <andythenorth> ok lets rule that out for now
13:32:13 <andythenorth> so what does a script usefully do - besides allow industries to close? :)
13:33:22 <Alberth> I don't know. I find the distinction between script and game code too unclear
13:33:46 <andythenorth> me too currently
13:33:50 <Alberth> perhaps a script should be more about policies
13:34:10 <andythenorth> so it's mostly returning allow / disallow?
13:34:22 <andythenorth> rather than logic to try and run the game...?
13:35:03 <Alberth> policies in a script are more useful than in the game code :p
13:35:45 <Alberth> but coding some function is also a form of implementing policies
13:36:04 <Alberth> in particular, policies that the game code does not know about
13:38:10 <andythenorth> Alberth: I have run out of thinking :P
13:38:27 <andythenorth> certainly a system that requires 80% of game logic to be reimplemented in script language is not good
13:39:13 <andythenorth> but a system that can't run any logic is not much use
13:39:40 <Alberth> you'll always have logic, otherwise you don't have a game.
13:40:04 <Alberth> currently it is all in the game code, which works, but is hard to change/extend
13:40:48 <Alberth> so people try to work around it by adding fancy newgrf features, or by hacking custom openttds
13:41:27 <Alberth> or trying to get patches applied to trunk :p
13:43:00 *** |Jeroen| has joined #openttd
13:45:14 <andythenorth> fancy / baroque /s wrt newgrf features
13:45:30 * andythenorth has questions but ideas
13:45:48 <andythenorth> say there was some methods like town.grow(), industry.close()
13:46:02 <andythenorth> and the script provided logic to handle those
13:46:19 <andythenorth> and the script could also iterate items like towns and industries
13:46:48 <andythenorth> so for i in town_list: if i.some_condition: i.grow()
13:46:54 <Alberth> I'd put those in game code, they are the primitives of the world
13:47:09 <Alberth> (the town.grow(), industry.close() functions)
13:47:10 <andythenorth> ok - I defer to almost everybody else about good code practice
13:47:28 <andythenorth> so the interesting question
13:47:32 <andythenorth> I'm a script author
13:47:36 <Alberth> those primitives are the same whatever your policy
13:47:43 <andythenorth> I call industry.close on a specific industry
13:47:51 <andythenorth> do I win? or does the newgrf author?
13:48:02 <andythenorth> seems to need either a cascading policy, or an auction of some kind
13:48:33 <andythenorth> seems to me that the industry author should concede to the script
13:48:51 <andythenorth> and industry authors who want to provide specific gameplay should also provide their own economy script
13:48:51 <Alberth> you'd specify what happens with the method of course :) but I'd say the script should win
13:48:57 <andythenorth> the script should win
13:49:09 <andythenorth> what should scripts have access to?
13:49:11 <Alberth> otherwise the script is useless
13:49:15 <andythenorth> - *not* vehicles
13:49:21 <andythenorth> - everything else?
13:49:56 <Alberth> why not vehicles? in prinicple anything may be useful
13:52:32 <andythenorth> vehicles belong to player + AIs
13:52:43 *** amkoroew has joined #openttd
13:52:44 <andythenorth> maybe useful to differentiate getter / setter methods
13:52:58 <andythenorth> you'd allow script to have setter methods on players stuff? :o
13:54:19 <Alberth> you should have inspection capabilities imho
13:54:44 <andythenorth> there might be valid setters
13:55:07 <andythenorth> maybe costs, but they're already a giant can of worms
13:55:23 <Alberth> not on individual vehicles, but on the set as a whole perhaps
13:55:24 <andythenorth> ceding costs to scripts would be really useful for balancing
13:55:43 <andythenorth> a script could define that 3,000hp locomotives cost £xyz amount
13:56:54 <andythenorth> but that's a distraction from economy :P
13:57:09 <andythenorth> disasters should be scriptable :)
13:59:49 <Alberth> hmm, this player is making to much money, let's destroy his factory :D
14:01:37 <andythenorth> something like that
14:01:46 <andythenorth> incidentally a bridge disaster would be witty :P
14:02:02 <andythenorth> it would help if bridges were state machines as per eddi's suggestion
14:02:52 <Alberth> didn't someone complain of the game eating batteries? :p
14:04:02 <andythenorth> Alberth: how often does a script cycle? Is it every tick, every n ticks?
14:04:12 <andythenorth> or does it specify event handlers?
14:04:27 <andythenorth> or something else? I am out of my depth with such
14:04:28 <Alberth> every n ticks may be easier
14:04:44 <andythenorth> my experience is limited to flash where all are possible + a crazy timeline
14:05:10 <Alberth> but n can be fairly large, as you control global goals
14:05:42 <andythenorth> AIs must have solved that already?
14:05:54 <Alberth> ie checking the #industries once a month may be too often
14:06:41 <Alberth> it should be possible to do an AI-ish experiment by some hacking
14:07:13 <Alberth> you'll need some new primitives, mostly
14:13:09 <andythenorth> some stuff might not be possible
14:13:23 <andythenorth> like running a custom price calculation when a cargo is delivered
14:15:09 <Eddi|zuHause> hm, so which one would you prefer? www.informatik.uni-halle.de/~krause/zi1-7.png or www.informatik.uni-halle.de/~krause/zi2-3.png
14:15:49 <Alberth> andythenorth: sounds like too detailed control imho, just setting a few parameters to steer the computation should be sufficient
14:16:09 <andythenorth> cargo price calculation?
14:16:15 <andythenorth> it's already possible in nfo, but not very useful
14:17:37 <andythenorth> Eddi|zuHause: which one lets you go faster?
14:18:14 <Eddi|zuHause> andythenorth: curve radiuses and platform length is about equal
14:18:23 <Alberth> but nfo has no global overview, so it's useless for economic control :p
14:19:07 <Eddi|zuHause> everybody who attempted cargo price calculation in NFO died trying :p
14:19:13 <andythenorth> and using town control storage for calculating delivery would be no better
14:19:18 <andythenorth> it would be very edge-casey
14:19:21 <andythenorth> even if it worked
14:19:45 <andythenorth> Eddi|zuHause: which one distracts you less from making ottd commits?
14:20:39 <Eddi|zuHause> err, i have never made ottd commits :p
14:20:55 <andythenorth> well you should :)
14:21:34 <Alberth> perhaps s/commit/patche/ ? :)
14:24:01 <andythenorth> Alberth: perhaps an example script might be the best initial spec? :o
14:24:14 <andythenorth> like defining some method handlers and sample logic?
14:25:19 <Alberth> I would add some primitives to the AI api, and make a script as a first experiment
14:26:00 <Alberth> next to looking at what to drop from newgrf specs
14:26:17 <andythenorth> I'll write some code for something else for 10 mins
14:26:22 <andythenorth> then maybe look at newgrf scrpts
14:26:34 <andythenorth> my brain is not good with words today
14:26:58 <andythenorth> minor sleep deprivation has same effect on cognition as drunkness
14:27:44 <Alberth> under the assumption that one should be able to play without scripts, changing newgrf specs would already cause major havoc :p
14:31:24 <andythenorth> Alberth: it's a step change in spec
14:31:42 <andythenorth> there would need to be retained a compatibility version I guess
14:32:17 <andythenorth> each newgrf cb would need a switch :P
14:33:41 <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 ;)
14:33:44 <Alberth> just switching to a new newgrf version would be easier :)
14:34:05 <caracal> having dealt with them as a player, they seem like a real rat's nest, though
14:34:25 <andythenorth> caracal: I would work on the basis of anything I suggest about implementation is likely wrong :P
14:34:39 <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.
14:34:48 <caracal> i have some ideas about what i want, but it's all very early days yet
14:35:17 <caracal> but i certainly want to avoid the sorts of issues you guys are grappling with right now
14:35:36 <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
14:35:55 <andythenorth> Alberth: it would be something like a lookup table containing cb IDs where script should win? I dunno
14:35:58 <caracal> for any software, in fact
14:36:40 <Alberth> I'd always let the script win for things it can do
14:37:06 <CIA-2> OpenTTD: frosch * r22619 /trunk/src/ (company_gui.cpp gfx.cpp gfx_func.h):
14:37:06 <CIA-2> OpenTTD: -Fix [FS#4662]: Consider the size of the vehicle sprite for the lineheight in
14:37:06 <CIA-2> OpenTTD: the company GUI. This also makes the widget containing the sprite not skip
14:37:06 <CIA-2> OpenTTD: drawing it, if the bounds of the widget are outside of the drawing area though
14:37:06 <CIA-2> OpenTTD: the sprite actually needs drawing.
14:37:54 <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
14:38:15 <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
14:39:03 <Eddi|zuHause> that's probably a valid point
14:39:14 <Eddi|zuHause> i've had the same thought already
14:40:10 <Eddi|zuHause> but the only real way to solve that would be to use a smaller scale ;)
14:41:01 <Eddi|zuHause> (or get a larger room :p)
14:41:29 <michi_cc> What's the room it has to fit inside? A big rectangle is always a bit boring in my opinion.
14:43:00 <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...)
14:44:46 *** supermop has joined #openttd
14:44:49 *** amkoroew has joined #openttd
14:50:30 *** anujmore has joined #openttd
15:03:42 <supermop> sory, just had to open up shop
15:04:52 <andythenorth> Terkhen: thoughts on scripting?
15:05:16 <Terkhen> anything that requires rewriting most of the game is too much work for me :)
15:05:41 <supermop> what would scripting be used for>/
15:10:08 <Terkhen> supermop: affecting economy, creating goals, making stuff happen at certain dates and so on
15:14:12 <Terkhen> indeed, specially as it conflicts with existing stuff such as the newgrf specs
15:16:08 *** Adambean has joined #openttd
15:26:23 <supermop> why are NAS boxes so ugly and expensive
15:26:34 <supermop> i could tolerate one or the other
15:28:53 <supermop> and most seem to be loud
16:06:27 <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!
16:06:31 <caracal> what am i doing wrong?
16:08:18 <caracal> no competitors in this town at all, in fact
16:08:59 <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
16:09:52 <caracal> oh, and ... is there a way to connect two *existing* stations? or must you always do that at build time?
16:09:59 *** Absolutis has joined #openttd
16:10:23 <Absolutis> do you know about Bill S.978?
16:11:22 <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.
16:11:33 <supermop> How would i read about something on a video?
16:11:51 <Absolutis> well, but the second, as it is a blog post
16:12:07 <caracal> yes, it's a drive-through ... but what "remove tool" are you referring to?
16:12:12 <supermop> i guess it could be a video of slowly scrolling text
16:12:18 <Absolutis> seemingly, the government of USA wants to make let's plays and speed runs etc. illegal.
16:12:23 <supermop> it looks like a little bulzozer
16:12:56 <supermop> on the far right of the construction toolbar
16:13:40 <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
16:13:55 <caracal> which i don't want to do, just the station
16:15:02 <glx> click on station then on bullbozer
16:16:36 <caracal> nope ... dozer is greyed out in that case
16:17:49 <caracal> whew, finally! well that was quite non-obvious, thanks for walking me through it!
16:18:04 <Absolutis> i think pretty obivous
16:19:44 <caracal> not to a dunce like me, clearly <g>
16:22:02 <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
16:22:10 <caracal> makes sense in retrospect
16:22:16 *** Devroush has joined #openttd
16:22:55 <caracal> nice to know about, actually, as the Demolish tool destroys the road *and* the station, which is quite often *not* what i want
16:23:47 <supermop> yeah, its helpful for finer detail work,
16:23:53 <supermop> like removing signals
16:24:21 <caracal> eh, i still haven't figured out the whole signal thing ... generally just avoid complex rail lines
16:46:01 <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.
16:59:10 *** ysangkok has joined #openttd
17:03:13 <ysangkok> i am experiencing some weird display corruption issues...
17:03:37 <ysangkok> i read the FAQ, it didn't say anything about this
17:03:52 <ysangkok> how do i get rid of this?
17:08:48 <Alberth> random guess, you are running full screen in windows?
17:08:56 <Alberth> and have the screen saver enabled?
17:09:52 <ysangkok> i think it only occurs when paused ... hmm
17:10:35 <Alberth> no idea. My linux doesn't do that, but I don't run a screen saver either
17:10:46 <Alberth> did you try a forum search?
17:11:04 <ysangkok> i don't use screen savers
17:11:37 <ysangkok> it's like a part of the screen stops getting updated (when it occurs)
17:11:53 <ysangkok> i can see that because when i move the mouse around
17:12:01 <ysangkok> it will disappear in a region
17:12:14 <ysangkok> but if i move it back it's visible again
17:12:15 <Alberth> just in the openttd window or also outside it?
17:13:05 <Alberth> I have sometimes an update problem with gvim
17:13:32 <Alberth> but until now I thought it was something of gvim
17:13:58 <ysangkok> i use intel graphics
17:14:05 <Alberth> the only thing I can think of is a sdl library problem
17:14:23 <ysangkok> i have display corruption in chrome sometimes, but i really think it's a chrome error
17:14:26 <Alberth> doesn't ring a bell, sorry
17:14:31 <ysangkok> okay i will glx, thanks
17:14:52 <ysangkok> but it's suspicious because i only see it when paused
17:15:02 <ysangkok> and i played for lots of hours today
17:15:11 <ysangkok> and it only just started now
17:15:20 <ysangkok> so i think it might be related to my save game
17:15:51 <Alberth> you can try loading an earlier game if you still have one
17:18:21 *** VaLeo_q has joined #openttd
17:19:17 <VaLeo_q> hi all! tell me please, how can I change source branch to 1.1.1?
17:22:33 <Alberth> you want to check out the source code of 1.1.1 ?
17:24:39 <VaLeo_q> it gives me latest version
17:24:47 <Eddi|zuHause> you need to switch branches
17:25:33 <VaLeo_q> $ svn update tags/1.1.1
17:25:43 <Alberth> svn switch svn://svn.openttd.org/tags/1.1.1
17:26:20 <Alberth> update just changes revision in the current branch
17:26:23 *** Xrufuian has joined #openttd
17:26:38 *** Progman has joined #openttd
17:31:12 <VaLeo_q> Alberth, Eddi|zuHause thank you! works well
17:32:28 <Alberth> not sure why you want it; changing that code is quite useless
17:33:27 <Alberth> (as soon as you change it, it is not 1.1.1 any more, and thus not compatible)
17:33:56 *** perk111 has joined #openttd
17:34:56 *** Wolf01 is now known as Guest689
17:34:56 *** Wolf03 is now known as Wolf01
17:39:31 <planetmaker> he'll find out ;-)
17:40:15 *** DayDreamer has joined #openttd
17:40:42 <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.
17:42:43 *** amkoroew has joined #openttd
17:45:01 <andythenorth> hello planetmaker
17:49:35 <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
17:50:18 <Alberth> buy a new computer :)
17:50:36 <Alberth> blup: FS#4665 is yours?
17:51:31 <Alberth> do you know how many windows could benefit from it?
17:52:25 <supermop> computer is fairly new,
17:52:36 <supermop> but i am paranoid about my work
17:52:46 <blup> not much.. station list , bridge selection.
17:53:36 <Alberth> afaik it already does what you want
17:53:41 <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
17:55:00 <Alberth> I am not sure about using the center of the window. Typically, my mouse is on top of what I try to do.
17:55:18 <Alberth> the bridge selection has some logic to avoid opening right over that
17:55:49 *** VaLeo_q has joined #openttd
17:56:05 <blup> should've used the origin of the window like popup menus
17:57:35 <Alberth> I was wondering whether the window could get queried to give a position, or a widget where the mouse cursor should be inside
17:57:38 <blup> window(0,0) try to be draw at _cursor.pos(x,y)
17:58:31 <Alberth> then you still have to move the mouse. the bridge selection places the first widget right under the mouse cursor
17:59:34 <Alberth> I was wondering whether you could add that to the generic system
17:59:38 <blup> hmm .. true, but in the other hand ... it does not hide the tile where we clicked
18:00:24 <andythenorth> supermop: we use 2.5" drives for backup at work
18:00:33 <andythenorth> they have upsides and downsides
18:00:44 <Alberth> I don't understand "does not hide the tile where we clicked", could you elaborate?
18:00:52 <andythenorth> upside: they get used a lot because there is no hassle with cables + power adapters
18:01:05 <andythenorth> downside: they're not reliable, which is an issue for a backup :P
18:01:44 <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
18:02:03 <andythenorth> otherwise recommended
18:02:20 <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?
18:03:13 <blup> sorry .. im still drinking my morning coffee
18:03:20 <supermop> i thought they would be more reliable, as they would not be reliant on another power adaptor which might fail
18:03:33 <Alberth> oh, that's fine, I am not in a hurry :)
18:04:41 <supermop> i really want a NAS with raid 5
18:04:45 <supermop> but they are so ugly
18:05:01 <Alberth> there are also some code style issues, should I put them here, or post them in the issue?
18:05:38 <supermop> and building a box for freenas is also ugly (dont have room for an extra desktop), and going to be noisy/power hungry
18:06:08 <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
18:06:24 <blup> that's why I was thinking of making that window opens at the cursor
18:07:00 <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
18:07:24 <blup> just to allow the player to be sure he's not placing the station at the wrong tile
18:07:51 <Alberth> oh, your implementation also already stays out of the way? good
18:08:41 <blup> I played a few games yesterday with ppl running the patches I released ... and this was the comment they gave me
18:08:48 *** andythenorth is now known as Guest691
18:08:48 *** andythenorth has joined #openttd
18:10:14 <supermop> has anyone here used a drobo?
18:10:42 <blup> nevertheless .. its a matter of second to modify it ... sadly .. I cannot update the patch .. just place a new one in the comments
18:11:32 <Alberth> you may want to check r21460 to see how the bridge selection computes coordinates
18:11:59 <Alberth> adding a new patch is fine
18:12:05 <andythenorth> supermop: that's what we use at work
18:12:10 <andythenorth> it's not great, but no NAS is
18:12:23 <andythenorth> NAS just never quite works well in practice
18:12:40 <andythenorth> supermop: how much stuff do you have? Too much for Dropbox?
18:12:56 <Alberth> you may want to address some code style issues too
18:13:06 <Alberth> give me a moment to write them down
18:16:18 <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
18:16:52 <supermop> all of that is on a 500 gb external now, which sort of failed a couple days ago
18:17:05 <supermop> but somehow my computer was able to fix it
18:17:47 <supermop> the music and a small subset of photos would be helpful to access from my ps3 as well
18:18:22 <supermop> the work needs to be fairly local so that i can work on it in CS5 for my portfolio
18:18:40 <supermop> but a remote back up would work as well
18:21:46 <supermop> im looking at these three
18:22:55 <supermop> so far i dont plan on taking it off of my desk
18:23:13 <supermop> but a 2.5 would let me if i wanted to
18:23:39 <Alberth> blup: perhaps you can put the bridge selection under the same mechanism too?
18:24:52 <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
18:25:38 <xQR> is there any magic trick that makes the flyspray search work?
18:27:27 <xQR> oh, it's not showing closed entries by default -_-
18:30:59 <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 :(
18:31:25 <xQR> should have looked into 1.1.1 source code earlier
18:32:21 <andythenorth> supermop: you don't want to keep your backup with your PC
18:32:36 <andythenorth> I have anecdotes...
18:33:08 <andythenorth> I once was leaving a room to go to see a film
18:33:17 <andythenorth> as I left a monitor caught fire
18:33:27 <andythenorth> another time I went back to my room for keys I'd forgotten
18:33:54 <andythenorth> and found a leak from the room above had just started dripping into the case vents on my mac
18:34:05 <H-land> Question about the way distances between qu- oh my.
18:34:10 <andythenorth> + you've got the basics like theft and lightning strike
18:34:28 <H-land> ...Right, um. Distances between stations. Profit is calculated by how far your vehicles go, right?
18:35:36 <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...
18:35:47 <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
18:36:00 <H-land> Would there be any problem if the passenger tracks were inaccessable to the ore trains?
18:46:58 <Alberth> otherwise, no problem. there is no need to connect all tracks to each other
19:05:56 <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.
19:07:48 <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.
19:13:17 *** andythenorth is now known as Guest695
19:13:17 *** andythenorth has joined #openttd
19:16:13 <supermop> well I don't live in the UK, so theft isnt a big deal
19:16:34 <supermop> but yeahmy apartment could easily burn down
19:16:59 <supermop> but id be more worried about losing my bag with the HD in it
19:30:59 <DorpsGek> Alberth: Commit by rubidium :: r22384 trunk/src/network/network_server.cpp (2011-04-30 12:09:26 UTC)
19:31:00 <DorpsGek> Alberth: -Fix [FS#4585]: No client error packet was sent to the admin bots
19:31:03 <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.
19:34:50 <Alberth> xQR: it is listed in the 1.1.1-RC1 changelog
19:39:14 *** andythenorth has left #openttd
19:55:28 *** Zeknurn has joined #openttd
20:15:53 *** amkoroew has joined #openttd
20:24:24 *** Xrufuian has joined #openttd
20:38:26 <xQR> which is probably why i thought it would be in 1.1.1 but apparently it isn't :/
20:43:23 *** andythenorth has joined #openttd
20:45:02 *** supermop_plus has joined #openttd
20:49:57 *** ar3k is now known as ar3kaw
20:52:57 <weirdy> Well, I'll go ahead and ask...
20:53:02 <supermop_plus> hmm it looks like andy is gone,
20:53:13 <weirdy> Is there a way to disable the map from flooding from the edges?
20:53:14 <supermop_plus> i just bought a hard drive
20:53:28 <supermop_plus> raise it above sea level?
20:53:54 <weirdy> With out having it above sea level, as in a setting or a console command or something
20:54:38 <weirdy> It's just that I could do with using that one tile
20:54:38 <supermop_plus> i dont think so
20:55:06 <supermop_plus> is there already water on the edge of the map?
20:55:20 <weirdy> Well, no, because it's freeform edges
20:55:48 <weirdy> but when I lower the last tile on the edge of the map it floods
20:55:55 <weirdy> which isn't very useful...
20:56:11 <weirdy> It's a shame 'cause TTDP had the option to turn it off
20:56:15 <Ammler> from where to flood it otherwise?
20:56:29 <weirdy> That I'm not concerned about
20:56:41 <Ammler> TTDP has nowater eges?
20:56:58 <weirdy> or could when I last used it
20:57:05 <supermop_plus> you could build a square of canal, but then you still lose 1 tile of space
20:57:25 <weirdy> I could really do with building right on the edge, nevermind
20:57:41 <Ammler> why not rise it one tile?
20:57:43 <Eddi|zuHause> what about just raising the map 1 tile?
20:57:51 <supermop_plus> build on the edge above sea level
20:58:12 <Sylf> hehehe, 3 ppl, same idea
20:58:12 <weirdy> How would I go about raising the entire map 1 level?
20:58:40 <Ammler> he, not automatically, I guess
20:58:45 <weirdy> Apart from the obvious
20:59:01 <supermop_plus> does the whole map need to be the same level? or just the area around that part of the edge?
20:59:45 <weirdy> What I'm trying to do is lay a junction with one two track line going under and across another two track line
21:02:14 <supermop_plus> how is that going to work on the map edge?
21:02:41 <weirdy> well, if I could lower the two most outer tiles without flooding it'd work brilliantly
21:02:54 <Ammler> I guess, you need to provide an idea, how to flood water level else then from edge
21:03:29 <Ammler> else someone could dry out the whole map
21:03:34 <weirdy> IIRC in TTDP a ship depot would flood the tiles to the rear and rear l/r
21:03:58 <weirdy> It'd be nice as a togglable feature at the least
21:04:26 <weirdy> If I had the coding knowledge and motivation I'd do something about it
21:04:54 <Ammler> oh well, people can also just rise teh map
21:05:18 <supermop_plus> maybe a really expensive 'sea' tile in the water contruction toolbar
21:07:07 <Ammler> river on sealevel does flood
21:10:10 <supermop_plus> and maybe an inverse canal tile
21:10:25 <supermop_plus> tile of land that wont flood
21:10:47 <Ammler> that you can make with canals
21:10:57 <supermop_plus> water that borders it shows the little canal border
21:11:36 <supermop_plus> i one tile island at sea level requires 8 canal tiles and 1 tile of clear water
21:12:08 <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?
21:13:19 <supermop_plus> buildable sea and river tiles could be useful for 'water types'
21:20:44 <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.
21:22:09 <frosch123> noone seems to play with disasters :p
21:22:27 <supermop_plus> maybe newgrfs for better disasters?
21:26:58 <frosch123> Rubidium: weren't those issues only with alpha versions of firefox?
21:28:59 <Rubidium> someone supposedly using chrome had the issue as well
21:30:01 <supermop_plus> can one currently add disasters via newgrf?
21:30:43 <frosch123> supermop_plus: newgrfs are an disaster themself
21:38:06 <MNIM> I play with disasters, actually.
21:38:40 <xQR> when i play it's always a disaster :/
21:38:41 <supermop_plus> i would like to have a few more pervasive, less disastrous disasters
21:39:26 <frosch123> like industry closure though being serviced? :p
21:39:59 <frosch123> actually, did you set the difficulty setting "economy" to "fluctuating"?
21:40:08 <frosch123> imo the biggest disaster in the whole game
21:42:06 <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
21:42:22 <xQR> or is that a too realistic scenario?
21:43:18 <frosch123> maybe "production out sourced to the east" ?
21:43:48 <xQR> has just the same problem that it's too realistic, thus boring :P
21:44:09 <xQR> you can see that happen everyday when you look outside
21:44:31 <frosch123> oh, you want "production out sourced to the west" ? :p
21:44:49 <xQR> and even more unlikely than the UFO attacks
22:04:11 *** amkoroew has joined #openttd
22:26:47 *** Brianetta has joined #openttd
23:38:12 *** ndujoe1 has joined #openttd
23:39:02 <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 ?
continue to next day ⏵