IRC logs for #openttd on OFTC at 2010-10-17
⏴ go to previous day
00:04:07 *** lobstah has joined #openttd
03:36:37 *** trebuchet has joined #openttd
03:59:36 *** Xrufuian has joined #openttd
04:03:51 *** roboboy has joined #openttd
04:56:18 *** Eddi|zuHause has joined #openttd
05:41:45 *** Kurimus has joined #openttd
06:09:19 *** andythenorth_ has joined #openttd
06:11:30 *** roboboy has joined #openttd
06:15:26 *** andythenorth__ has joined #openttd
06:28:36 *** andythenorth_ has joined #openttd
06:28:36 *** andythenorth__ has quit IRC
06:28:38 *** ^Spike^ has joined #openttd
07:10:54 *** andythenorth_ has joined #openttd
07:21:20 *** last_evolution has joined #openttd
08:04:18 *** andythenorth_ has joined #openttd
08:06:49 <andythenorth_> Terkhen: what did you decide about partial refits?
08:07:06 *** Progman has joined #openttd
08:07:53 *** roboboy has joined #openttd
08:23:55 *** |Jeroen| has joined #openttd
08:45:07 <Terkhen> andythenorth_: the biggest problem is partial refit orders
08:45:30 <andythenorth_> I can see that would be hard
08:46:24 <Terkhen> I'm not sure if I should just ignore them, but given the amount of problems they raise IMO it's probably the best option
08:46:53 <Terkhen> besides that it is mostly a GUI problem only, as the existing refit command could be converted to work with partial refits
08:47:42 *** Cybertinus has joined #openttd
08:51:11 <Terkhen> about the GUI; my idea was to allow selecting the part of the train you want to refit at the depot window
08:51:27 <Terkhen> then a refit window for only that part would be opened
08:51:48 <andythenorth_> did you figure out how to do the selection yet?
08:52:20 <andythenorth_> I suppose ctrl-dragging to a refit button is a bad interaction?
08:53:31 <Terkhen> since most click combinations are already in use, I'd go with a refit button that would switch the behaviour to "select part to be refitted"
08:54:16 <Terkhen> but I still have not checked the depot GUI code to see if this is feasible
08:54:53 <andythenorth_> it's quite a change - moves the refit to be on the depot, not the vehicle?
08:55:50 <Terkhen> the refit button in the vehicle would maintain its behaviour: clicking on it would show the refit window for the complete vehicle
08:56:57 <Terkhen> the ideal solution would be showing the consist at the refit window and allowing to select parts there
08:57:14 <Terkhen> the vehicle drawing code is already splitted, but the selection code is not
08:58:27 <andythenorth_> consist makes more sense
08:58:40 <andythenorth_> if this gets extended to planes (two slots) then the depot view won't make any sense
08:58:49 <andythenorth_> it would be better to have a good generic solution
08:59:03 <andythenorth_> (and not have two different refit buttons - confusing!)
08:59:04 <Terkhen> hmmm... you are right
08:59:25 <Terkhen> then the best option is allowing to select parts at the refit window
08:59:31 <andythenorth_> I think it's quite a big ask to make this good
08:59:39 <andythenorth_> it would help to know how consists might work
09:00:26 <Terkhen> IMO this is independent of consists: now it would work with single vehicles, and when/if consists are done it could be tweaked to work with them
09:02:51 *** roboboy has joined #openttd
09:03:56 * andythenorth_ puzzles about interaction of shared orders (with refit) and consists
09:04:19 <andythenorth_> seems like solution would be 'goto depot A and refit to consist xyz'
09:04:26 <andythenorth_> then 'goto depot B and refit to consist pdq'
09:04:38 <andythenorth_> Terkhen: ^ that would simplify your life
09:04:47 <andythenorth_> only consists have to deal with partial refits in that case
09:05:03 <andythenorth_> shared orders don't care about what's inside the consist, just the consist ID
09:06:05 *** Keyboard_Warrior has quit IRC
09:07:43 <Terkhen> what if some of the vehicles sharing orders can't refit to that consist?
09:09:10 <andythenorth_> it's a consist - they replace vehicles ;)
09:09:25 <andythenorth_> consist specifies vehicles & refit *per* vehicle
09:09:40 <andythenorth_> orders specifies which consist to use when refitting
09:09:48 <andythenorth_> seems clean to me :)
09:13:21 <andythenorth_> if we have rv-wagons, we have to teach the AI about them....
09:15:09 <Terkhen> the consist idea alters many core parts of the game: vehicles, refits, groups, orders... I expect it to have a big can of worms hidden somewhere; that's why I think the first requirement for this are some specs describing what would it do and what would need to be changed
09:15:29 <andythenorth_> I am happy to try and write something
09:15:34 <andythenorth_> I know *nothing* about the internals :)
09:16:28 <Terkhen> as long as the specs are consistent, IMO they should make appear any concept problems with the idea
09:16:28 <andythenorth_> Terkhen: wiki page?
09:17:26 <Terkhen> a wiki page is better, otherwise it will become a feature suggestion discussion thread, and IIRC there's already one for this
09:19:16 <andythenorth_> let me finish refactoring HEQS and I'll try
09:20:41 * andythenorth_ is running out of IDs for articulated parts
09:21:09 <andythenorth_> there are only 40
09:21:21 <planetmaker> hm. Not when you keep default
09:21:31 <andythenorth_> I have to start at 58
09:21:49 <andythenorth_> I have a solution, but it's....much work :(
09:21:58 <planetmaker> @calc 0x80 - 0x58
09:22:18 <andythenorth_> currently HEQS ID use is very inefficient, as there were problems with refit cb for RVs when I first wrote HEQS
09:22:30 <andythenorth_> so I just made lots of vehicles with different properties
09:22:35 <planetmaker> But... how many articulated things do you need? One per tram probably, one per lorry
09:22:42 <Terkhen> are you planning that many additional vehicles for HEQS?
09:22:55 *** frosch123 has joined #openttd
09:22:55 <andythenorth_> trailers change capacity over time, so currently '1 trailer' might have 6 IDs
09:23:01 <andythenorth_> it's resolvable
09:23:09 <andythenorth_> I just have to change quite a lot of code :(
09:23:26 <frosch123> port to nml instead :p
09:24:09 <andythenorth_> we'll try BANDIT in nml
09:24:14 <andythenorth_> I'm not porting any existing nfo
09:24:31 <andythenorth_> for a start, I'd have to work out what it actually *does* so I can port it :P
09:44:48 *** roboboy has joined #openttd
09:57:16 *** ChanServ sets mode: +v tokai
09:59:18 <frosch123> andythenorth_: "I'm going to change many of the vehicle IDs in HEQS. This is so that HEQS doesn't replace the default game vehicles." <- what weird reasoning is that? :o
10:00:08 <frosch123> just tell them to load "original engines" grf or so
10:01:53 <planetmaker> :-) true Or OpenGFX+RV ;-)
10:08:56 <andythenorth_> then I have to do work to tell people
10:09:19 <andythenorth_> this way I just have to do some amount of code work to gain no new features :P
10:11:52 <xiong> I don't like industries to disappear. But it takes quite some time to spread out over the whole map and provide good service to all. Is it better to provide no service or crappy service? By 'crappy', I'm thinking of truck stops that go 2 tiles and dump their cargo. What kinds of cheap service can I provide to keep industry from closing up?
10:12:16 <andythenorth_> try a better industry set :)
10:12:26 <andythenorth_> or do the truck thing you suggested
10:13:16 <xiong> Also, is there ever any point trying to save an industry whose closure is 'imminent'? Seems that by the time I get anything set up, no matter how quickly or sparse, the industry is gone -- the warning comes too late. Can I inspect an industry and get earlier warning?
10:13:18 <frosch123> or use alberth's industry patch
10:13:32 <andythenorth_> the warning is to late
10:13:40 <andythenorth_> there's no earlier warning in default industries
10:16:33 <xiong> Patch is interesting; I'm looking it over. I'm not sure if I feel right about moving the goalposts that way, though.
10:17:57 <xiong> Seems to me I can keep a primary industry content, at least, by dumping its cargo at a next-door station. Dunno. But I don't see if doing that will work for a secondary industry, which seems to claim lack of supply as the reason for closure. Yes? No?
10:18:38 <andythenorth_> I'm not sure if the secondary code actually checks cargo delivered or cargo transported
10:18:48 <andythenorth_> but you can't get the latter without the former :)
10:21:31 <xiong> Right. I see a statement in (http://wiki.openttd.org/Game_mechanics#Station_rating): "Note: If a vehicle was ready to pick up a cargo but there was no cargo, it is regarded as a cargo pickup anyhow" -- I don't know if this applies to keeping an industry from closing. I can easily imagine dummy trucks going in and out.
10:22:00 <xiong> My problem is that I don't see a way to test this simply. If I put such a gimmick near an industry and it doesn't close, this tells me nothing.
10:22:41 <andythenorth_> testing industry things is....somewhat time consuming and frustrating :)
10:22:41 <frosch123> if you stockpile too many stuff at a station, the rating will decrease faster than it raises due to the trucks
10:23:04 <xiong> I imagine using a cheat to give me extra cash, then going around and doing this sort of thing all over a test map, then running for 100 years with breakdowns off.
10:23:16 <xiong> ... seeing what survives and what doesn't.
10:23:48 <andythenorth_> xiong: or use FIRS :)
10:23:52 <andythenorth_> and disable closures
10:23:54 <xiong> frosch123, I got a hint of that in one case.
10:24:14 <andythenorth_> or there is a 'no close' grf somewhere I think for default industries
10:25:30 <xiong> I probably should not think so hard about how to fix this; I dunno. The truck gimmick, even if it works, is not exactly square. I'm having a goal issue here.
10:26:27 <andythenorth_> xiong: you'll find you easily get enough money that you can build your own industries
10:26:34 <andythenorth_> depends on what your goal is
10:26:37 <xiong> I have a secondary bus station in every town I work, with local service, which seriously improves station rating and town growth. I can justify this under the heading of, yes, local service -- although with two stations right across the road from each other, it's a bit funky.
10:26:49 <andythenorth_> are you trying to win according to original 'win conditions' from default game?
10:26:51 <xiong> andythenorth_, That's the problem. What is my goal?
10:27:02 <andythenorth_> first win the game according to original win conditions
10:27:07 <andythenorth_> then you have to invent your own goals
10:27:10 <xiong> Ordinarily, I'm a very competitive player.
10:27:23 <andythenorth_> the best and worst things about openttd are 'no goals'
10:27:31 <xiong> I didn't know there was a particular win goal built in.
10:27:56 <andythenorth_> find 'detailed performance rating'
10:28:12 <planetmaker> hardly anyone uses it. Seems many not even know it ;-)
10:28:17 <andythenorth_> I used to use it
10:28:20 <xiong> So, my current goal is just to build out -- build big and build over the map; try to build efficiently. I think efficiency is more important than gross size.
10:28:27 <planetmaker> so do I sometimes
10:28:30 <andythenorth_> I won in every climate with default, then I had to invent my own stuff
10:28:31 <planetmaker> Most often not, though
10:28:43 <andythenorth_> it's a meta-game for me now
10:28:54 <andythenorth_> the 'game' is making stuff for the game
10:29:15 <andythenorth_> which means playing the technical game of nfo, and the social game of collaborative coding
10:29:36 *** KenjiE20 has joined #openttd
10:29:46 <andythenorth_> it's approximately similar to lego, but the collaboration opportunities are better :)
10:29:53 <andythenorth_> I think minecrack is having the same effect
10:30:19 <V453000> and which is also why openttd is so uniquely entertaining even for LOOOONG time :) because you basically challenge yourself and your ideas ... possibly improving them, for which there is like endless possibilities :)
10:30:45 <xiong> I guess I really am going to have to sit down and think about goals. My general approach to an open-ended game is to push against its limits.
10:30:54 <andythenorth_> xiong: you'll end up writing code :)
10:31:02 <andythenorth_> already you started on that route
10:31:11 <andythenorth_> the limits are the limits of the code, not the game
10:31:11 <xiong> andythenorth_, In a small way.
10:31:54 <xiong> I can't get too deeply into this; I have a large Perl project to complete. I have set a deadline of Easter Sunday for it.
10:32:20 <andythenorth_> openttd will suck time
10:32:34 <andythenorth_> occasionally I used to delete it
10:32:42 <andythenorth_> but I always ended up reinstalling
10:33:14 <andythenorth_> HEQS articulated parts just fit into available IDs
10:33:21 * Rubidium would rather go for whit monday as deadline
10:33:30 <andythenorth_> deadlines are weird
10:33:38 <xiong> Perhaps I should just abandon attempts to save industry. It closes, it closes.
10:33:56 <V453000> prospect more if you need?
10:34:02 <Rubidium> just to annoy all the folks with their it's "with" not "whit" complaints
10:34:08 <xiong> andythenorth_, Self-imposed. Otherwise, I'll never finish it.
10:34:12 <andythenorth_> frustrating if you just constructed a route to an industry that closes
10:34:40 <andythenorth_> has anyone tried recent FIRS with closure *on*?
10:34:45 <andythenorth_> I have no idea if it works
10:35:37 * Rubidium wonders whether this is the right channel for that question. Most in here either don't really play OpenTTD anymore and just hang around, or they find joy in changing things about OpenTTD and thus not really play OpenTTD
10:35:54 <andythenorth_> I could try #tycoon, but...
10:35:58 <andythenorth_> it's a wrong place
10:36:42 *** roboboy has joined #openttd
10:36:53 <lugo> but i'm definitly playing ;)
10:40:22 * Terkhen was going to play but things to do came up as usual
10:40:50 <planetmaker> lol @ Rubidium :-)
10:41:18 <planetmaker> lugo: can you prepare an update of the FIRS translation?
10:47:35 *** HerzogDeXtEr has joined #openttd
11:11:53 <planetmaker> still I think that the farms need some more thought
11:12:03 <planetmaker> Using the burocratic words is no solution either
11:12:11 <planetmaker> and just looks ugly IMHO
11:12:19 <andythenorth_> I was wondering if 'mixed farm' is just farm
11:12:33 <andythenorth_> in the UK it makes complete sense, but seems problematic for just about everyone else
11:15:50 <planetmaker> Milchvieh-Betrieb or Bauernhof is quite accurate and used - despite what he claims
11:16:07 <planetmaker> Ackerbaubetrieb might be better worded
11:16:27 <planetmaker> and indeed just Bauernhof for the mixed farm
11:17:36 <lugo> Milchvieh-Betrieb is ok i guess
11:18:29 <andythenorth_> is there a way to make an RV *longer*
11:18:40 <andythenorth_> return signed byte to length cb?
11:18:47 <planetmaker> maybe "Schafzuchtbetrieb" - but that doesn't cover wool adequately IMHO
11:20:29 <planetmaker> Bauernhof mit Schafhaltung?
11:22:05 <frosch123> andythenorth_: no, else you could bulldoze road/track between the trailers and crash ottd :)
11:28:54 <lugo> planetmaker, that's pretty hard, latter i think is correct but it looks and sounds weird ;)
11:36:36 *** roboboy has joined #openttd
11:38:43 <lugo> planetmaker, so i'd replace mixed farm with Bauernhof but as for arable farm, 'Getreidefarm' seems pretty unusual too :/
11:39:27 <planetmaker> lugo: Ackerbaubetrieb
11:40:28 *** Singaporekid has joined #openttd
11:41:19 <lugo> planetmaker, what do you think about 'Schrott-Recycling-Hof' for 'Abfallhalde'
11:41:39 <planetmaker> uhm... not really :-)
11:41:41 <davis> Abfall isn't quite recycling now , is it
11:42:07 <davis> whats wrong with Schrottplatz though
11:47:19 <lugo> ok 'Schrottplatz' sounds less awkward than Schrott-Recycling-Hof which i think would be technically correct
11:47:39 <lugo> so it's good word indeed :D
11:48:16 <frosch123> if (year < 1995) return "Schrottplatz"; else return "Recyclinghof";
11:48:35 <planetmaker> feature request!°
11:49:22 <frosch123> just like if (year < 1995) return "Mülldeponie"; else return "Wertstoff-Sammelplatz";
11:50:00 <planetmaker> that's the same industry :-P
11:50:28 <frosch123> hmm, isn't it also in the other case?
11:51:39 <planetmaker> yes... I think the waste collection point was removed. I might err, though
11:52:12 <planetmaker> that's why I assumed you meant the junk yard
11:57:55 <davis> if (year > 1999) return "Putzfrau"; else return "Reinigungsfachkraft";
11:59:02 <lugo> Schafbauernhof seems to be a real word too
11:59:22 *** fonsinchen has joined #openttd
11:59:28 <lugo> i mean one which is used fairly often
12:00:16 <planetmaker> then let's use that
12:06:24 <lugo> i think holzverarbeitung and bauxitmine don't need change, since holzverabeitungsbetrieb and bauxitbergwerk are more or less synonymous
12:12:37 <CIA-2> OpenTTD: frosch * r20957 /trunk/src/ (9 files in 2 dirs): -Codechange: Add another parameter to FindGRFConfig() to define search restrictions.
12:13:18 <CIA-2> OpenTTD: frosch * r20958 /trunk/src/ (newgrf_config.cpp newgrf_config.h): -Add: the concept of min-loadable-version to NewGRFs when choosing compatbile NewGRFs. (planetmaker)
12:13:47 <CIA-2> OpenTTD: frosch * r20959 /trunk/src/newgrf_config.h: -Codechange: Realign comments.
12:15:07 <CIA-2> OpenTTD: frosch * r20960 /trunk/src/ (lang/english.txt newgrf.cpp newgrf_config.cpp newgrf_gui.cpp):
12:15:07 <CIA-2> OpenTTD: -Add: Allow setting 'minimal compatible version' via Action14. (planetmaker)
12:15:07 <CIA-2> OpenTTD: Note: Setting 'VRSN' also sets 'MINV' resulting in the Grf being only compatible to the same version. Set 'MINV' after 'VRSN' if your Grf is compatible to older versions.
12:15:46 <xiong> Is there any reason not to use 3x3 grid for "Road layout for new towns"?
12:16:09 <planetmaker> ^ andythenorth_ your newgrfs need an update ;-)
12:16:33 <xiong> frosch123, Classical or romantic ugly?
12:17:20 <frosch123> anyway, i do not like towns :p
12:17:21 <planetmaker> oh, andythenorth_ no need to change the grfID anymore ;-)
12:17:44 <planetmaker> so you can undo your last HEQS grfid change :-P
12:17:49 <frosch123> planetmaker: wanna crash old versions of ottd? :p
12:17:51 <xiong> Okay, well, then, perhaps I'd better try again. Is there any technical reason why 3x3 grid streets are a poor choice?
12:17:59 <planetmaker> frosch123: yes :-P
12:18:03 <planetmaker> then people do update ;-)
12:18:33 <planetmaker> (or don't play at all anymore :S )
12:18:55 <xiong> I imagine that early towns will not fill the center square, but that later, bigger buildings will fill them in.
12:19:12 <frosch123> "technical"? you mean workes need shorter schooling when they only have to build straight roads?
12:19:15 <planetmaker> there's one easy way to find out
12:20:29 <Rubidium> grids give me an American feeling and I don't fancy the USA that much anymore
12:21:06 <xiong> planetmaker, I have a certain way of looking at things, which may seem strange. It probably comes from a career as a hardware engineer. I got into the habit early on of trying to know what may happen before I actually do anything. Certainly, I experiment; but I ask for good advice on major issues.
12:22:41 <xiong> Rubidium, I understand that there may be all sorts of romantic objections (in the ZAAMM sense) to 3x3 grid. I'm asking about technical, classical objections of the form "towns won't grow properly" or that other bad, functional things happen.
12:23:25 <planetmaker> it's a feature. You can use it or skip it. It just changes how it looks like
12:23:34 <xiong> I'm pretty sure, on the face of it, that 2x2 grid towns will function properly. I'm also fairly certain that buildings want to build only adjacent to roads. I'm only guessing about later developments.
12:24:16 <xiong> Boy, I really do seem to have a hard time expressing myself clearly today.
12:24:40 <Rubidium> with 3x3 you can have less 2x2 buildings
12:25:06 *** Biolunar has joined #openttd
12:25:23 <xiong> Functionally, 3x3 grids *might* be more efficient, since less of town area is consumed by roads. 3x3 should be more dense.
12:25:42 <xiong> It's not value-neutral.
12:26:34 <xiong> Rubidium, Thank you; that is a pertinent statement.
12:39:53 *** Alberth has joined #openttd
12:53:04 <andythenorth_> with 3x3 does the middle tile get filled?
12:53:09 <andythenorth_> it's not near a road...
12:53:20 <andythenorth_> near / adjoining /s
12:53:41 <andythenorth_> planetmaker: why don't I need to change grfid :o
12:54:42 <DorpsGek> planetmaker: Commit by frosch :: r20958 /trunk/src (newgrf_config.cpp newgrf_config.h) (2010-10-17 12:12:52 UTC)
12:54:43 <DorpsGek> planetmaker: -Add: the concept of min-loadable-version to NewGRFs when choosing compatbile NewGRFs. (planetmaker)
12:55:10 <DorpsGek> planetmaker: Commit by frosch :: r20960 /trunk/src (4 files in 2 dirs) (2010-10-17 12:14:49 UTC)
12:55:11 <DorpsGek> planetmaker: -Add: Allow setting 'minimal compatible version' via Action14. (planetmaker)
12:55:12 <DorpsGek> planetmaker: Note: Setting 'VRSN' also sets 'MINV' resulting in the Grf being only compatible to the same version. Set 'MINV' after 'VRSN' if your Grf is compatible to older versions.
12:56:09 <planetmaker> for the sake of current stable versions it might still be a good idea, though
12:57:24 <andythenorth_> I should add that to HEQS / FISH / FIRS?
12:57:44 <Alberth> andythenorth_: if you have larger buildings than 1x1, the middle tile can be used.
12:57:59 <planetmaker> andythenorth_: yes, you should
12:58:13 <andythenorth_> planetmaker: I should add it to HEQS before I release 0.8.0?
12:58:15 <planetmaker> it should be the version which can (still) be loaded
12:58:30 <planetmaker> and always be changed when it's not compatible anymore
12:58:50 <planetmaker> also between releases. As the version is changed with every commit
12:59:01 <planetmaker> it's the repository version
12:59:23 <andythenorth_> what do I need to do?
12:59:55 <planetmaker> add a new action14 line with MINV and the minimum revision which is compatible to the current one
13:00:13 <planetmaker> (which could be the one now, if you don't care to look :-) )
13:00:46 <planetmaker> it subsequently only needs changing when you do incompatible stuff
13:00:54 <frosch123> but make sure to set MINV after VRSN
13:00:57 <andythenorth_> I have to learn to remember to do this
13:01:08 <andythenorth_> shipping this broken would be unhelpful :P
13:01:26 <planetmaker> yes, it needs to be remembered to be used
13:01:33 <planetmaker> But there's no way to do it automatically
13:01:57 * andythenorth_ has just eaten too much to figure this out right now :)
13:02:08 <andythenorth_> I want to ship HEQS 0.8.0 today
13:02:12 <andythenorth_> maybe I figure it out later
13:02:12 <frosch123> i failed to put it in short sentences :)
13:02:19 <andythenorth_> or maybe planetmaker adds it for me :D
13:02:40 <planetmaker> frosch123: that's probably as short as it gets :-)
13:03:03 <frosch123> "When loading a game which used an older version of your GRF which is no longer installed, the newest installed version of your GRF will be picked which is still compatible to the version used before." <- might be too long :)
13:03:19 <planetmaker> andythenorth_: just add the current revisions ;-)
13:03:28 <planetmaker> I don't know when you broke compatibility
13:03:30 <andythenorth_> I don't have action 14 in HEQS yet
13:09:46 <andythenorth_> planetmaker: I broke compatibility at r407
13:11:18 <planetmaker> then 407 is what you put there
13:14:00 <andythenorth_> what action 14 stuff do I need to add :P
13:14:58 <planetmaker> version and minversion: VRSN, MINV
13:15:29 <planetmaker> hm, yes, you should
13:15:54 <planetmaker> and parameters, if there are
13:16:14 <andythenorth_> fatal renum error :P
13:16:14 <CIA-2> OpenTTD: frosch * r20961 /trunk/src/tunnelbridge_cmd.cpp: -Cleanup: Remove redundant/duplicate invisibility test. (uni657)
13:18:04 <andythenorth_> planetmaker: I need to change the nfo version ;)
13:18:44 <andythenorth_> no idea if it works :P
13:19:26 <planetmaker> you'll see that when you use r20960 or later ;-)
13:20:41 * andythenorth_ thinks to release HEQS 0.8.0
13:21:36 *** Devroush has joined #openttd
13:21:50 <Rubidium> better let someone test it first, i.e. let the nightly run and wait a bit :)
13:22:18 <planetmaker> might be good :-)
13:22:55 <planetmaker> doesn't stop you preparing everything but the last tag, though, andythenorth_ ;-)
13:26:17 <andythenorth_> planetmaker: will you be sad if I post a grf in the forums :o
13:26:43 <planetmaker> I don't mind. The question is: why?
13:26:55 <andythenorth_> when does the nightly build run?
13:26:58 <planetmaker> IMHO you hurt yourself
13:27:15 <planetmaker> and there's always time till the next nightly, we're not in a racing competition
13:27:37 <andythenorth_> it's only a few hours :)
13:27:53 <planetmaker> as long as few >24, it's always a few
13:28:02 <planetmaker> that's the whole point of nightlies...
13:30:18 <planetmaker> the argument against posting is exactly this: a) you might add something else (which then will go untested) and worse: b) you'll continue to work on it - and if people use the nightly (or have a link) - they'll use your (nearly) newest. And not what you _now_ posted
13:30:37 <planetmaker> but... whatever suits you best :-)
13:31:52 *** Chillosophy has joined #openttd
13:35:05 <andythenorth_> can I tag a release candidate, or is that overkill for a grf?
13:35:19 <Eddi|zuHause> anybody experience with steam? is it normal that simple connection takes ages?
13:36:06 <planetmaker> depends, andythenorth_
13:36:17 <planetmaker> but as long as you don't use branches it's overkill
13:37:17 <andythenorth_> I guess I have to remember to release sometime next week :)
13:37:19 <planetmaker> I pondered long about that for OpenGFX
13:37:29 <planetmaker> no point. I can just release a.b.(c+1)
13:41:44 <andythenorth_> yeah, but batteries don't affect town growth :P
13:42:11 <planetmaker> andythenorth_: just a matter of newgrfs...
13:42:31 <andythenorth_> just a matter of TownControl
13:42:51 <planetmaker> introduce batteries in tropic and change the towneffect cargo
13:43:00 <xiong> (1) Best site for FIRS user docs? (2) Suggestions on choosing airplane set?
13:43:15 <Alberth> it never hurts to promote the toyland climate :)
13:43:18 <planetmaker> they could be dug out in a battery pit
13:43:29 <andythenorth_> xion also the FIRS readme...
13:43:50 <Alberth> planetmaker: nah, a 'ligtning catcher' would be more useful
13:44:05 <planetmaker> that sounds awesome, Alberth :-)
13:44:10 <andythenorth_> airplanes: I use AV8 and general AV8ion
13:44:35 <planetmaker> it gives a new idea for the toyland battery farm graphics...
13:45:01 <Alberth> I was thinking that too, better than the current 'farm-ish' approach :)
13:45:16 <planetmaker> I'll ask Zephyris :-)
13:45:26 <andythenorth_> two cargos: 'empty batteries' and 'full batteries' :P
13:45:57 <Alberth> glass tubes with optional sparks flying around in it :)
13:46:05 * andythenorth_ ponders refactoring FISH next
13:46:16 <xiong> Hm. Good link, andythenorth_++
13:46:34 <planetmaker> Default I cannot animate that much
13:46:46 <planetmaker> or not at all. But... in OpenGFX+ Industries :-P
13:46:50 <xiong> The two aviation sets aren't mutually exclusive? Is that general for vehicles?
13:47:14 <andythenorth_> those two are designed by Pikka to work together
13:47:18 <andythenorth_> one is an addon for the other
13:47:30 <andythenorth_> some sets work well with others; some don't
13:48:34 <xiong> I see this huge eGRVTS download but I fear it means all existing vehicles will have to go. I rather like the North American Renewal Set, for perhaps obvious reasons.
13:48:53 <andythenorth_> eGRVTS is road vehicles and trams only
13:49:07 <andythenorth_> you can combine sets with different vehicle types quite freely
13:49:31 <andythenorth_> only trains really have problems, and that only because of decisions by some newgrf authors
13:49:57 <andythenorth_> but not all vehicle sets have cargo support for all industry sets
13:50:03 <xiong> I cannot read the small type very well. 'trains' and 'trams' look almost alike.
13:50:34 <xiong> Right now, I'm at the point in the FIRS readme that tells about what vehicle sets are compatible.
13:50:42 <andythenorth_> try eGRVTS, NARS 2, HEQS, AV8, General AV8ion, and FISH
13:51:32 <andythenorth_> with US Road Set (but turn off the trams in that set), and Canadian Stations
13:51:40 <xiong> Yes, that was the direction I was headed. Thank you very much; it's good to know I'm not insane.
13:51:52 <andythenorth_> also expensive, short and slow bridges is useful
13:51:58 <andythenorth_> it's a grf by Pikka
13:52:30 <xiong> I cannot imagine why it would be good to have bridges cost more or impede traffic. Unless I found myself building them wantonly.
13:52:40 <andythenorth_> more challenging :)
13:53:06 <andythenorth_> other trainsets I like personally are: 2CC set and UKRS 1 or UKRS 2
13:53:22 <andythenorth_> Canadian Set and US Set are good, but don't fully support FIRS / ECS cargos
13:54:17 <CIA-2> OpenTTD: frosch * r20962 /trunk/src/ (gui.h toolbar_gui.cpp viewport_gui.cpp): -Fix [FS#4166](r20956): Determine tile under cursor before opening the new viewport. It might appear just below the cursor.
13:55:06 <xiong> Should I be starting gameplay in 1800 or 1850? By default, OpenTTD starts in 1950, so I thought that was 'correct'.
13:55:28 <xiong> ... but I see vehicles and buildings designed for earlier times.
13:55:40 <frosch123> starting in 1800 is quite hard
13:55:51 <andythenorth_> 1800 sucks a btit
13:56:04 <andythenorth_> I started my last game around 1850
13:56:22 <andythenorth_> and will play until about 2020 before I get bored
13:56:31 * andythenorth_ goes out for a bit
13:56:41 <andythenorth_> sunshine in the UK in October
13:57:05 <xiong> According to readme, NARS 2 supports FIRS. I have checked it out and it looks good for it -- many cars, many possible refits.
13:57:57 <xiong> I am a little concerned that refitting seems to be on a train-by-train basis. This means no hetrogenous trains? Or I have to shuffle cars around in the depot while refitting?
13:58:58 <xiong> I will start over in 1850. I have no problem with early times, in general. Disconcerting to start with diesels on the board already.
13:59:13 <lugo> xiong, yep don't forget sailing ships then ;)
13:59:15 <xiong> Thank you, Eddi|zuHause.
13:59:31 <xiong> I will just start over.
14:04:04 <xiong> Hm. As experiment, I enabled all these enhancements while running a game. It did not crash. But, strangely, even though it is 1950, horse-drawn carriages and freight vans are available.
14:10:43 <xiong> Realistic, perhaps. Inconvenient, though. I have not been able to find any way of removing vehicles from the 'available' list.
14:11:07 <V453000> "vehicles never expire" ?
14:11:10 <planetmaker> they'll be removed when they're not available anymore
14:11:15 <xiong> It doesn't help that the oldest ones are at the top -- when generally, one wants to build the newest or so.
14:11:21 <planetmaker> which will never happen with 'vehicles never expire'
14:11:31 <planetmaker> xiong: you can sort it
14:11:33 <V453000> although that is quite a gamebreaking and imo tarded option to have off :)
14:12:03 <V453000> and as pm says :) you can sort them by introduction date, or anything you like, either way A-Z or Z-A
14:12:27 <planetmaker> you can also filter by cargo
14:12:27 <xiong> I had turned 'vehicles never expire' on, after reading some page that suggested it. I was concerned about getting a good-running city up and having all my vehicles expire in 2050.
14:12:50 <planetmaker> that could happen, though not with newgrf.
14:13:10 <planetmaker> Still, as passage of time is somewhat arbitrary I don't like it. But that's my personal opinion.
14:13:22 <V453000> btw 2050 is the same date as any other :) you still play :) (provided you still didnt get bored :) )
14:13:38 <V453000> ... and provided you have vehicles never expiring :D
14:14:26 <xiong> Well. If I start in 1850, I think that eliminates that issue. I suppose I can always switch 'vehicles never expire' on again in, say, 2020.
14:14:58 <V453000> dont forget to "reset_engines" or what is that command, to get even the old vehicles back
14:15:09 <xiong> I see that FIRS freight trains require a caboose. Does that hold right up to game end? Or at some point is an EOT device assumed?
14:15:20 <V453000> firs is industries nto trains
14:15:32 <V453000> and you can remove these later
14:16:15 <xiong> Mind you, I have never liked EOT and I'm a rabid caboose supporter. But I had to ask.
14:17:05 <xiong> I *highly* approve of NARS, all over. It has flatcars and I'm very much a flatcar man. I consider that a flatcar is a real test of a modeler's ability -- if he is brave enough not to put a load on it.
14:17:45 <xiong> A poorly-done flat, with no load, is obviously a toy. Any flat with a cute load on it is... the easy way out. I never models loaded flats.
14:19:06 <V453000> imo NARS looks nice, but works terribly, it just has a shitload of engines of all the same kind, not much variety :/
14:19:14 <xiong> Similar level of difficulty with a fairly new train of tank cars. Tanks are often in captive service, they rarely mix with other cars (due to safety issues), and so are often found all together, all the same.
14:19:38 * planetmaker wonders whether NARS has a switch to disable the speciality of the caboose
14:20:19 <V453000> pm: not with parameters
14:20:24 <xiong> The challenge is to keep, oh, 12 tanks realistically the same, yet different enough to be individual cars. You have to admit a slight ding in a railing here, a very small streak of rust there. If the tanks are new, you can't justify much of that.
14:20:36 <planetmaker> V453000: I feared as much
14:20:40 <V453000> it has some interesting parameter settings but not sadly no cabooses :|
14:21:06 <planetmaker> maybe you can propose that to Pikka? :-)
14:21:17 <V453000> for example parameter which allows for compatibility to be mixed with some other train sets in one game is quite interesting
14:21:26 <xiong> An extremely interesting article in one of the rail mags I read awhile back talked about some strange caboose-flats. They had been built in all sorts of nonstandard ways to serve as work vehicles.
14:21:29 <planetmaker> Then it's not always me who argues "I want simple settings" ;-)
14:22:12 <planetmaker> personally I'd skip the parameter for allowing to be used with other trainsets and just allow it. But well
14:22:29 <planetmaker> it works, so it's fine
14:22:37 <xiong> One especially weird car had been built onto a 40-foot flat, with a caboose-like bunk/office structure at one end and a small crane at the other.
14:23:37 <xiong> I wonder if there's an OpenTTD use for unusual cars, like depressed flats.
14:25:04 <Rubidium> OpenTTD couldn't care less on how the cars/wagon/plane/ships look
14:25:23 <xiong> Then there are the log cars that aren't really cars so much as loose trucks with some sort of bracketing. You strap about 3 big logs together at each end.
14:25:30 <Rubidium> it's totally obnoxiously unaware of the aesthetics of anything
14:25:52 <xiong> Obviously, you can't rail the empties back; you load them on a flat.
14:26:39 <xiong> Well, for something like a depressed flat you need special loads, like generators and transformers.
14:27:09 <xiong> A crane car goes in a work train and heads out to derailments.
14:27:20 <planetmaker> hm, how do I remove an alias from the environment variables?
14:28:11 <planetmaker> indeed. Thank you
14:28:30 <Rubidium> oh, it actually exists?
14:28:34 <xiong> Can company livery schemes be saved? I seem always to start with everything blue.
15:01:03 *** Eddi|zuHause has joined #openttd
15:13:28 <ccfreak2k> Last I checked, it's random, but both base and stripe are the same.
15:18:13 *** fonsinchen has joined #openttd
15:23:03 *** b_jonas has joined #openttd
15:23:33 <b_jonas> oil rigs have two extra squares that just look like water but are actually part of the oil rig and can't be raised?
15:25:37 *** Brianetta has joined #openttd
15:32:28 <Eddi|zuHause> afair oil rigs are 2x3
15:32:40 <b_jonas> is that so even in ttd?
15:32:55 <b_jonas> they're 2x3 in this game
15:33:04 <b_jonas> hmm, let me check that
15:33:06 <Eddi|zuHause> oil rigs haven't changed since TTO
15:34:16 <b_jonas> yes, you're right, they're 2x3 in ttd too
15:34:24 <b_jonas> they have those two invisible squares
15:34:40 <b_jonas> wow... how could I ever play on such a small screen?
15:37:38 <b_jonas> I'm used to ottd now apparently
15:38:15 *** andythenorth_ has joined #openttd
15:44:52 <Eddi|zuHause> hm, apparently they used debian's random number generator in the israelian lottery :p
15:45:49 <b_jonas> they used a rng that's not intended to be cryptographically secure?
15:46:30 <b_jonas> or one that was intended to be secure but isn't?
15:47:09 <Eddi|zuHause> they drew the same numbers as last month
15:48:54 <b_jonas> nah, that's not notable
15:52:19 <TrueBrain> so betting on the numbers of last month does result in win ... kewl
15:52:37 <TrueBrain> what are the odds of that happening again!
15:52:50 <TrueBrain> (hint: identical to any other combination of numbers)
16:04:42 <andythenorth_> Terkhen / anyone - is there already a wiki page for reworking consists/groups/shared orders/refits ?
16:08:16 *** kenneth has joined #openttd
16:08:37 <Hirundo> Do all grfs get reloaded when the game mode (menu, game, editor) changes?
16:08:43 <kenneth> Im new to running my own dedicated servers guys
16:08:46 <kenneth> and was looking into patching
16:08:53 <kenneth> but am running into all sorts of issues with revisions
16:08:58 <Terkhen> andythenorth_: not that I know of
16:09:06 <Zuu> Do you know how to compile a clean trunk/stable?
16:09:14 <kenneth> is there an area where patches are avaliable for the stable version
16:09:26 <kenneth> i can compile, i just cant find the patches i would like for the stable version
16:09:33 <kenneth> or is there its a case of get yours hands dirty
16:09:40 <Rubidium> patches + stable version -> not so stable version (in 99% of the times)
16:10:00 <Rubidium> not so stable as in incompatible, i.e. desync generating
16:10:03 <kenneth> what I mean is, if i compile a trunk, can clients with the stable version still connect
16:10:20 <kenneth> will a vanilla client with stable release connect and talk to a patched trunk server
16:10:25 <Zuu> There is no website or page that contains patches that target the source code of the stable versions.
16:10:49 <Yexo> but a vanilla client won't talk to a patched stable server either
16:10:57 <Yexo> at least for 99% of the patches
16:11:11 <kenneth> so when I connect to other peoples servers and it tells me I cant play until i set a password etc and it actually locks the controls and i have connected from stable client
16:11:15 <kenneth> how has this been acheived ?
16:11:46 <Zuu> Most patches are against the current development version. Patches are a way of publishing on going work on new features/fixes etc for OpenTTD. The final goal for patches is often to reach the trunk.
16:11:55 <Yexo> most likely that is done by making you a spectator
16:12:08 <Yexo> as spectator all controls are indeed locked
16:12:16 <Rubidium> but if you're a spectator you can't change the password of your company
16:12:23 <Yexo> the server does have a patch in that case
16:12:49 <Rubidium> but it can't tell your client to lock you out. It just messes with the commands you send the server
16:12:58 <Yexo> kenneth: do you have an example server where the controls are locked when you join?
16:13:07 <Zuu> If you know what you are doing it is possible to run a modified "stable" server that works with vanilia clients. However, the key is that you know what you are doing.
16:13:44 <kenneth> all of the luukland servers
16:13:50 * andythenorth_ wonders how to add a page to wiki
16:14:05 <Zuu> Maybe they do it so you have to send the password to the server via chat.
16:14:06 <kenneth> and they have a game called city builder
16:14:26 <Zuu> The server then set the password on your company and move you onto the company.
16:15:06 <kenneth> i just joined the server, created my own company, havent set a password or anything
16:15:31 <kenneth> when i click to build a road, it doesnt do anything, the toolbar isnt greyed out, i just get a chat message from the server says Company locked until password ....
16:15:34 <Zuu> andythenorth_: Type the URL for it (as you want to have it), and it will show up as missing with an option to add it.
16:16:17 <Zuu> When you search for pages that don't exist it also may give you the option to add it.
16:16:56 <andythenorth_> I guess we need to add stuff there
16:25:22 <b_jonas> this is like the tenth news I'm getting about the same blue transport company being in trouble
16:33:28 *** theholyduck has joined #openttd
16:35:09 <Terkhen> andythenorth_: I'd start with what we want it to achieve
16:35:25 <Terkhen> easier autoreplace? more powerful group management?
16:39:48 *** Devroush has joined #openttd
16:42:58 <xiong> Hm. I have an 1850 town with a pop over 2K yet it accepts no mail. My station coverage includes nearly every building. Is this natural? Should I run mail wagons anyway?
16:49:01 <kenneth> does anyone know much about autopilot
16:49:04 *** Prof_Frink has joined #openttd
16:50:33 *** Alberth1 has joined #openttd
16:50:33 *** Alberth is now known as Guest3085
16:50:33 *** Alberth1 is now known as Alberth
16:54:02 <Yexo> kenneth: yes, someone does
16:54:14 <Yexo> see also the second-last part of the channel topic
16:54:22 <Eddi|zuHause> <Hirundo> Do all grfs get reloaded when the game mode (menu, game, editor) changes? <- i believe the answer is "yes"
16:56:27 <andythenorth_> Terkhen: so what are the goals?
16:56:57 <andythenorth_> I haven't seen the forum thread(s?) about this topic :)
16:57:10 <andythenorth_> I looked, but couldn't find any
16:58:00 <Terkhen> andythenorth_: I don't know, I have never used groups
16:58:10 <andythenorth_> the blind leading the blind :)
16:58:15 <Terkhen> mostly because I have to create them manually
16:58:38 <Hirundo> "The definition of variable 1B is slightly feature-dependent. For features that can be drawn transparently (stations, bridges, houses, industry tiles and objects) bit 4 is set if the current feature will be drawn normally, and clear if the current feature will be drawn transparently." <- does this work in openttd?
16:58:38 <Terkhen> so, for me I'd say... groups automatically created for vehicles sharing orders
16:59:25 <Hirundo> I'd define it the other way around, shared orders are accomplished by moving a vehicle into a group and defining orders for that group
17:00:04 <Alberth> I'd do 'the same orders', whether shared or not
17:00:37 <Alberth> but I think a users should be able to group in pretty much any way he/she likes
17:01:54 <Alberth> what to do group-based is more difficult, I found summed profits, use of capacity, round-trip times perhaps, auto-renew/replace
17:01:59 <b_jonas> if groups are "labels", that is, a vehicle can be in multiple labels at once, than those are not exclusice
17:02:21 <Terkhen> vehicles grouped by a certain condition (shared orders, consist used, vehicle colours), groups that include groups...
17:02:26 <xiong> Terkhen, I'm with you. I'd like as many details to be handled by default as possible. Given a vehicle with orders, I would like to select it, create a group that includes only it (named, by default, via a sensible derivative of its order list and cargo type) and thereafter, be able to add more vehicles with the same shared orders from the group list, without reference to where any of the vehicles in the group may be.
17:03:14 <Hirundo> I'm completely with Brianetta, actually
17:03:23 <b_jonas> (and I'd like an easier way to add a vehicle to a group. dragging a large vehicle-shaped icon to a narrow bar in a list is not so good.)
17:03:26 <Yexo> Hirundo: no, bit 4 of var 1B is never set by openttd
17:03:31 <xiong> I realize that there are other reasons to group. Last game, I put all 'local service' road vehicles into one group to get them out of the way.
17:03:33 <Alberth> the goal is I think sort of what you can do with a single vehicle, but to make it scaling to more vehicles
17:03:36 <Yexo> at least I couldn't find any code that sets it
17:05:23 <Alberth> Hirundo: it focusses too much on orders I think, eg order by type of cargo would be valid too
17:05:48 <V453000> yeey, group liveries could be nice :)
17:06:22 <Hirundo> That's up to the user
17:06:30 <xiong> There is an option under 'Manage list' to 'Add shared vehicles', which is the right direction; but it's kinda obscure.
17:06:33 <Terkhen> maybe you should be able to easily define groups with vehicles sharing a set of properties, for example, "vehicles sharing a certain set of orders"
17:06:36 <planetmaker> I'd use groups to a) assign individual liveries b) assign individual replacement rules c) assign individual orders
17:06:59 <Rubidium> Alberth: to what extent can we "hide" groups? You could say that every OrderList is a group, and that some groups are not necessarily shown in the group list
17:07:04 <xiong> The thing is, grouping implies hierarchy and the whole idea of rigid hierarchies has pretty much been exploded.
17:07:14 <andythenorth_> to me 'shared orders' is already a form of group
17:07:20 <andythenorth_> do we have to expose 'groups' to players
17:07:26 <Hirundo> In my case, I'd define one group to hold all my wood trains and a subgroup for each set of orders. Proper per-group replacement and statistics would be very nice
17:07:38 <andythenorth_> or do we expose other ways to manipulate groups in useful and interestingways?
17:07:55 <andythenorth_> are groups tags?
17:07:59 <Eddi|zuHause> # there's a cat in the bucket
17:08:05 <xiong> Usta be, I would reach for nested groups. But what's really wanted is vehicle tagging, so I can easily construct a group based on any number of things, with some tags being inherent in the vehicle or its orders.
17:08:19 <Alberth> Rubidium: perhaps we can hide groups, I was more thinking in terms of unfolding, like in the adv settings menu
17:08:40 <Eddi|zuHause> Brianetta: i'm sure we're discussing an old suggestion by you
17:08:43 <Alberth> andythenorth_: being able to put a vehicle in more than one group seems nice
17:09:10 <andythenorth_> how does this relate to consists?
17:09:20 <andythenorth_> I think consists have nothing to do with groups in relational terms
17:09:37 <xiong> I've confronted the same issue with my file system. At first, nested folders (directories if you enjoy typing) seem to be rational. But there are too many items that "belong" to more than one group, so I've started to itch for tagged files.
17:09:58 <andythenorth_> groups are associations between/across vehicles
17:10:09 <andythenorth_> based on data / metadata?
17:10:44 <Eddi|zuHause> andythenorth_: a "group" in this context would be an internal method to assign several vehicles to one general property
17:11:06 <andythenorth_> and what affordances does a group provide to the player?
17:11:07 <Alberth> we really need a glossary at the wiki :s
17:11:12 <xiong> Nested folders are fine in most cases but the very existence of symlinks shows they have a limitation. When I create a Perl module's test suite, I quickly find I have dozens of test scripts, each of which naturally "belongs" in several overlapping groups. I wish to tag these files, not sort them.
17:11:43 <andythenorth_> 'started' being a literal comment :P
17:11:52 <andythenorth_> "groups allow players to..."
17:12:06 <andythenorth_> - replace vehicles
17:12:09 <Brianetta> yes, I stand by my suggestion
17:12:11 <andythenorth_> send for servicing
17:12:22 <xiong> Then, I'd be able to perform actions on tagsets: run these, remove (some other tag) from these, copy these to here...
17:12:23 <Rubidium> so only new thing is liveries
17:12:39 <Eddi|zuHause> this property can be a shared order list (all vehicles with a shared order), an order entry (all vehicles going to station x), a shared consist, a shared livery/company colur, a logical player-assigned grouping, or something completely different
17:12:43 <andythenorth_> I can't see how groups would replace shared orders...
17:12:59 <Brianetta> The groups in my suggestions would be like lines, or services
17:13:06 <Rubidium> andythenorth_: shared orders are an implicit grouping of vehicles
17:13:10 <xiong> Tags can embrace both groups and shared orders.
17:13:19 <Brianetta> You define a service by livery and orders, then add vehicles to it
17:13:46 <Alberth> andythenorth_: shared orders allow easy group-wise changing of orders
17:13:48 <andythenorth_> Brianetta: perfectly reasonable, but there are probably other uses for groups
17:13:49 <Brianetta> Rubidium: Shared orders suck as a concept. Helen *never* understood it, and I'm a patient teacher.
17:13:56 <xiong> Oh wow, I'm so screwed. I should have been asleep hours ago. Trains not to blame entirely for this. See you.
17:14:22 <andythenorth_> for example, I use groups to handle auto-replace of certain vehicles
17:14:51 <andythenorth_> if current shared-orders window allowed auto-replace....I wouldn't use groups much
17:14:53 <Eddi|zuHause> autoreplace would be a sub-feature of consists, imho
17:14:54 <Alberth> andythenorth_: I was thinking to merge replace & renew, I don't see much difference
17:15:26 <Alberth> andythenorth_: I think it is the other way around, if you have groups, you don't need shared orders
17:15:34 <Rubidium> Brianetta: they are just lines without making it explicit that they are lines. It's more the human interaction that is broken than the backend.
17:15:45 <andythenorth_> if you have *nested* groups you don't need shared orders
17:15:48 <Brianetta> Rubidium: Exactly what I meant by "concept."
17:15:59 <Brianetta> She couldn't *conceive* it
17:16:00 <andythenorth_> if groups === shared orders, we broke groups :P
17:16:06 <Alberth> andythenorth_: why nested?
17:16:31 <Brianetta> Alberth: If groups offer more than just liveries, then they can inherit undefined options from containers
17:16:39 <andythenorth_> ok, so I have five sets of shared orders for iron ore trains. I want to upgrade wagons on three of them...
17:16:42 <andythenorth_> groups let me do that
17:17:20 *** Brianetta is now known as Brian_changing_seats
17:17:30 *** Brianetta has joined #openttd
17:17:39 *** Brian_changing_seats has quit IRC
17:17:57 <Alberth> Brianetta: I am not sure about the inheritance, I think it would break if I have another hierarchy next to it, eg based on carried cargo, or a 'line' of transfers (boat -> train->plane in an extreme case)
17:18:07 <Rubidium> in any case, the major problem with groups is that nobody actually implemented significant changes (AFAIK)
17:18:17 <Rubidium> where changes ought to be improvements
17:18:30 <andythenorth_> maybe we list what's wrong with current groups?
17:18:42 <andythenorth_> - dragging is annoying
17:19:03 <andythenorth_> the implementation is not great
17:19:04 <Eddi|zuHause> no possibility of selecting multiple vehicles and then dragging all of them
17:20:08 <Alberth> better have 'automagic' selection based on some criterium, I think. Manually doing things is too much work :p
17:20:23 <andythenorth_> I want to drag from the list of vehicles using a station...which makes me think - are vehicles using a station implicitly a group?
17:20:57 <Eddi|zuHause> andythenorth_: not really, which is why groups internally need to become more flexible
17:21:27 <Brianetta> One problem with shared orders as they stand, is that they vanish when there are no trains associated with them.
17:21:33 <Eddi|zuHause> andythenorth_: imho it should be. then you could also set autoreplace etc. for station or order groups
17:21:45 <Brianetta> There's absolutely no interface for looking at the shared orders that are instantiated.
17:22:25 <Eddi|zuHause> Brianetta: i agree. a remodeled group gui should have that feature
17:22:29 <Alberth> Brianetta: neither for the non-shared orders, how are shared orders different?
17:22:32 <Brianetta> Being able to bring up a list of shared orders, and to assign liveries to those lists, would be incredible.
17:22:52 <Brianetta> Alberth: They're different in that you're actually expected to USE them.
17:23:16 <Brianetta> Non-shared orders are simplicity itself - they're oly associated with one vehicle, and finding them is child's play.
17:23:53 <Brianetta> When you have a vehicle, and a set of shared orders with which you want to join it, you have to find (by trial and error) a vehicle already using those orders.
17:24:08 <Brianetta> If there are no vehicles still using those orders, you must make the orders again from scratch.
17:24:37 <Alberth> I always just pick a random train that does the orders already and share with it
17:24:37 <Brianetta> This leads to ludicrous work-arounds, like a depot full of locomotives used exclusively for orders management.
17:24:46 <Brianetta> Exactly - trial and error.
17:25:02 <Brianetta> It's easy if you know exactly which trains share orders, but sometimes they're not easy to find.
17:25:10 <Brianetta> You can group them, but you must do that manually, too.
17:25:32 <dihedral> nice to see you so ... chatty :-D
17:25:38 <Alberth> no, I mean random, as in pick a train that has the orders, being shared or not.
17:25:41 <Brianetta> Living with this broken interface is fine if you've grown used to it over the past fifteen years
17:26:02 <Brianetta> If you have two duplicate sets of shared orders, you're in for a fun time
17:26:23 <Brianetta> If your last two trains with those orders crash into each other, you'd better share those orders quickly.
17:26:39 <Alberth> that's why you should have groups with *the same* orders, whether shared or not :)
17:26:58 <Brianetta> Orders should be a property of the group
17:27:13 <Brianetta> Moving a vehicle from one group to another should change its orders
17:27:50 <Brianetta> I suggested hierarchical groups, simply so that each train could be in an implicit gruop of its own
17:27:51 <Alberth> but that makes no sense in general, as the cargo being moved changes then
17:27:55 <Brianetta> for "legacy support"
17:28:09 <Brianetta> Alberth: You don't move trains between groups on a whim
17:28:15 <Brianetta> you refit them, or change consists
17:28:36 <Brianetta> I'd be fine if this could only happen in a depot, although some might see that as an artificial restriction
17:29:01 <Alberth> would you ever have 2 sub-groups with the same trains & same orders?
17:29:31 <planetmaker> red line and yellow line.
17:29:34 <planetmaker> Different start times
17:29:43 <planetmaker> but that might count as different orders
17:29:45 <Brianetta> Not with the same train
17:30:00 <Eddi|zuHause> if you move a train from one group to another, and that other group has another consist, it is scheduled for autoreplace on the next depot visit
17:30:27 <Brianetta> Eddi: I'd never considered associating a consist with a group. If it was, then yes, for sure.
17:30:27 <Eddi|zuHause> if the player insists on this being instantaneous, he can send the trian to servicing immediately from the group gui
17:30:55 <Brianetta> Theoretically, liveries should only change in a depot, too (:
17:31:04 <Eddi|zuHause> like i said previously, shared orders and shared consists are really not that different concepts
17:31:14 <Brianetta> Just like real life, busy trains might not get their new colours for years
17:31:29 <CIA-2> OpenTTD: rubidium * r20963 /trunk/ (13 files in 6 dirs): -Add: stubs for a remote administration connection
17:31:30 <Brianetta> Eddi: I'm fine with that; it's a sound idea
17:32:05 <Brianetta> Orders, consists and liveries, as properties of a group, which would override the vehicle's own properties
17:32:20 <Brianetta> and which could be managed from an explicit list box
17:32:36 <Brianetta> I'd be totally happy with that
17:33:00 <Eddi|zuHause> biggest problem with that is probably designing a sensible gui
17:33:09 <Alberth> Brianetta: probably not, but it is as far as we can think without having an implementation :)
17:33:11 <Brianetta> Hierarchical groups gives more fun things, like a coal livery containing loads of coal services
17:33:12 <Eddi|zuHause> but the other parts are probably not trivial either
17:33:46 <Alberth> Eddi|zuHause: GUI design is where I am very stuck :(
17:34:02 <CIA-2> OpenTTD: rubidium * r20964 /trunk/src/network/ (network_admin.cpp network_admin.h): -Add: disconnecting remote admins that fail to authenticate
17:35:00 <dihedral> how many pieces have you turned this into??
17:35:11 <CIA-2> OpenTTD: rubidium * r20965 /trunk/src/settings_type.h: -Fix: typo in comment
17:35:25 <planetmaker> dihedral: many :-)
17:35:25 <andythenorth_> why would orders === consist?
17:35:34 <Alberth> dihedral: one semantical change == one commit
17:35:54 <CIA-2> OpenTTD: rubidium * r20966 /trunk/src/ (5 files in 3 dirs): -Change: enable remote administration sockets (parts by Yexo and dihedral)
17:36:09 <Alberth> andythenorth_: I am not convinced that is a good limitation yet
17:36:11 <Brianetta> andythenorth_: Orders require that a vehicle can carry the goods in question
17:36:17 <b_jonas> what I'd like is a "sell" order where you can send a vehicle to depot and it will sell itself when it arrives
17:36:31 <andythenorth_> orders *may* require that a vehicle can carry the goods in question
17:36:35 <CIA-2> OpenTTD: rubidium * r20967 /trunk/src/ (7 files in 3 dirs): -Add: infrastructure to send information to remote admins at specific intervals (dihedral)
17:36:39 <Brianetta> Hierarchical groups would allow a group with orders to contain a couple of different consists (-:
17:36:42 <Eddi|zuHause> andythenorth_: both orders and consists are virtual objects, which then make trains obey to them
17:36:46 <planetmaker> Brianetta: orders only include a station. Not a cargo
17:36:52 <andythenorth_> orders include stations
17:36:58 <andythenorth_> consists have to be different
17:37:11 <CIA-2> OpenTTD: rubidium * r20968 /trunk/src/network/ (4 files in 2 dirs): -Add: date notification of remote admins (dihedral)
17:37:15 <andythenorth_> are vehicles passing through a bouy or waypoint implicitly a group?
17:37:33 <andythenorth_> are 'all vehicles which can carry more than 96t of iron ore' implicitly a group?
17:37:35 <Eddi|zuHause> andythenorth_: they should be
17:37:38 <CIA-2> OpenTTD: rubidium * r20969 /trunk/src/network/ (5 files in 2 dirs): -Add: client info change notification to remote admins (dihedral)
17:37:45 <andythenorth_> are 'all vehicles with reliability < 75%' implicitly a group?
17:37:58 <CIA-2> OpenTTD: rubidium * r20970 /trunk/src/ (8 files in 3 dirs): -Add: company change notification to remote admins (dihedral)
17:38:11 <Eddi|zuHause> yes to all of those, if the implementation would get flexible enough
17:38:16 <Alberth> andythenorth_: I see no reason to limit such conditions, at least conceptually. Perhaps in the implementation
17:38:21 <andythenorth_> so what *isn't* a group
17:38:29 <Hirundo> 'all vehicles built on mondays' ?
17:38:30 <CIA-2> OpenTTD: rubidium * r20971 /trunk/src/network/ (4 files in 2 dirs): -Add: company economy updates at intervals to remote admins (dihedral)
17:38:38 <Alberth> andythenorth_: nothing, a group is what you say is a group
17:38:45 <andythenorth_> I don't think we can define group===shared orders, nor group===consist
17:38:58 <CIA-2> OpenTTD: rubidium * r20972 /trunk/src/network/ (4 files in 2 dirs): -Add: company statistics updates at intervals to remote admins (dihedral)
17:38:58 <Brianetta> andythenorth_: A group is a list of vehicles
17:39:01 <planetmaker> consist is concerning orders a single vehicle
17:39:18 <andythenorth_> so the concepts for 'orders' and 'consist' need to be separate entities
17:39:18 <Brianetta> What we're proposing is that a group can have vehicular attributes, which override those of its members
17:39:42 <andythenorth_> and there need to be ways to manipulate orders and consists
17:39:44 <Eddi|zuHause> a group is a list of vehicles, and it can (but not must) have properties like an order list, a consist or a livery
17:39:48 <Brianetta> You could use them for liveries, orders, consists or any combination thereof
17:40:01 <andythenorth_> you would assign a group to use a set of orders
17:40:09 <andythenorth_> but the set of orders exists independently of the group
17:40:20 <andythenorth_> think of this in two stages
17:40:32 <Brianetta> If (and only if) groups could contain other groups, then properties could *be overridden* be child groups, where devined
17:40:32 <CIA-2> OpenTTD: rubidium * r20973 /trunk/src/ (8 files in 4 dirs): -Add: chat sending and receiving support for remote admins (dihedral)
17:40:33 <andythenorth_> first select objects to group, then manipulate them somehow
17:41:11 <andythenorth_> so the two questions are (a) how to manipulate groups (add/remove members) (b) what affordances there are to manipulate objects in groups
17:41:15 <Brianetta> I'd like the current shared orders pointer scheme to be ditched, of groups could emulate it
17:41:21 <Brianetta> It's hard to understand
17:41:24 <andythenorth_> forget current schemes :)
17:41:26 <Alberth> andythenorth_: I think so, basically, instead of modifying 1 vehicle at a time, modify a group
17:41:27 <Eddi|zuHause> andythenorth_: i'd define it as "two groups may not share the same set of orders". that might make things easier compared to the current shared order implementation
17:41:29 <Brianetta> It's a barrier to new players
17:41:51 <andythenorth_> why couldn't two groups could share the same set of orders?
17:41:53 <dihedral> no need for ap+ again :-D
17:41:58 <Brianetta> Groups wouldn't share orders. They'd just *have* orders.
17:42:05 <CIA-2> OpenTTD: rubidium * r20974 /trunk/src/ (6 files in 3 dirs): -Add: remote console (rcon) for remote admins (dihedral)
17:42:09 <planetmaker> Brianetta: in my words: you want the fundamental reference for orders to be a group, not a vehicle (as now). Right?
17:42:12 <Eddi|zuHause> so two vehicles share the orders if and only if they are both member of this one group that defines the orders
17:42:23 <Brianetta> If you want two groups to have orders shared between them, let groups belong to groups.
17:42:32 <Brianetta> planetmaker: Bang on.
17:42:33 * andythenorth_ thinks orders can't be defined by groups
17:42:47 <Brianetta> planetmaker: With liveries on groups too, for optimum fun
17:42:47 <Eddi|zuHause> andythenorth_: orders are defined by order windows
17:42:49 <andythenorth_> orders should be defined by orders
17:42:55 <andythenorth_> consists should be defined by consists
17:43:04 <andythenorth_> but making such a big change to orders scares me :P
17:43:04 <planetmaker> Brianetta: that's only added benefit. Maybe later
17:43:08 <Eddi|zuHause> the group would get an order window like the vehicles have
17:43:13 <CIA-2> OpenTTD: rubidium * r20975 /trunk/src/ (6 files in 3 dirs): -Add: logging of console output for remote admins (dihedral)
17:43:18 <andythenorth_> scares me as a player, nvm coding it :P
17:43:40 <planetmaker> well. I still like that idea :-)
17:43:41 <andythenorth_> orders == routes?
17:43:51 <andythenorth_> probably orders == orders :P
17:43:53 <Alberth> andythenorth_: I think it is vital to keep a simple 'modify one vehicle at a time' interface too
17:44:12 <andythenorth_> that's just manipulating an 'order' somewhere in the sets of orders
17:44:20 <planetmaker> that makes it complicated, Alberth :-)
17:44:31 <andythenorth_> some of you a much more mathematically smarter than me - this should resolve to a maths problem
17:44:41 <Brianetta> In Simutrans, you make lines, and assign your vehicles to them.
17:44:41 <andythenorth_> it's just sets and entities isn't it?
17:44:45 <Alberth> planetmaker: you cannot expect a child of 10 to understand groups and have fun with the game imho
17:44:48 <Rubidium> Alberth: they would get their *own* group
17:44:55 <Brianetta> Alberth: You can, though
17:44:57 <planetmaker> though not necessarily: the orders could show as top line the group it belongs to.
17:45:16 <planetmaker> Alberth: it was no argument agains that :-)
17:45:28 <Alberth> Brianetta: do you have feeder servives in simutrans?
17:45:34 <CIA-2> OpenTTD: translators * r20976 /trunk/src/lang/ (finnish.txt hungarian.txt slovenian.txt):
17:45:34 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:34 <CIA-2> OpenTTD: finnish - 1 changes by jpx_
17:45:34 <CIA-2> OpenTTD: hungarian - 1 changes by IPG
17:45:34 <CIA-2> OpenTTD: slovenian - 1 changes by ntadej
17:45:51 <Brianetta> Alberth: Simutrans is entirely feeder driven.
17:46:07 <Eddi|zuHause> imho it would "simply" be that you move the current order lists from (front-) vehicles to groups. and remove the special code for shared orders.
17:46:19 <Brianetta> It's had cargo packets since day one, and they've had to go to the place they were sent, not just somewhere like it.
17:46:21 <Rubidium> more to the point, Simutrans enforces cargod*st
17:46:38 <Eddi|zuHause> and all places that would look up the orders of a vehicle, look up the groups that this vehicle belongs to
17:46:58 <andythenorth_> if a vehicle is in two groups that define orders?
17:47:04 <Alberth> Eddi|zuHause: that's mostly implementation stuff, let's keep it out for now?
17:47:20 <planetmaker> Alberth: it basically means that modifying a vehicle orders is either creating a new group or modifying the group orders of that vehicle
17:47:31 <Brianetta> andythenorth_: That's where my idea for hierarchical groups comes into play. You can't give a vehicle more than one group.
17:47:45 <andythenorth_> which is nice for your use case, but very specific :P
17:47:49 <andythenorth_> it breaks my game
17:47:55 <Eddi|zuHause> Brianetta: i don't think that will work out hierarchically
17:47:57 <Brianetta> Any more than you can put a file into more than one directory (ina filesystem without hardlinks)
17:48:00 <b_jonas> and I wish the lorry station tool + remove would also remove bus stations and vice versa
17:48:03 <Eddi|zuHause> then you can't have station groups
17:48:09 <Alberth> Brianetta: how would you replace all engines that eg transfer wood?
17:48:21 <Brianetta> or a Windows Active Directory user into more than one Organisational Unit
17:48:33 <Brianetta> Alberth: The hard way, as ever
17:48:38 <Hirundo> Alberth: Define a group 'wood trains' with subgroups for all 'lines'
17:48:42 <Brianetta> or, a group which contains all wood services
17:48:47 <Alberth> Brianetta: I'd like to have a group for that too
17:48:51 <andythenorth_> Brianetta: a 'dividing' question: do you file your email in hierarchical folders, or use search?
17:48:56 <andythenorth_> most people are strictly one or the other
17:48:59 <Brianetta> andythenorth_: Both.
17:49:11 <Hirundo> andythenorth_: nice analogue
17:49:12 <Brianetta> procmail sorts into folders, and I search only rarely.
17:49:31 <Brianetta> You can always add tags to trains (-:
17:49:44 <Alberth> Brianetta: I think we'd need groups not only for orders but also for other things, and/or we need a vehicle to be in more than one group.
17:49:47 <Brianetta> Then you can have cloud trains
17:49:47 <andythenorth_> I know people who would sooner die than stop filing email hierarchically
17:49:50 <Brianetta> where you own no trains
17:49:56 <andythenorth_> but they still end up using search
17:49:57 <Brianetta> but simply pay to have trains do stuff
17:50:26 <andythenorth_> this is a relational problem not a hierarchical one
17:50:31 <Hirundo> Alberth: how often would you do different things to trains with the same orders?
17:50:32 * andythenorth_ has learnt this the hard way
17:50:36 <andythenorth_> in another place
17:50:43 <Alberth> Brianetta: I see a group more as a tag attached to a train
17:50:46 <Brianetta> andythenorth_: Trains really aren't emails
17:50:49 <b_jonas> andythenorth_: I do both with my emails
17:50:56 <CIA-2> OpenTTD: rubidium * r20977 /trunk/src/ (console.cpp debug.cpp): -Fix (r20975): compilation didn't get to the link stage if you, or config.lib, decided you don't need network support
17:51:11 <b_jonas> but they're different from trains
17:51:16 <Hirundo> It's indeed the fundamental question whether to use a 'tagging' or 'hierarchy' system
17:51:21 <andythenorth_> the problem is effectively the same
17:51:31 <andythenorth_> I've built web apps on a hierarchical structure
17:51:48 <andythenorth_> then I've had proper developers come along and replace it all with correct relational databases :P
17:51:54 <b_jonas> for emails, I use groups because there are some mailing lists I don't want to appear in my inbox, but read them only occasionally in batches
17:51:57 <Alberth> Hirundo: not often, but mostly by accident perhaps, as orders visit stations, they do not say anything about cargo (maybe they should though)
17:52:00 <andythenorth_> groups are a relation between vehicles
17:52:08 <andythenorth_> they aren't a hierarchy
17:52:12 <Brianetta> Alberth: If trains can belong to several groups, then you will ened some disambiguation mechanims where different groups give orders. Such as, only belonging to one group with orders specified. A hierarchy does solve this, but there are other methods.
17:52:26 * andythenorth_ tries to find a way to do more than just assert stuff :P
17:52:27 <CIA-2> OpenTTD: rubidium * r20978 /trunk/src/network/network.cpp: -Fix (r20963): MSVC seems to be complaining more than GCC once again :)
17:52:33 * Alberth agrees with Brianetta
17:52:39 <andythenorth_> Brianetta: you are still thinking groups give orders
17:52:42 <andythenorth_> that would be broken
17:52:49 <andythenorth_> orders are orders
17:52:51 <Hirundo> 'tagging' is more flexible, but opens up the multiple inheritance-worm can
17:52:52 <andythenorth_> groups are not orders
17:53:13 <Eddi|zuHause> the user interface for player-defined groups may be hierarchical, but the implicit groups e.g. for "all vehicles visiting station X" must be relational
17:53:13 <Brianetta> andythenorth_: I don't care what you call them. We need some sort of method for giving and sharing orders that doesn' trely on a stupid memory pointer and guesswork.
17:53:15 <andythenorth_> if orders are all we need, simply remove groups from the current game, and allow assigning colour to current shared orders
17:53:16 <Hirundo> Assigning orders to a group, which then apply to all vehicles therein, is very sensible IMO
17:53:20 <Alberth> Hirundo: perhaps not do inheritance?
17:53:36 <andythenorth_> don't do inheritance
17:53:41 <andythenorth_> any of you ever write css?
17:53:51 <Brianetta> Current shared orders are THE MOST broken concept in the game.
17:53:52 <andythenorth_> cascading inheritance is a necessary evil, but very evil
17:53:54 <b_jonas> but groups are a special case of labels: you can have an option which makes manually adding a train to a group remove it from any other group to which it was added manualy
17:53:57 <Hirundo> Even without inheritance, what is the colour of a train is in both group 'BLUE' and 'RED'?
17:54:07 <Brianetta> It's impossible to explain to newcomers, and I've tried several times.
17:54:30 <Hirundo> andythenorth_: exactly, it causes bloody victims ;)
17:54:45 <Rubidium> Hirundo: easy, both via 2cc
17:54:46 <Brianetta> In fact, orders is the only thing that I want to use groups for.
17:54:48 <planetmaker> [19:53] <Brianetta> Current shared orders are THE MOST broken concept in the game. <-- I don't share that view
17:54:52 <Terkhen> what could replace shared orders?
17:55:01 <Alberth> Hirundo: don't allow such conflicts to happen?, ie you cannot drop that vehicle or you cannot assign a colour
17:55:02 <andythenorth_> Terkhen: 'orders'
17:55:02 <planetmaker> It 'just' needs to be interpreted as a group. And shown as such in the group view
17:55:22 <Brianetta> That, or shared orders lists should exist explicitly
17:55:29 <planetmaker> and it then could also be implemented the other way around
17:55:32 <andythenorth_> ^^ what he just said
17:55:38 *** Eddi|zuHause has joined #openttd
17:55:43 <andythenorth_> shared order lists should exist explicitly
17:55:45 <Brianetta> rather than the current mthod of looking for a train that looks like it's going the way you need, examining its orders, then asking your new train to share its orders.
17:55:59 <andythenorth_> Brianetta: you don't use the station view of vehicles?
17:56:05 <andythenorth_> makes it trivial
17:56:05 <planetmaker> Brianetta: it needs not be an either or. As Alberth explained
17:56:10 <planetmaker> It needs to be a two-way thing
17:56:18 <Brianetta> andythenorth_: Stations can appear in a significant number of orders lists
17:56:26 <Brianetta> especially if you're playing passengers
17:56:27 <andythenorth_> I run into that
17:56:36 <andythenorth_> ships are prone to that
17:56:47 <Brianetta> That's just another method of hunting for a vehicle
17:56:54 <Brianetta> it's trial and error, and that's not clever
17:57:18 <andythenorth_> select into group -> perform operation
17:57:35 <andythenorth_> what if 'change livery' is just instant for a group
17:57:51 <andythenorth_> I need the correct comp sci term
17:58:12 <andythenorth_> it's an object verb operation: I choose my group, then do the operation 'make everything in this group red'
17:58:18 <andythenorth_> think of it as a tool, not a setting
17:58:19 <Eddi|zuHause> changing company colours is instantly currently
17:58:26 <Brianetta> What we need, if not groups, is an incredibly group-like interface to orders.
17:58:40 <andythenorth_> Eddi|zuHause yes, but we're assuming there's a drop down menu somewhere to define livery for a group
17:58:53 <andythenorth_> photoshop doesn't have a drop down menu for groups of pixels, I just flood fill
17:58:57 <Brianetta> It would be instant, in teh first instance
17:58:58 <planetmaker> Brianetta: that's what I mean with it should work two-way
17:59:16 * andythenorth_ thinks of an orders GUI
17:59:19 * andythenorth_ is scared of it
17:59:20 <Brianetta> planetmaker: Sure; as I said, though, there would have to be disambiguation
17:59:23 <andythenorth_> but it's the right thing to do
17:59:30 <planetmaker> orders of a vehicle are in the group. But you can modify the group / or vehicle from the existing orders window of the vehicle
17:59:44 <planetmaker> it'd need a means to select "group" or "this vehicle only".
17:59:50 <planetmaker> The latter'd create a new group
17:59:56 <andythenorth_> planetmaker: I thought the same
17:59:59 <Brianetta> planetmaker: Sure thing; the "end of shared orders" could read "end of group orders"
18:00:00 <andythenorth_> can't think how to make it 'esy'
18:00:30 <Brianetta> but the group window could have an orders button on the bottom right, just like a vehicle window
18:00:35 <Eddi|zuHause> the multiple-inheritance-problem for orders and liveries may be solved like this: when a group order is changed, it does a depth-first search through its vehicles, and sets a pointer in the vehicle "orders are used from this group"
18:01:27 <andythenorth_> Eddi|zuHause: what does that mean? :)
18:01:29 <Eddi|zuHause> assuming groups have some way to decide whether another group is a sub-group or overlapping group
18:01:36 <Brianetta> Or, if we're talking about specific groups for orders alone (aka "lines" or "services") then we could just ban using more than one group per vehicle.
18:01:52 <andythenorth_> turn it upside down, think of it as tools....
18:01:57 <andythenorth_> imagine sets of orders
18:02:00 <Brianetta> Those would exist alongside current groups.
18:02:12 <andythenorth_> now pick a group....assign all vehicles in group to use order set xyz
18:02:23 <Brianetta> andythenorth_: Simutrans gets it right already. You define your orders before you even have a vehicle, if you want.
18:02:24 <andythenorth_> don't think of it as a setting
18:02:34 <andythenorth_> Brianetta: screenshot the gui and post it somewhere
18:02:50 <Brianetta> andythenorth_: I'll have to install simutrans first...
18:02:58 <Brianetta> Simutrans gets *track* wrong (-:
18:03:05 <Eddi|zuHause> Brianetta: i'd like to allow taking any group, and add a livery/order/consist/whatever to that group, regardless of what other groups the vehicles belong to
18:03:13 <andythenorth_> *forget* the current livery gui, and think of photoshop or something, this will all seem easier
18:03:46 <Brianetta> Eddi: Me too, but that's too much culture shock
18:03:49 <Eddi|zuHause> and have the internal logic take care about possible overlaps between two groups that both define orders
18:03:54 <Rubidium> photoshop is easier as there the pixels don't move, so freeform selecting pixels is easier than freeform selecting trains on a map
18:04:35 <andythenorth_> what's the comp sci terms I want? User can perform operations to entities in the group? Entities are mutable?
18:04:57 <andythenorth_> in my model, what happens when I add a new member to the group?
18:05:06 <andythenorth_> I have to repeat my operation :(
18:06:24 <Alberth> if you 'attach' a property to a group, anything you add to the group gets the property
18:06:36 <andythenorth_> but then overlapping is a horrible problem
18:06:55 <andythenorth_> what properties could the group define?
18:07:09 <andythenorth_> (consist handles autoreplace)
18:07:25 <Eddi|zuHause> yes, the internal logic must take care of the parts that may not overlap
18:07:39 <Eddi|zuHause> but not all properties need exclusiveness
18:07:42 <Alberth> otherwise, your group can have different values for the same property
18:07:56 <Zuu> Is having a firewall rules kind of list of groups a solution? Eg. first group on the list can decide over group settings below?
18:08:12 <Brianetta> Zuu: Not a bad idea at all.
18:08:35 <andythenorth_> this seems a little complicated :D
18:08:36 <Alberth> basically any form of disambiguation is good :)
18:08:41 <Eddi|zuHause> Zuu: that needs a way to define a chronology of groups
18:08:41 <Zuu> The problem is if this is a GUI that just sits around somewhere and users aren't really aware of it.
18:09:01 <andythenorth_> what is the problem with that? (just asking you to expand it) :)
18:09:12 <Alberth> Eddi|zuHause: order of appearance or order of definition
18:09:13 <Brianetta> andythenorth_: You have to remember, that you want each vehicle to behave very explicitly. You don't want it to try to do or be more than one thing at once. The UI doesn' tneed to have to let it.
18:09:28 <Zuu> And we already don't like that users should need to be aware of the newGrf load order.
18:09:32 <Eddi|zuHause> especially, that needs a way to reorder them.
18:10:11 <Eddi|zuHause> including possibly hundreds of implicit groups, like station groups
18:10:27 *** Bobbysepp has joined #openttd
18:10:43 <andythenorth_> question: do liveries really matter?
18:10:56 <andythenorth_> like, *really*?
18:10:57 <Brianetta> Eddi|zuHause: Implicit groups can be excluded
18:11:19 <Eddi|zuHause> local transport in city A should be red/white, local transport in city B should be yellow/blue
18:11:24 <andythenorth_> if reworking groups had one each of primary, secondary, and tertiary goal, what would they be?
18:11:28 <Brianetta> You don't want to assign orders to a station, because until it gets orders, the vehicle won't go to the station to join the group to get its orders
18:11:49 <planetmaker> each group could have properties orders / livery / refit rules
18:12:07 <Brianetta> Implicit groups should be read-only, for-reference
18:12:12 <andythenorth_> for me: primary: support consists: secondary: support better shared orders manipulation; tertiary, don't care
18:12:14 <Alberth> planetmaker: + auto renew/replace
18:12:15 <planetmaker> and a flag for each of those [force|allow redefine] - and then it could allow sub-groups
18:12:29 <Brianetta> You can command them, but not configure them
18:12:32 <planetmaker> meant that with refit
18:12:42 <Zuu> And a vehicle may only have one group that defines orders / livery / refit rules?
18:12:52 <Zuu> So up to 3 groups if they only define one of each..
18:12:58 <Alberth> planetmaker: ah, already covered thus :)
18:13:37 <andythenorth_> Zuu: refit rules means?
18:13:39 <Eddi|zuHause> Brianetta: fine, but then it needs a button "create an explicit group out of this implicit group"
18:13:43 <Alberth> Zuu: seems like a sane idea at this time :)
18:13:53 <andythenorth_> Eddi|zuHause: used anything that has a 'save this search'?
18:14:24 <Brianetta> Eddi|zuHause: That's acceptable
18:14:32 <Eddi|zuHause> andythenorth_: never seen any useful appliance of that... or in places where it really mattered, that option was not supplied
18:14:43 <andythenorth_> I use it to organise email :P
18:14:49 <Zuu> I like the planetmaker idea of [force|allow redefine]
18:14:54 <andythenorth_> Eddi|zuHause it's the same affordance you just described
18:15:12 <Eddi|zuHause> andythenorth_: yes, i see that ;)
18:15:31 <Brianetta> andythenorth_: One email can have several purposes. Delivery vehicles in the TT world are, thankfully, rather simpler creatures.
18:17:20 <andythenorth_> but an email just moves some bits from one place to another
18:17:21 <Brianetta> They follow exactly one set of orders, indefinitely.
18:17:32 <andythenorth_> an email just follows the rules in it's headers
18:17:51 <Brianetta> An email can have contexts, recipients, content and attachments entirely unique to it. No two emails are like; two vehicles might well be identical.
18:17:51 <andythenorth_> the several purposes are all imposed by the user :)
18:18:06 <Rubidium> an email without orders doesn't work, a TT vehicle without orders does "work" (for varying degrees of work)
18:18:09 * andythenorth_ is getting sidetracked :)
18:18:33 <Brianetta> We don't need the sort of tag soup we need for emails, because many of our vehicles are, deliberately, identical.
18:19:02 <andythenorth_> one 'groups' gui - each group has multiple settings....or multiple guis (one for orders, one for liveries, etc.), with groups in them
18:19:27 * Brianetta parses that carefully
18:19:34 <Alberth> that's just a matter of adding a grop-down, isn't it?
18:19:48 <Brianetta> If groups can contain groups, then they really should have hierarchy
18:19:59 <Brianetta> Otherwise you open to door to circular references, etc
18:20:30 <b_jonas> wait... does ottd 1.0.4 have high bridges enabled?
18:20:44 <Eddi|zuHause> andythenorth_: the main feature of the new group gui would be "show groups by [order, consist, livery, other]"
18:21:11 <Eddi|zuHause> then some ordering and filtering feature
18:21:32 *** Adambean has joined #openttd
18:21:58 <andythenorth_> it's probably right, but I'm feeling baffled :D
18:22:06 <Eddi|zuHause> so i could say things like: "show me all tram lines that go to A-Town Mainstation"
18:22:38 <Eddi|zuHause> and it would list me the groups "A-Town Line 2, A-Town Line 3 and A-Town Line 5"
18:23:29 <Eddi|zuHause> which are subgroups of the "A-Town Tram Lines" group [which defines the livery]
18:23:40 <Alberth> b_jonas: I think it allows bridges over deep canyons yes
18:23:58 <b_jonas> I just noticed that an opponent built such a bridge
18:24:02 <Alberth> b_jonas: it is much easier to simply try it
18:24:30 *** theholyduck has joined #openttd
18:25:37 <Eddi|zuHause> the last line, along with introducing consists, whould be secondary goal, the lines before would be primary goal
18:26:17 <Rubidium> b_jonas: nah, they are only supported since 0.3.0, so 1.0.4 can't have them
18:26:45 *** fjb is now known as Guest3088
18:27:29 <andythenorth_> so I'm going to put 2p on this being how most players expect to interact with train orders, refit and livery
18:27:40 <andythenorth_> what do I click to do what if we rework groups
18:27:56 <andythenorth_> I left consists out, because they are currently depot-based, and that'll need to change :P
18:28:07 <Eddi|zuHause> that doesn't look like the right image
18:28:12 * andythenorth_ will try and write this as some kind of user stories
18:28:25 <andythenorth_> 'bob wants to set a livery for this train'
18:28:33 <andythenorth_> where does bob click?
18:28:51 <b_jonas> I'll try. I'm just surprised because I don't remember reading this in the changes. I know such a patch was planned, but I didn't know it was in 1.0.4
18:29:10 <Rubidium> b_jonas: it was implemented in 2004
18:29:49 <andythenorth_> 'alice wants to put this train in an order group'
18:29:52 <andythenorth_> where does alice click?
18:30:03 <b_jonas> there are so many things there are implemented as patches but aren't in the stable release
18:30:11 <Rubidium> andythenorth_: on the buggy button
18:30:17 <b_jonas> like diagonal dinamite/landscaping
18:30:30 <andythenorth_> Rubidium: is it more buggy in the mac port :P
18:30:46 <planetmaker> b_jonas: but that is for ages in trunk / stables
18:31:07 <Alberth> b_jonas: new changes are developed constantly
18:31:13 <planetmaker> psst, you push work in my direction, andythenorth_ ;-)
18:31:39 <planetmaker> quite productive weekend actually
18:31:51 <andythenorth_> 'susan wants to change the consist used by this train'
18:31:54 <andythenorth_> where does she click?
18:32:01 <Alberth> b_jonas: and it costs a lot of time to get them right, that's why there are so many
18:32:12 <Rubidium> andythenorth_: same button, as she should know what the other buttons do
18:32:14 <Alberth> in a consist-defining group?
18:32:50 <Brianetta> Fixing shared orders would get me playing again.
18:32:54 <Rubidium> the point is, you can point at the current buttons but that makes no real sense. If you want to change it, you better change the icons as well. Otherwise you'll get into a support nightmare
18:33:16 <Rubidium> Brianetta: what does fixing entail exactly?
18:33:21 <Eddi|zuHause> andythenorth_: "eddi was careless in organizing his few vehicles, but now with lots of vehicles he wants to group the vehicles into city/regional/express groups"
18:33:21 <andythenorth_> but unless someone knows how the buttons should be changed....
18:33:25 <Brianetta> Rubidium: Moving away from guesswork
18:33:58 <andythenorth_> "eddi seems to need a search-by-arbitrary-criteria and add-to-group framework"
18:34:20 <Eddi|zuHause> andythenorth_: that's a task i have done more than once, and it's very tedious
18:34:54 <Alberth> ah, you have experience :p
18:35:05 <andythenorth_> Brianetta: shared orders are guesswork when you're trying to find a vehicle to clone?
18:35:26 <Rubidium> but it doesn't get much better with unnamed groups
18:35:34 <planetmaker> hm, the nightly takes its time
18:35:35 <andythenorth_> so if you could see all sets of shared orders you would be happy?
18:35:36 <Rubidium> or do you want to name the groups automagically?
18:35:51 <Rubidium> in which case the names either get horribly long, or are very similar
18:36:05 <andythenorth_> Brianetta: if there was a list of *all* orders there have ever been would that serve your needs?
18:36:15 * andythenorth_ suspects it's not possible to cache all that :P
18:36:37 <TrueBrain> meh! I wish minecarts were stable in Minecraft multiplayer ... /me goes being annoyed
18:36:49 <Rubidium> e.g. all trains starting from "Berlin Hbf" pass "Berlin Zoo", so all shared orders from those trains will be "Berlin Hbf - Berlin Zo..."
18:36:59 <Rubidium> doesn't remove much of the guessing I'd guess
18:37:20 <Alberth> allowing to rename a group would be good :)
18:37:22 <b_jonas> I shouldn't complain. After all, I haven't done anything to improve ottd.
18:37:31 <andythenorth_> groups can be renamed
18:37:35 <andythenorth_> shared orders can't
18:37:44 <Rubidium> yes, but shared orders can be put into a group
18:37:50 <Alberth> shared orders have no name :)
18:38:03 <andythenorth_> ergo cannot be renamed :)
18:38:22 <Rubidium> but you can name them as groups without much hassle
18:38:23 <andythenorth_> all vehicles using an order can be put in a group though, which is close...
18:38:32 <Brianetta> andythenorth_: If that list could be used to assign them, then you've basically implemented it
18:38:40 <Rubidium> it's like one or two extra steps
18:38:46 <andythenorth_> so that has nothing to do with groups, and everything to do with orders?
18:39:09 <andythenorth_> 'brianetta has no needs that are met by current groups, nor would be met by a change to groups'
18:39:12 <Rubidium> shared orders are just implicit (fairly) invisible groups
18:39:13 <Brianetta> andythenorth_: Read up. I've sugegsted "group-like" several times.
18:39:28 <Brianetta> Current groups have little use.
18:39:35 <andythenorth_> ^^ I know, but it's a long and noisy discussion
18:39:47 <Alberth> andythenorth_: Briannetta is just very order-oriented :)
18:39:56 <Rubidium> groups work perfectly for me :)
18:39:59 <andythenorth_> 'eddi wants to be able to search vehicles and save the results as a group'
18:40:05 <andythenorth_> groups work near-perfect for me
18:40:07 <Brianetta> No, I want liveries and orders both (:
18:40:14 <Rubidium> to replace engines and such on specific groups of trains
18:40:18 <Brianetta> Groups work, sure, but they do very little.
18:40:29 <Brianetta> They're just an orders broadcast list.
18:40:30 <andythenorth_> Brianetta: I want lots of ponies, but I don't get them :)
18:40:54 <Brianetta> andythenorth_: Make sens
18:40:58 <Eddi|zuHause> "Mandy wants for her parents to buy them a pony"
18:40:59 <Brianetta> please, make some sense
18:41:22 <Brianetta> I couldn't give two hoots whether groups continue unchanged
18:41:36 <dihedral> <Brianetta> please, make some sense <- we could have used that line a few days ago :-D
18:41:42 <Brianetta> That thread from September 2008 still have my answers to most of the arguments
18:42:12 <andythenorth_> I read it, I'm just trying to separate proposed implementation from actual problem :)
18:42:13 <Brianetta> My needs haven't changed a jot since then
18:42:44 <andythenorth_> does it make *any* sense to have a 'liveries' gui?
18:42:54 <Brianetta> The problem is that the current shared orders have no useful interface of their own, and that liveries aren't as versatile as they could be
18:43:12 <Brianetta> If you thin kI have a problem with groups, you've mis-understood everything.
18:43:25 <andythenorth_> nah, I think they don't serve your needs, that's the main probelm
18:43:40 <Brianetta> I'm not interested in them
18:43:56 <Brianetta> You're not understanding the problem in the slightest
18:44:52 <andythenorth_> the first place to set orders is on a vehicle
18:45:09 <Brianetta> you should be able to set orders before you even buy a vehicle
18:45:25 <andythenorth_> the first place to set consist is on a vehicle (currently train only) (in depot)
18:45:32 <andythenorth_> where would be the first place to set livery?
18:45:39 <Brianetta> Same place as orders.
18:45:40 * andythenorth_ suspects on a vehicle
18:45:58 <Brianetta> On the definition of a new service from Little Frimpton to Great Bottomley East.
18:46:09 <Brianetta> To which, vehicles can be added.
18:46:14 <Alberth> depends whether you can have empty groups, I think
18:46:27 <andythenorth_> lets have scheme A: things are defined initially on vehicles, groups are another level
18:46:35 <andythenorth_> scheme B: groups first, vehicles second
18:46:47 <Alberth> Brianetta: not sure, but you blindly assume there are, and andy doesn't
18:46:48 <andythenorth_> currently the game is engineered around scheme A
18:47:10 <Brianetta> Simutrans has already solved this problem.
18:47:20 <Brianetta> You can give a schedule to a vehicle ("orders" in TT)
18:47:34 <Brianetta> You can also define a line
18:47:42 <Brianetta> A line is a list of orders
18:47:54 <Brianetta> You can add any vehicle to a line, and it'll follow those orders instead.
18:47:59 <andythenorth_> can you also assign orders individually to a vehicle without it being on a line?
18:48:05 <Alberth> Simutrans solved *a* problem, I don't know whether they solved ours too
18:48:21 <andythenorth_> why not play simutrans?
18:48:31 <Brianetta> Because its track layout tools suck
18:48:32 * andythenorth_ assumes there's a good reason :)
18:48:41 <Brianetta> A simple junction in track
18:48:44 <Brianetta> it has to be a triangle
18:48:57 <Brianetta> OpenTD is so much better than the orders issue
18:49:07 <Brianetta> Simutrans sucks in so many other ways
18:49:16 <Alberth> Brianetta: so let's make groups better than Simutrans too
18:49:17 <andythenorth_> Brianetta: this isn't an argument by me against your case, there are just lots of wishes for what groups / orders / consists can / should do
18:49:23 <andythenorth_> I'm trying to make sense of them
18:49:24 <Brianetta> this is one tiny aspect wher ethat game mails it, and ours is lost int he deep ocean
18:49:56 <andythenorth_> someone has to write a non-technical spec for changes, then someone has to make that a technical spec
18:50:06 <ccfreak2k> andythenorth_, wasn't there some kind of recent patch (or maybe it was really old) that basically just catered to as many people as possible because of a lack of a 100% agreeable answer?
18:50:21 <andythenorth_> probably not a good one :P
18:50:44 <andythenorth_> open framework is one thing, design by committee is another
18:50:52 <ccfreak2k> Well I think the underlying problem is that everyone has a different idea on how a complex system should work.
18:51:06 <ccfreak2k> Once it's implemented, someone isn't going to like it.
18:51:06 <Brianetta> The biggest hurdle is conservatism
18:51:09 <Alberth> andythenorth_: I think it needs experimentation, making mock-ups, making working prototypes, etc until we find something that works
18:51:13 <Brianetta> Nobody wants the game to be too different
18:51:19 <andythenorth_> I'm with alberth
18:51:26 <Brianetta> and assume that any slightly larger than normal suggestion is a Big Change
18:51:39 <Alberth> Brianetta: as long as you keep the original play style, a change is not problem
18:52:13 <Brianetta> Hirundo: You have restated my original suggestion in ascii art (:
18:52:48 <Hirundo> I have stated here before, that your post could also have been mine :)
18:53:03 <Brianetta> It's been there for two years. I don't expect anybody to implement it, or any other real improvements.
18:53:52 <Alberth> Hirundo: a single hierarchy breaks horribly if you want to do different actions, I think
18:54:03 <Terkhen> I agree on the problem with shared orders, my problem with groups is that making groups is not straightforward and therefore usually not worth it for me
18:54:08 <andythenorth_> Hirundo: so I have city A and city B. I run some passenger trains and mail trains between them. So orders could be on C and consists on D and E?
18:54:35 <Hirundo> If your orders happen to be the same and shared, yes
18:54:43 <andythenorth_> I want all the trains to share orders, but 50% use a pax consist and 50% use a mail consist
18:54:59 <Brianetta> andythenorth_: Understanding dawns.
18:55:09 <Hirundo> Note that I don't have a clear concept of 'consist' in my mind (yet)
18:55:21 <Brianetta> You can even give them colours based on their container, or the parent containers.
18:55:37 <andythenorth_> Brianetta: please don't make the assumption that I don't understand what you wrote. It was *extremely* clear what you intend
18:55:47 <andythenorth_> neither of us are stupid
18:55:56 <Brianetta> It's what simutrans calls a convoy. It's the vehicles that go in to making up a single, orderable unit of transportation. Locomotive and wagins, normally.
18:55:58 <Alberth> Brianetta: a problem with that post is that it posts *the* solution rather than a problem, so it is hard to judge how good the solution is, imho
18:56:40 <Brianetta> Alberth: At the time I kind of assumed that the problem was as obvious to others as it was to me.
18:57:00 <Eddi|zuHause> that's usually a tricky assumption :p
18:57:02 <Brianetta> The past two years have showed me how hard somebody will work around an issue, and also how attached they become to their work-around.
18:57:28 <Alberth> mostly because they don't see that they do a work-around
18:57:35 <Brianetta> There are people who actually believe that the current shared orders "system" is an ideal.
18:57:47 <Alberth> or they lack the power or will to change it
18:57:50 <Brianetta> What I see is something that was crowbarred in.
18:58:22 <Brianetta> Then again, OpenTTD has no design document.
18:58:28 <andythenorth_> so following my example....now I want to replace the engines on *all* my mail trains
18:58:31 <Alberth> Brianetta: if you see the current shared orders as a sort of adding to a group, it is usable
18:58:42 <andythenorth_> but I use the same engines on my passenger trains, but I don't want to replace them
18:58:44 <Brianetta> Alberth: Sort of, yes - but where the hell do I find this group?
18:58:55 <andythenorth_> I have mail trains in group B as well
18:58:57 <Brianetta> And what happens to this group when the trains in it have gone?
18:59:26 <Brianetta> How do I recover my long and complex orders list for the four-train pile-up that was every train in that list?
18:59:35 <Alberth> as always, improvements are incremental, and people stack small changes on top of each other, which gives you the current OpenTTD group/replace/order/??? mess
18:59:43 <Brianetta> Alberth: No, not as always.
18:59:47 <Brianetta> Just as always in this project.
18:59:55 <Brianetta> Improvements can be designed.
19:00:12 <Brianetta> It's just that, with OpenTTD, they never are.
19:00:29 <Brianetta> They're coded, and the code is looked at by maintainers to see if it's worth including.
19:00:35 <Alberth> your post and this discussion is a big change. If you look at suggestions, they are mostly very small
19:00:44 <Brianetta> From brain to code without any readable design.
19:01:39 <planetmaker> [21:00] <Brianetta> It's just that, with OpenTTD, they never are. <-- I think you cannot be more wrong
19:01:41 <Alberth> you need several groups next to each other, with different views, imho
19:01:52 <andythenorth_> Alberth: to solve my problem, or the general one?
19:02:11 <Alberth> at least your problem
19:02:15 <andythenorth_> there are two obvious questions in my problem
19:02:19 <andythenorth_> (1) how do I do it now?
19:02:27 <andythenorth_> (2) it doesn't say how consists are defined...
19:02:39 <glx> <TrueBrain> meh! I wish minecarts were stable in Minecraft multiplayer ... /me goes being annoyed <-- and working bucket for lava and water sources
19:02:40 <Brianetta> andythenorth_: Depends what the parent groups are doing. Your diagram doesn't say.
19:03:03 <andythenorth_> C and F define orders
19:03:10 <andythenorth_> they are different ;)
19:03:28 <andythenorth_> currently I use groups to handle this situation
19:03:47 <andythenorth_> I have to move trains into groups, do the replace, then (optionally) I kick them out of the group again
19:03:59 <Brianetta> Feel free to continue doing so. ALthough, really, you don't. Groups only send commands, like stop, or go to depot.
19:04:04 <andythenorth_> if I do that in the hierarchical situation, my orders are lost
19:04:19 <TrueBrain> glx: that works in latest
19:04:31 <Brianetta> Just change the consist of the group. Send to depot for service. Watch account balance drop.
19:04:55 <Brianetta> You need to change two "argon" locos to "xenon"
19:04:58 <andythenorth_> where would consists be defined?
19:05:11 <Brianetta> It's a property of teh group
19:05:16 <Alberth> Brianetta: but you need to change groups D and F, that's a work -around
19:05:21 <Hirundo> andythenorth_: in a hierarchy, you'd either have to define the order list or the replacement rule twice
19:05:50 <Alberth> so you need more hierarchies :)
19:05:55 <andythenorth_> unless consists exist outside of the hierarchy
19:06:08 <andythenorth_> and if consists exist outside of the hierarchy, why not orders?
19:06:25 <Brianetta> He has enough. In his chosen schema, top tier is undefined, second tier is orders, third tier is consist.
19:06:45 <Alberth> Brianetta: you create groups around orders, if I want a different hieracrhy at the same time, eg engine replacement, you cannot do that
19:07:09 <Brianetta> Alberth: I create groups around orders?
19:07:18 <glx> TrueBrain: anyway it will be better with damages :)
19:07:21 <andythenorth_> Alberth you can, but you have to go down each branch until you find each consist
19:07:22 <Alberth> Brianetta: 'lines' than
19:07:50 <Brianetta> However you look at it, you still have less work than you do in OpenTTD as it stands
19:07:51 <andythenorth_> a hierarchy is a form of graph?
19:07:59 <Brianetta> andythenorth_: It's a tree
19:08:08 <andythenorth_> is a tree a graph?
19:08:13 <Brianetta> Folders on your hard disk are a hierarchy
19:08:14 * andythenorth_ is not very good at proper maths
19:08:16 <TrueBrain> glx: very true! 14 more days, sadly enough :(
19:08:23 <Alberth> I'd make a A' next to A and define the replacement there
19:08:27 <andythenorth_> Brianetta: the bits on the disk are *not* a hierarchy ;)
19:08:36 <Hirundo> "a tree is an undirected graph "
19:08:36 <Brianetta> andythenorth_: We don't care; they're abstracted
19:08:47 <Brianetta> ANy more than we care how trains are stored in RAM
19:09:02 <Alberth> andythenorth_: one or more trees with shared leafs?
19:09:20 <andythenorth_> so if we use a tree, the consist is defined on a per node level
19:09:25 *** ChanServ sets mode: +v tokai
19:09:36 <andythenorth_> instead of nodes that have a relation saying they share a consist?
19:09:42 <Alberth> (sharing nodes seems a bit weird imho)
19:09:50 <andythenorth_> we're defining properties inside the graph, not outside the graph
19:10:17 <Eddi|zuHause> i really don't think we need to insist on a hierarchy/tree...
19:10:30 <andythenorth_> Eddi|zuHause: reasons?
19:10:34 <Alberth> (09:10:02 PM) andythenorth_: instead of nodes that have a relation saying they share a consist? <-- I don't get that
19:10:39 <Brianetta> It's a tree with inheritance. So, think of these groups/lines/whatever as folders. The folder defines properties of any train it contains. If the folder doesn't define something, because it's left blank, the parent folder does. Repeat all the way up to the root folder.
19:10:54 <Eddi|zuHause> since the three prospected properties "order", "consist" and "livery" are completely independent from each other
19:11:01 <andythenorth_> Alberth: if the nodes define the consist, and there are three similar consists, that is defined three times
19:11:07 <Brianetta> Eddi: I don't, either, but andythenorth is asking about that specifically.
19:11:30 <Eddi|zuHause> we only need a way to enforce uniqueness of each property in the "contains" relation
19:11:31 <Brianetta> andythenorth_: Only three! Right now, it's once per vehicle.
19:11:45 <andythenorth_> which is a problem...
19:11:45 <andythenorth_> there should be one consist definition, and each node is marked to say it uses that consist
19:11:48 <Brianetta> Eddi: Take it as read: I agree.
19:12:13 <andythenorth_> * one consist definition per consist :)
19:12:21 <Brianetta> andythenorth_: You're getting hung up on hierarchy. That's simply one way to ensure that no train can get more than one set of orders.
19:13:13 <Brianetta> Another simple way is to ensure that each vehicle can belong to no more than one group.
19:13:26 <Eddi|zuHause> andythenorth_: if you insist on a tree structure, you are bound to run into troubles because when you base your hierarchy on orders, you need to duplicate consists and liveries... this is an exponential growth in the number of properties
19:13:33 <Brianetta> A slightly less simple way is to ensure that no vehicle can belong to more than one group that provides orders
19:13:52 <andythenorth_> Eddi|zuHause: which is why I think a tree structure is a bad way to implement this
19:14:01 <andythenorth_> apparently photoshop keeps application state in the gui :P
19:14:16 <andythenorth_> when they want to know the value of a parameter, they have to go look what the control is set to
19:14:23 <Eddi|zuHause> andythenorth_: yes, we seem all to think tree is a bad idea, so we need to think about alternatives
19:14:26 <Brianetta> A preferred way, suggested by Zuu, is that vehicles can belong to an arbitrary number of groups, but they are ordered, and only the first one with orders would apply to the vehicle.
19:14:27 <andythenorth_> which is fun when there are multiple controls for the same property on screen :P
19:14:41 *** Progman has joined #openttd
19:15:42 <Brianetta> Zuu's method would require some way to re-order the group membership list of a vehicle.
19:16:05 <Brianetta> Or, to have a global precedence, which could be an integer.
19:16:19 <Eddi|zuHause> Brianetta: i'd prefer the global precedence
19:16:31 <Brianetta> Emulatin gthe best parts of the hierarchy solution (the fact that everything has an order).
19:16:41 <Brianetta> Eddi: I quite like it, too
19:16:42 <nicfer> if you force bolt down a shop door, the shopkeeper may be directly angry rather than asking for money?
19:17:08 <Brianetta> Depends on teh keeper
19:17:29 <nicfer> I was going to ask on the #nethack channel
19:17:37 <andythenorth_> re-ordering the group membership list of a vehicle on a *per-vehicle* basis would certainly have a few problems :D
19:17:46 <nicfer> sorry for the inconvenance
19:18:05 <Eddi|zuHause> andythenorth_: it might cause more nightmares than it solves :p
19:18:10 <Brianetta> It'd become an irritating chore
19:18:17 <andythenorth_> you'd need a group to manage the group membership :P
19:18:31 <andythenorth_> we'd be in the same madness we have now, but with a lot more code effort to get there ;)
19:18:39 <andythenorth_> how would global precedence work?
19:18:49 *** lobstar has joined #openttd
19:18:50 <Brianetta> The best solution might be separate precedence indicators for orders, liveries, etc
19:19:03 <andythenorth_> orders, consist, livery
19:19:09 <andythenorth_> anything else we might want to specify?
19:19:18 <Brianetta> 1 == this group has the highest precedence, and any member of this group *will* follow these orders.
19:19:26 <Brianetta> Or have this livery.
19:19:49 <Alberth> assume global precedence is enough for now, we will find out whether it is true
19:19:54 <andythenorth_> servicing interval?
19:20:12 <Brianetta> Alberth: One global precedence number for each definable attribute
19:20:20 <Alberth> sure, no reason to exclude anything imho
19:20:22 <Brianetta> andythenorth_: Sure
19:20:32 <Eddi|zuHause> so, in this instance, groups would work like tags.
19:20:32 <Brianetta> Why don't we knock up a wiki page?
19:20:39 <Alberth> we can always not implement it :)
19:20:45 <Brianetta> Eddi: Tags with numbers, yes
19:21:14 <andythenorth_> well we don't the spec yet ;)
19:21:17 * Brianetta rattles in a problem definition
19:21:20 <andythenorth_> feel free to start
19:21:39 <andythenorth_> out of interest, how many livery groups could there reasonably be?
19:22:27 <andythenorth_> I think there are only two answers
19:22:44 * Alberth likes multiple choice :p
19:24:10 <andythenorth_> 'livery group' is misleading
19:24:44 *** JVassie has joined #openttd
19:25:48 * Brianetta is having to fudge about with accounts on openttd.org
19:26:03 <Brianetta> Just groups, surely
19:26:08 <Brianetta> and livery is a possible attribute
19:26:12 <Brianetta> which might not be defined
19:26:47 <andythenorth_> I was thinking of an alternative still....but nvm that for now
19:27:06 <Brianetta> As soon as I get my calidation code I'm going to put some stuf fin there
19:27:18 <Brianetta> perhaps my nails need cutting
19:30:25 <Eddi|zuHause> if you haven't used your accounts in the last 2 years, you might have to merge them first...
19:30:57 <Brianetta> So it's not so much merging as copying
19:31:33 <Brianetta> but the validation code is being retarded by my graylist spam defences
19:31:56 <Brianetta> so I have to wait a minimum of five minute for an email from a new sender
19:32:00 <Eddi|zuHause> if you annoy TrueBrain enough, he might either kick you or help you ;)
19:32:20 <Brianetta> Likely the former, since it's my system
19:34:20 <TrueBrain> oeh, I can kick someone? :D
19:34:28 <Brianetta> TrueBrain: If I can come back (:
19:34:31 <Eddi|zuHause> hm... i have "The Prisoner" [old series from the '60s] here, and am too bored to watch it...
19:34:35 <TrueBrain> depends .. do you smell?
19:34:47 <Brianetta> I use my nose for that
19:35:33 <Brianetta> Thanks, Rubidium (-:
19:35:41 <Eddi|zuHause> he's merging his accounts and is fighting with his greylist ;)
19:35:59 <Brianetta> I'll get the email eventually
19:36:00 <andythenorth_> maybe we write css per train :P
19:36:28 <TrueBrain> nothing we can help anyway
19:36:46 <TrueBrain> Brianetta: but it does mean you have a very poor greylisting, as openttd.org has a (valid, strict) SPF record
19:36:49 <Brianetta> TrueBrain: Indeed. hence, of the two options, it'd be kick
19:36:54 <TrueBrain> I would suggest upgrading :)
19:37:17 <Brianetta> It's postgrey, and I don't use SPF because anybody can make a valid, strict SPF record.
19:37:26 <andythenorth_> Eddi|zuHause: search / filtering for groups....would it be dynamic? i.e. 'vehicles over 20 years', 'vehicles losing money'...?
19:37:33 <andythenorth_> you seemed to think yes earlier?
19:37:49 <TrueBrain> Brianetta: euh ... you can't really fake connection-from in a two-way data stream
19:37:55 <Alberth> if you want to hook autorenew to it, I think so
19:37:56 <Brianetta> Basically, as a newly introduced SMTP server, the mail is delayed until you retransmit, by which time my server has had time to consult updated blacklists.
19:38:00 <TrueBrain> that with strict SPF records, you have a pretty good identification
19:38:08 <andythenorth_> Eddi|zuHause: I was thinking about consists
19:38:18 <Eddi|zuHause> andythenorth_: the complexity of this feature may vary
19:38:35 <Rubidium> TrueBrain: I think the point is, that I can still get a domain, give it a strict SPF record and spam everyone
19:38:40 <TrueBrain> so not using SPF 'because anybody can make a calid, strict SPF record' is just saying: I don't use a car, because it drives
19:38:45 <Brianetta> You don't have any identification. You're yet another new mail source.
19:38:49 <Eddi|zuHause> andythenorth_: currently, different lists have different filtering abilities
19:38:58 <Eddi|zuHause> it seems a little inconsistent overall
19:39:02 <andythenorth_> Eddi|zuHause: what if the consists themselves use rules?
19:39:04 <TrueBrain> Rubidium: true; for that we have uceprotect :)
19:39:10 <andythenorth_> just to try another option
19:39:16 * Alberth refuses to bring sugar beet to a green box
19:39:20 <Eddi|zuHause> what do you mean?
19:39:20 <Rubidium> SPF records are only useful to weed out sending from a domain you don't own
19:39:25 <andythenorth_> Alberth: me too oddly
19:39:34 <Eddi|zuHause> for defining consists i'd imagine a depot-like gui
19:39:40 <andythenorth_> Eddi|zuHause: each consist has n slots. For each slot, the vehicle in it is define by rules
19:39:45 <Eddi|zuHause> where you set engines, wagons and refits
19:39:46 <TrueBrain> Rubidium: we accept all mails from SPF valid domains, given they are not in uceprotect
19:39:51 <Eddi|zuHause> without actually buying the vehicles
19:39:56 <andythenorth_> Eddi|zuHause: that's the obvious route :)
19:39:57 <TrueBrain> so far, it has not given a single spam message :)
19:40:06 <TrueBrain> (in other words: greylist is skipped when SPF is valid, and uceprotect validates)
19:40:13 <andythenorth_> what about the vehicle in each slot of the consist being determined by a decision tree of some kind?
19:40:21 <TrueBrain> even works correct with google :D
19:40:38 <andythenorth_> so 'if engine in slot 1 is more than 20 years old, change it for this type'?
19:40:49 <Eddi|zuHause> andythenorth_: yes, but you need to evaluate these decisions on train construction. and then on what criteria?
19:41:03 <andythenorth_> player has to create rules :P
19:41:10 <andythenorth_> I'm just fooling around with options
19:41:31 <Eddi|zuHause> andythenorth_: the more complex you define this feature, the less likely it will get implemented
19:41:58 <Eddi|zuHause> andythenorth_: in the most evil case, the consist would contain "wagon slots", and the wagons are attached at the station
19:41:58 <andythenorth_> so it's good to rule out complex stuff explicitly no?
19:42:17 <andythenorth_> 'if cargo B is waiting at station xyz, use wagon type pdq in this slot'
19:42:31 <andythenorth_> very railroad tycoon :)
19:42:51 <andythenorth_> and in RT3 the game had a despatcher who sorted the consists out automatically based on cargo prices
19:43:04 <andythenorth_> leaving the player alone to build industries, which is the proper function of a transport game :P
19:43:10 <Eddi|zuHause> andythenorth_: the 3 minutes that i played rrt2, i had the feeling empty wagons would just magically hop back to the source
19:43:17 <Eddi|zuHause> that should not happen
19:43:24 <andythenorth_> a bit like 20 tile trains magically fit into depots :P
19:43:43 <Eddi|zuHause> a bit like rondje om de kerk AI :p
19:43:54 <andythenorth_> RT3 makes more sense in terms of bills of lading or whatever, rather than actual trains
19:43:58 <Eddi|zuHause> no. i think that is bad
19:44:18 <andythenorth_> ok, so consists are just simple drag and drop, but on a virtual train somewhere
19:44:26 <Eddi|zuHause> part of the logistics is managing empty wagons get back to where they need to be loaded
19:44:31 <andythenorth_> so consists could be defined on a pool of hidden / virtual trains?
19:44:49 <andythenorth_> so all dragging, newgrf complexity etc would be handled by this
19:44:56 <andythenorth_> as it's just a copy of what exists
19:45:02 <Eddi|zuHause> but that is probably a too technical design decision which should not be made in this early design state
19:46:14 <Eddi|zuHause> as a mini feature: a setting that defines whether changed consists leave old vehicles behind in the depot, or sell them.
19:46:45 <andythenorth_> what's the purpose of leaving them behind?
19:47:07 <Eddi|zuHause> degrading the probably still good high speed engines to regional service
19:47:15 <Eddi|zuHause> when switching to better high speed engines
19:47:22 <andythenorth_> if the vehicles for a consist change are in depot when a train enters it, it uses them in preference to new ones?
19:47:30 <andythenorth_> or player does it manually?
19:47:45 <Eddi|zuHause> if the vehicles are in the depot, reuse them. yes
19:48:11 <andythenorth_> what if the vehicles could have a different group applied by the consist change?
19:48:29 <andythenorth_> 'goto depot and apply groups xyz'
19:48:40 <andythenorth_> that would be bonkers but plausible,
19:48:42 <Eddi|zuHause> the groups are discarded
19:48:54 <andythenorth_> you could have vehicles going around automatically switching which orders they're using :o
19:50:12 <andythenorth_> Eddi|zuHause: so you want to cascade loco type A down to 'regional service' from 'fast service'. You just change the group surely, and it picks up new orders?
19:50:14 <Eddi|zuHause> depot based shunting :)
19:50:20 *** HerzogDeXtEr has joined #openttd
19:50:44 <Eddi|zuHause> andythenorth_: example:
19:50:51 <andythenorth_> I guess switching orders leaves the wagons on the wrong train
19:51:04 <Eddi|zuHause> i have two groups, an express group and a regional group, each having a consist assigned
19:51:40 <Eddi|zuHause> in the express consist, i replace BR 110 by BR 103. the trains go to depot, buy a BR 103 and leave the BR 110 behind
19:52:09 <andythenorth_> then you send the regional group to depot to swap out to the BR 110, selling whatever they are using
19:52:19 <andythenorth_> assuming they go to the right depot :P
19:52:28 <Eddi|zuHause> then in the regional consist, the trains are ordered to go to depot, and switch their engine with a BR 110 if one is available in the depot
19:52:55 <Eddi|zuHause> possibly with a setting to buy a new one, or to just do nothing
19:53:25 <andythenorth_> works brilliantly if you have limited number of depots :)
19:54:03 <Eddi|zuHause> yes, but the less depots you have, the more urgently you need a conditional "how to get to the depot" path in each order
19:54:29 *** asnoehu has joined #openttd
19:54:34 <andythenorth_> differentiate 'main' depot and 'servicing' depots?
19:55:06 <andythenorth_> I am making the assumption that current 'goto depot and refit' order would be upgraded to 'goto depot and use consist'
19:55:07 <Alberth> not everybody connects all lines to each other :p
19:55:11 <Eddi|zuHause> that could be as simple as extending the "if needs servicing" conditional order with a "if needs autoreplace"
19:55:32 <andythenorth_> 'if needs autoreplace goto Zurich Depot 1'
19:56:28 <Alberth> doesn't sound like a regular order-ish thing to me, at first read
19:56:39 <andythenorth_> if 'goto depot and use consist' was available (it should be), then that's approximately the same behaviour as RT3 :P
19:56:49 <Alberth> perhaps autoreplace is a form of servicing?
19:56:55 <andythenorth_> I can just constantly sell and buy vehicles
19:57:23 <Alberth> like rondje om de kerk ?
19:57:57 *** andythenorth_ has joined #openttd
19:58:07 <Alberth> like rondje om de kerk ?
19:58:41 <andythenorth_> Brianetta: wiki page looks good
20:00:45 * Brianetta is still typing away
20:01:04 <andythenorth_> is there any case for train to change livery as part of orders
20:01:10 <andythenorth_> I can't think of one, but just checking...
20:01:29 <Brianetta> well, for a group to have both orders and livery
20:01:42 <andythenorth_> I mean 'goto A and be red, goto B and be blue'
20:01:47 <Brianetta> Say you have a train that you want to run the Orient Express
20:01:53 <Brianetta> You want its lovery and schedule
20:02:09 <Brianetta> vehicles don't do that until 2070 at the earliest
20:02:21 <andythenorth_> what about 'goto depot and be repainted' :P
20:02:36 <Brianetta> so I don' think it should be encouraged
20:02:41 <Brianetta> it'd just be eye candy
20:03:16 <andythenorth_> servicing interval same - no reason for orders to change it
20:03:19 <Brianetta> Some vehicles let you see if they're carrying cargo or are empty, which would be the main benefit
20:03:53 <Brianetta> Feel free to add these to the "The problem" section
20:04:02 <Brianetta> I'm editing "The Solutions" atm
20:05:03 * andythenorth_ still wonders if orders can be changed by orders :P
20:05:29 <Brianetta> That's pretty high level
20:06:29 <andythenorth_> if orders could change group (go to x and change group), then livery, servicing, orders, consist etc could all be changed by orders
20:06:33 <andythenorth_> mad but it would work
20:06:43 * andythenorth_ wonders if we could programme emergent behaviour that way
20:07:31 <Terkhen> I don't know, but madness would emerge for sure
20:07:59 * andythenorth_ wonders if we could programme prisoners dilemma with it
20:11:49 <Eddi|zuHause> yes, instead of current refit orders, you'd give a change group order to change the consist
20:12:53 <Eddi|zuHause> "load at A" - "unload at B" - "change consist to X" - "service at depot" - "load at B" - "unload at A" - "change consist to Y" - "service at depot" [repeat]
20:13:33 <andythenorth_> better than the current refit option
20:13:39 <andythenorth_> who uses the current refit option?
20:13:42 <Eddi|zuHause> might want to combine to "change group and go servicing"
20:18:56 *** De_Ghosty has joined #openttd
20:19:24 <Brianetta> andythenorth_: Review page please?
20:22:53 <V453000> <andythenorth_> who uses the current refit option? <- I do
20:23:21 <Eddi|zuHause> the usefulness of that option depends drastically on the used newgrf set
20:23:41 <Eddi|zuHause> with the proposed consist system, that would be also possible with default vehicles
20:25:38 <Brianetta> andythenorth_: I'm done with that page for now. Feel free to throw your say in there.
20:26:58 <andythenorth_> not to get stuck on implementation but...
20:27:13 <andythenorth_> Eddi|zuHause: if consists *were* defined by a pool of virtual/hidden trains....
20:27:19 <andythenorth_> ...orders could be done the same way?
20:27:35 <andythenorth_> forget all discussion of groups for a minute or two
20:27:38 <Eddi|zuHause> there is already an order pool
20:28:02 <Brianetta> Of course they could. You can do that already in the game, if you have the cash and consider a depot full of trains to be virtual/hidden
20:28:02 <andythenorth_> is it persistent beyond the removal of the last vehicle in the pool?
20:28:30 <Eddi|zuHause> no, but that is only because they are explicitly deleted
20:28:50 <Eddi|zuHause> if the orders were "posessed" by a group, they would be deleted when the group is deleted
20:29:05 <Eddi|zuHause> but they'd stay intact if the group has no vehicles in it
20:29:35 <Eddi|zuHause> that change should be one of the easiest
20:30:45 <andythenorth_> for the sake of arguing can we call these 'master vehicles'?
20:30:56 <andythenorth_> and assume vehicles are slaved to a master vehicle for various properties...
20:30:59 <CIA-2> OpenTTD: yexo * r20979 /trunk/src/newgrf.cpp: -Fix: [NewGRF] ignore the variable for action7/9 condition type 0x0D and 0x0E as documented
20:31:32 <Eddi|zuHause> andythenorth_: that is pretty much how it's done currently
20:31:50 <andythenorth_> seems to be a pattern. we have a web app that is similar
20:32:16 <andythenorth_> so livery and servicing interval could also be slaved to a master vehicle
20:32:53 <Rubidium> yay memory usage reduction! :)
20:33:17 <andythenorth_> lots of master vehicles :P
20:33:33 <Brianetta> Rubidium: We've got that group thing on the wiki now
20:34:06 <andythenorth_> seems like memory gobbling to me, especially if master vehicles persist for whole game once created
20:34:39 <andythenorth_> I guess properties on slave vehicles would use a pointer to master, instead of storing actual props?
20:34:43 <Terkhen> slave vehicles could just have a pointer to the master for shared properties
20:34:44 <Brianetta> Ooh, I just got my validation code (-:
20:35:06 <andythenorth_> so change props just means change pointer?
20:35:09 <andythenorth_> except for consist
20:36:32 <andythenorth_> so then there are two ways of doing stuff with vehicles.
20:36:48 <andythenorth_> 1. build new vehicle, choose which master vehicles to slave to for each property
20:36:55 <andythenorth_> 2. pick a slave vehicle and clone it
20:37:09 <andythenorth_> or clone some aspects of it
20:37:16 <andythenorth_> not sure how the gui would work
20:39:49 <Brianetta> It would hide that virtual vehicle
20:40:31 <Brianetta> The window for that virtual vehicle would be the window containing the real vehicles to which it is linked
20:40:48 <Brianetta> and would have appropriate furniture for consist modiification, etc
20:41:22 <Brianetta> Perhaps the same furniture, within reason - icons down the right.
20:42:04 <nicfer> grass and rainforest is different to distinguish from, without trees
20:44:47 * andythenorth_ once read about pointers
20:45:07 <andythenorth_> for some properties, a master vehicle could have a pointer to another master vehicle?
20:46:57 <Brianetta> Link a vehicle to a bunch of virtual vehicles and let them fight by precedence.
20:47:18 <Brianetta> master vehicle == group
20:47:27 <Brianetta> it's just a record in memory, after all
20:47:39 <Brianetta> This is just implementation.
20:48:00 <Brianetta> It certainly could be done that way, and if the devs find it easiest, let them do that.
20:48:09 <andythenorth_> this is fine for vehicle properties
20:48:22 <andythenorth_> but not for things that aren't mutable properties :o
20:48:47 <andythenorth_> however, selecting what's in a group is probably different to using groups to define certain properties
20:49:04 <andythenorth_> profits, age, reliability
20:49:13 <Brianetta> They can be ignored.
20:49:17 <andythenorth_> timetable lateness
20:49:32 <Brianetta> Your virtual train is going to be, basically, a template
20:49:44 <andythenorth_> but I don't think it covers 100% of what groups should do
20:49:49 <Brianetta> so those immutable fields can be masked out
20:50:03 <Brianetta> Well, probably not.
20:50:17 <andythenorth_> each group gets the mutable properties from a master vehicle
20:50:25 <andythenorth_> or leaves them unchanged
20:50:36 <Brianetta> I'd have thought that making explicit records for groups, such as a livery definition, an orders sheet, a template consist, etc
20:51:10 <Brianetta> I don't believe that vehicles currently have their own livery record
20:51:17 <Brianetta> unless it's changed recently
20:51:39 <andythenorth_> although colour map can be set by newgrf, so the structure is probably there
20:51:40 <Brianetta> and orders sheets are separate
20:52:02 <Brianetta> They can already be linked to a vehicle
20:52:22 <Brianetta> so that's trivial; link one to a group, and link it to each vehicle that joins
20:52:30 <Brianetta> and wipe the orders of any vehicle that leaves
20:52:49 <Brianetta> which is what shared orders does right now
20:53:31 <Brianetta> make the orders persist for as long as the group does
20:53:40 <Brianetta> *maybe* also for as long as the trains
20:53:52 <Brianetta> if you want complete compatibility with today's brain-dead system (:
20:54:12 <Brianetta> delete a group, and it reverts to shared orders
20:54:21 <andythenorth_> if I'm setting orders for a group, I can choose to use another group as the source of the orders?
20:54:28 <andythenorth_> or set the orders explicitly
20:54:45 <Brianetta> you might even be able to share the orders with another group; depends how pure we wan tthis
20:55:02 <andythenorth_> it would be cleaner to use another group
20:55:05 <Brianetta> Personally, I think that shouldn't be encouraged
20:55:15 <andythenorth_> or you end up with the shared order system, but just moved up to group level
20:55:55 <andythenorth_> so a train has orders
20:55:57 <Brianetta> In fact, if you wanted to just use that as a system (join adds shared orders, leave wipes them) then which ever group a vehicle joined last would define the orders
20:56:04 <Brianetta> erasing the ambiguity problem
20:56:40 <andythenorth_> talking implementation is dangerous, but whatever...
20:56:48 <Brianetta> although I do think that there should be a *strong* link between group membership and orders
20:56:49 <andythenorth_> a train has a pointer for orders
20:56:56 <andythenorth_> the pointer goes to a master vehicle, or a group
20:57:09 <andythenorth_> if a group, the group gets orders from a master vehicle, or another group
20:57:09 <Brianetta> which might be the same thing
20:57:34 <andythenorth_> if the group has a pointer to a group which recurses back to the first group, crash the game
20:57:34 <Brianetta> Are you talking nested groups?
20:57:43 <andythenorth_> forget hierarchy
20:57:56 <Brianetta> I'm not talking about hierarchy, just groups containing groups
20:58:18 <Brianetta> why would a group get its orders from another group?
20:58:39 <Brianetta> So two groups would share orders?
20:58:48 <andythenorth_> if a player wanted to
20:59:05 <Brianetta> You know what I'd prefer?
20:59:26 <Brianetta> One big group containing all the vehicles which need those orders.
21:00:03 <Brianetta> Shared orders has comprehension issues.
21:00:27 <Brianetta> It needs to be obvious which vehicles share orders, and why, and how that's controlled.
21:00:41 <Brianetta> Which, why and how should all be "because of the group"
21:02:04 <planetmaker> Brianetta: phrasing it that way, it's simply a matter of renaming 'shared orders' to 'group orders' and it's done
21:02:20 <Brianetta> planetmaker: Nope; there's no "obvious"
21:02:33 <CIA-2> OpenTTD: rubidium * r20980 /trunk/readme.txt: -Change: some tweaking of the readme about grfcodec/nforenum and linking to a more clear opengfx/opensfx/openmsx download page
21:02:59 <Brianetta> I've bulleted why it's not the same thing in the first section
21:03:26 * andythenorth_ knows that the pointers suggestion smells right, but doesn't know why
21:04:08 <andythenorth_> vehicle has pointer to master vehicle. Master vehicle may have orders, or a pointer to another master vehicle
21:04:26 * Brianetta doesn't care, as long as all that's hidden from the player behind a usable interface
21:04:53 <Brianetta> It doesn't have a pointer to another master vehicle
21:05:08 <Brianetta> otherwise, if you sell the right vehicle, the other trains lose thier orders
21:05:30 <andythenorth_> master vehicles aren't real ;)
21:05:30 <Brianetta> Since this demonstrably does not happen, we can assume they just have pointers to the same orders, somewhere in memory
21:05:56 <Brianetta> then there's no reason at all to complicate things be pointing them at each other
21:06:33 <andythenorth_> I think the issue comes somewhere else than orders
21:06:38 <andythenorth_> I'm not sure, let me think
21:06:52 <Brianetta> We just need a custom struct on a group
21:07:19 <Brianetta> which contains everything we want to happen to member vehicles, and to which some of their own properties can point
21:07:39 <andythenorth_> no there's a reason that won't work, I just can't find the words for it yet :D
21:07:43 <Brianetta> such as orders, service interval and livery
21:07:56 <Brianetta> whereas consist would be handled at the next visit to a depot, funds permitting
21:08:26 <Brianetta> and would only need a list of stock, not a complete instantiation of a vehicle.
21:12:34 <andythenorth_> Brianetta: I have vehicle group 1, with order set A. I have vehicle group 2, with order set B.
21:12:34 <andythenorth_> I want all vehicles in group 1 and group 2 to share livery.
21:12:43 <andythenorth_> I can set livery on group 1 and group 2 separately
21:12:51 <andythenorth_> I can put all vehicles in a new group manually
21:13:05 <andythenorth_> or I can point livery property of group 1 and group 2 at another group (group 3)
21:13:08 <andythenorth_> which is better?
21:17:45 <andythenorth_> Eddi|zuHause: any group could set a property explicitly, or choose to inherit it from another group?
21:18:13 <Brianetta> andythenorth_: Adding groups 1 and 2 to 3. This action should add the groups' members only.
21:18:58 <andythenorth_> does that merge groups 1 and 2?
21:19:05 <andythenorth_> i.e. are they removed?
21:19:15 <Brianetta> it copies their membership
21:19:50 <andythenorth_> if I add a new vehicle to group 1...
21:19:57 <andythenorth_> I have to also add it to group 3
21:20:38 <Brianetta> think of it like MP3 playlists
21:20:47 <Brianetta> you can add several lists, then save as a new list
21:20:51 <Brianetta> but there's no link created
21:21:38 <Brianetta> so, in your group editor, you can add new vehicles, and from the add windows, you can choose vehicles or groups
21:21:49 <Brianetta> from a group, you can add vehicles, or "all vehicles"
21:22:10 <andythenorth_> ...I clone a vehicle in group 1, and because the vehicle is also in group 3, it's added to both?
21:22:14 <andythenorth_> that seems sane
21:22:26 <Brianetta> group membership is a cloneable attribute
21:22:33 <andythenorth_> so cloning a vehicle also clones all of it's group memberships
21:22:47 <Brianetta> same as it does share orders right now
21:22:50 <andythenorth_> but building a new vehicle manually requires manual group work
21:22:59 <Brianetta> again, as it does now
21:23:23 <Brianetta> although joining the groups of another vehicle is an option to consider
21:23:51 <Brianetta> in reality, though, to how many groups will a single vehicle belong?
21:24:02 <Brianetta> It's not likely to be that difficult to manage as a one-off
21:24:04 <andythenorth_> depends on the imagination and other tendencies of the player
21:24:09 <Brianetta> especially since cloning is still an option
21:24:34 <andythenorth_> I prefer the logic of groups inheriting, but not the GUI for it
21:24:39 <Brianetta> groups as tag lists is a good analogy
21:24:53 <Brianetta> groups inheriting implied groups containing groups
21:25:08 <andythenorth_> groups containing pointers to other groups
21:25:16 <Brianetta> not necessarily as a hierarchy, but controls against being a member of a child group must be in place
21:25:30 <Brianetta> those pointers need to be absolutely clear to the player
21:25:43 <Brianetta> there should be no question whatever about what that relationship is, and how to change it
21:26:10 <Brianetta> If your group is a member of its child, which one's ultimately responsible for an attribute?
21:26:25 <Brianetta> bearing in mind that the child is now your parent
21:26:30 <andythenorth_> a group wouldn't have children
21:26:51 <Brianetta> They're defined as any groups which are members of a group
21:26:58 <andythenorth_> it would look like a tree per property, not per group
21:27:20 <Brianetta> The UI for that would be frightening
21:28:12 <andythenorth_> I probably wouldn't use it
21:28:16 <andythenorth_> but some people probably would
21:28:28 <andythenorth_> it addresses the 'rainbow routes' use case quite well
21:28:30 <Brianetta> Somebody will use any feature you add
21:28:48 <andythenorth_> group 1 defines orders A
21:28:54 <andythenorth_> group 2 defines orders B
21:28:59 <andythenorth_> group 3 defines only livery
21:29:13 <andythenorth_> group 1 and 2 have their livery set to 'inherit from group 3'
21:29:25 <Brianetta> sure; it's not an awful lot more complicated to use tag soup, though
21:29:38 <Brianetta> un-nested groups act just like tags
21:30:03 <andythenorth_> depends if you can have an arbitrary number of tags or not
21:30:48 <andythenorth_> un-nested groups ~= tags
21:30:59 <andythenorth_> are there ways in which they'd differ?
21:31:22 <Brianetta> My photo manager uses tags, and they manifest as groups
21:32:40 <andythenorth_> does it organise photos adequately?
21:33:21 <Brianetta> not really, but that's because it's a work in progress (Yorba Shotwell). I used to use F-Spot, which has the same tagging, but a better search interface. It's excellent, except for the random crashes.
21:33:40 <Brianetta> In another few weeks, it'll be ready.
21:35:02 <andythenorth_> groups inheriting is probably smarter for those that need it
21:35:16 <andythenorth_> neither of us is going to implement this right?
21:35:21 <Brianetta> as long as there's some check against circular references
21:35:38 <andythenorth_> I think circular pointers crash the game?
21:35:45 <andythenorth_> that sorts it out
21:35:50 <Brianetta> Yes. That's a Bad Thing.
21:36:03 <andythenorth_> otherwise yes, it's a tricky GUI problem
21:36:10 <andythenorth_> greying out one menu choice is easy
21:36:14 <Brianetta> I won't be implementing it, but that's because I don't contribute code to OpenTTD.
21:36:22 <andythenorth_> greying out lots according to the pointer chain is horrible
21:36:27 <andythenorth_> if even possible
21:36:42 <Brianetta> Creating a precedence integer could solve it, but it's unpredictable
21:36:49 <andythenorth_> if neither of us is going to implement, that's enough theory for one day :P
21:37:53 <CIA-2> OpenTTD: orudge * r20981 /trunk/src/lang/english.txt: -Fix: British English uses 'centre', not 'center'
21:40:01 *** last_evolution has quit IRC
21:51:31 *** fonsinchen has joined #openttd
22:03:19 <CIA-2> OpenTTD: orudge * r20982 /trunk/ (readme.txt src/lang/english.txt): -Change: Don't refer to OpenTTD as a "clone" any more
22:03:43 <SpComb> how long since orudge last commited?
22:05:14 <Rubidium> or did you mean the 9 months and 20 days gap
22:05:29 <SpComb> r20981 | orudge | 2010-10-18 00:37:27 +0300 (Mon, 18 Oct 2010) | 1 line
22:05:29 <SpComb> r18662 | orudge | 2009-12-30 04:23:10 +0200 (Wed, 30 Dec 2009) | 1 line
22:07:30 <Rubidium> wow... an ICU 4.4.2 release. They usually don't get any further than .1
22:08:10 <Rubidium> last x.y.2 was 2.6.2 in 2004
22:08:45 *** George|2 has joined #openttd
22:08:46 *** George is now known as Guest3097
22:08:46 *** George|2 is now known as George
22:08:50 <__ln__> orudge: you changed the text but not the id... does that mean other languages will not automatically get updated?
22:09:20 <Rubidium> maybe now ICU 4.4 compiles on Windows :)
22:14:14 <Yexo> __ln__: the string is marked in wt3 as "English string was changed"
22:15:59 <glx> there is "string needing validation" in dropdown :)
22:16:52 <orudge> SpComb: I tend to try to commit something at least once a year
22:17:48 <orudge> __ln__: I have no idea. Does the webtranslator not pick up that there's a difference and show it to the translators?
22:18:00 <SpComb> to the ttdpatch svn repo! Since I actually have commit access there!
22:18:52 <orudge> I have commit access there too, I do believe
22:19:01 <orudge> and if not, I host it, so that can be easily rectified
22:19:08 <orudge> not that I have anything to commit...
22:21:00 <Rubidium> orudge: the webtranslator has marked the changed strings as "needing validation", which are listed after the "untranslated" strings
22:22:12 <Rubidium> so in order of importance for showing first (the next is only chosen if the previous lists are empty): "untranslated", "needing validation", "all strings"
22:22:58 <Rubidium> oh, "needing validation" is actually the first in the order of importance
22:28:26 <CIA-2> OpenTTD: orudge * r20983 /extra/website/ (3 files in 2 dirs): [Website] -Change: Don't refer to OpenTTD as a clone
22:34:40 *** Roberto has joined #openttd
22:36:08 <Roberto> hi can any one help me?
22:37:50 <Roberto> i have a server running by adding -D onto the target sortcut.. thats all working fine people can join etc.. but when i do a console command e.g. "rcon password reset_client 6 it just says in blue the format ? it don't work i have tryed otherways but it just says error.
22:38:59 <glx> add quotes around the command
22:39:14 <glx> rcon password "command args"
22:40:00 <__ln__> glx: can i ask a question about the fullscreen mode on windows?
22:40:19 <glx> what's wrong with fullscreen ?
22:40:43 <xiong> Horses come in three colors!
22:41:29 <Yexo> Roberto: "don't work" is the most vague description you can give
22:41:46 <Yexo> what doesn't work? Do you get an error message (if so, copy-paste it here)?
22:41:52 <__ln__> glx: the fact that after I press alt-enter, i regret i just did that. the taskbar gets messed up because the screen's resolution shrinks to something ridiculously small. and color palette is messed up on the second screen.
22:42:05 <Yexo> if not, what did you try exactly and what did you expect to happen?
22:42:09 <glx> alt-enter is a standard shortcut on windows
22:42:26 <__ln__> glx: it's not the shortcut that bothers me :)
22:42:49 <glx> and fullscreen uses current resolution
22:42:54 <Yexo> __ln__: have you tried a 32bpp blitter?
22:43:08 <glx> if the window is 800*600, fullscreen will be 800*600
22:43:34 <__ln__> glx: does that make any sense in the era of LCD screens that have one native resolution?
22:44:01 <glx> it's not windows specific
22:44:29 <__ln__> (there's a patch for separating window and fullscreen solutions in FS, btw)
22:44:43 <Roberto> @ Yexo When i type = rcon password "reset_company 4" it says under it -remove an idle company from the game. usage:' reset_company <company-id>' in lught blue also has another line where to find the ID
22:45:13 <__ln__> glx: but could the fullscreen be implemented as a borderless window that is the size of the current screen?
22:46:07 <__ln__> GhostlyDeath: please read what i said in the first place.
22:46:17 <GhostlyDeath> __ln__: I just came from home from work
22:46:22 <Yexo> Roberto: there are only 2 blue lines? not a red line above those?
22:46:29 <GhostlyDeath> I do not know the time at which your question starts
22:47:03 <GhostlyDeath> OpenTTD uses SDL
22:47:08 <GhostlyDeath> You'd have to change SDL
22:47:26 <GhostlyDeath> Or change OpenTTD to use SDL differently
22:47:27 <Roberto> my command i put in "yellow" and 2 lines under it after i hit enter in "light blue" that is info? that don't even help lol
22:47:31 <__ln__> GhostlyDeath: no it doesn't on the relevant platform.
22:47:40 *** HerzogDeXtEr1 has joined #openttd
22:48:22 <GhostlyDeath> On which platform does it not use SDL?
22:49:03 <Yexo> Roberto: I can only reproduce that problem when not using any quotes at all
22:49:06 <GhostlyDeath> Why would OpenTTD not use SDL when SDL is cross-platform?
22:49:19 <GhostlyDeath> SDL works as it does on Linux, Windows, and Mac OS X
22:49:34 <GhostlyDeath> If OpenTTD doesn't use SDL for Windows then they should have a good reason
22:49:37 <__ln__> GhostlyDeath: "Why" is not my problem, but the fact is that it doesn't.
22:49:47 <GhostlyDeath> __ln__: What does it use on Windows then?
22:49:58 <__ln__> Although I know the "why" part too.
22:50:29 <__ln__> GhostlyDeath: Something Microsoftish, DirectSomething or whatever.
22:50:44 <GhostlyDeath> SDL can use Win32 directly and can use DirectDraw
22:51:06 <orudge> OpenTTD uses the Win32 GDI API directly on Windows
22:51:13 <orudge> it's generally a lot more efficient than going through SDL
22:51:18 <orudge> you have the choice of using SDL if you want, though
22:51:24 <xiong> I'm baffled. My new '4 Horse Hopper Carriage' will not go to a truck stop that catches a coal mine. The error is "Can't insert order... vehicle can't go to that station." Nor will it go to the steel mill, the iron ore mine, or even a bus stop.
22:51:54 <Yexo> you have an articulated road vehicle with a non-drive through road stop
22:52:33 <Yexo> easiest solution: build a drive through stop
22:52:53 <xiong> Oh damn. That's so blatantly obvious, Yexo. Thank you. By pure chance, I made all my bus stops ro-ros, which worked perfectly.
22:53:08 <GhostlyDeath> The screenshot in that bug report lacks red
22:53:13 <GhostlyDeath> No, it lacks green
22:53:49 <GhostlyDeath> Maybe SDL is giving the game a different color format instead of RGB
22:54:02 <glx> no SDL is broken that's all
22:54:15 <GhostlyDeath> SDL has some bugs
22:54:19 <xiong> I haven't worked an articulated vehicle yet. And I actually know something about backing up a horse carriage, too, in Real Life.
22:54:27 <GhostlyDeath> It would also depend on the version of SDL
22:54:33 <glx> and when you can use native API it's better
22:54:41 <xiong> "Dey is none so blind as dem who will not see."
22:54:42 <Eddi|zuHause> <__ln__> glx: but could the fullscreen be implemented as a borderless window that is the size of the current screen? <<-- i gzess a window without title bar is possible, but it would be overlapped by the task bar etc. but why bother and not just play windowed?
22:54:43 <GhostlyDeath> and then you'd have to tell the SDL team they got a bug that needs fixing
22:55:32 <GhostlyDeath> Also that resizing issue is an OpenTTD bug i'd say
22:55:32 <glx> when each new OSX version breaks working things
22:55:57 *** [twisti] has joined #openttd
22:55:58 <GhostlyDeath> I've gotten that before
22:56:06 <GhostlyDeath> But in a different area
22:56:14 <[twisti]> hi, why would a city station not accept goods ? what can i do to make it accept goods ?
22:56:28 <__ln__> Eddi|zuHause: we all know that apps such as VLC or Media Player can operate in a fullscreen mode which covers the task bar and everything, but still you can e.g. move the mouse cursor to another screen (so it is not a "real" fullscreen mode).
22:56:43 <GhostlyDeath> On Windows you can task switch regardless
22:56:57 <GhostlyDeath> But some programs lock the mouse which prevents moving around
22:57:24 <GhostlyDeath> If you set the video mode to 256 colors, the entire desktop is affected
22:57:26 <Yexo> [twisti]: a station only accept goods if enough industry tiles or houses in the neighbourhood accept goods
22:57:40 <GhostlyDeath> Hence the loss of color
22:57:42 <Yexo> so you need to place your station closer to the city center or in a bigger city
22:57:51 <[twisti]> it USED to accept goods
22:57:54 <[twisti]> it just suddenly stopped
22:58:04 <Eddi|zuHause> <GhostlyDeath> SDL works [...] on [...] Mac OS X <-- that's a blatant lie, i'm afraid
22:58:05 <Yexo> town buildings care sometimes removed by the game
22:58:07 <[twisti]> is there a way to make it go back ?
22:58:32 <Yexo> if there wer only one or two buildings that accepted goods and they were removed your goods acceptance is gone
22:58:50 <Yexo> you could wait for the game to randomly build a new building that accepts goods near your station or move your station
22:58:52 <[twisti]> can i somehow encourage the town to build more ... goods acceptors ?
22:59:04 <GhostlyDeath> fund local buildings maybe
22:59:07 <Yexo> no, but you can generally try to grow the town
22:59:10 <Eddi|zuHause> there is an osx port of sdl, but it doesn't actually work in any meaning of the word.
22:59:27 <[twisti]> how do i grow it other than shipping it passengers & mail from another town ?
22:59:27 <GhostlyDeath> Eddi|zuHause: I don't touch macs heh
22:59:29 <Yexo> which means: have 5 regurarly visited stations, fund local buildings every 3 months
22:59:44 <GhostlyDeath> It's not like SDL is closed source, you can submit bugs and hope they accept it
22:59:45 <Yexo> you don't actually have to ship passengers and mail
22:59:50 <[twisti]> i have like 6 stations total
23:00:08 <GhostlyDeath> SDL_mixer is just broken completely though heh
23:00:10 <Eddi|zuHause> GhostlyDeath: ok, please do that then.
23:00:20 <GhostlyDeath> Eddi|zuHause: Buy me a Mac and I will fix the bugs
23:00:35 <xiong> Unrelated to the orders issue: I see that my new freight carriage shows, in depot, only the horses, not the wagon itself. The wagon, together with its horses, shows properly in the all-vehicles list and on the road itself. Bug or feature?
23:00:47 <Eddi|zuHause> how stupid do you think i am?
23:01:02 <GhostlyDeath> You want me to fix a bug but I don't have the correct hardware to do such things
23:01:27 <__ln__> GhostlyDeath: a talented guy like you does it by looking at the code, without using hardware.
23:01:36 <GhostlyDeath> __ln__: How do you test it?
23:01:50 <GhostlyDeath> Shipping the code off to someone else is unreliable, trust me
23:02:06 <GhostlyDeath> There is VNC but it is inconvenient
23:02:13 <Eddi|zuHause> GhostlyDeath: don't you think we asked that exact same questions when we deprecated the mac port?
23:02:28 <[twisti]> Yexo: do i understand that page correctly that less than 5 stations still work, just not as fast as 5 ?
23:02:33 <GhostlyDeath> You could also drop SDL and make your own replacement
23:02:42 <__ln__> lol, VNC is the perfect solution for debugging palette issues
23:03:11 <GhostlyDeath> When I ported my own program to Mac OS X, I VNCed and SSHed into his system to get it done, was very nice
23:03:12 <Eddi|zuHause> GhostlyDeath: we had a replacement, it was called cocoa, and then apple deprecated that one.
23:03:20 <[twisti]> also, would it be a good idea in general to demolish some buildings in the center of a town to build a super busy station there and then wait for the town to grow around it ?
23:03:28 <GhostlyDeath> Eddi|zuHause: wasn't cocoa their super duper UI?
23:03:37 <Rubidium> and then we deprecated the whole OS X port
23:03:45 <GhostlyDeath> What replaced cocoa then?
23:03:50 <__ln__> Eddi|zuHause: apple certainly didn't deprecate cocoa. some other api probably. quickdraw.
23:03:57 <Rubidium> following in the footsteps of Steve
23:03:58 <GhostlyDeath> When was this deprecation anyway?
23:04:29 <GhostlyDeath> First google of "Mac cocoa deprecated" says the Cocoa-Java API
23:04:38 <Eddi|zuHause> __ln__: i only heard stuff third hand, but the parts of the API we used threw lots of deprecation warnings
23:05:23 <Eddi|zuHause> maybe it was only the 8bpp parts or something
23:05:29 <Eddi|zuHause> i really have no idea
23:05:43 <__ln__> Eddi|zuHause: no doubt about that, but i think it was the parts that were not using cocoa.
23:05:45 <Rubidium> if only they did deprecate 8bpp
23:05:46 <orudge> 8-bit has been deprecated in Snow Leopard, basically
23:06:04 <GhostlyDeath> Unless you recompile it and see what it says
23:06:17 <GhostlyDeath> It's not uncommon that everything is deprecated
23:06:21 <GhostlyDeath> just look at what MS did
23:06:35 <Rubidium> it depends on some combination of iDunno and iSomething
23:06:37 <orudge> GhostlyDeath: hmm? Microsoft generally maintains excellent backwards compatibility
23:06:50 <orudge> indeed, it's one of the reasons the various Windows APIs are such a mess :p
23:07:13 <GhostlyDeath> hehehe, like that PDF orudge
23:07:26 <GhostlyDeath> orudge: I was referring to the deprecation of the C library
23:07:35 <GhostlyDeath> orudge: It's a paper on about how they maintained compatibility with programs
23:07:36 <__ln__> Eddi|zuHause: QuickDraw is something that has existed in MacOS Classic since forever, according to the internet.
23:07:40 <orudge> ah, you mean the "insecure" functions and so on?
23:07:56 <GhostlyDeath> They fixed a bug and the program and it crashed since it relied on a bug or did something wrong completely
23:08:01 <GhostlyDeath> and yes I do mean that
23:08:18 <orudge> [18:07:56] <GhostlyDeath> They fixed a bug and the program and it crashed since it relied on a bug or did something wrong completely <-- yep
23:08:23 <orudge> there's a lot of that in Windows
23:08:31 <GhostlyDeath> That's why it's so buggy
23:08:32 <orudge> I work on Wine, and we generally aim for Wine to be "bug-compatible" with Windows
23:08:41 <orudge> even if something is wrong, we have to implement the same hacks Microsoft did
23:08:44 <orudge> at least, in some cases
23:08:44 <GhostlyDeath> orudge: How's Win64 coming along?
23:08:51 <orudge> Reasonably well at the moment
23:08:56 <Rubidium> in that case, deprecate in Windows means: "please don't use it, but it will still work", in OS X it means: "please don't use it as it will definitely not work some time soon"
23:08:57 <orudge> Wine 1.2 supports 64-bit
23:09:28 <orudge> I'm not quite sure what mingw-w64 has to do with it as such
23:09:38 <orudge> but you can build a 64-bit and a 32-bit version of Wine on a 64-bit Linux
23:09:41 <GhostlyDeath> It's the only GCC that I know of
23:09:48 <orudge> and run both 64-bit and 32-bit applications in the same Wine environment
23:09:59 <orudge> 64-bit isn't especially well tested just now though
23:10:06 <GhostlyDeath> I got a bunch of 64-bit systems
23:10:07 <glx> mingw-64 is not stable yet
23:10:08 <orudge> and there will no doubt be issues
23:10:17 <GhostlyDeath> glx: mingw64 works pretty good but there are bugs
23:10:30 <GhostlyDeath> But it's not like they'd ignore your bug report
23:11:00 <GhostlyDeath> I assist in their efforts, although slightly
23:11:08 <Eddi|zuHause> i can't download mods in civ5 under wine...
23:11:43 <Eddi|zuHause> says some "BITS" [or so] service wasn't running
23:12:01 <GhostlyDeath> ReactOS is nice though, despite it's youngness
23:12:12 <glx> BITS is used by windows update
23:12:16 <orudge> that's a Microsoft service
23:12:21 <orudge> which isn't implemented in Wine
23:12:44 <Eddi|zuHause> orudge: but "net start bits" says some stuff about starting and running
23:12:48 <GhostlyDeath> I have yet to try WINE 1.2 though
23:12:51 <glx> background transfer service or something like that
23:12:54 <orudge> it isn't fully implemented
23:13:09 <Eddi|zuHause> then it needs more implementing ;)
23:13:12 <Rubidium> glx: apparantly it's intelligent as well
23:13:17 <Eddi|zuHause> IT'S URGENT!!!11!einself
23:13:28 <GhostlyDeath> When I can run MSVC++ 9 in WINE, i'll be happy
23:13:38 <orudge> GhostlyDeath: the compiler (should) work
23:13:48 <orudge> you can install it via winetricks
23:13:59 <Eddi|zuHause> orudge: i also can't install MSVC 2010 stuff necessary for the civ5 sdk!
23:14:01 <GhostlyDeath> I like to avoid winetricks, it's very tricky
23:14:10 <orudge> well, install it by hand
23:14:19 <orudge> Eddi|zuHause: shocking
23:14:23 <GhostlyDeath> Plus sXs is kinda messy
23:14:24 <glx> Eddi|zuHause: civ5 is too recent ;)
23:14:32 <orudge> Civ5 in general works reasonably well under CrossOver
23:14:36 <orudge> it works fine on Snow Leopard though
23:14:47 <glx> and a bad idea, your time will disappear
23:14:56 <Eddi|zuHause> yes, civ5 itself works
23:15:04 <GhostlyDeath> But he wants to hack it
23:15:17 <GhostlyDeath> make his own game and sell it only to be sued by it's creators who want all the money he earned from it
23:15:30 <CIA-2> OpenTTD: orudge * r20984 /extra/website/account/templates/account/ (13 files): [website] -Change: Assorted spelling/grammar changes and rewordings
23:15:37 <GhostlyDeath> Which will then hire him at a low wage where he will work on the game outside of what he originally intended
23:15:43 <Eddi|zuHause> i'm hoping they release the civ5 patch soon-ish
23:15:54 <GhostlyDeath> and will be unhappy with the game, leave and start his own company
23:15:55 <CIA-2> OpenTTD: orudge * r20985 /extra/website/bananas/templates/bananas/ (index.html notAvailableYet.html tosInner.html): [website] -Change: Assorted spelling/grammar changes and rewordings
23:15:57 <Eddi|zuHause> has some important initial issues...
23:16:22 <CIA-2> OpenTTD: orudge * r20986 /extra/website/frontpage/templates/frontpage/ (about.html development.html download.html links.html): [website] -Change: Assorted spelling/grammar changes and rewordings
23:16:39 <GhostlyDeath> orudge: Win64 is not that different from Win32 though
23:16:45 <GhostlyDeath> just some types and pointer size
23:16:52 <orudge> compared to Win16 -> Win32, they're practically the same
23:16:59 <GhostlyDeath> Win32 is not Win16 heh
23:17:07 <GhostlyDeath> Win32 was a major overhaul
23:17:09 <__ln__> should we have a parallel channel called #openttd-sdl-fanatics to which the discussion about using SDL on all platforms could be conveniently redirected?
23:17:10 <orudge> that's what I'm saying
23:17:26 <GhostlyDeath> There's no open source Win16 compilers I know of
23:17:30 <GhostlyDeath> except for maybe Watcom
23:17:30 <orudge> GhostlyDeath: Open Watcom
23:17:38 <GhostlyDeath> I havn't got any Win16 systems though
23:17:43 <GhostlyDeath> I'm gonna port OpenTTD to Win16
23:17:46 <orudge> there are also closed source compilers that have been released for free
23:17:52 <orudge> such as old versions of Borland
23:17:57 <Eddi|zuHause> __ln__: i don't see any such discussion ;)
23:18:00 <GhostlyDeath> Borland's compiler are hard to get
23:18:11 * orudge still has some Windows 3.x VMs floating around
23:18:11 <GhostlyDeath> You used to be able to get them but then someone bought them out afaik
23:18:28 <GhostlyDeath> I tried downloading one and I had difficulty getting it sometime ago
23:18:30 <Eddi|zuHause> i have delphi 2 on some diskettes lying around
23:19:52 <Eddi|zuHause> i used to have delphi 6 also
23:20:02 <Eddi|zuHause> but i have no idea where
23:20:08 <[twisti]> i learned programming with pascal
23:20:09 <GhostlyDeath> I got an educational version of MSVC6
23:20:12 <Eddi|zuHause> hm... a kernel update...
23:20:13 <glx> I still have Turbo Pascal 6 somewhere
23:20:19 <xiong> [twisti] Disclaimer: I'm new at this and don't know much. But so far, what I've seen is that tiles central to a city fill in very solidly, very quickly. So demolishing an interior building will not have long-term consequence. But chances are, interior tiles will contain superior buildings, which you will find expensive to demolish and besides, you will lose all that pop.
23:20:26 <orudge> I have rather a lot of old compilers and the like lurking around
23:20:27 <Eddi|zuHause> i'm pretty sure that's a bad idea right now...
23:20:32 <[twisti]> and then i got my first borland turbo pascal 6.0 compiler/ide and was like "omgomgomg"
23:20:42 <GhostlyDeath> I collect old compilers
23:20:43 <orudge> plus MSDN carried many ancient versions of MSVC, etc
23:20:46 <orudge> although they've mostly been removed now
23:20:58 <GhostlyDeath> I started programming in C with a Turbo C++
23:21:10 <GhostlyDeath> A friend gave me it................
23:21:17 <[twisti]> yay, my city accepts goods again! (just after i built a second station + tracks ofc)
23:21:22 <GhostlyDeath> orudge: They got old versions of Windows still
23:21:26 <glx> like the references to pre-2000 in API docs
23:21:30 <GhostlyDeath> but you gotta pay a hefty subscription free
23:21:42 <Eddi|zuHause> i started programming with a dbase 3 clone called foxbase+
23:21:48 <GhostlyDeath> I got the SDK just before they deprecated Windows 98
23:21:50 <Eddi|zuHause> and later switched to borland pascal 7
23:21:53 <xiong> [twisti] I find very useful to build a ro-ro bus stop as close to the town center (the town name sign) as possible, which is cheap and non-obtrusive. Then a rail station can be built on the outskirts and connected to the ro-ro bus.
23:21:55 <orudge> GhostlyDeath: I've managed to acquire pretty much every version of Windows over the years anyway
23:21:57 <__ln__> glx: since you are listed also as "General Coding"; does it make sense on any platform to try fullscreen at the same resolution as the window is? typically the window is smaller than the screen, otherwise it wouldn't fit on it.
23:21:59 <GhostlyDeath> Because after that point, they all say Supported in "Windows 2000"
23:22:04 * orudge still has Windows 3.0 and 3.1 on floppies
23:22:13 * GhostlyDeath still has Windows 98 SE running on PCs
23:22:18 <orudge> yes, that is a little bit annoying
23:22:21 <[twisti]> xiong: ro-ro ? and how do you connect a rail station to a bus station ?
23:22:32 <orudge> Watcom 10.6 came with a nice win32.hlp
23:22:35 <GhostlyDeath> So even though I support a 12 year old OS...
23:22:39 <orudge> being a rather huge file containing the Win32 SDK of the time
23:23:06 <GhostlyDeath> plus the documentation of the PSDK 2003 R2 is nice
23:23:12 <xiong> [twisti] A through station, one of the two to the right in the GUI, as opposed to one of the four dead-end stations, is a ro-ro -- roll in, roll out.
23:23:26 *** Keiya_ is now known as Keiya
23:23:35 <[twisti]> ah, yeah, i use those most of the time, just didnt know that term
23:23:35 <xiong> You can build a ro-ro bus or truck stop on a town road without demolishing anything.
23:23:48 <Eddi|zuHause> [twisti]: you connect two stations by building them adjacent or using the ctrl key
23:24:01 <GhostlyDeath> Why would you want to ever join stations?
23:24:21 <GhostlyDeath> 1 station is all you'll ever need
23:24:25 <[twisti]> i still dont get how i would build a train station on the outskirts and then connect it to a bus station on the inside
23:24:29 <Eddi|zuHause> GhostlyDeath: have you ever played the game?
23:24:34 <GhostlyDeath> Eddi|zuHause: yes I have
23:24:39 <xiong> There are good reasons to use the dead-end stops, though, [twisti]. Depending on your road layout, it can take a long time for a bus to turn around -- it will not turn around right inside the ro-ro.
23:24:41 <glx> __ln__: feel free to open a bug report/feature request about it
23:24:51 <GhostlyDeath> The non-dead end stops are bad I say
23:24:58 <GhostlyDeath> Because every single truck stops at it
23:25:01 <GhostlyDeath> and causes traffic jams
23:25:15 <[twisti]> GhostlyDeath: you can turn that off
23:25:15 <xiong> GhostlyDeath, use 'Non-stop'.
23:25:16 <Eddi|zuHause> [twisti]: look up "feeder service" in the wiki
23:25:41 <GhostlyDeath> Would that prevent trucks from stopping even if they have no load there
23:25:50 <xiong> [twisti] Are you asking from a prototype viewpoint or from a game mechanics viewpoint?
23:26:07 <xiong> Yes, GhostlyDeath; non-stop means they don't stop.
23:26:08 <[twisti]> i dont know what you mean by that
23:26:12 <[twisti]> im just playing the game
23:26:23 <[twisti]> trying to understand how things work
23:26:31 <GhostlyDeath> Buses at bus stops that aren't dead ends when loading should pull off to the side
23:26:40 <xiong> [twisti] Real trains, trucks, houses, and roads are 'prototypes'. The game is a model of the prototype.
23:27:10 <xiong> There is a prototype consideration and a mechanics consideration. Your question might be interpreted either way.
23:27:10 <[twisti]> then im asking game mechanics lol
23:27:13 <GhostlyDeath> At least in my version, buses loading from non dead end stops block traffic for awhile
23:27:22 <[twisti]> i dont care how it works irl
23:28:03 <GhostlyDeath> When the year reaches 2200s, transporter technology should become available
23:28:10 <GhostlyDeath> to instantly transport goods from one end of the map to another
23:28:17 <CIA-2> OpenTTD: rubidium * r20987 /extra/website/ (6 files in 4 dirs): [Website] -Fix: assortment of small fixes/updates that were already "live" but not committed, e.g. support for newer versions of OpenTTD in BaNaNaS, base graphics set upload fix, etc
23:28:38 <GhostlyDeath> And in 1994, a technology in the shape of the ring that creates a wormhole to another ring should be available also
23:28:38 <Eddi|zuHause> GhostlyDeath: the game already has instantaneous transportation
23:28:41 <xiong> [twisti] Then, assuming you have enabled such in Advanced Settings, just hold down Ctrl key when placing a new station, of any kind. You will not immediately place the station but instead see a menu of choices. Click on an existing station and your new station will become part of the existing station, logically, as if the two had been built adjacent.
23:28:56 <GhostlyDeath> Eddi|zuHause: Which is that? I havn't found any so far
23:29:11 <[twisti]> oh btw, i found a solution to my problem with spacing out multile trains on the same tracks without complicated signal magic or the time table thing - just have a long area of your track without signals, and if two trains clump, the 2nd one will have to wait there for the first to clear the whole stretch
23:29:13 <Eddi|zuHause> i'm not going to tell you, then. :p
23:29:30 <GhostlyDeath> Eddi|zuHause: Why not?
23:29:41 <glx> Eddi|zuHause: station walking ?
23:29:44 <Eddi|zuHause> because i'm sinister.
23:29:56 <Rubidium> those rings are called tunnels in-game, but are in fact wormholes
23:29:59 <Eddi|zuHause> glx: well, "walking" isn't really part of it anymore ;)
23:29:59 <GhostlyDeath> Stations supplying and demanding it's own goods
23:30:16 <GhostlyDeath> i.e. woods next to a sawmill
23:30:24 <GhostlyDeath> single station wanting wood, another giving wood
23:30:31 <xiong> [twisti] You will find that several hours' investment of time studying Advanced Settings will pay off. It's really that complex. OpenTTD, compared to say, RRT2 or SC2K, is about 8 times more complex, perhaps 32, if one could be that precise.
23:30:58 <glx> no you'll still need to transport stuff from source to dest for it to be accepted
23:31:09 <GhostlyDeath> glx: Even to itself?
23:31:11 <[twisti]> because its actually really hard
23:31:18 <[twisti]> unless you fast forward to millions
23:31:22 <GhostlyDeath> You can just have a bunch of dead end stops next to each other heh
23:31:37 <GhostlyDeath> I had trucks drive 1 tile to transport stuff
23:31:45 <[twisti]> shame they never made sc4 work right in win7
23:31:56 <Eddi|zuHause> sc4 is only hard if you start to borrow money
23:32:24 <GhostlyDeath> heh SC as SimCity, thought you meant Starcraft
23:32:24 <Eddi|zuHause> sc or sc2k were much harder in that respect...
23:32:58 <Eddi|zuHause> GhostlyDeath: you have your associative dissonnance backwards :p
23:33:02 <[twisti]> sc4 is pretty hard if you play at sensible speeds
23:33:16 <[twisti]> because its basically designed to break even at all but easy/lowest density
23:33:18 <glx> IIRC windows included some bugfixes/special handling for simcity
23:33:25 <xiong> Note that it is extremely useful to increase station spread. According to Eddi|zuHause, you may safely ignore the dire warning about large station spread slowing down the game. I can say I've doubled it, to 24, without ill mechanical effect. However, large spread quickly becomes unrealistic. I've reduced mine to 18.
23:33:48 <[twisti]> glx: its gone with 7 - it just breaks sc4 now (but not for everyone), its listed as unsupported too
23:34:02 <GhostlyDeath> I want a station spread of 2048
23:34:11 <Rubidium> simcity != simcity 4
23:34:17 <xiong> SC2K sucked, IMO, largely because of the crummy traffic generator.
23:34:34 <xiong> RRT2 sucked in so many ways, I'm not at liberty to say.
23:35:07 <[twisti]> i liked sc2k but it got boring quickly because once you figured out what made money, youd just repeat that until the map was full
23:35:18 <xiong> But I will admit that I spent many hundreds of hours on both. I have a real fear that the entire remainder of my time on Earth is going to fall into OpenTTD.
23:35:25 <Eddi|zuHause> i played so many hours of sc2k...
23:35:59 <Eddi|zuHause> but once you built those mega-thingies, there was hardly any sense to it anymore
23:36:09 <xiong> I think it is fair to say that OTTD encompasses all of SC and RRT. plus much more. That's scary.
23:36:15 <Rubidium> we're actually talking about simcity (1) and a special mode for Windows' memory allocator to make it run SimCity properly
23:36:22 <glx> [twisti]: usually if something fails in a new version of windows, it's because it was badly coded
23:36:48 <GhostlyDeath> Or they tried fixing a bug
23:36:52 <[twisti]> glx: while that is entirely possible, it still pisses me off that one of my top5 games doesnt run on my new awesome rig
23:36:56 <Eddi|zuHause> glx: you can assume that >95% of proprietary software is badly coded ;)
23:37:05 <GhostlyDeath> Eddi|zuHause: Except code that I write
23:37:17 <xiong> Arcologies. I have twice built enough arcos to launch and start over. I cannot tell you why, the second time around. It's exceedingly boring and requires that almost half the board be covered in identical arcos.
23:37:26 <ccfreak2k> Mostly because 95% of programmers either have no business programming or are cramming for deadlines.
23:37:35 <GhostlyDeath> or they don't know
23:37:47 <xiong> You can now play SC1 online. FWIW.
23:37:48 * Rubidium guesses he has primarily seen the former category
23:38:03 <Rubidium> otherwise you're not going to manually "unfold" a loop
23:38:03 <[twisti]> ccfreak2k: i offer a different reason
23:38:03 <GhostlyDeath> Some programmers are not programmers
23:38:04 <ccfreak2k> There's also the ones in that 5% that cram for deadlines but make it work anyway.
23:38:29 <[twisti]> the fun in programming is, for most people, learning new things and figuring out new things
23:38:48 <[twisti]> spending 40 hours a day repeating things you already know well is extremely boring to most programmers i know
23:39:02 <xiong> Oh, speaking of making money... I gotta go. [twisti], it's very hard to be newer here than I am but you may be the guy. Feel free to ask me very new questions when I'm on.
23:39:05 <GhostlyDeath> Alot of them get hit by the logic
23:39:08 <[twisti]> hence programmers tend to do things they dont understand well, because they are more exciting than doing things they know work
23:39:11 <ccfreak2k> That's pretty much their fault for taking up programming as a profession.
23:39:31 <GhostlyDeath> And logic loves me
23:39:49 <glx> logic is vital when programming
23:39:49 <[twisti]> so thats why most programs contain bad code
23:40:02 <Rubidium> yeah, I particularly like triggering bugs in compilers
23:40:21 <[twisti]> im very proud to have actually FOUND one in my whole life :|
23:40:23 <GhostlyDeath> Triggering compiler bugs are nasty
23:40:24 <glx> dune2 is full of weirdness :)
23:40:39 <GhostlyDeath> Because then you have to go around the bug just to get it working
23:41:12 <[twisti]> GhostlyDeath: opposite for me - i had to go around the bugfix
23:41:23 <GhostlyDeath> [twisti]: what was the bug?
23:41:46 <GhostlyDeath> On a certain line of code I wrote, something very simple, GCC exploded and said "Internal compiler error"
23:41:54 <[twisti]> class loader in java ... i want to say 1.4, but it was a long time ago
23:41:54 <GhostlyDeath> Other code did the same thing for MSVC also
23:42:08 <GhostlyDeath> and depreciated, nobody loves it anymore
23:42:14 <[twisti]> the bug was, custom class loaders would come precached with the classes from the default CL
23:42:30 <[twisti]> so what people would do was just make custom CLs and use them for everything
23:42:35 <[twisti]> and then in 1.5 i think it was fixed
23:42:42 <Rubidium> and currently OpenTTD's trunk triggers an internal error in ICC
23:42:45 <[twisti]> and suddenly the custom CLs could ONLY do their custom stuff
23:42:57 <[twisti]> and not load normal, java core classes anymore
23:43:19 <[twisti]> and lots of things using the old buggy CLs stopped working
23:43:25 <GhostlyDeath> alot of people I met hated me because I dynamically used Java
23:43:30 <GhostlyDeath> They said Java was static
23:43:35 <[twisti]> with helpful exceptions like "Can't find a class definition for String"
23:43:50 <GhostlyDeath> If your java implementation lacks String...
23:44:09 <[twisti]> i JUST described why it said that
23:44:19 <GhostlyDeath> But they got their own class loaders now
23:44:34 <[twisti]> right, which USED to be able to load all the default stuff
23:44:57 <[twisti]> or rather inherited them, i think
23:45:02 <GhostlyDeath> But they shouldn't have been using custom loaders anyway despite it being broken
23:45:06 *** Xaroth_ has joined #openttd
23:45:23 <GhostlyDeath> It would break later on of course, always happens
23:45:50 <GhostlyDeath> [twisti]: How about this
23:45:51 <[twisti]> well, fair enough, but its an odd problem that isnt really apparent if you dont know about the bug
23:46:11 <GhostlyDeath> Obtaining a list of functions for dynamic usage based on existence in a class
23:46:31 <GhostlyDeath> I made some code that would look in a class' declared functions and add it to a list based on an index in it's name
23:46:44 <GhostlyDeath> It was an emulator
23:46:58 <GhostlyDeath> Functions were named after their opcode ID, OpCode_12 for example
23:47:18 <GhostlyDeath> The reflection handler would then find the function named OpCode_12 and place it in the 12th spot
23:47:33 <GhostlyDeath> Then once that opcode was struck it called the function
23:47:58 <[twisti]> sounds relatively reasonable
23:48:13 <GhostlyDeath> It works as it should in Java
23:48:37 <GhostlyDeath> It worked out great
23:48:38 <[twisti]> i always tried to avoid reflection, always seemed hacky and shoddy
23:48:56 <[twisti]> but in all fairness thats probably because most people who use reflection abuse it
23:49:04 <GhostlyDeath> Alot of Java people i've met in life hate reflection
23:49:09 <[twisti]> because they dont understand the language and how to do what they want to do correctly
23:49:09 <GhostlyDeath> and hate you if you use it
23:49:21 <GhostlyDeath> But I did Java for awhile
23:49:31 <GhostlyDeath> and I read all the docs to see what should happen before I didit
23:49:38 <GhostlyDeath> did some single test programs
23:49:50 <[twisti]> i love java, as long as you exclude swing
23:49:56 <Eddi|zuHause> if you want a dynamic language like that, why not use python or something?
23:49:59 <GhostlyDeath> heh... swing...................
23:50:09 <GhostlyDeath> It does do what it does
23:50:22 <GhostlyDeath> Java is meant to do that
23:50:32 <[twisti]> swing has gotten fairly usable over the years, but gods, it used to be SO incredibly bad
23:50:43 <GhostlyDeath> Doesn't work in GCJ though
23:51:05 <[twisti]> its still pretty terrible in parts
23:51:10 *** Xaroth__ has joined #openttd
23:51:12 <Eddi|zuHause> "X does Y", "X is meant to do Y", "X is designed to do Y" and "X is best suited to do Y" are fundamently different propositions
23:51:14 <GhostlyDeath> It reminded me of things
23:51:53 <[twisti]> you shouldnt have to write custom renderers just to get a behaviour considered the default by multiple major operating systems
23:51:59 <GhostlyDeath> [twisti]: Just beware, some say Reflection is not possible in Java
23:52:33 <[twisti]> but its generally just silly to claim anything in programming languages impossible
23:52:34 <GhostlyDeath> The best thing to say to them is "What about the class loader?"
23:52:37 <Rubidium> fills that with X:="Rubidium", Y:="sleep now". Won't hold now, but should pretty soon
23:52:56 <ccfreak2k> Rubidium is best suited to do sleep now?
23:52:57 <GhostlyDeath> Rubidium: X inherits off Y, Y is an implementation of X
23:52:59 <[twisti]> Rubidium is designed and best suited to sleeping now ?
23:53:28 <GhostlyDeath> Rubidium inherits off Sleep, Sleep is an implementation of Rubidium
23:53:48 <[twisti]> speaking off "impossible", did you guys see that guy who built a APU in that lego like computer game ?
23:53:56 <[twisti]> thats just ridiculous
23:54:18 <GhostlyDeath> provided there is core logic you can do anything really
23:54:24 <ccfreak2k> Switched over at the right moment to see my Mesa build fail.
23:54:37 <Eddi|zuHause> [twisti]: did you see the guys who implemented counters and cpus in openttd?
23:54:49 <[twisti]> probably about the same idea eddi
23:54:49 <GhostlyDeath> People made counters in Boom (Doom)
23:54:52 <ccfreak2k> [twisti], you're probably talking about Minecraft.
23:56:02 <Eddi|zuHause> well, at least minecraft has builtin "wires" and "switches"
23:56:16 <GhostlyDeath> You can do it in OpenTTD
23:57:00 <Eddi|zuHause> GhostlyDeath: but usually these things require the NAND signal patch, not a clean trunk
23:57:43 <GhostlyDeath> Implement your own NAND
23:57:46 <Eddi|zuHause> GhostlyDeath: you have a hard time building a NOT gate without those
23:58:03 <GhostlyDeath> Then after that's done
23:58:09 <GhostlyDeath> Make a CPU and a compiler in OpenTTD
23:58:13 <GhostlyDeath> and run OpenTTD in OpenTTD
23:58:17 <Eddi|zuHause> if it's possible at all, it needs ridiculous amounts of space
23:58:42 <GhostlyDeath> Buses for memory storage
23:59:04 <GhostlyDeath> Someone will figure it out
23:59:46 <ccfreak2k> Bus with one passenger capacity.
23:59:52 <GhostlyDeath> Trap buses in dead end areas?
23:59:55 <ccfreak2k> The loading of a passenger indicates the presence of a charge.
continue to next day ⏵
