21:33 <@Hellfire667> Let's start then. From now on, comments are made according to http://tt2.sourceforge.net/wiki/index.php/Meeting_Rules ==> End your monologues with ~, Type -> if you have comments and <- to cancel the ->.
21:33 <+Steve^> ->
21:33 <@Hellfire667> Today's agenda: http://www.tt-forums.net//files/agenda_130205_302.pdf ~
21:33 <@Hellfire667> Steve, go ahead.~
21:33 <@Metalcore> ->
21:33 <+Steve^> Who's a chair? Can i be a table?
21:34 <+Steve^> ~
21:34 <@Hellfire667> I'll be the chair. We don't need tables :P. ~
21:34 <@Hellfire667> Evan?
21:34 <@Hellfire667> ~
21:34 <@Metalcore> and don't forget ! for an important comment~
21:34 <+Steve^> Umm, the pdf isn't working for me ~
21:34 <@Hellfire667> GGV?~
21:34 <+Steve^> Nevermind ~
21:35 <@Hellfire667> Who will make minutes tonight? ~
21:36 < Zuu> I made them last meeting.~
21:36 <@Hellfire667> Steve, could you make them? ~
21:37 <+Steve^> I could... ~
21:37 <@Hellfire667> Will you please make them for this meeting? Or do you have a good reason not to? ~
21:38 <+Steve^> Sadly i do not ~
21:40 <@Hellfire667> Ok then. Minute maker for tonight: Steve. (Now I know why Hyr likes to boss people around.) ~
21:40 <+Steve^> Sir, yes Sir!
21:40 <+Steve^> ~
21:40 <@Hellfire667> Now then, Metalcore's favourite part: Roll call!. ~
21:40 <@Hellfire667> orudge? ~
21:40 <@Metalcore> wee!~
21:40 <@Hellfire667> Steve is here. ~
21:40 <@Hellfire667> jfs? ~
21:41 <+Steve^> Aye Cap'n ~
21:41 <@orudge> Hellfire667: Here
21:41 <@orudge> ~
21:41 <@Hellfire667> jpl? ~
21:41 <@Hellfire667> Mek? ~
21:41 <@Hellfire667> MontiMcMannus? ~
21:41 < MontiMcMannus> Iam here... ~
21:41 <@Hellfire667> Prof_Frink? ~
21:42 < Prof_Frink> what?
21:42 <@Hellfire667> Will you join the meeting or just "lurk around"? ~
21:42 < MontiMcMannus> Are we allowed to do both?~
21:42 <@Hellfire667> Sure. ~
21:42 <@Hellfire667> uzurpator? ~
21:42 <@Metalcore> that's what I do.~
21:42  * Prof_Frink is a lurker
21:43 <@Hellfire667> Zuu is here... Until his ADSL fails... ;) ~
21:43 < Zuu> :P
21:43 <@Hellfire667> Before we start continuing on the FRD, I'd like to welcome MontiMcMannus.
21:44 <+Steve^> Hi Monti!~
21:44 <@Bot425> Don't forget me, I'm here!~
21:44 <@Metalcore> howdy monti.
21:44 < Zuu> Hi
21:44 <@Metalcore> ~
21:44 < Zuu> ~
21:44 < MontiMcMannus> hi~
21:44 <@Hellfire667> Monti, what is your point of view to the project? ~
21:45 -!- ChrisCF [~chris@cpc2-cdif4-5-0-cust139.cdif.cable.ntl.com] has joined #tempire
21:45 -!- mode/#tempire [+o ChrisCF] by L
21:45 < MontiMcMannus> Just looking, and thinking about how long it will take to fix all of your requirements.~
21:46 <@Hellfire667> "Fix?" Fix them so your engine will match tem? Or just fix the requirements themselfs? ~
21:46 < MontiMcMannus> Themself. And wondering, which of the requirements will survive the first lines of coding :-)=)~
21:46 < uzurpator> Greetz - I'm back
21:47 <@Hellfire667> Do you know at which point of development we are? And what our plans are?~
21:47 <+Steve^> ->
21:47 <@Hellfire667> Go ahead, Steve. ~
21:47 <+Steve^> Do i include this in the minutes? ~
21:48 < Zuu> ->
21:48 <@Hellfire667> Just a summary. ~
21:48 <@Hellfire667> Zuu?~
21:48 < Zuu> I would say no.~
21:48 < jpl> here
21:48 < MontiMcMannus> Yes, at fixing the requirements. And developing some mini examples for different requirements.~
21:48 -!- mode/#tempire [+v jpl] by L
21:49 <@Metalcore> ->
21:49  * uzurpator is anxious to start the meeting
21:49 <@Hellfire667> Metalcore?
21:49 <+Steve^> ->
21:49 <@Metalcore> what exactly do you mean by "fixing"?
21:49 < Zuu> ! The meeting have started.
21:49 < Zuu> ~
21:49 <@Metalcore> ~
21:49  * uzurpator is glad
21:50 < MontiMcMannus> To define the reqs.~
21:50 <@Metalcore> alright. that's what i thought.~
21:51 <@Hellfire667> Ok. I'd like to move on. I don't want this meeting to last for more than two hours. (But experience tells me otherwise...) ~
21:51  * uzurpator agrees
21:51 <@Hellfire667> [FRDF] Train propulsion. ~
21:51 <+Steve^> <-
21:51 < Zuu> ->
21:52 <@Hellfire667> Sorry steve... I didn't see the "->" Go ahead if you still like. ~
21:52  * uzurpator is wondering what -> and <- means
21:52 <+Steve^> Doesn't matter now. ~
21:52 <+Steve^> uzurpator, read the meeting rules. ~
21:52  * uzurpator nods
21:52 <@Hellfire667> ! uzurpator:  http://tt2.sourceforge.net/wiki/index.php/Meeting_Rules ~
21:52 <@Hellfire667> Go ahead, Zuu. ~
21:52 < Zuu> Didn't we decide that last meeting.
21:53 < Zuu> The topic for this point was discussed last meeting.
21:53 < Zuu> ~
21:53 <@Hellfire667> I thought so too. Close discussion and continue with the next one? ~
21:53 <+Steve^> I don't think we did... ~
21:53 <+Steve^> It's not in your minutes either @
21:53 <+Steve^> Oh wait, it is ~
21:54 <+Steve^> <-
21:54 <@ChrisCF> I'm sure we talked about things like fuel load, etc. on that topic.
21:54 <+Steve^> ! THe minutes are wrong though
21:54 <@Hellfire667> What's wrong with the minutes, Steve? ~
21:54 <+Steve^> I think, i thought we were having fuel? ~
21:55 < Zuu> ->
21:55 <@ChrisCF> No, it was rejected for a series of fairly-obvious reasons
21:55 <@ChrisCF> ~
21:55 <@Hellfire667> Zuu? ~
21:56 < Zuu> From minnutes:
21:56 < Zuu> 12. Train propulsion:
21:56 < Zuu> 		*Trains will not carry fuel. 
21:56 < Zuu> ~
21:56  * uzurpator thinks that fuel is too much of micromanagement ~
21:56 <@Hellfire667> Ok. Next topic then. 
21:56 <@Hellfire667> [FRDF] Pollution ~
21:56  * uzurpator thinks that pollution should be "optional" and implemented when we are done with the basics ~
21:57 <@ChrisCF> Maybe a charge for the company, and that's it.
21:57 <+Steve^> Drop ~
21:57 <@Hellfire667> Most of the people voted for dropping pollution. Anyone agains dropping? ~
21:57 < Zuu> ! uzurpator please respect -> and <- (and do you reed my private messages?)~
21:57 <@Metalcore> ->
21:57 <@ChrisCF> Ahem.  Did I say "~" yet?
21:58 <+Steve^> Did you say -?
21:58 <+Steve^> No! ~
21:58 <+Steve^> (->)*
21:58 <@Hellfire667> Sorry. Go ahead, ChrisCF. ~
21:58 <@ChrisCF> You don't in open air.  That's not what they're for ...
21:59 <@ChrisCF> Maybe charge the company for high pollution, or vaguely affect howdesirable vehicles are for ratings purposes.  We don't need things like clouds, recorded pollution levels, etc.
21:59 <@Metalcore> I think it should be only in that the gov't/public might not like you as much if you have heavy pollution. This would cause stuff like less passengers, less subsidies, etc.
21:59 <+Steve^> !
21:59 <@ChrisCF> Wait for the ~, dammit!
21:59 <@Hellfire667> Metalcore: ChrisCF is talking! ~
21:59 <@Metalcore> (oops. didn't mean to hit enter yet)
22:00 <@ChrisCF> Other than vehicle types affecting ratings, I don't see where environmental pollutino fits in. ~
22:00 <@Hellfire667> Steve. ~
22:00 <+Steve^> Can we please respect the rules? Just because your ops, doesn't mean they are optional... (Except for the chair) ~
22:01 <+Steve^> ->
22:01 <@Hellfire667> I'll interrupt when they are broken. Go ahead with your next comment. ~
22:02 <+Steve^> I think pollution is perhaps too much micromanagement. Speed limits in towns would be ok. But they probaly aren't made for the same reason. ~
22:02 <@Metalcore> ->
22:02 < Zuu> ->
22:02 <@Hellfire667> Metalcore? ~
22:02  * Steve^ will brb: water
22:02 <@Metalcore> As I said earlier, before accidentally screwing myself over: I think it should be only in that the gov't/public might not like you as much if you have heavy pollution. This would cause stuff like less passengers, less subsidies, etc.
22:03 <@Metalcore> ~
22:03 <@Hellfire667> Zuu. ~
22:03 < Zuu> The topic (on tt-forums) where locked before last meeting, and it was a DROP. Can we go ahed with next point?~
22:03 <+Steve^> !
22:03 <@Hellfire667> Steve. ~
22:04 <+Steve^> Only that? What else would there be? (Regarding metalcore)
22:04 <+Steve^> And i agree with Zuu ~
22:04 <@ChrisCF> Steve: Isn't what a -> rather than a ! ?
22:05 <@Metalcore> Well, environmentall effects might get a bit too annoying. I suppose you should be able to research more efficient motors and cleaner fuels, to get less pollution~
22:05 <@Hellfire667> I agree that it was closed. Next item. 
22:05 <@Hellfire667> [FRDF] Game controls ~
22:06 <@Hellfire667> Is there anything to be discussed on the controls, other than "they should be customizable"? ~
22:06 < uzurpator> agree with hellfire~
22:06 <@Metalcore> agree~
22:07 <+Steve^> ->
22:07 <@Hellfire667> Steve. ~
22:07 <+Steve^> Need shortcuts for building options. That was one of the things people missed in Loco. ~
22:07 <@Metalcore> ->
22:07 <@Hellfire667> I agree, Steve. Metalcore? ~
22:08 <@ChrisCF> ->
22:08 < Zuu> ->
22:08 <@Metalcore> Do you mean shortcuts as in keyboard shortcuts, for building tunnels, etc, or macros for building intersections and complex station complexes?~
22:09 <@Hellfire667> Steve? (ChrisCF, Zuu later... First an answer to this question :)  ) ~
22:10 <+Steve^> I meant keyboard shortcuts. I thought that was what the topic is about. But we do need both in the game. Hellfire, clear up what this topic is about? ~
22:10 <@Hellfire667> Jfs started the topic with a comment on the edge-scrolling.
22:10 <@Hellfire667> Then the discussion migrated to customizing controls.~
22:10 < uzurpator> ->
22:11 <@Hellfire667> ChrisCF, go ahead. ~
22:11 <@ChrisCF> Visual controls need to be meaningful.  Use different types for their intended purpose.  No using a menu item when you meant to use a button, for instance ...
22:12 <@ChrisCF> Shouldn't be too difficult to have customisable keyboard shortcuts either, though the defaults need to be either totally sensible, so people can pick them up, or totally dumb, to encourage people to change them.
22:12 <@ChrisCF> ~
22:12 <@Hellfire667> Zuu. ~
22:12 < Zuu> Mouse and keybord hardware buttons should be treated equally. And be mapped to diffrent actions. Like select object at crousor or open finances window. 
22:12 < Zuu> Mouse scroll whell should be treated as two buttons. To allow people without a scrollwheel to use keybord buttons for that.~
22:13 <@Hellfire667> Impressive... Pretyped and copy/pasted? ;). Uzurpator, your turn. ~
22:13 < uzurpator> OK - we have three branches here:
22:13 < uzurpator> 1. Eacha nd every function shoudl be accesible with 2-button mouse only through gui
22:14 < uzurpator> 2. Some functions (user chooses which?) could be shortcuted through keys
22:14 < uzurpator> whic are at user's choosing
22:14 < uzurpator> 3. Minor things like edge scrolling/window snapping which can be decided later and added in about 20 minutes of coding ~
22:15 <@ChrisCF> We don't seem to have an outstanding "->", so ...
22:15 <@ChrisCF> Some principles on accessible UI:
22:15 <+Steve^> !
22:16 <@ChrisCF> 1. Every function must be accessible on a standard 2-button mouse.  Agreed.
22:16 <@ChrisCF> 2. Every function must be accessible on a standard 101/102-key beyboard.
22:16 <@ChrisCF> (though keybindings can be changed)
22:16 <+Steve^> ->
22:17 <@ChrisCF> The things in point 3 should be left to the user to decide.
22:18 <@ChrisCF> In particular, it might be worth exploring whether we can go down the route of macros accessible by keyboard shortcuts or bindable to buttonss onscreen.
22:18 <@ChrisCF> ~
22:18 <@Hellfire667> Steve. Your ! ~
22:18 <+Steve^> That's not how it works! You still do a -> incase someone else did one right before you typed yours! ~
22:18 <@Hellfire667> True. If there are no outstanding "->"'s, type them just in case. Your ->, Steve? ~
22:19 <@ChrisCF> Disagreed.  -> is for when you can see someone else is actually mid-flow
22:19 <@ChrisCF> ~
22:19 <+Steve^> Not every function needs a key, we have menus too. So 101/102 key keyboards aren't that important. ~
22:19 -!- orudge [orudge@orudge.users.quakenet.org] has quit [Quit]
22:19 < uzurpator> ->
22:19 < Zuu> ->
22:19 <@ChrisCF> ->
22:19 <@Hellfire667> Just one thing on the ->'s. Just type them, to avoid having two people talking at the same time. ~
22:19 <@Hellfire667> Zuu. ~
22:20 <@Hellfire667> WOOPS
22:20 <@Hellfire667> uzurpator first! ~
22:20 < uzurpator> OK - note that some functions are nested. Like "buy train" isn't accesible without depot window. Methinks we can add standard windows
22:21 < uzurpator> scheme: tab to switch through buttons and enter to accept (with arrows to navigate also).
22:21 -!- orudge [orudge@orudge.users.quakenet.org] has joined #tempire
22:21 -!- mode/#tempire [+o orudge] by L
22:21 <@ChrisCF> ->->
22:21 < uzurpator> There is not enough of keyboard fo all functions ~
22:21 <@Hellfire667> Zuu. ~
22:21 < Zuu> Alltroght not every function might need a key in your world steve, I think it would be preferable to allow keybord freeks to use their keybords as much as possible.~
22:21 <@Hellfire667> ChrisCF. ~
22:21 < Zuu> ->
22:22 <@ChrisCF> Noboddy said anything about everything having a shortcut key.  Only that you should be able to access each function reasonably using only a keyboard.  If that means use of menus, fair enough, as long as keyboard users aren't entirely dependent on the menu system.
22:23 < uzurpator> ~?
22:24 <@ChrisCF> More importantly, simply tabbing through fields is not generally accepted as a standard workaround for keyboard access to dialogues, since not all controls can be tabbed to.
22:24 <@ChrisCF> So, if you have a "More" button, as well as being able to tab to it, it should be accessible via an accelerator, e.g. M, Alt+M, etc.
22:24 <@ChrisCF> ~
22:24 <@Hellfire667> Your second comment, ChrisCF? ~
22:25 <@Hellfire667> ->
22:25 <@ChrisCF> Oh, right.
22:25 <@ChrisCF> "~"
22:25 <@ChrisCF> (Covered them both)
22:25 <@Hellfire667> Zuu then. ~
22:25 < Zuu> As I suggested in the new ideas thread, I think a terminal can be good to have, if we make a system built on keys etc. are maped to actions. (not necessary, but can perhaps give more power to keybord users.) It should have support for TAB completion as in bash.~
22:26 <@Metalcore> ->
22:26 <@Hellfire667> Hellfire667. ~
22:26 <@Hellfire667> :P
22:26 <+Steve^> !
22:26 < uzurpator> ->
22:27 <@Hellfire667> My comment was that a "More" button could look like this: [More] (I hope this works on Quakenet).
22:27 <@Hellfire667> But I think a terminal is too complicated. ~
22:27 <@Hellfire667> Metalcore. ~
22:28 <@Hellfire667> Wake up, Evan... Or I'll give the stick to Steve. ~
22:28 <@Metalcore> I think a terminal would make some things easier, such as changing settings, and some things harder, such as buying a train. So I'm for a terminal.~
22:29 <@Hellfire667> (Sorry... I take that back.)
22:29 <@Hellfire667> Steve. ~
22:29 <+Steve^> A terminal? ~
22:29 < Zuu> ->
22:29 <@ChrisCF> A prompt at which you can send commands to the engine. ~
22:29 < Zuu> <-
22:29 <+Steve^> Oh a console ~
22:29 <@Hellfire667> Like the terminal in Quake. ~
22:29 < uzurpator> A quake like console where you can play the game just by issuing commands. Imho this is eensy-weensy to much to decide for now.
22:29 <@Metalcore> ->
22:29 <+Steve^> ->
22:30 <@Hellfire667> Was that your comment, uzurpator? ~
22:30 < uzurpator> We should try to develop basic gui, then build some game around it and then - decide how to issue comands through keys.
22:30 < uzurpator> Yes - it was my comment ~
22:30 <@ChrisCF> ->
22:30 <@Hellfire667> Ok. Metalcore. ~
22:31 < uzurpator> !
22:32 < Zuu> ->
22:32 <@Metalcore> <-
22:32  * Steve^ slaps Metalcore around a bit with an accelerator
22:32 <@Metalcore> (sorry, i forgot)
22:32 < uzurpator> ! General comment - try to write things line after line. Waiting is a bit annoying "->" grants priority anyways~
22:33 <@Hellfire667> Good comment. Steve. ~
22:33 <+Steve^> I think nothing bad can come from having a terminal. But a well built system wouldn't need one. It would make things like changing graphics settings easier. ~
22:33 <@Hellfire667> ChrisCF? ~
22:34 <@ChrisCF> We can't take the approach of "build the game, assign all the controls, then deal with keyboard", since by that point it might be too late. ~
22:34 < uzurpator> ->
22:34 <@Hellfire667> Zuu. ~
22:35 < Zuu> The gnome HID (Human Interface Document) recomendates to NOT decide keybord commands afterwards, but during the work with the GUI.
22:35 < Zuu> Steve: that is what windows tries to fool its users to beleve. Howver in unix we know what power a terminal can give. 
22:35 <@ChrisCF> ->
22:35 < Zuu> but I also see, that it might be to advanced for avagere windows user to handle.~
22:35 <@Hellfire667> Uzurpator. ~
22:35 < uzurpator> Well - depends how you manage client(player) server comminication. Most commands are sent in text/binary anyways.~
22:36 <@Hellfire667> ChrisCF ~
22:36 <@Metalcore> ->
22:36 <@ChrisCF> The GNOME HIG (HI Guidelines) is a fairly good set of guidelines for usability, and well worth considering in our standards. ~
22:37 <@Hellfire667> Metalcore. ~
22:37 <@Metalcore> While I am for the terminal, it should be merely an accessory, not the sole way of doing something~
22:37 <@Hellfire667> ->
22:38 <@Hellfire667> Ok. We have a number of opinions on the controls. Steve, could you summarize them in the minutes? We'll decide later on on the forums.
22:38 <+Steve^> !
22:38 <@Hellfire667> I'd like to move on to the next item. Go ahead, Steve. ~
22:38 <+Steve^> Umm, they all seem to fit together. We have a console..
22:39 <+Steve^> We make inplement functions during building the game..
22:39 <+Steve^> Where's the clash? ~
22:39 < uzurpator> ->
22:39 <@Hellfire667> uzurpator. ~
22:39 < uzurpator> The console thingy is interesting.
22:39 < uzurpator> In my proto I send commands to the server in a manner command/its parameters
22:40 < uzurpator> Example command BuyTrain 1,2,3,2
22:40 <+Steve^> ->
22:40 < uzurpator> Buy train at depot 1 , train model 2, 3 pieces, 2;nd schedule it could be useful for making scripts that make
22:40 <@Hellfire667> ->
22:40 < uzurpator> some mundane tasks faster~
22:41 <@Hellfire667> Steve. ~
22:41 <+Steve^> Ok, i think what uzurpator just said "BuyTrain" is a bit too complicated. Options should be kept simplier, we have a UI for a reason.
22:41 <+Steve^> May get complicated with buying trains with numbers for example ~
22:41 <@Hellfire667> ->->
22:41 < uzurpator> ->
22:41 <@Metalcore> ->
22:41 <@Hellfire667> My first comment: your way of client/server communications is probably the best way to go... ~
22:42 <@Hellfire667> My second comment: BuyTrain is just an example of c/s communication. This has nothing to do with the UI. ~
22:42 <@Hellfire667> uzurpator. ~
22:42 < uzurpator> Agree with hellfire - you can issue commands through GUI or through console~
22:43 <@Hellfire667> metalcore. `
22:43 <@Hellfire667> ~
22:43 <@Metalcore> as has been said, the console should not be the sole method of operating~
22:44 <@Hellfire667> Any more on the controls? Or can we move on to the next topic. ~
22:44 <+Steve^> Next! ~
22:44 < uzurpator> next~
22:44 <@Hellfire667> Ok. [RFD] Scale ~
22:45 < uzurpator> ->
22:45 <+Steve^> ->
22:45 <@Hellfire667> Go ahead. ~
22:45 <@Hellfire667> (Uzurpator). ~
22:45 < uzurpator> My initial proposition fo 16m per tile was for geometric sizes only
22:45 < uzurpator> eg - 16 meter object would be 1 tile long
22:45 < uzurpator> also 1024^2 terrain is 144 sqkm~
22:46 < uzurpator> ->
22:46 <@Hellfire667> ->
22:46 <@Hellfire667> Steve. ~
22:46 <+Steve^> With bigger maps, i think our scale should be alot more realistic than TTD and Loco. Especially with ships. They need to be big and stuff.
22:46 <@ChrisCF> ->
22:46 <+Steve^> But it also depends hugely on the type of tile system we use. If we have strict blocks like TTD, then a similar scale would be a better choice. ~
22:46 <@Hellfire667> Hellfire667. ~
22:47 <@Hellfire667> 144 sqkm is not much for a map. Especially not for a full-country map. 144 sqkm = 12x12km... ~
22:47 <@Hellfire667> Uzurpator. ~
22:47 <@ChrisCF> <-
22:47 < uzurpator> Ok - the 16m/tile is to ensure that unlike in Loco trains and other types of transport would not outsize buildings. that is 256 sqkm :p
22:48 < Zuu> ->
22:48 < uzurpator> have you seen 2048x2048 map in OpenTTD? That is huge~
22:48 <@Hellfire667> No, not yet. :) Just the 64x64 variant. Zuu. ~
22:49 < Zuu> I think we should seperate objects scale and landscape scale. To make the game better to play.~
22:49 < uzurpator> ->
22:49 <@Hellfire667> uzurpator. ~
22:50 < uzurpator> Time and speed scales are a bit different. The 16m/tile is geometric scale - for objects only.~
22:50 < uzurpator> ! note TTD uses something about 16m/tile for geometry
22:50 < uzurpator> ~
22:51 <@Metalcore> ->
22:51 <@Hellfire667> Does everyone agree to the 16x16m only for objects and other scales for maps? ~
22:51 <@Metalcore> <-
22:51 <@Metalcore> agree~
22:52 < Zuu> ->
22:52 <@Hellfire667> Zuu. ~
22:52 < Zuu> I wrote at the wki:
22:52 < Zuu> One problem with realistic size of cities is that the world would need to be verry big eaven if we want the same amount of cities, indusries as in TTD. But since we want eaven more space, so that would lead to eaven bigger maps.
22:52 < uzurpator> ->
22:53 < Zuu> ~
22:53 < Zuu> ->
22:53 <@Hellfire667> uzur. ~
22:53 <@Hellfire667> uzurpator? ~
22:54 < uzurpator> Performance issues. 2048x2048 map uses just 2048^2*6*4 bytes for gemoetry alone (not counting normals)
22:54 <@Hellfire667> ->
22:54 < uzurpator> if we settle for smaller scale (32m/tile) then all objects will start to look really small. So we will waste more memory for placing them
22:54 < uzurpator> on the tile~
22:54 <@Hellfire667> Zuu. ~
22:54 < Zuu> about 16x16 I think that we should not be to strict about the 16x16m. Ie allow a 15x17 meters big object to  be one cell. ~ 
22:55 <@Hellfire667> Hellfire667 ~
22:55 <@Hellfire667> 2048^2*6*4 <-- factor 6?? ~
22:55 < uzurpator> ->
22:55 <@Hellfire667> uzurpator. ~
22:55 < uzurpator> float number is 6 bytes long :) I might squeeze it to short-int later though
22:55 < uzurpator> 16m is reference. We are not a slaves of it : ) ~
22:56 <@ChrisCF> !
22:56 <@Hellfire667> Chris. ~
22:56 <@ChrisCF> Brief point of order:
22:57 <@ChrisCF> Suggest that people can answer questions posed to them directly, without having to "->" themselves? ~
22:57 < uzurpator> ->
22:57 <+Steve^> ChrisCF, yes they can ~
22:57 <@Hellfire667> Ok. I'll give the people the opportunity to answer after the question. Uzurpator. ~
22:58 < uzurpator> Note - if we tie tile vertices to their neighbours
22:58 < uzurpator> then we will save about 75% of that memory
22:58 < uzurpator> ~
22:58 <@Hellfire667> Ok noted. No more comments on memory sizes please.
22:58 <@Hellfire667> Can we end the scales discussion? ~
22:58 < Zuu> ->
22:59 <@Hellfire667> Zuu. ~
22:59 < Zuu> Z scale..
22:59 < uzurpator> ->
22:59 <+Steve^> !
22:59 < Zuu> Should we scale Z diffrent from X and Y? To make slopes esier to see?~
22:59 <@Hellfire667> Steve, you go first. ~
22:59 <+Steve^> Can someone just summarize? I'm kind of lost to what we've decided. ~
23:00 <@Hellfire667> I'll wrap it up after the Z scale. uzurpator. ~
23:00 < Zuu> ! minutes from last meeting: http://www.tt-forums.net//files/meeting20050205_minutes_192.txt
23:00 < uzurpator> The memory thingy is important :) if we drop that requirement we can have 4 times bigger maps - thus better scales
23:00 < uzurpator> ~
23:01 < MontiMcMannus> ->
23:01 <@Hellfire667> Monti. ~
23:01 < MontiMcMannus> As I said the map may be swapped to disk.
23:01 < MontiMcMannus> With some prog tricks its possible even with city calculations, path finding and so on. ~
23:01 <@Hellfire667> ->
23:02 <@Hellfire667> I/O efficiency is something for the coding stage. I think we will notice a decrease in performance though. ~
23:02 <@Metalcore> ->
23:02 <@Hellfire667> Metalcore. ~
23:02 <@Metalcore> Um.....what does that mean for us less technical people?~
23:02 < MontiMcMannus> -->
23:02 <@Hellfire667> Monti. ~
23:02 < MontiMcMannus> Nothing, it can be hidden in an abstract layer.
23:03 < uzurpator> ->
23:03 < MontiMcMannus> The performaance degree will occure also in pathfinding in a 4000*4000 map. so we
23:03 < MontiMcMannus> need good algorithms.
23:03 < MontiMcMannus> ~
23:03 <@Hellfire667> uzurpator. ~
23:04 < uzurpator> I don't think that swapping to disk is such a good idea. We are operating files that are 600+ MB in size here.
23:04 < uzurpator> also - the scale is about: should we have 100 tiles as average distance between cities or 200?
23:04 <+Steve^> !
23:04 < uzurpator> proposition: make a discussion for devs for programming only so we won't bring that up here~
23:05 <+Steve^> 600 mb files? I bloody hope tha
23:05 <+Steve^> sorry, mistake
23:05 <+Steve^> ~
23:05 <@Hellfire667> Steve. ~
23:05 <+Steve^> 600 mb files? I bloody hope not! ~
23:05 < Zuu> ->
23:05 <@Hellfire667> hehe... I agree, uzurpator. Programming details for programmers only. Zuu? ~
23:06 < MontiMcMannus> ->
23:06 < Zuu> <-
23:06 <@Hellfire667> Monti. ~
23:06 < MontiMcMannus> Are 600MB too much? Only if they are in memory.
23:06 <@Hellfire667> ->
23:06 <@Metalcore> ->
23:06 < MontiMcMannus> The trains needs a good graph, airplains another map with a bigger raster.~
23:07 <@Hellfire667> Airplanes don't need a map at all. They just have to fly from point to point. But on Uzurpator's remark:
23:08 <@Hellfire667> I think we should prefer 200 over 100 tiles between cities, but again, --this should be a parameter of a map generator, not a requirement!-- ~
23:08 <@Hellfire667> Metalcore. ~
23:08 <@Metalcore> 600 MBs? you wouldn't need that much RAM, would you? This computer has downward of 300.
23:08 <@Metalcore> ~
23:08 < uzurpator> ->
23:08 <@Hellfire667> go ahead, uzurpator. ~
23:09 < Zuu> ->
23:09 < uzurpator> My point exactly - we want as big maps as possible. With some trickery I'll be able to make maps up to 16384 tiles
23:09 < uzurpator> with just 500 MB...
23:09 < uzurpator> 16384x16384
23:09 < uzurpator> ~
23:09 <@Hellfire667> Zuu. ~
23:10 < Zuu> About Z-scale, I think Z of landscape should be sclaed more than Z of objects.
23:10 < Zuu> ~
23:10 <+Steve^> ->
23:10 < uzurpator> ->
23:10 <@Hellfire667> ->
23:10 <@Hellfire667> Steve. ~
23:10 <+Steve^> I vote we drop this now, and let the programmers decide it. ~
23:10 <@Hellfire667> uzurpator. ~
23:11 < uzurpator> Zuu - you want Z to be shorter or longer then x/y?
23:11 < Zuu> On screen: longer~
23:11 < uzurpator> ->
23:11 <@ChrisCF> ->
23:11 <@Hellfire667> I also think the Z scale of the map should be enlarged, or else slopes will be invisible. 
23:12 <@Hellfire667> But the objects should have equal X/Y/Z scale. ~
23:12 <@Hellfire667> Uzurpator. ~
23:12 < uzurpator> Currently my proto uses 1/1 z/x/y.... But you mean 16 m of tile side would mean (let uss ay) 8 m in rise?
23:12 < uzurpator> ~
23:13 <@Hellfire667> Chris. ~
23:13 <@ChrisCF> From the perspective of trying to sell this, 500MB of memory usage is totally unacceptable.
23:13 <@Hellfire667> Ok stop.
23:14 <@Hellfire667> Please, on the scale only. Not on the memory usage. ~
23:14 <@Hellfire667> We'll discuss memory usage later, on the forum. ~
23:14 < uzurpator> agreed~
23:14 <@Metalcore> agree~
23:14 < Zuu> agree~
23:14 < MontiMcMannus> +
23:14 < MontiMcMannus> ~
23:14 <@ChrisCF> Sorry, but that had to be said. ~
23:15 <@Hellfire667> ->
23:15 < Zuu> ->
23:16 <@Hellfire667> But as answer to uzurpator's question: I once said on the forum that a 10% incline is almost invisible. We should bump it up to for example 30%, just to make it visible to the user. ~
23:16 <@Hellfire667> Zuu. ~
23:16 < Zuu> Can we have a vote on if Z scale for lanscape should differ (would it be smaller or bigger?), and then continue with the meeting?~
23:16 <@Hellfire667> Ok. Please vote in favour or against. ~
23:17  * Hellfire667 is in favour. ~
23:17 <+Steve^> Bigger. ~
23:17  * Zuu is in favor~
23:17 < MontiMcMannus> Lets make an example image and decide later.~
23:17 <@ChrisCF> In favour or against what?  Remmber what was agreed last time about votes? ~
23:17  * uzurpator is undecided~
23:17  * Metalcore is in favor~
23:17 < MontiMcMannus> ->
23:17 <@Hellfire667> In favour or agains different Z scales for the map. ~
23:18 <@Hellfire667> Monti, go ahead. ~
23:18 < MontiMcMannus> If bigger, the mountains will be go heavy up to the sky (eg. 1000 height meter to a 3m train)
23:18 < MontiMcMannus> If smaller, the slopes are not visible.
23:18 <@ChrisCF> If you mean the Z scale being different to the X and Y scales, then I am in favour.  If you really mean different Z scales, then I'm confused suddenly. ~
23:19 <+Steve^> ->
23:19 < MontiMcMannus> I think we need an own landscape (not realistic).
23:19 <@Hellfire667> I meant the former. ~
23:19 < MontiMcMannus> ~
23:19 < uzurpator> ->
23:19 <@Hellfire667> Steve. ~
23:19 <+Steve^> We don't need huge mountains. You can't build transport on them very easily. ~
23:19 <@Hellfire667> Uzurpator. ~
23:20 < uzurpator> I think we should wait with decision on Z until we see how will it look like. trains do not go above 3-4% IRL - but trucks somethimes do
23:20 < uzurpator> 25%
23:20 < uzurpator> it may produce too much of weirdness imo
23:20 < uzurpator> ~
23:20 <@ChrisCF> ->
23:21 <@Hellfire667> Chris. ~
23:22 <@ChrisCF> As far as how steep slopes go, remember that, depending on the power and effort of the vehicle, it may be able to manage much more than 4%, and we shouldn't exclude this.  Though I agree that we would be in a better-informed position once we know exactly how steep we can build things.
23:22 <@ChrisCF> ~
23:22 <@Hellfire667> Ok, noted. 
23:22 < Zuu> ->
23:23 <@Hellfire667> Steve, could you write in the minutes that we will allow a different scale for the Z axis on the map, if necessary?
23:23 <@Hellfire667> I'd really like to move on to the next item. ~
23:23 <@Hellfire667> Zuu? ~
23:23 < Zuu> <-
23:23 <@Hellfire667> For the next item, shape of the maps was planned, but I'll treat "[RFD] Triangular or rectangular tiles" first.
23:23 <@Hellfire667> There has been a poll on the forum
23:23 < MontiMcMannus> ->
23:23 <@ChrisCF> ->
23:24 <@Hellfire667> The outcome was 2 in favour of triangle tiles. Four in favour of square tiles.
23:24 <@Hellfire667> Monti. ~
23:24 < MontiMcMannus> I want to suggest only rectangular.
23:24 < MontiMcMannus> All other would end in headache for the developer.
23:24 < MontiMcMannus> ~
23:24 <@Hellfire667> Make that 2 vs 5 then. Chris. ~
23:24 <@ChrisCF> IMO, we should separate the landscape from the objects on it.
23:25 <@ChrisCF> Obviously, it goes without saying that square tiles make more sense for the location of objects,
23:25 < MontiMcMannus> Yep!
23:25 <@ChrisCF> however, the landscape itself need not be formed of square tiles.
23:25 < MontiMcMannus> ->
23:25 < uzurpator> ->
23:26 <@ChrisCF> Any idea of how we achieve this is left as an exercise. ~
23:26 <@Hellfire667> Monti. ~
23:26 < MontiMcMannus> Other, I want the landscape with square tiles, the buildings with a free location
23:26 < MontiMcMannus> and maybe a free degree (with a 3dengine)
23:26 < MontiMcMannus> ~
23:26 <@Hellfire667> uzurpator. ~
23:27 < uzurpator> The landscape is formed from square tiles - and it looks pretty decent imo... (but I'm biased :p )~
23:27  * MontiMcMannus has forgotten to mention tracks as 3d.
23:27 <@ChrisCF> ->
23:27 <@Hellfire667> Chris. ~
23:27 -!- Hellfire667 changed the topic of #tempire to: Transport Empire discussion :: www.tt-forums.net :: FRD meeting in progress :: Agenda: http://users.tt-forums.net/hyronymus/Agenda.htm
23:28 <@ChrisCF> I said nothing about the tiles being atomic.  It might well be that you have a building at point (3.5,4.5)
23:28 <@ChrisCF> only that a square grid makes more sense mathematically. ~
23:28 < Zuu> ->
23:28 <@Hellfire667> Zuu. ~
23:28 < MontiMcMannus> has to leave now :(
23:29 < Zuu> Please leave discussion about fredome placement or cell fixed to point 18 on the agenda.~
23:29 <@Hellfire667> Ok. Thanks for joining us tonight. I hope to see you again in the future! ~
23:29 < MontiMcMannus> Of course! good bye and have fun!
23:29 -!- MontiMcMannus [~qwertzasd@tom.newtron.net] has quit [Quit]
23:30 <@Hellfire667> Can we now finally decide on triangles vs squares? It's 2 vs 5 already. ~
23:30 <@Hellfire667> Is there anyone who would like to change their vote (or place a vote)? ~
23:30 <@ChrisCF> Abstaining, and remaining so. ~
23:30 <@Metalcore> If my vote is not already there, I'd like it on triangles.~
23:30 < Zuu> ! <OT>I will leave within 30 minutes. </OT>~
23:31 <@Hellfire667> That makes it 3 triangles vs 5 squares.
23:31 <@Hellfire667> ~
23:31 <@Hellfire667> I guess it's squares then. NEXT!
23:31 <@ChrisCF> ! While I remember, I'll be leaving at a random point between now and 10.  Work tomorrow morning and all.
23:32 <@Hellfire667> Ok.
23:32 <@Hellfire667> [RFD] Shape of the maps ~
23:32 < uzurpator> ->
23:32 <@Hellfire667> Square tiles -> Square or rectangle. Uzurpator? ~
23:32 < uzurpator> isn't that tied with the former?~
23:32 <@Hellfire667> I guess so. Does anyone have anything to add? ~
23:33 <+Steve^> ->
23:33 <@ChrisCF> ->
23:33 <@Hellfire667> Go ahead, Steve. ~
23:33 <+Steve^> Rectangle, user picks the size. (Or map creator) ~
23:33 <@Hellfire667> ChrisCF. ~
23:33 <@ChrisCF> <- 
23:33 <@Hellfire667> :)
23:33 <@Metalcore> agree~
23:33 <@Hellfire667> Anything else? ~
23:33 <@Hellfire667> 3
23:34 <@Hellfire667> 2
23:34 <@Hellfire667> 1
23:34 <@Hellfire667> [RFD] Cell based, freeform or something in between ? ~
23:34 <@Hellfire667> ->
23:34 < Zuu> ->
23:34 <+Steve^> !
23:34 <@Hellfire667> I still think that we should have "something in between". ~
23:34 <@Hellfire667> Steve. ~
23:34 <+Steve^> Can i have a better topic title please?
23:34 <+Steve^> And minutes will easily be done by the end of the meeting ~
23:35 <@Hellfire667> What do you mean with that? ~
23:35 < uzurpator> ->
23:35 <+Steve^> It seems a bit, chatty. Rather than a serious title to a section. ~
23:35 <+Steve^> But i've been wrong several times today. ~
23:35 <@Hellfire667> Do you know what that topic is about? ~ (http://www.tt-forums.net/viewtopic.php?t=13159)
23:36 < uzurpator> <-
23:36 <+Steve^> Ignore me. ~
23:36 <@Hellfire667> Go ahead, zuu. ~
23:36 < Zuu> The reson why I am talking for a cellbased thing is that I fear that a fredome variant would be to easy. So it won't be any challenge to make good and efficent track layouts.
23:37 <+Steve^> ->
23:37 < Zuu> I think it can be fair that a track section con go from the center of any square to any other square that is close enoght, which does not need to be the 8 closest squares. 
23:38 < Zuu> That would work as a compromise I think. ~
23:38 <@Hellfire667> Steve. ~
23:38 <+Steve^> It adds so much more to the game though. So you can make things that are so complex and efficient that would make TTD junctions look like.. umm.. something rubbish.
23:38 <@Hellfire667> ->
23:38 <+Steve^> I'm for a full 360 degree track and road system ~
23:38 < uzurpator> ->
23:38 <@Hellfire667> Hellfire667. 
23:39 <@Hellfire667> I'm for a system like PJayTycy's prototype, but restricted to a grid, possibly smaller than the map. ~
23:39 <@Hellfire667> uzurpator. ~
23:39 < uzurpator> <-
23:39 < Zuu> ->
23:39 <@Hellfire667> Go ahead. ~
23:40 < Zuu> Hellfire667: that was what I where thinking about as a compromize, depending on how small the grid would be. 
23:40 < Zuu> ~
23:40  * ChrisCF disasppears in a poor attempt at a puff of smoke
23:40 < uzurpator> ->
23:41 <@ChrisCF> night all
23:41 <@Hellfire667> Any comments on that? ~
23:41 <@Hellfire667> Goodnight, ChrisCF! ~
23:41 < uzurpator> gnight chris~
23:41 <@Metalcore> night~
23:41 <@Hellfire667> Uzurpator. ~
23:41 < Zuu> ! godnight~
23:41 <+Steve^> ->
23:41 < uzurpator> Methinks that 3 snap points between two vertices (on a side of a tile) would be enoight
23:42 < uzurpator> that would give 5 snap points evenly distributed on a tile ~
23:42 < uzurpator> ! side of a tile~
23:42 <@Hellfire667> Steve. ~
23:42 <+Steve^> I'm not against a smaller grid than is used for the landscape and buildings. But we need alot more freedom than TTD and Loco offer. Otherwise we're wasting a nice 3D engine. ~
23:42 < Zuu> ->
23:43 <@Hellfire667> Zuu. ~
23:43 < Zuu> I agree with uzurpator suggestion.~
23:43 < Zuu> ->
23:43 <@Hellfire667> Zuu. ~
23:43 < Zuu> Or not..
23:44 <+Steve^> ->
23:44 < Zuu> becuse 16 m = 4 lanes?
23:44  * Hellfire667 will be right back... Go ahead, Steve, after Zuu. ~
23:44 < uzurpator> nope
23:44 < Zuu> ok, ~
23:44 < uzurpator> axis of the track is aligned with snap points :)
23:44 < uzurpator> ~
23:44 <+Steve^> I think uzurpator's suggestion will need extra algos just the same as a full 360(ish) design to watch for collsions. So i see no reason to sacrifice freedom. ~
23:45 < uzurpator> ->
23:45 <+Steve^> uzurpator 
23:45  * Steve^ chuckles
23:45 < uzurpator> easier management of the map might be a good reason to limit some freedom ~ :)
23:45  * Hellfire667 is back. ~
23:45 <+Steve^> ! Management? In what way?
23:46 < uzurpator> easier to calculate collisions~
23:46 < Zuu> ->
23:46 <@Hellfire667> Zuu. ~
23:46 < Zuu> Esier to create paralell tracks!~
23:46 < Zuu> ->
23:46 <@Hellfire667> Agree. ~
23:46 <@Hellfire667> Zuu. ~
23:46 <+Steve^> ->
23:47 < Zuu> And reproduce junctions etc.~
23:47 <@Hellfire667> Steve. ~
23:47 <@Hellfire667> ->
23:47 <+Steve^> There is no reason why we couldn't make a simple system to help users build a track parralel to another track. Similar to how programs like flash let you align abouts as you move them ~
23:47 <@Hellfire667> Hellfire
23:48 <@Hellfire667> How about a poll on this:
23:48 <+Steve^> *objects i guess ~
23:48 <@Hellfire667> 1. Fixed elements as in TTD/Loco.
23:48 <@Hellfire667> 2. Total freeform with optional flash-like snapping.
23:48 <@Hellfire667> 3. Freeform, but restricted to a grid.
23:48 <@Hellfire667> ~
23:48 < uzurpator> 3~
23:48 < Zuu> 3~
23:48 <+Steve^> 2! To the max!
23:48 <@Hellfire667> 3~
23:48 <+Steve^> ~~
23:49 <+Steve^> !
23:49 <@Hellfire667> Has anyone ever played 3dtt a.k.a. trains and trucks tycoon? ~
23:49 <@Metalcore> 3
23:49 <@Hellfire667> (after the answer, you're up, Steve)~
23:49 <+Steve^> If there is only 4 of us, i suggest we put it to the forums. And no. ~
23:49 <@Metalcore> ~
23:49 < Zuu> nope~
23:49 <@Hellfire667> Steve, agreed. Put it on my todo list. ~
23:49 < uzurpator> I toyed a bit with 3dtt, not much tho~
23:50 <+Steve^> ->
23:50 <@Hellfire667> How did the track laying interface work, uzurpator? ~
23:50 < uzurpator> whole 3dtt worked weird :p
23:50 < uzurpator> rt3 has semi-free track laying
23:50 < uzurpator> and it works well there~
23:50 <@Hellfire667> Steve ~
23:50 <+Steve^> If we limit pieces to the edges of tiles, we lose alot of flexibilty. Can we still build stations properly on an angle? ~
23:51 <@Hellfire667> I think we can. ~
23:51 < uzurpator> yup~
23:51 <+Steve^> !
23:51 <@Hellfire667> In fact, I'd really like to build stations in curves. ~
23:51 <@Hellfire667> Steve?~
23:51 <+Steve^> Let me explain:
23:52 <+Steve^> Your curving into a 45 degree station. You want to put the corner right up to the mouth. If the pieces have to end on a tile, the way the edge of the tiles work, would it really work out properly?
23:52 <+Steve^> With a 360 system, you could make it work how you like. ~
23:53 < Zuu> ->
23:53 < uzurpator> ->
23:53 <@Hellfire667> Zuu. ~
23:53 <@Hellfire667> ->
23:54 < Zuu> The snap ing will NOT limit things to 8 directions. it will still allow you to build things in any angle (untill we decide on something else), as long as they snap to a grid point.~
23:54 <@Hellfire667> uzurpator. ~
23:54 <+Steve^> ->
23:54 < uzurpator> we can limit station platform entrances to snap-points. problem solved. And as zuu pointed out - track elemetns begin and end on a
23:55 < uzurpator> snap point - and span wherever we wish it to go - on any angle~
23:55 <@Hellfire667> I'm having flashbacks from Pontifex... Hmm... Steve, you go ahead first. ~
23:55 <+Steve^> If we have a small grid. It wouldn't techincally offer 360, but i think it would still be a better solution. Retaining alot of flexibilty. It would be like your system, but with more points in the centre of tiles!
23:56 < uzurpator> ->
23:56 <+Steve^> Pontifex rocks btw. Foolish D&T installed it at school for lessons :) ~
23:56 <@Hellfire667> ! That would be optoin 3. ~
23:56 <@Hellfire667> uzurpator. ~
23:56 <+Steve^> It would? ~
23:56 <@Hellfire667> ! yes. ~
23:56 < uzurpator> (chunckles) small grid -> more memry :p ~
23:56 <@Hellfire667> ->
23:56 <@Hellfire667> Not much.
23:56 <+Steve^> No, it wouldn't! ~
23:56 <@Hellfire667> Coarse grid for the map.
23:57 < uzurpator> ! Move to forums
23:57 <+Steve^> ->
23:57 < uzurpator> ~
23:57 <@Hellfire667> Smaller grid just for the track pieces. This just means bigger values for the begin and end coordinates. ~
23:57 <@Hellfire667> Steve. ~ (and then I put my final remarks and move on)
23:57 <+Steve^> Your only storing where a bit of track begins and ends. It's not different that you selecting which bit of a tile it connects to. ~
23:57 <@Hellfire667> I'll put a summary of this discussion in the topic on the forum. We'll decide on what to do there. For now, the next topic:
23:57 <@Hellfire667> [RFD] Tunnels (what is a tunnel?)
23:57 <@Hellfire667> Can anyone give a brief summary of that topic? ~
23:58 < uzurpator> ->
23:58 <@Hellfire667> go ahead, uzurpator. ~
23:58 < uzurpator> I have no idea how to implement this - unless we do some trickery like in Loco - auto-tunnels when we want to auto-
23:58  * Zuu will soon leav the meeting.~
23:58 < uzurpator> terraform the terrain.
23:58 < uzurpator> ~ 
23:58 < Zuu> ->
23:59 <@Hellfire667> Zuu. ~
23:59 <+Steve^> ->
23:59 < Zuu> Please read ttp://www.tt-forums.net/viewtopic.php?t=13039
--- Log closed ma helmi  14 00:00:00 2005
--- Log opened ma helmi  14 00:00:00 2005
--- Day changed ma helmi  14 2005
00:00 < Zuu> ~
00:00 <@Hellfire667> Steve. ~
00:00 <@Hellfire667> _>
00:00 <+Steve^> A tunnel should be simply: A track that is underground. No need to give it extra rules or anything. ~
00:00 < Zuu> ->
00:00 <@Hellfire667> How about we just specify what tunnels (and bridges) should be and move the discussion to the forum? ~
00:00 <@Hellfire667> Zuu. ~
00:01 < uzurpator> agreed~
00:01 < Zuu> What do you think about this suggestion http://www.tt-forums.net/viewtopic.php?p=243190#243190?
00:01 <+Steve^> ->
00:01 < Zuu> I agree with Hellfire667 that this could be keept on the forums.~
00:01 <@Hellfire667> Steve. ~
00:02 <+Steve^> A bridge should be simply: A track that is elevated above the ground. Although, you'd need new graphics and different bridge types. Some could be straight, some curvy etc. ~
00:02 < uzurpator> ->
00:02 <+Steve^> !
00:02 <@Hellfire667> ->
00:02 <@Hellfire667> Hmm... Steve, your ! first. ~
00:02 <+Steve^> Should i write my suggestions in the minutes? Noone seems to disagree...
00:03 <@Hellfire667> Ok. ~
00:03 < uzurpator> Imho bridge should be a structure - and track/road built on it. As a structure bridghe should be built seperately.~
00:04 <+Steve^> !
00:04 <@Hellfire667> Steve. ~
00:04 <+Steve^> Why are we talking about bridges?
00:04 <+Steve^> ~
00:04 < Zuu> ->
00:04 <@Hellfire667> Zuu. ~
00:04 <@Hellfire667> ->
00:05 < Zuu> I dissagre with Steve, I think that the idea http://www.tt-forums.net/viewtopic.php?p=243190#243190 is conficting with steves suggustuon. ~
00:05 <@Hellfire667> My turn :)
00:06 <+Steve^> ->
00:06 <@Hellfire667> I think that jfs' suggestion, in post 243190 is a really good way to go, but a bit unclear.
00:06 <@Hellfire667> I think he should have used the word "ceiling" instead of "roof".
00:06 <@Hellfire667> You can build anything between a surface and a ceiling, as long as there is enough space.
00:06 <@Hellfire667> And ofcourse, you can always build below the lowest ceiling or above the highest surface.
00:06 <@Hellfire667> ~
00:06 <@Hellfire667> Steve. ~
00:06 <+Steve^> I actually see that as more of a programming solution. I see no reason why it conflicts with my idea. ~
00:07 <@Hellfire667> ->
00:07 < uzurpator> !
00:07 <@Hellfire667> So you mean your idea is more in the visual area? ~
00:07 <@Hellfire667> Steve answer first, then uzurpator. ~
00:07 <+Steve^> When your building the tracks. It'd be exactly the same in building when your underground (with a height modifier).
00:08 <+Steve^> Like in Loco, not like in TTD. ~
00:08 < uzurpator> I dont want to be the one to implement jfs idea...~
00:08 < Zuu> ->
00:08 <@Hellfire667> Zuu. ~
00:09 <@Hellfire667> ->
00:09 < Zuu> I am leaving you now, just a last note: please consider what have been discussed on the forums before taking any decissions. Please. ~
00:09 < Zuu> Bye~
00:09 <@Hellfire667> Bye!
00:09 <+Steve^> I think we should call a close to the meeting. 3 isn't enough. ~
00:10 <@Hellfire667> I'd like to move on. We'll discuss this further on the forum. I'll put some implementation details for uzurpator on the forum.
00:10 -!- Zuu [~Zuu@h135n11c1o1028.bredband.skanova.com] has left #tempire ["You run, never stop, got to win, got to run till you drop"]
00:10 <@Hellfire667> Steve, elaborate on 3, please :) ~
00:10 < uzurpator> agree with steve~
00:10 <+Steve^> Hellfire667, uzurpator, me. 1,2,3 ~
00:10 <@Hellfire667> Right!
00:10 <@Hellfire667> Ok.
00:10 <@Hellfire667> Hmm.
00:10 <@Hellfire667> Let's see what's left on the agenda.
00:11 <@Metalcore> try 4
00:11 <@Metalcore> I'm reading everything
00:11 <@Hellfire667>  9.	[RFD] Airports: how is they constructed? by modules or fixed
00:11 <@Hellfire667> 10.	[RFD] Docks
00:11 <@Hellfire667> 11.	[RFD] Research
00:11 <@Hellfire667> 12.	[RFD] Signalling
00:11 <@Hellfire667> 13.	[RFD] Finding routes and services
00:11 <@Hellfire667> 14.	[RFD] Company rating
00:11 <@Metalcore> just lack comments~
00:11 <@Hellfire667> 15.	[RFD] Liveries
00:11 <@Hellfire667> 16.	[RFD] Variable trains? (attach/deattach locos and cars)
00:11 <@Hellfire667> 17.	[RFD] Vehicle breakdowns
00:11 <@Hellfire667> 18.	[RFD] Computer players
00:11 <@Hellfire667> 19.	[RFD] SI or not SI?
00:11 <@Hellfire667> 20.	[RFD] Style
00:11 <@Hellfire667> (waiting to get kicked for flooding)
00:11 <@Hellfire667> No kick. Okay. 
00:11 <@Hellfire667> End of meeting pending then. Next meeting in two weeks? Discuss the items in the above list in the mean time.~
00:12 < uzurpator> agreed~
00:12 <+Steve^> 1 week
00:12 <+Steve^> ~~~~
00:12 <@Hellfire667> My girlfriend will kill me. :( Okay. Anyone against in one week? ~
00:13 <@Metalcore> I'm not
00:13 <+Steve^> Your fault for having one :D ~
00:13 <@Metalcore> i won't be there, though.
00:13 <@Metalcore> I'll be on an Aircraft Carrier.
00:13 <@Metalcore> ...well, on the way back, if Sunday
00:13 <+Steve^> They let you on an aircraft carrier? ~
00:13 <+Steve^> Bush is desperate... ~
00:13 <@Metalcore> :P
00:13 <@Metalcore> it's a museum.
00:13 <+Steve^> In iraq?
00:14 <@Metalcore> going with the BoScouts.
00:14 <@Metalcore> Boy Scouts*
00:14 <@Metalcore> in South Carolina
00:14 <@Metalcore> the USS Norfolk
00:14 <@Hellfire667> MEETING ADJOURNED. Next meeting will be on 20-feb-2005, same time: 1930 UTC. ~