IRC logs for #openttd on OFTC at 2013-08-13
⏴ go to previous day
00:16:51 *** amiller has joined #openttd
01:40:27 *** Supercheese has joined #openttd
02:09:38 *** montalvo has joined #openttd
02:12:57 *** Supercheese has joined #openttd
03:39:20 *** roboboy has joined #openttd
03:41:56 <Supercheese> Good lord, I've had a typo in my forum signature for ages now, just noticed
04:48:47 *** kais58__1 has joined #openttd
04:56:16 *** Eddi|zuHause has joined #openttd
04:59:09 *** kais58__1 is now known as kais58|AFK
06:20:12 *** sla_ro|master has joined #openttd
06:35:31 *** Pensacola has joined #openttd
06:54:55 *** Devroush has joined #openttd
07:36:22 *** valhallasw has joined #openttd
07:38:02 <maddy_> since the game has a scripting language used for AIs and gamescripts, I am thinking it could also be used for small in-game scripts to control signals and the like
07:38:18 <maddy_> similar to the programmable signals patch, but better
07:40:05 <maddy_> what do you guys think?
07:41:51 <planetmaker> maddy_, in principle that's thinkable. Practically you then have no means to tell what a signal acts on. Even less so, if they're freely programmable by scripting language. Additionally the state of signals is not exposed nor is there any interface to access them other than by tile and direction information by the train controller
07:44:59 <maddy_> I am thinking for things like priorities and stuff, couldn't I just add one programmable signal for these special cases, then attach a script to it, and the script is run everytime the signal state needs to be checked
07:46:13 <maddy_> at the script level, I would really only need to know the state of the nearby signals, if I can get that in some meaningful way
07:48:42 <maddy_> of course if I could get information about the incoming train to the signal script, then it'd be really easy to do things like splits based on cargo type, etc
07:55:02 <dihedral> maddy_, i think that would impose nasty load on the server
07:55:17 <dihedral> esp in multiplayer the script would have to be placed on each client
07:55:37 <dihedral> this is not the case for ai or gs
07:55:58 *** Ristovski has joined #openttd
07:56:22 <planetmaker> that is not a principle problem if handled similarily to NewGRFs which also each client must have.
07:57:16 <planetmaker> But the definition of "nearby" eludes me :-) As anything you normally want can be done by means of block or path signals. Otherwise you want signals from all-over accessible for programming
07:57:38 <planetmaker> or information on whether a station is blocked etc. And then a network becomes virtually un-debuggable ;-)
07:58:43 <peter1138> signal 1 = !signal 2
07:58:47 <peter1138> signal 2 = !signal 1
07:59:48 <peter1138> actually i think i mean signal 2 = signal 1
08:00:35 <maddy_> ok, I have to go afk a bit, if this idea is at all feasibly, I will explore the possibility of trying to make some prototype of it
08:03:20 <dihedral> planetmaker, i would expect it to be an issue ;-)
08:05:05 <dihedral> but that is more a gut feeling, and probably worth nothing :-P
08:09:03 <peter1138> handling signal scripts like a newgrf seems fundamentally wrong, heh
08:10:21 <planetmaker> well :-) I do agree. Feasible != desirable :-)
08:11:22 <dihedral> but then why do we need to discuss other peoples desires? that just "seems fundamentally wrong" also
08:17:41 <dihedral> depending on the desire of course
08:18:45 <peter1138> all i meant was that newgrfs are general, even if game-wide. signal scripts are going to be specific to the situation
08:19:14 <peter1138> unless you argue that you just want premade scripts for a type of junction
08:19:23 <dihedral> can a grf not add a new signal ?
08:19:29 <peter1138> in which case you could also argue for copy & paste of map chunks...
08:20:05 <dihedral> thank you peter1138 - now i had to think of people like peter_t, muxy, yorick.....
08:22:22 <peter1138> i personally prefer to think of pretty women
08:33:40 <Eddi|zuHause> i think a "full-blown script engine" is totally overkill for programmable signals
08:35:15 *** LordAro has joined #openttd
08:36:25 <TinoDidriksen> Such an engine will almost certainly be used for other things in the future.
08:36:42 <Eddi|zuHause> also, i think a "script" should not be attached to a signal, but to a whole block of signals. possibly with a way to include/exclude signals. then only signals of this block can be accessed/modiified
08:37:12 <dihedral> Eddi|zuHause, attach it to a type of signals ;-)
08:38:24 <Eddi|zuHause> that makes absolutely no sense, this early in the morning...
08:39:17 *** kais58|AFK is now known as kais58__1
08:41:20 <V453000> I think programmable signals are total overkill :) especially without some simplified gui
08:42:45 <Eddi|zuHause> yeah, like some SCADA system where you just graphically connect things and they start to do stuff
08:43:17 <V453000> that would be nice too, but I mainly meant something like the link graph does - draw links beetween stations - between signals in this case
08:43:32 <V453000> otherwise it is inevitable brutal mess if you cant directly see which signal logically connects to which
08:47:25 <V453000> the current solution of signal logic is nicer because it is visible, if that would be substituted by something, the feature might make at least some sense
08:48:53 <Eddi|zuHause> anyway, "just pipe it to squirrel" is totally the wrong approach
08:52:25 <peter1138> dihedral, sorry, i am not a pretty woman
08:57:08 <dihedral> V453000, not quite - you'r just a woman
08:58:40 <maddy_> well if the idea wasn't outright rejected as impossible or totally stupid, I think I will look into it
09:05:08 <dihedral> is that you? i thought you were one of those ugly hairy women :-P
09:05:24 <dihedral> maddy_, just do not be disappointed
09:06:53 <peter1138> if you can make it work, cool
09:08:38 <maddy_> I am an ugly haired man, tho not pictured in the above link
09:09:39 <maddy_> I am not very familiar with openttd insides, which is why I am asking would such a project be possible? so I don't waste my time with something that won't work out in the end due to openttd inner mechanics
09:11:18 <dihedral> possible is one thing - feasible or sensible is the other
09:11:24 <maddy_> like, the code which determines if a signal is green or red, would it be possible to insert a 'hook' to that function, and call a script?
09:11:40 <dihedral> it would not make much sense
09:11:56 <dihedral> as you would need access to a bunch of further signals, which you do not have
09:12:09 <dihedral> at least not in the scripts
09:12:25 <maddy_> but couldn't I just pass the relevant game state (e.g. any nearby signals) to the script
09:12:53 <dihedral> nearby signals iirc are determined by the pathfinder
09:14:09 <dihedral> obviously this also depends on the signal type you are using
09:15:47 <maddy_> I will look at the code later tonight when I get a chance
09:23:09 <maddy_> I am just thinking since there already exists an embedded scripting language, like 90% of the work is already done
09:49:34 <planetmaker> maddy_, I think that much less is done to make it work. It need work on multiplayer and scripts only work server-side. But they work globally while signals work locally. And they are part of one of the most time critical things in the game: path finding
09:59:40 <maddy_> yeah there's a lot to think about, for sure
10:01:15 <maddy_> are regular signals handled on client or server side?
10:03:56 <maddy_> btw, I wasn't thinking of the scripts as separate entities like say newgrfs, but internal to the game state / save game
10:13:42 <maddy_> that should make it a bit simpler I hope
10:14:02 <dihedral> everything (with the exception of ai and gs) is handled client side
10:16:10 <dihedral> to me that signal thing just shouts for desyncs :-)
10:17:11 <maddy_> I'm a total beginner when it comes to openttd source, but why?
10:17:45 <dihedral> because every client does calculations them selves, every frame has to be the exact same result of calculation
10:18:10 <dihedral> between clients there can be a lag of (default) up to 500 frames? something like that
10:18:28 *** Pinkbeast has joined #openttd
10:18:41 <dihedral> or was it 500 ticks?
10:18:47 <dihedral> i am confusing myself now
10:19:09 <maddy_> so...if the same script is executed on 2 clients, with different cpu speeds and stuff, we could end up with different outcomes on those 2 clients
10:19:13 *** Pinkbeast has joined #openttd
10:19:13 <dihedral> anyway - if something is different by a tad - allowing a train to pass a signal one one client and not for another....
10:19:40 <dihedral> if different cpu speeds were causing a problem there would be no multiplayer
10:20:07 <maddy_> ok, but what would desync it then?
10:20:59 <dihedral> a green on one client and a red on the server
10:45:39 <peter1138> hmm, need a decent dvb viewer
10:45:44 <peter1138> me-tv works but has annoyances
11:04:03 *** Pereba_ has joined #openttd
11:10:13 *** Pereba_ is now known as Pereba
11:13:46 <wakou2> Any opensuse users here? Which repo should I be getting openttd from?
11:19:36 <peter1138> when do we implement an auto updater? :D
11:21:35 <wakou2> planetmaker: don't want really to be compliling tars etc. I currently have 1.3.1 from the repo..
11:22:33 <peter1138> the binary tar is... already compiled...
11:37:21 *** TrueBrain has joined #openttd
11:39:39 <Eddi|zuHause> wakou2: opensuse has a "games" repo
11:39:51 <Eddi|zuHause> which has openttd in it
11:40:39 <Eddi|zuHause> if it's not up to date, blame the manager
11:41:11 <V453000> if it is up to date, blame them anyway
11:41:17 <Eddi|zuHause> when was the last time anyone saw Ammler, anyway?
11:41:46 <DorpsGek> __ln__: Ammler was last seen in #openttd 17 weeks, 0 days, 17 hours, 44 minutes, and 35 seconds ago: <Ammler> oh and just for your info, those grfs are in the grfpack anyway, I posted those there for the non-pack users back then
11:54:58 *** sla_ro|master has joined #openttd
11:58:03 *** Tom_Soft has joined #openttd
12:06:47 *** Tom_Soft has joined #openttd
12:29:51 *** Snoopey78 has joined #openttd
12:30:31 <Snoopey78> Is there anyone of the openttd.org Homepage ? I would like to publish my Public Server Address
12:32:19 <planetmaker> :D we don't publish addresses. Have it run and it will be added to the server list
12:32:31 <planetmaker> make sure you allow 'advertizing'
12:33:03 <planetmaker> aka connection to the master server
13:06:49 *** zeknurn has joined #openttd
13:30:17 <maddy_> cool the openttd svn server is pretty fast
13:30:39 <Eddi|zuHause> unless you check out /
13:41:55 *** HerzogDeXtEr has joined #openttd
13:48:19 <dihedral> Eddi|zuHause, if YOU check out / it is slow for everybody
13:52:52 <maddy_> where do the language files go on compile?
13:54:00 <planetmaker> maddy_, make bundle && cp -Rf bundle/* server-folder
13:54:30 <maddy_> cool I got as far as to compile openttd and run it without problems
13:54:42 <maddy_> planetmaker: I'm on windows
13:55:43 <planetmaker> also windows builds have the equivalent of 'make bundle'
13:57:44 <maddy_> ok, got around it by just copying the files manually to existing openttd installation
13:59:06 <Eddi|zuHause> if you just copied the .exe and the .lng files, you forgot half of it
14:02:46 <maddy_> good point, copied the rest over too
14:19:37 *** amiller has joined #openttd
14:22:15 <dihedral> this for sure smells like .. :-)
14:29:08 <planetmaker> it doesn't stink, though ;-)
14:31:18 <V453000> no, beer is the default, normal air is like negative
14:32:55 <V453000> therefore air negatively smells
14:41:08 <planetmaker> sorry, I forgot that :-(
14:42:26 <V453000> the council of alcoholism will let you go unpunished for this once
14:42:58 <maddy_> so, how does it sound if I added a new signal type, then (for that type, if a script exists), run the script in UpdateSignalsAroundSegment (signal.cpp) function?
14:48:29 <peter1138> try it and find out
14:49:50 <maddy_> yeah I gotta figure out how to run scripts first
14:51:46 * Rubidium decrees that beer is yuck and stinks ;)
14:52:55 *** sla_ro|master has joined #openttd
14:54:43 * Rubidium ponders requesting the @kickme feature together with an automatic ban
15:06:14 *** Midnightmyth has joined #openttd
15:10:19 *** ntoskrnl has joined #openttd
15:10:23 <maddy_> so is there any prob with just creating a new script instance that I want to use client side? you said earlier that ai/gamescripts run on the server
15:17:32 *** killertester has joined #openttd
15:20:19 *** killertester has left #openttd
15:21:58 <peter1138> client-side actually means "all-sides" in ottd :D
15:26:20 <maddy_> it's obvious I will need a bit of help from you who know the source
15:27:30 <Eddi|zuHause> maddy_: you need to use the command system to transfer stuff to all clients (see "DoCommand" and "DoCommandP")
15:31:33 <planetmaker> maddy_, I'd recon the MUCH easier approach would be to allow signal logic in a similar way that you can use conditional orders for vehicles
15:32:18 <Eddi|zuHause> not that nobody ever thought the order system needs a cleanup :p
15:32:29 <planetmaker> i.e. w/o resorting to scripts and hard-coding the possible choices, but allowing choice trees
15:32:33 <planetmaker> Never ever, Eddi|zuHause ;-)
15:32:55 <planetmaker> you clearly are the first to bring it up :D
15:34:07 <krinn> wonder what "MUCH easier" could mean... as if a "custom" logic can be set on signals, the server must handle all signals and send state to clients
15:35:01 <planetmaker> krinn, you'd have an "order list" for the signal. You could borrow most infrastructure for that from current order list
15:35:11 <planetmaker> if you use scripts, you'll have to re-invent all that infrastructure
15:35:44 <planetmaker> and additionally find means to transfer basically their source code in DoCommands
15:35:50 <planetmaker> Which have a rather limited size
15:36:13 <krinn> so signals logic remain on client side?
15:37:14 <krinn> forget it, i was thinking you were speaking about client controlling the state of signals, while you seems to speak about client able to check/react to signals state only
15:37:52 <planetmaker> clearly the client wants to be able to programme the behaviour, thus change the decision algorithm. But not the actual state
15:39:47 <krinn> that's why i see the "much easier" and think wtf! nothing scare him
15:41:10 <maddy_> planetmaker: but isn't that done already, the old "programmable signals" patch?
15:41:27 <planetmaker> what's the definition of 'done'?
15:41:52 <krinn> something already inside openttd ?
15:42:01 <maddy_> coded and diff available at tt-forums.net? I just know because I edited it myself a few years ago
15:42:47 <planetmaker> and yes, that's probably the way I mean. And it's major drawback is, that it lacks somewhat a nice GUI for players to see the impact of the programming. I.e. the scope of the programmed signals
15:44:12 <planetmaker> maddy_, thus IMHO the main work which should be thought about decently in advance: how do you want to properly convey the information on the programme to the user
15:44:23 <planetmaker> that's what never has been done. Also not in the old patch
15:44:46 <maddy_> the problem with the old method, while pretty cool, does not allow the flexibility of what a script can do
15:45:05 <planetmaker> just telling you: the problem is the UI. Not the lack of flexibility
15:47:05 <planetmaker> it needs a way to visualize the impact of the programmed signals
15:47:34 <maddy_> I am just a bit uncomfortable with all the logic code in the programmed signals patch, it feels like extra overhead, compared to having it hidden inside squirrel
15:47:36 <planetmaker> inspecting the programming of every single one of 200 programmed signals on a map ... would make it otherwise impossible to find any issue
15:48:11 *** valhallasw has joined #openttd
15:49:47 <maddy_> for scripts, a GUI could be just a simple textbox window
15:49:56 <krinn> i don't think it's a good idea to gave such functions handling to squirrel, that language is too weird
15:51:05 <planetmaker> maddy_, a text window with a script does not explain the resulting logic on the viewport.
15:51:18 *** megakacktus has joined #openttd
15:51:18 <planetmaker> that's exactly the shortcoming I speak of :-)
15:51:35 <planetmaker> I want to be able to understand a signal without reading a 100-line script
15:52:27 <maddy_> yeah a 100-line won't work, I was thinking they could be kept fairly short, and possibly developing a library of some kind for most common functions, which could then be reduced to maybe 1 line in the actual script
15:53:10 <maddy_> if they were in the range of say 1 to 4 lines, I think it'd work
16:00:12 <maddy_> DoCommand and DoCommandP seems to have a "text" parameter, wonder if that could be used
16:00:53 *** Bad_Brett has joined #openttd
16:14:25 *** DarkAceZ has joined #openttd
16:17:09 *** Alberth has joined #openttd
16:17:09 *** ChanServ sets mode: +o Alberth
16:32:24 *** oskari89 has joined #openttd
16:34:57 <maddy_> so do you think I shouldn't attempt to do this?
16:36:07 <Alberth> plain signals are already beyond being understood by many
16:37:59 <krinn> well, maddy_ make a patch with : the signals, the GUI, and a default optional state to off so beginners won't even see them until allow
16:38:01 <maddy_> well, sure, but this would be intended for more advanced players, probably not intended as something which would ever be included in trunk
16:38:58 <krinn> if it's something that won't goes in openttd, i don't see why you are asking anyone if you should do it or not.
16:39:24 <Alberth> he wants a user-count > 1 :p
16:39:35 <planetmaker> oh, hi Alberth :-)
16:40:07 <krinn> actually if he could make a nice GUI, that might also help users with "default signal" handling, as they are always lost
16:40:28 <planetmaker> I just prodded ^Spike^ to look into converting the DevZone DB ;-)
16:40:44 <^Spike^> pssst... planetmaker i can read this
16:41:06 <maddy_> well, but aren't the forums full of odd patches that some players like to play with, but won't be included in trunk due to not being suitable for most?
16:41:08 <planetmaker> I know. I looked and made sure you can't read it ;-)
16:41:12 <Alberth> too late, you have given yourself away now :)
16:41:17 <planetmaker> but don't tell everyone ;-)
16:41:45 <planetmaker> Indeed I had to scroll the complete user list of this channel :-P
16:41:54 <Alberth> maddy_: most are just below trunk standards
16:42:09 <^Spike^> mirc shows me on top of the list... but most clients on the bottom :D
16:44:29 <maddy_> I'm sure more advanced players would like the fine grained control for signals that scripts would enable, but non-programmers wouldn't get them, so it's hard task to have the same feature serve those 2 user groups
16:46:02 <dihedral> actually, those players with enough brains create nand flash with trains and signals
16:46:49 <krinn> maddy_, i don't see what prevent you from making it optional, except more work
16:47:36 <planetmaker> hehe, dihedral :-)
16:47:38 <maddy_> dihedral: yeah, those are cool in their own way, but those are exactly what I'd like to do in scripts...it would result in much cleaner track layout
16:47:44 <dihedral> it basically needs to be a new signal type, krinn
16:47:58 <dihedral> maddy_, but at what cost
16:48:21 <krinn> dihedral, and what? you can activate rail speed or not... if he want, he can add an option to hide that new type of signal or not
16:49:12 <maddy_> is there a gui widget already in game which acts like a multiline textbox? for editing the scripts
16:49:45 <planetmaker> probably there's not, maddy_
16:50:00 <planetmaker> OpenTTD is not text editor (so far) :D
16:50:06 <dihedral> why not look at existing patches that did programmable signals
16:50:17 <dihedral> planetmaker, i smell a feature
16:50:18 <krinn> maddy_, your script approch is a failure imo, do make pre-build system (like orders)
16:50:53 <dihedral> krinn, pre build system??
16:50:57 <planetmaker> says one of the most active script writers :D
16:51:26 <maddy_> I have looked at the programmable signals patch
16:51:50 <dihedral> very good, maddy_ then you know how to make the multi line text box
16:52:47 <krinn> dihedral, i mean instead of using script to handle it, he offer a number of choices already made by him, and user can only use them
16:53:37 <krinn> dihedral, hence "pre-build", or ready made... flexibilty <> simplicity
16:54:16 <dihedral> we have that already, yet aparently the available choice is not big enough
16:54:25 <maddy_> why would scripts be a fail tho, if I included a squirrel library with some commonly used features, like priorities or 1:1 splits (which I saw done using logic stuff in openttdcoop)
16:56:00 <krinn> if you do a library, then you lost your flexibility, i was thinking you want user "edit the script" and do what he want. And a c++ or squirrel library won't change anyone, as you will offer a limited choice to user (that pre-build choice i speak off)
16:56:08 <dihedral> i am not sure it's as easy as you imagine it
16:56:36 <maddy_> krinn: no, the library would contain some pre-built functions for common tasks, but it'd be fully user editable
16:57:01 <krinn> so it will be a failure then
16:57:09 <dihedral> in all honesty though, if you use a multi line text box in game to edit signal settings, remember the signal script (for each signal) must reach the server and be distributed to every client
16:57:22 <krinn> why prevent me to edit it to access other squirrel functions to do something ?
16:57:54 <dihedral> krinn, the layer in between
16:57:57 <maddy_> krinn: you lost me there...the scripts would be fully editable by users
16:59:14 <planetmaker> I'd like to switch a signal in sinoidal way red/green ;-)
16:59:25 <dihedral> maddy_, i am not quite sure you understand the implications of your enthusiastic vision
16:59:45 <maddy_> dihedral: in what way?
17:01:14 <dihedral> i do not know how to put it any other way
17:01:31 <maddy_> well, you have to be more specific, but in any case, I won't start this task since there's clearly no support for it among more experienced developers
17:02:12 <dihedral> maddy_, you remind me of people visiting this channel and the forums long before you joined :-P
17:02:46 <dihedral> " clearly no support for it among more experienced developers" <- that
17:03:01 <planetmaker> maddy_, you should do, what you do, for your own profit and enjoyment
17:03:04 *** megakacktus has joined #openttd
17:03:07 <dihedral> do you want people to be as enthusiastic about your idea as you are?
17:03:23 <dihedral> and help you develop something
17:03:48 <maddy_> I just appreciate the input of people who have spent years with the source, and know it so much better than me
17:04:07 <dihedral> saying that the task actually is huge, bigger than you might think it is, is help
17:04:14 <Alberth> maddy_: if you ask specific questions, you get answers
17:04:51 <Alberth> stuff like "I have an idea" is too global to comment on other than the idea itself
17:05:39 <maddy_> Alberth: well yeah, I did ask some specific stuff too
17:05:53 <dihedral> in all honesty, he/she did
17:06:31 <krinn> i still don't get why you ask people if you can do something that will run only for you
17:07:02 <planetmaker> let's not bash him, ok? :-)
17:07:22 <dihedral> however, maddy_, do not be discouraged to dig in the code, however be informed that the task is bigger than you expect it to be, and has huge implications, like mentioned earlier today you need to also be sure it works in multiplayer, and exactly that will cuse issues with the wrong approach
17:07:26 <Alberth> maddy_: I missed that, did you get an answer?
17:07:38 <dihedral> planetmaker, who's bashing?
17:08:00 <krinn> i wasn't saying that to bash him
17:08:02 <maddy_> Alberth: irrelevant now, since I've decided not to pursue this specific task, I will think of some other patch to make instead
17:08:44 <dihedral> maddy_, perhaps a piece of encouragement: start with small changes ;-)
17:08:47 <maddy_> dihedral: yeah, the multiplayer aspect came up, but what specifically was wrong with my approach that would not work with multiplayer?
17:09:34 <krinn> there's two way to make patch : doing it for you, you don't need any input on it from anyone. Or doing it in hope it get include, then this time, you can query devs to get hint of success.
17:09:45 <dihedral> multiplayer is basically a single player with a 'relay' in the middle telling each client what actions other clients are performing
17:09:54 <krinn> and planetmaker already answer you hints about it : make a gui, and i hint you : make it with an option
17:10:03 <dihedral> so any script you enter in one signal must be sent to every other client
17:10:20 <dihedral> further the script must use a syncronized type of random, else clients will be out of sync
17:10:27 <Alberth> krinn: false, you can still need info about how some parts of the code work, or how to add stuff, or where to find stuff
17:10:46 <dihedral> krinn, options can always be added later on ;-)
17:11:22 <maddy_> the limitations of passing data between clients using the DoCommand stuff came up, would that be the problem?
17:11:58 <dihedral> seeing as each client makes its own calculations, the result run on any client must be exactly the same for the exact same frame
17:12:27 <Alberth> you have about 32bit or so space, is that enough?
17:12:58 <maddy_> dihedral: well, I don't think I would need randomness for basic scripts, and yeah they would/should return same result for all clients
17:13:09 <maddy_> Alberth: no, if strings would need to be passed
17:13:31 <Alberth> maddy_: then you have a challenge to make it work, to say the least
17:14:21 <dihedral> Alberth, where do you get that from?
17:14:34 <maddy_> Alberth: ok, I just noticed the DoCommand has a "text" parameter, so I thought maybe I could pass something there
17:14:58 <planetmaker> without looking it up, it might be an error message ;-)
17:15:16 <dihedral> are signs not a do command
17:15:17 <Rubidium> ... but only up to ~100 bytes
17:15:34 <dihedral> Alberth, just wondering where exactly the 32bit are still available
17:15:36 <Alberth> dihedral: oh, good point
17:16:20 <maddy_> ok, now we are getting somewhere, specific reasons why the approach is not viable...instead of what dihedral is saying, which is general stuff like "it's huge" and "it won't work"
17:17:38 <maddy_> so, that pretty much decides it I think, that I can forget the idea at least in it's initial form
17:17:51 <Alberth> maddy_: it's usually always viable for some form, the trick is to find that form
17:17:52 <dihedral> maddy_, if you do not know the code, why should i explain the code, as you would then clearly not be able to follow
17:18:24 <dihedral> and the trick is also to understand what is going on in the code and understand what implications are there
17:18:40 <dihedral> and further, to find an approach that will take those implications into account
17:19:00 <krinn> it's easy if "viable" mean can work, it is as you said someone made a patch for it already, and if viable is add in openttd, it is not, as this patch already lack a gui for that
17:19:40 <dihedral> krinn, the lack of a patch does not mean it was not viable - patches can be declined for many reasons
17:19:46 <Alberth> and the best way to understand code and implications, is just to try a few times (and fail), learning each time what not to do.
17:20:09 <dihedral> i could write a patch that lets me control a plane while mid air - i bet you that would not be accepted :-P
17:20:15 <krinn> people are programming robots to walk on mars, how could adding a signal in openttd would be state as non-viable
17:20:21 <dihedral> and probably you will find peter1138 already has a patch for that somewhere
17:20:42 <dihedral> maddy_, and what Alberth sais :-)
17:20:45 <maddy_> Alberth: yeah that works great, I just want to run an idea by experienced developers who can immediately say if it'll work or not, before wasting potentially hours (or days) of my time
17:21:14 *** amiller has joined #openttd
17:21:46 <krinn> maddy_, you won't waste hours... you will work on something that may not work or you decide to drop, but hours spent teach you how to handle the code... so not lost hours, just some hours spent
17:22:06 <Rubidium> krinn: the same reason why installing Internet Explorer on Curiosity is non-viable?
17:22:55 <krinn> Rubidium, considering how its pathfinding is working, i'm sure MS built the OS that run on it :)
17:23:23 <Rubidium> oh does it's pathfinding work?
17:24:06 <Alberth> maddy_: but at global conceptual level it is hard to say, the devil is always in the details. I do disagree with you "wasting hours", you spent time on learning about the internal structure of openttd, knowledge that you will keep available. Having an dev tell you yes/no is not the same depth of knowledge
17:25:31 <maddy_> and I do want to learn the openttd code, since I like the game, and the code is fairly clean and easy to read (I guess that's a compliment for you guys), just need to figure out some other project now
17:25:55 <Rubidium> krinn: because as far as I know the pathfinding is mostly done by humans with models and simulators on earth
17:27:27 <planetmaker> they recently upgraded its software. they just give it a destination and curiosity is supposed to go around (small) obstacles autonomously
17:28:43 <Alberth> maddy_: that will take you a few years :)
17:30:03 <planetmaker> maddy_, I look at OpenTTD code for some years now... I'm sure there are code lines which I never looked at :-)
17:30:23 <planetmaker> I'm actually 100% positive. OS/2 code was so far of little interest :-P
17:30:23 <dihedral> planetmaker, over 6 years for me now :-)
17:30:36 <maddy_> for some reason I am not a big fan of the existing programmable signals patch
17:31:43 <dihedral> maddy_, but it might help find a way of doing it, and it might show you all the areas in the code you need to tough
17:32:12 <DorpsGek> planetmaker: Commit by smatz :: r13481 trunk/src/dock_gui.cpp (2008-06-11 21:37:36 UTC)
17:32:13 <DorpsGek> planetmaker: -Codechange: add 'B' keyboard shortcut to build aqueduct (planetmaker)
17:32:21 <dihedral> planetmaker, i was around for 6 years
17:32:50 <planetmaker> and I joined like 9 months earlier or so.
17:37:00 <maddy_> oh, I could have just used the openttd console as the script gui ;) that'd been even easier I guess
17:37:02 *** frosch123 has joined #openttd
17:40:52 <DorpsGek> dihedral: Commit by peter1138 :: r9771 trunk/src/console_cmds.cpp (2007-05-02 19:00:59 UTC)
17:40:53 <DorpsGek> dihedral: -Feature: (-tte) Add password protected status to 'players' (network server) console command. (mostly dihedral)
17:41:44 <DorpsGek> michi_cc: Commit by Darkvater :: r3008 /trunk (13 files in 2 dirs) (2005-10-02 22:39:56 UTC)
17:41:45 <DorpsGek> michi_cc: [ 1247535 ] Native Support for Win64 (compile&run only) (michi_cc)
17:41:46 <DorpsGek> michi_cc: Fix warning in graph_gui.c with const problem
17:42:20 <planetmaker> wow, I didn't know you were around *that* long, michi_cc :-)
17:43:17 *** killertester has joined #openttd
17:43:36 <frosch123> hmm, yeah, that has quite a chance to be second after tb
17:43:57 <frosch123> when is first commit of gl*/peter*/rubi* ?
17:44:08 <DorpsGek> Rubidium: Commit by tron :: r3511 /trunk (59 files in 4 dirs) (2006-02-01 07:36:15 UTC)
17:44:09 <DorpsGek> Rubidium: More whitespace ([FS#46] by Rubidium)
17:44:16 <dihedral> michi_cc, it's not a matter of size :-P
17:45:26 <DorpsGek> Commit by translators :: r25721 /trunk/src/lang (lithuanian.txt slovenian.txt) (2013-08-13 17:45:19 UTC)
17:45:27 <DorpsGek> -Update from WebTranslator v3.0:
17:45:28 <DorpsGek> lithuanian - 32 changes by Stabilitronas
17:45:29 <DorpsGek> slovenian - 14 changes by matej1245
17:45:49 <frosch123> 2231 is first mentioning of peter
17:46:33 <DorpsGek> Rubidium: Commit by rubidium :: r3729 /branches/tfc_newmap (4 files) (2006-03-02 07:11:16 UTC)
17:46:34 <DorpsGek> Rubidium: [tfc_newmap] - Synching to trunk r3727 and fix mismerges of r3726 and r3710
17:46:35 <frosch123> oh, gl* is even earlier, r2100 :p
17:46:42 <Rubidium> might be my first actual commit ;)
17:47:11 <frosch123> well, my first checkout was something around 7000 :p
17:47:31 <dihedral> a small total of 36 commits - could have been more planetmaker :-D
17:48:09 <DorpsGek> __ln__: Commit by miham :: r1297 /trunk (18 files) (2004-12-29 13:13:29 UTC)
17:48:10 <DorpsGek> __ln__: Language fixes in the source.. (ln-)
17:48:28 <planetmaker> that can't be you, __ln__
17:48:50 <dihedral> planetmaker, it says "Language fixes" that for sure is __ln__
17:49:00 <planetmaker> no. the nick is wrong. totally
17:49:18 <frosch123> dihedral: it's his brother
17:49:30 <planetmaker> that sounds likely, yes
17:49:45 <krinn> tt forum sold its cpu and get an old zx81 at work?
17:50:40 <Alberth> krinn: yep, it was cheaper
17:51:23 <__ln__> i've only been __ln__ instead of ln- since ... i don't remember when, but only on oftc.
17:58:18 <dihedral> __ln__, that was such a shocking comment, nobody seems capable to find the right words for that :-P
17:59:19 <LordAro> __ln__: why'd you change?
18:00:24 <__ln__> i don't remember really, could have been to avoid a ban mask or something
18:04:54 <krinn> @param cost_callback should accept four parameters, old_path, new_tile, new_direction and
18:05:06 <krinn> this._cost = cost_callback(pf_instance, old_path, new_tile, new_direction);
18:06:49 <dihedral> krinn, what exactly did you want to tell us?
18:07:00 <krinn> doc doesn't match the function
18:08:27 <dihedral> and you did check that there is no default set. allowing to call it with just three params?
18:08:50 <krinn> i show the call -> this._cost = cost_callback(pf_instance, old_path, new_tile, new_direction);
18:09:21 <dihedral> you really do seem to know what you are doing :-P
18:09:39 <krinn> not always, but this time, yeah
18:09:53 <dihedral> then look where the function is defined
18:11:11 *** SamanthaD has joined #openttd
18:12:09 <dihedral> krinn, where is that code from??
18:12:22 <krinn> dihedal, well, from aystar6
18:13:00 <krinn> must be in devzone i check
18:13:16 *** killertester has joined #openttd
18:16:10 <dihedral> Rubidium, slow is an understatement for tt-forums
18:16:34 <SamanthaD> woooaaaaah, that's like a museum display!
18:17:22 <LordAro> indeed, the only name i reocgnise (other than sir rudge) is GoneWacko, but he's only in #tycoon
18:17:42 <DorpsGek> LordAro: Commit by miham :: r1297 /trunk (18 files) (2004-12-29 13:13:29 UTC)
18:17:43 <DorpsGek> LordAro: Language fixes in the source.. (ln-)
18:17:58 <LordAro> ^ the original reason for bringing this up, SamanthaD
18:18:38 <SamanthaD> That's sad... I guess people got bored with trains!
18:18:52 <dihedral> i also remember SirkoZ
18:19:18 <dihedral> but i do not want to read all 7 pages, not because I had anything better to do, but I don't want to wait for them to load
18:21:11 <LordAro> i believe i've seen Roman around also, and a few others, but none of them recently
18:23:05 <Wolf01> I'm here since that time too, I remember all of them :P
18:23:19 <LordAro> oh, and mr Wolf01 is at least on the last page
18:24:11 <krinn> i was 2 years old in 2004 so i'm not in
18:24:38 <Chrill> pfft. I have brothers younger than krinn
18:25:34 <LordAro> lie? on the internet? who would do such a thing?
18:25:39 <Wolf01> I just finished high school at that time
18:26:42 <krinn> LordAro, politicians are on the net too
18:26:46 *** Devroush has joined #openttd
18:27:29 <LordAro> Rubidium/whoever, backporting documentation updates from 1.3.2 seems to have been forgotten
18:28:58 *** Progman has joined #openttd
18:30:16 <Eddi|zuHause> when i came here, michi_cc was already the "win64 release guy"
18:30:36 <Eddi|zuHause> not that i ever needed such a thing
18:31:25 <Eddi|zuHause> only somewhat later the compilefarm produced win64 builds for releases
18:31:42 <krinn> can wait to have forcefeedback support in openttd !
18:31:58 <Eddi|zuHause> "is lab-grown meat kosher/halal?"
18:32:35 <krinn> oh the meat, not the animal, ok don't know then :)
18:33:15 <frosch123> krinn: do you know what neighbours are important does?
18:33:26 <frosch123> it's also active in your game
18:33:37 <frosch123> anyway, the clearing pattern is weird
18:33:46 <frosch123> as in, it's a complex shape
18:34:08 <krinn> it do control town rating if neighbor town are too small, the town get a small rate
18:34:39 <krinn> i don't think nai is doing that
18:34:43 <Eddi|zuHause> krinn: the point is that you don't have to kill an animal to get the meat :p
18:34:50 <krinn> my ai could have done it, but not to that big shape
18:35:23 <Wolf01> Eddi|zuHause, you mean you could just ask it for its meat?
18:35:27 <krinn> i have functions to clean tree, but limited in size, so i'm sure it's not the ai frosch123
18:35:51 <krinn> frosch123, and of course not me :)
18:36:41 *** andythenorth has joined #openttd
18:36:59 <andythenorth> troll or not troll?
18:37:34 <krinn> frosch123, if it help, when i reload the savegame to check it was the good savegame, the industry : "Rennes raffinerie pétrolière", next to the big clean was also cleaned for no reason
18:37:40 * andythenorth decides not troll
18:38:01 <SamanthaD> Eddi: You don't have to kill an animal to get the meat anyway... but the ASPCA didn't buy it...
18:38:48 * krinn think Eddi|zuHause just eat animal alive
18:38:58 <frosch123> krinn: what does limited in size mean?
18:39:11 <frosch123> the area is not rectangular, so it's not one big area, but many small ones
18:39:19 <Eddi|zuHause> krinn: the meat was grown from a few cells
18:39:30 <krinn> frosch123, i think town influence area
18:39:35 <Eddi|zuHause> without an animal attached to it
18:40:06 <andythenorth> not trolling lego fans is boring
18:40:12 <andythenorth> but trolling them will get me mod warning
18:40:19 <frosch123> krinn: ok, what version of your ai is running exactly?
18:40:58 <krinn> so one that change a lot
18:41:17 <krinn> i have put it in another issue with orders
18:41:24 <frosch123> did you restart your ai or something?
18:41:29 <frosch123> all expenses are zero
18:41:35 <frosch123> and it started only 11 days ago
18:41:43 <krinn> i always reload it in those test
18:42:02 <krinn> and cheat to gave it money to let it build trains
18:42:27 <krinn> so the ai have the money to do havock if it wish
18:42:34 <krinn> but honestly it's not what happen here
18:42:49 <frosch123> i am quite sure it must be the ai then :p
18:43:27 <krinn> the shape of clean tiles isn't even a square
18:44:01 <Eddi|zuHause> of course, there's an isometric distortion to the square :p
18:44:07 <krinn> and i was testing the ai of course, i would have seen it if the ai was working on that so many tiles
18:46:26 <Eddi|zuHause> NYT: "why did you go to a foreign newspaper instead of to us?" - Snowden: "Because american press gave up their role as a check to power after 9/11, because of fear to look 'unpatriotic'"
18:47:42 <Xaroth|Work> not untrue either
18:50:30 <krinn> :P usa have all the clues of a dictatorship country
18:50:57 <frosch123> dictator ai is just currently clearing a complete town area
18:51:22 <krinn> not that size frosch123
18:51:42 <frosch123> "that size" is just the area combined by three towns
18:53:00 <frosch123> and it's not done yet, i paused the game while it was doing so
18:53:28 <krinn> ah maybe i should recheck that part (as i don't even remember if i change it)
18:53:42 <krinn> but the area upper left area seems way too far
18:56:41 <krinn> nope only clean limit to town authority area
18:57:11 <frosch123> maybe ottd even lmitied your ai with the clear-tile limit
18:57:20 <frosch123> thus the area is not quite square
18:57:43 <krinn> it's limit to town authority size
18:58:44 <krinn> or do town authority that much big for a small city ?
19:01:11 <krinn> frosch123, in the samegame you still have the stations the ai was working on : la rochelle & lille town
19:11:13 <frosch123> so, you mean it's rather related to the pathfinder and route construction?
19:11:17 <frosch123> instead of the tree stuff?
19:11:44 <krinn> the tree stuff is old stuff, it has never do such thing
19:12:41 <krinn> as the area is good if you consider a* nodes
19:13:50 <Rubidium> LordAro: I'm not doing that for each and every release, and it's not that important for trunk. It'll get there eventually
19:15:39 <Rubidium> LordAro: I'm not sure migrating to SDL 2.0 is going to happen "soon"
19:15:47 <krinn> frosch123, that must be that, i don't remember, but i was working on pathfinding, and the hypothesis looks ok with the area involve
19:15:49 * andythenorth did a lego troll :(
19:16:17 <Rubidium> LordAro: mostly because then the generic binaries will fail basically everywhere
19:18:51 <Alberth> make brickland sprites?
19:18:53 <Rubidium> LordAro: it looks like you might want an SDLv2 video driver
19:48:56 *** Devroush has joined #openttd
19:52:38 <LordAro> Rubidium: so maybe in a couple of years time?
19:54:49 <planetmaker> LordAro, it still may make sense to add that. But keep using 1.2 as default
19:55:03 <planetmaker> configure and detection of available libraries could take care of that
20:00:27 <LordAro> planetmaker, but the generic binaries would have to use 1.2 (at least for now), right ?
20:01:34 <planetmaker> that's the matter of defaults, yes. Like you can have SDL installed on windows or osx as well. Yet by default you'll get the GDI or cocoa binaries
20:04:52 <__ln__> is it the yearly SDL on OSX discussion again?
20:07:01 <LordAro> SDL 2.0 on everything discussion :)
20:07:35 <glx> I though SDL 2 was dead ;)
20:08:18 <LordAro> new website too, for that matter
20:08:37 <planetmaker> released like... this week, glx
20:09:25 <LordAro> a few hours ago, i believe, actually :)
20:11:00 <planetmaker> hm... PDT. whatever
20:13:44 <LordAro> 14 hours ago, then :p
20:13:56 <LordAro> according to some probably overcomplicated googling
20:31:48 *** HerzogDeXtEr has joined #openttd
20:48:12 *** Ristovski has joined #openttd
21:08:39 *** megakacktus has joined #openttd
21:10:36 <Eddi|zuHause> forum still slow :/
21:13:02 <frosch123> but does it improve the quality of the content?
21:17:50 *** tokai|mdlx has joined #openttd
21:21:28 <Eddi|zuHause> no idea, when i can't get to it :p
21:22:11 <frosch123> does that in itself improve it? :p
21:23:38 *** valhallasw has joined #openttd
21:25:29 <Xaroth|Work> TWerkhoven: it appears all dates are off by 1 day, as provided by libottdadmin2
21:25:44 <Xaroth|Work> so I think the gamedate_to_datetime is off
21:25:56 <Xaroth|Work> (checking map info shows start date always at jan 2 as well)
21:28:20 <Bad_Brett> i think i'm going insane
21:29:34 <Bad_Brett> who came up with this "extra turning angles" stupidity? ;)
21:42:36 <Eddi|zuHause> it was certainly not my idea
21:42:54 <Eddi|zuHause> only parts of the concept were developed by me
21:49:16 <Xaroth|Work> hm, dev.openttdcoop.org is also sluggish.. if it ever responds
21:49:53 <frosch123> yup, but that is planned
21:54:36 <Bad_Brett> well, you were the one who introduced me to it
21:56:15 *** andythenorth has left #openttd
21:56:37 <Bad_Brett> and now i'm trying to do one with 128 angles, which seemed to be a good idea until I started working on it
21:58:24 <Xaroth|Work> bye bye openttdcoop proxies
21:58:33 <LordAro> oop, looks like the ottdcoop bouncer just broke
21:58:44 <frosch123> the server is rebooting
21:58:51 <frosch123> are you not in the important channels?
21:59:06 <DorpsGek> LordAro: yexo was last seen in #openttd 36 weeks, 4 days, 8 hours, 42 minutes, and 34 seconds ago: <Yexo> <NGC3982> The station glitches are CHIPS related. I adressed it to Andy the other day, and it seems like it's b0rked in some way. <- it's still in the issue tracker for CHIPS, but I haven't had time to look at it yet
21:59:25 <LordAro> and with that, g'mnight all from me also
21:59:29 *** planetmaker has joined #openttd
21:59:29 *** ChanServ sets mode: +o planetmaker
22:01:14 *** amiller has joined #openttd
22:01:28 *** ^Spike^ has joined #openttd
22:01:58 *** XeryusTC has joined #openttd
22:01:58 *** V453000 has joined #openttd
22:02:40 *** fonsinchen has joined #openttd
22:04:34 <^Spike^> Xaroth|Work me broke it sort of :D
22:04:47 <Xaroth|Work> TWerkhoven: in -theory- you can call self._rcvChat(irc, **data) .. it turns the data dict into keyword args (so _rcvChat(irc, action, destType, clientID, message, data) )
22:04:53 <Xaroth|Work> ^Spike^: figures :P
22:04:58 <^Spike^> should be fixed now :)
22:05:51 <^Spike^> atleast 1 advantage: I know what i broke :D
22:06:58 <^Spike^> time for bed now as it works :D
23:06:26 *** Stimrol has joined #openttd
23:22:42 *** amiller has joined #openttd
23:32:56 *** eQualizer has joined #openttd
continue to next day ⏵
