Log for #openttdcoop.devzone on 24th January 2011:
Times are UTC Toggle Colours
00:19:45  *** ZuRiP has joined #openttdcoop.devzone
00:19:45  *** ZuRiP has left #openttdcoop.devzone
01:18:41  <Brot6> OpenGFX - Feature Request #2201 (New): Full maglev coal wagons are too bright (DJNekkid) @
01:26:31  *** KenjiE20 has quit IRC
02:32:27  *** Brot6 is now known as Guest1402
02:32:27  *** Guest1402 has quit IRC
02:32:39  *** Brot6 has joined #openttdcoop.devzone
02:33:33  *** Brot6 has quit IRC
02:34:18  *** Brot6 has joined #openttdcoop.devzone
05:33:03  <Brot6> Bundles Update: g24ae2307 2011-01-24 cargodist   (
09:34:59  *** ODM has joined #openttdcoop.devzone
09:35:57  *** ODM has quit IRC
09:47:22  *** andythenorth has joined #openttdcoop.devzone
09:47:31  *** andythenorth has left #openttdcoop.devzone
09:55:24  * dihedral pokes planetmaker 
10:00:47  <planetmaker> ja?
10:11:07  <V453000> nein :)
10:11:15  <dihedral> jawohl
10:11:52  <dihedral> i have some questions regarding handling of a bot
10:12:13  <dihedral> supybot handlines commands with ![<plugin> ]<cmd>
10:12:31  <dihedral> <plugin> is optional, and the space separates <plugin> from <cmd>
10:13:05  <dihedral> however programming wise i find that logic a little hard to follow, so i was wondering if there might be another char that could be used instead of the space
10:13:13  <dihedral> any ideas / hints ?
10:14:42  <dihedral> e.g. !plugin.cmd or !plugin:cmd or !....something
10:15:51  <planetmaker> use the hypen
10:16:00  <planetmaker> math-sqrt(2)
10:16:22  <planetmaker> mod-kick 63
10:16:38  <planetmaker> admin-set max_trains 1500
10:16:55  <planetmaker> or the slash
10:17:02  <dihedral> admin/set hehe
10:17:02  <planetmaker> admin/set max_trains 1500
10:17:11  <dihedral> slash over . ?
10:17:29  <planetmaker> or period. But that might collide with math.calc 2.0+3.0
10:17:49  <dihedral> nah - because i would only check the first 'word' for a . :-)
10:17:49  <planetmaker> but so might the slash and hyphen. Not sure
10:18:11  <dihedral> the issue with space that i see is, if there was a plugin and a command with the same name
10:18:12  <dihedral> :-D
10:19:06  <dihedral> then the question would arise: is the second word a argument or a command name :-P
10:20:26  <planetmaker> I think though that space might be the most commonly expected character to separate things
10:20:52  <Ammler> rbot does it like supybot
10:21:05  <planetmaker> rcon uses it. Current bots around here use it. So... it'd be not too user friendly to make them suddenly use another char.
10:21:20  <planetmaker> I'd never remember, I learn very slow to adopt to new commands ;-)
10:21:28  <planetmaker> ask Ammler, he can tell you about it :-P
10:21:35  <dihedral> hehe
10:30:15  <dihedral> hehe
10:30:22  <dihedral> you guys did something at redime?
10:30:28  <dihedral> <- translation missing ...
10:31:43  <dihedral> and my last commits are not visible at redmine
10:33:04  *** ODM has joined #openttdcoop.devzone
10:35:11  <Ammler> dihedral: yes, somehow the hook to push to redmine is broken
10:35:42  <dihedral> ha
10:36:02  <dihedral> well - just wanted to report ;-)
10:36:08  <dihedral> in your own time :-D
10:36:11  <dihedral> hihi
10:37:41  <Ammler> it does pull every .44
10:37:46  <Ammler> still quite silly
10:37:51  <Brot6> Grapes - Revision 46:ac4994d29db1: Cleanup: remove unused import (dih) @
10:37:51  <Brot6> Grapes - Revision 47:78e615a23b44: Cleanup: remove unused import (dih) @
10:37:51  <Brot6> Grapes - Revision 48:094497657642: Cleanup: style (dih) @
10:37:51  <Brot6> Grapes - Revision 49:539393391158: Add: a set of interfaces for message / command handling (dih) @
10:37:54  <Brot6> Grapes - Revision 50:3b934c4187ed: Change: CommandContext extends MessageContext and is too an in... (dih) @
10:37:58  <Brot6> Grapes - Revision 51:f33f0d527ff1: Add: implementation of just introduced interfaces (dih) @
10:38:01  <Brot6> Grapes - Revision 52:f121da2c36f4: Change: visibility - this class should be extended later on (dih) @
10:38:05  <Brot6> Grapes - Revision 53:48968012f084: Cleanup: style (dih) @
10:38:11  <Ammler> the log does report the sudo
10:38:36  <Ammler> Jan 24 10:26:37 dev sudo:       hg : TTY=unknown ; PWD=/home/hg/grapes ; USER=dev ; COMMAND=/home/dev/ /home/hg/grapes
10:39:18  <Ammler> Jan 24 10:37:21 dev sudo:       hg : TTY=pts/0 ; PWD=/home/hg ; USER=dev ; COMMAND=/home/dev/ /home/hg/grapes
10:39:24  <Ammler> the only differenece is TTY
10:43:45  <dihedral> wow
10:45:39  <dihedral> and the sudo command failes?
10:45:56  <dihedral> pwd is different too
10:58:38  <Ammler> <-- nothing in the script which refers to $PWD
11:01:18  <dihedral> i ment in the sudo logs you pasted up above
11:01:58  <Ammler> <-- the hook runs as the releases do build instantely
11:03:54  *** DayDreamer has joined #openttdcoop.devzone
11:22:09  <dihedral> Ammler, can you paste the contents of script/runner
11:22:20  <dihedral> unless of course it is binary :-P
11:22:25  <Brot6> 2cc train set - Feature #2202 (New): FS Class 880 (Voyager1) @
11:22:51  <dihedral> heh ^ that worked ^^
11:37:19  *** KenjiE20 has joined #openttdcoop.devzone
11:50:35  <Ammler> dihedral:
11:50:42  <Ammler> don't think, that helps you :-)
11:51:04  <dihedral> grrr
11:51:11  <dihedral> commands/runner ? :-P
11:51:45  <Ammler> repo devzone is the current productive redmine
11:51:50  <dihedral> ok
11:57:57  <dihedral> cannot find a commands folder
11:58:27  <dihedral> looking at
11:59:39  <dihedral> so if it is missing, that would be why it's failing :-P but i somehow doubt it's really missing - i rather think i am failing to find it
12:00:00  *** thgergo has joined #openttdcoop.devzone
12:00:40  <dihedral> uh - a thgergo :-)
12:00:49  <dihedral> that's a nick i've not seen in a while
12:00:56  <thgergo> im here for ages:P
12:01:05  <thgergo> about a half year by now
12:01:08  <thgergo> I think
12:01:16  <thgergo> hello
12:01:50  <thgergo> this channel is on my auto-join list
12:04:11  <Ammler> dihedral: I doubt if I run the exact same script from shell, it works, but not if it runs from the hook because of that
12:04:33  <Ammler> I highly suspect TTY
12:06:55  <Ammler> I will make the hook a bit more verbose and play around with the test repo, but not now... :-)
12:08:39  <dihedral> i cannot see how the tty could cause such an issue :-S
12:09:13  <dihedral> where does the sudo command come from (which script)
12:09:18  <dihedral> is it directly in the hook?
12:09:33  <dihedral> i could assume sude rights or path to be an issue
12:09:48  <dihedral> if $PATH was not set as expected, that could fail
12:10:49  <Ammler> everyhting has full paths
12:11:13  <Ammler> I pasted the involved hook and the scripts
12:11:42  <Ammler> changegroup.uprepos = /home/hg/misc/compiler/ 1>/dev/null 2>&1 & <-- this is in .hgrc
12:13:30  <dihedral> thgergo, sorry i did not notice you :-(
12:13:45  <dihedral> but anyway, nice to see you :-)
12:14:08  <thgergo> no problem, I havent been active here
12:14:17  <dihedral> hehe
12:14:41  <dihedral> Ammler, hmm - sorry i cannot debug further
12:14:53  <Ammler> thanks anyway :-)
12:14:54  <dihedral> i'd love to know what is causing the issue
12:14:58  <Ammler> I can't either right now
12:15:13  <dihedral> :-P
12:34:45  <Brot6> 2cc train set - Feature #2203 (New): EB10 (Voyager1) @
12:42:07  *** DayDreamer has quit IRC
15:04:29  *** Lakie has joined #openttdcoop.devzone
15:24:19  <Ammler> planetmaker: you don't like compiler maintenance per repo, I guess a solution would be to make the maintenance in seperate branch like devzone
15:25:25  <planetmaker> you mean a separate repo for the CF?
15:25:33  <planetmaker> that'd be probably a good solution
15:25:49  <Ammler> no, a special branch for the repos
15:26:07  <planetmaker> well, that'd be the repo then still, no?
15:26:12  <Ammler> which you can safely ignore from Makefile etc.
15:26:51  <Ammler> you could quite easy strip such a branch without changing hash of the "main" branches
15:27:40  <Ammler> now changing .devzone does mostly affect history, I thought that is what concerns you
15:28:04  <planetmaker> doing so in branches does so, too.
15:28:10  <Ammler> how?
15:28:26  <planetmaker> it changes the revision number
15:28:48  <planetmaker> so changing the CF's build options changes the grf which is being built
15:28:54  <Ammler> oh well, that does not really matter
15:29:13  <planetmaker> but that's what feels wrong to me
15:29:16  <Ammler> I use the hash to determine if a version has changed
15:29:43  <planetmaker> yeah. So I present the newgrf version as h290d10ABF49A
15:29:49  <planetmaker> not feasable
15:29:58  <Ammler> you can still use rev number
15:30:10  <planetmaker> but that changes. And that's the point
15:30:23  <Ammler> no
15:30:27  <planetmaker> why not a separate CF repo?
15:30:36  <Ammler> head of default doesn't change if you change branch devzone
15:30:52  <Ammler> a cf repo for every repo?
15:31:00  <planetmaker> no. One for all
15:31:07  <Ammler> how to manage access?
15:31:28  <planetmaker> Admins and some managers.
15:31:50  <planetmaker> No one is anyway able to configure the CF settings on their own.
15:32:04  <planetmaker> every one so far has to ask.
15:32:28  <planetmaker> And as such, enabling the CF for a project or their mode can just as well be managed via such global thing
15:32:36  <planetmaker> it'd also keep the repos separate and the CF
15:32:42  <planetmaker> which is the normal approach
15:33:17  <Ammler> well, it is nice, if the repos do also have build scripts
15:33:36  <Ammler> I might also remove the default script and add the spec to every repo
15:33:36  <planetmaker> I mean... look at openttd. It just pulls the repo. And then builds it. And the CF is configured to pull this and that repo and build it with these and those options
15:34:35  <planetmaker> The CF might use a build script from the repo - if some repo requires a special one. But submitting to 95% of the repos a default thing is... more work than needed, too
15:34:35  <Ammler> the openttd CF is for openttd only or whatever rubi enables
15:34:46  <Ammler> our compiler can build everything
15:35:37  <Ammler> also our compiler doesn't need to trust the source
15:36:51  <planetmaker> having a build script in a repo which tells how to build something: that's one thing.
15:37:26  <Ammler> yeah, I meant that
15:37:28  <planetmaker> But having the frequency and mode a particular CF shall compile the project etc in the repo. That's another. And that's wrong IMHO
15:37:40  <Ammler> agreed
15:37:53  <Ammler> I would like to move that to a branch
15:37:59  <planetmaker> ...
15:38:06  <planetmaker> but branch = part of repo
15:38:09  <Ammler> or redmine plugin or whatever
15:38:19  <Ammler> planetmaker: not if the parent is null, imo
15:38:38  <planetmaker> ?
15:38:42  *** DanMacK has joined #openttdcoop.devzone
15:39:24  <Ammler> those are just like 2 unrelated merged repos
15:39:56  <planetmaker> how uncool is that?
15:40:09  <planetmaker> when I clone the repo I clone thus also the CF settings...
15:40:27  <Ammler> yes, but you don't see those
15:40:58  <Ammler> hmm, maybe hg has an option to hide a branch from default pull
15:41:18  <Ammler> well, those are just thoughts
15:42:55  <Ammler> also e.g. openttd does have the website in the repo or other not really very related things to the openttd trunk
15:43:15  <Ammler> so using that as example might not work too :-)
15:44:06  <Ammler> most svn users checkout trunk, not the whole repo, why isn't that possible with hg repos?
15:45:10  <planetmaker> <-- quote from hg page ;-)
15:45:25  <planetmaker> so comparing svn vs hg might fail :-P
15:45:41  <planetmaker>
15:45:42  <Webster> Title: UnderstandingMercurial - Mercurial (at
15:46:45  <Ammler> well, building meta infos are related to the project
15:47:20  <planetmaker> but it's not a meta-info to switch on or off the use of the CF. Or re-building on every push. That's ... unrelated.
15:48:13  <planetmaker> telling the CF to (not) build and when to build is no useful information for the project. It's only useful information for the CF.
15:48:31  <planetmaker> And the managers of the project which should be able to change that.
15:48:37  <Ammler> well, it might also be interesting to have the build logs in that branch
15:48:49  <planetmaker> woot? No.
15:49:05  <planetmaker> Not at all. They have no place in the _repository_
15:49:11  <planetmaker> It's like committing the grf
15:49:14  <planetmaker> or the binary
15:50:09  <planetmaker> I just wonder why you don't see that these info all are not supposed to be part of a repo.
15:50:21  <Ammler> the problem is, I can't move teh whole thing to obs
15:50:54  <Ammler> as then it is too complicated for some to maintain the building
15:51:01  <Ammler> also maybe overkill anyway
15:51:36  <Ammler> planetmaker: I agree to keep those off from the history
15:51:44  <planetmaker> from the repo
15:51:45  <Ammler> I see no issue to have those data in the repo
15:51:54  <Ammler> as you have quite easy a repo without
15:51:58  <planetmaker> I do. In repo = in history
15:52:20  <planetmaker> whether branch or whatever.
15:52:32  <Ammler> as long as they don't influence the hash, it should not matter
15:52:45  <planetmaker> I don't commit the output of each of my compiles either. Nor the command I used to compile nor my possible crontab script
15:53:24  <Ammler> the only alternative is something similar to the Hudson plugin
15:53:51  <planetmaker> I don't know how that works. But possibly
16:01:25  <Ammler> I guess, the debian build system does also work similar to my idea
16:02:10  <Ammler> but with git, is is a bit easier to "hide" meta information, afaik
16:06:32  <Brot6> feed NewGRFs had 15 updates, showing the latest 10
16:06:32  <Brot6> 2cc train set - Feature #2147 (Closed): ChME2 (DJNekkid) @
16:06:32  <Brot6> 2cc train set - Feature #2154 (Closed): NMBS/SNCB Class 83 (DJNekkid) @
16:06:32  <Brot6> 2cc train set - Feature #2151 (Closed): SAR Class ES (DJNekkid) @
16:06:33  <Brot6> 2cc train set - Feature #2150 (Closed): DB Class 169 (DJNekkid) @
16:06:36  <Brot6> 2cc train set - Feature #2149 (Closed): DB Class 270 (DJNekkid) @
16:06:39  <Brot6> 2cc train set - Feature #2178 (Closed): MAV Class 377 (DJNekkid) @
16:06:44  <Brot6> 2cc train set - Feature #2177 (Closed): SW1200 (DJNekkid) @
16:06:47  <Brot6> 2cc train set - Feature #2162 (Closed): SJ V4 (DJNekkid) @
16:06:50  <Brot6> 2cc train set - Feature #2161 (Closed): ALCO S-2 (DJNekkid) @
16:06:53  <Brot6> 2cc train set - Feature #2179 (Closed): SBB E 3/3 (DJNekkid) @
16:07:33  <Brot6> feed NewGRFs had 13 updates, showing the latest 10
16:07:33  <Brot6> 2cc train set - Feature #2184 (Closed): HŽ Class 51 (DJNekkid) @
16:07:33  <Brot6> 2cc train set - Feature #2186 (Closed): VL41 (DJNekkid) @
16:07:33  <Brot6> 2cc train set - Feature #2197 (Closed): Le Belge (DJNekkid) @
16:07:34  <Brot6> 2cc train set - Feature #2198 (Closed): GWR Class 5700 (DJNekkid) @
16:07:37  <Brot6> 2cc train set - Feature #2199 (Closed): 9P (DJNekkid) @
16:07:40  <Brot6> 2cc train set - Feature #2194 (Closed): OBB 1161 (DJNekkid) @
16:07:45  <Brot6> 2cc train set - Feature #2192 (Closed): Gravita 10BB (DJNekkid) @
16:07:48  <Brot6> 2cc train set - Feature #2203 (Closed): EB10 (DJNekkid) @
16:07:51  <Brot6> 2cc train set - Feature #2202 (Closed): FS Class 880 (DJNekkid) @
16:07:54  <Brot6> 2cc train set - Feature #2200 (Closed): Milwaukee Road ES-2 (DJNekkid) @
16:10:52  <Brot6> 2cc train set - Feature #2177 (Closed): SW1200 (DJNekkid) @
16:10:52  <Brot6> 2cc train set - Bug #2180 (Closed): blablabla from neko (DJNekkid) @
16:12:00  <Brot6> 2cc train set - Feature #2161 (Closed): ALCO S-2 (DJNekkid) @
16:27:17  <planetmaker> yes, looks like something like the hudson plugin might be very nice.
17:18:20  <Brot6> 2cctrainset: update from r720 to r721 done (6 errors) -
17:19:04  <Brot6> nutracks: update from r162 to r165 done -
17:19:14  <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r39), ai-admiralai (r75), ai-aroai (r11), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r70), basecosts (r22), belarusiantowns (r8), bros (r45), comic-houses (r71), firs (r1631), fish (ERROR r532), frenchtowns (r6), grfcodec (r821), heqs (r567), indonesiantowns (r41), manindu (r6), metrotrackset (r56), narvs
17:19:14  <Brot6> (r5), newgrf_makefile (r254), nml (r1138), ogfx-industries (r3), ogfx-landscape (r22), ogfx-rv (r78), ogfx-trains (r201), ogfx-trees (r42), opengfx (r593), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r45), spanishtowns (r10), swedishrails (r193), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), ttrs (r24), worldairlinersset (r671)
18:05:32  <Ammler> maintenance mode for hg| ....
18:06:17  <DJNekkid> Ammler: is it hard to get my server to be able to build a windows exe as well?
18:09:56  <Ammler> yes
18:10:03  <Ammler> why is that needed?
18:10:13  <Ammler> you can download those from
18:10:52  <planetmaker> nutracks.exe :-P
18:10:55  <Ammler> crosscompiling of openttd isn't that straight forward, maybe the wiki does help you, if it works, please tell me
18:11:14  <DJNekkid> well, there are some patches i would like to be able to build
18:11:24  <DJNekkid> and doing it on windows have i given up on ages ago :P
18:11:35  <planetmaker> better even: note down in the wiki
18:11:46  <Ammler> afaik, it is easier to build on windows as crosscompiling on linux
18:11:47  <planetmaker> Cross compiling mostly not trivial
18:11:59  <Rubidium> DJNekkid: if you fail on Windows, then you'll definitely fail with cross-compiling
18:12:08  <DJNekkid> Rubidium: oki, nice to know
18:12:15  <DJNekkid> it were AGES ago tho
18:12:33  <Rubidium> even then, Windows cross-compiling is (for cross-platform cross-compiling) the least hard as far as I'm aware
18:12:37  <Ammler> well, setup mingw works now
18:12:42  <DJNekkid> perhaps if i install  that microsoft dev-thingy
18:12:44  <Ammler> just check the updated wiki from Terken
18:12:58  <DJNekkid> and i can do the svn and patching in linux
18:13:25  <DJNekkid> iirc were it there i failed in the first attempts
18:13:29  <Ammler> mingw has become again working and easy
18:13:31  <planetmaker> cross compiling means: make a compiler on linux use all necessary windows libraries and compile a binary for another system. Thus it needs to have re-defined all defaults a usual compiler can use
18:13:50  <Ammler> also cygwin should again work, afaik
18:14:18  <planetmaker> the typical linux->windows cross-compilation environment is to setup a mingw environment on linux ;-)
18:14:33  <DJNekkid> lol...
18:14:42  <planetmaker> though it might exist as package even for easy install
18:15:03  <Ammler> yes, suse has mingw packages to build windows apps with obs
18:15:09  *** frosch123 has joined #openttdcoop.devzone
18:15:11  <Ammler> but I didn't check them yet
18:15:17  <planetmaker> port search mingw
18:15:18  <planetmaker> i386-mingw32-binutils @2.19.1 (cross, devel)
18:15:19  <Rubidium> but you'll likely need to cross-compile the dependencies for OpenTTD, which makes it somewhat less trivial
18:15:20  <DJNekkid> but if i install that Microsoft virtual dev-thingy (cant remember its name atm)
18:15:20  <planetmaker>     Mingw32 Binutils for i386-mingw32 cross development
18:15:33  <planetmaker> quite indeed, yes
18:15:39  <DJNekkid> and then i do the svn and patch-stuff on the linux machine it would be easy
18:16:04  <Ammler> afaik mingw is easysier as MSVC
18:16:22  <planetmaker> it's more unix-like
18:16:27  <Rubidium> svn and patch stuff are more or less equal in mingw, if you install subversion and get the right patch
18:16:29  <planetmaker> thus many things work similar
18:19:32  <DJNekkid> i'll take a look at it later :)
18:26:43  <Ammler> [19:05] <Ammler> maintenance mode for hg| .... <-- should run again (uWSGI)
18:27:18  <Ammler> now debugging hooks :-)
18:53:47  <Brot6> test: compile of Hallo failed -
18:57:02  <DJNekkid> hmm
18:57:05  <DJNekkid> thoose B-unit engines
18:57:24  <DJNekkid> should the 'b-unit' also be the 'end unit' if they are configured in push/pull
19:02:42  <Brot6> 32bpp-ez-patches: update from r21905 to r21906 done -
19:05:32  <Brot6> clientpatches: update from r21488 to r21488 done -
19:06:40  <Hirundo> 'b-unit' is what engines like american E-unit / F-unit have?
19:06:41  <Brot6> serverpatches: compile of r21906 still failed (#2080) -
19:07:13  <DJNekkid> yes
19:07:26  <DJNekkid> sharknose, genesis, and a handfull others
19:08:50  <Hirundo> hmm...
19:08:57  <DJNekkid> it isnt an issue when the B-unit is 'just' a reverse one, but there are a few where the gfx is a 'wagon-like' thing
19:09:01  <DJNekkid> no window etc
19:09:27  <Hirundo> Is there any support for 'real' push-pull in 2cc, like with some tender engines in UKRS (haven't checked recently)
19:09:29  <Hirundo> ?
19:09:33  <DJNekkid> no
19:09:52  <Hirundo> how do you decide if it is a b-unit?
19:10:11  <DanMacK> B unit has no cab'
19:10:11  <DJNekkid> ehm ... its american and its diesel :P
19:10:23  <DJNekkid> *what he saied*
19:11:00  <DJNekkid> <-- B-unit
19:11:07  <Hirundo> I meant, how do you decide whether to draw a B-unit in nfo
19:11:09  <DJNekkid> <-- not B-unit
19:11:26  <DJNekkid> well, thats what i need to decide
19:11:29  <DJNekkid> variable 40 or 41
19:12:48  <Hirundo> If (vehicle in front has same id) then b-unit else normal-unit?
19:13:00  <DJNekkid> hold on :D
19:13:10  <Hirundo> if you want a reverse unit at the end of your train, you can just buy while holding ctrl to reverse it
19:13:19  <DJNekkid> yes, i know
19:13:58  <DJNekkid> but for example, i could have    front-wagons-bunit(no cab)-wagons
19:14:10  <DJNekkid> but with 41 the middle one would be with cab
19:14:20  <DJNekkid> but i could have two checks, thats no problem
19:15:32  <Brot6> 2cc train set - Revision 722:a6d387ab9efb: Change: The american B-unit now draw the B-unit if it ... (DJNekkid) @
19:15:40  <DJNekkid> take a look at line 210 of sprites/nfo/templates/engine.pnfo
19:17:39  <Hirundo> looking at it now
19:19:20  <Hirundo> yes, I see what that varact2 does
19:19:51  <DJNekkid>
19:19:56  <DJNekkid> could also do like that
19:20:19  <DJNekkid> that way would the end unit be one with cab
19:20:46  <Hirundo> but not reversed as you'd want, right?
19:21:00  <DJNekkid> the user would have to ctrl-click it in that case
19:21:13  <DJNekkid> unless there is a nice way to turn the gfx around
19:21:28  <DJNekkid> by default i mean
19:22:37  <Hirundo> I fear there might be none
19:22:55  <DJNekkid> no, not that i know of either
19:22:58  <Hirundo> I'll take a quick glance at the ottd source to see if I can find any trace
19:22:59  <DJNekkid> only if it were articulated
19:24:28  <DJNekkid> YAFR? :D
19:24:50  <Hirundo> I'd try :) it'd be nice to get something like that in before 1.1
19:25:06  <Hirundo> gotta do dishes now though, back in 15-30 mins or so
19:25:06  <DJNekkid> indeed
19:26:20  <DJNekkid> hmm
19:26:22  <DJNekkid> i wonder
19:27:09  <DJNekkid> if bit 6 or 7 were set in var40/41, the non-default result would be a flipped variant
19:27:27  <DJNekkid> no, i might be thinking wrong
19:28:13  <DJNekkid> hmm, something can only be 100 units long
19:28:29  <DJNekkid> so bit7 could perhaps do something
19:32:14  <DJNekkid> hmm, no, it probably needs an var2 alltogether
19:44:54  <DJNekkid> i think i might have an idea afterall Hirundo
19:47:54  <Hirundo> DJNekkid: I'm back, now tell me what's the idea :) ?
19:48:34  <DJNekkid> im working on it
19:48:48  <DJNekkid> in inculded bit7 of variable 40/41
19:49:03  <DJNekkid> but first a question, if you can awnser it
19:49:17  <DJNekkid> if i use 'type' 83 (read word size)
19:49:43  <DJNekkid> or i mean, that would be bit31 or something
19:49:47  <DJNekkid> point was
19:49:49  <DJNekkid> if i use 'type' 83 (read word size)
19:50:17  <DJNekkid> then i check the 4 lowest bytes in the mentioned variable, right?
19:51:02  <DJNekkid> i.e. i can check both 'ff' and 'bb' at once?
19:51:27  <Hirundo> type 83 is a randomaction2 type
19:51:42  <DJNekkid> 85 then
19:51:43  <DJNekkid> :)
19:51:48  <Hirundo> type 85 is word (2 bytes), type 89 is dword (4 bytes)
19:51:53  <DJNekkid> the one that check for 'word size'
19:52:33  <DJNekkid> i GOTTA test that
19:56:55  <DJNekkid> dont seem like it
19:57:48  <DJNekkid> or i just gotta think streight
20:02:05  <DJNekkid>
20:02:22  <DJNekkid> this gives a a B-unit if its 3 engines in a row
20:02:40  <DJNekkid> but if i insert a wagon or something it turns to a front
20:03:31  <Hirundo> I could come up with this:
20:04:05  <Hirundo> I couldn't find a way around the double variable access, although it shouldn't really matter as it's cached
20:05:47  <DJNekkid> /!!Fatal Error (42): Length does not match nvar of 02. (Expected 23 bytes)
20:05:58  <DJNekkid> does it lack '10 00' in the end?
20:05:59  <Hirundo> <- fixed version
20:06:22  <Hirundo> At least, I was missing the 'num-ranges' somewhere
20:07:31  *** andythenorth has joined #openttdcoop.devzone
20:07:33  *** andythenorth has left #openttdcoop.devzone
20:07:43  <Hirundo> ah, some bit of the varadjust needs to be set also
20:09:00  <Hirundo> <- yet another fix, I'm not that used to hand-writing nfo it seems
20:09:20  *** andythenorth has joined #openttdcoop.devzone
20:10:25  <DJNekkid> btw, front is 10 00, B is 50 00
20:11:13  <Hirundo> how to do 'rear' (w/o doubling sprite count) remains a mystery to me
20:11:26  <DJNekkid> ctrl-click :P
20:11:29  <Brot6> Backup test: abort: no suitable response from remote hg!
20:11:32  <DJNekkid> no error on that last code
20:12:35  <DJNekkid> buuut: congratulations :D
20:12:41  <DJNekkid> that actually works!
20:14:49  <DJNekkid> now what if that 85 were 89
20:15:14  <DJNekkid> and if bit31 was set, the cargoid(gfx) would be flipped?
20:15:15  <Hirundo> Then you need \d instead of \w everywhere
20:15:24  <Hirundo> bit 31 set on what?
20:15:50  <DJNekkid> variable 40/41
20:16:00  <DJNekkid> the one that dont exsist yet
20:16:06  <DJNekkid> hehe
20:16:14  <Hirundo> you can read the 'reversed' flag out somewhere
20:16:20  <Hirundo> lemme check
20:16:41  <DJNekkid> modflag FE/FF
20:18:21  <Hirundo> no, that doesn't work, that's the global reversing flag that's flipped every time you reverse
20:18:40  <Hirundo> you'll need to read 0x80+0x48, the sprite number
20:19:01  <Hirundo> that's 0xFD for normal and 0xFE for reversed
20:21:29  <DJNekkid> -1 * 0  02 00 <id> 80 48 00 FF 01      10 00 FE FE     10 00 ?
20:22:32  <Hirundo> 80 + 48 ==> C8
20:29:26  <DJNekkid>
20:29:38  <DJNekkid> probably just me missunderstanding, but none the less
20:31:33  *** andythenorth_ has joined #openttdcoop.devzone
20:32:23  <DJNekkid> howdy andythenorth_:D
20:32:32  <andythenorth_> hi
20:34:35  <DJNekkid> Hirundo: i dont think we really need to flip the sprite, as the 'end unit' would need red lights
20:35:08  <Hirundo> true
20:35:40  *** andythenorth has quit IRC
20:36:13  <DJNekkid> then i think im gonna leave it as it is, and then update the code when i get around to change thoose lights... i dont feel like messing with gfx right now, but that code piece of yours is really nice :D
20:40:35  <Brot6> 2cc train set - Revision 723:833952344be0: Change: the B-unit code from hirundo's magic liberary (DJNekkid) @
20:44:30  *** andythenorth has joined #openttdcoop.devzone
20:47:57  *** andythenorth__ has joined #openttdcoop.devzone
20:49:15  <Brot6> 2cc train set - Revision 724:b05f477270e8: Change: Only the ones with cabless B-units need that p... (DJNekkid) @
20:50:24  *** andythenorth__ has quit IRC
20:51:27  *** andythenorth_ has quit IRC
20:51:47  *** andythenorth_ has joined #openttdcoop.devzone
20:53:04  *** andythenorth__ has joined #openttdcoop.devzone
20:54:49  *** andythenorth has quit IRC
20:56:36  * DanMacK senses some equipment in Andy's household is going to to go flying soon
20:57:02  <Brot6> 2cc train set - Feature #2189 (Closed): BR Class 14 (DJNekkid) @
20:57:02  <Brot6> 2cc train set - Feature #2081: More Graphical Improvements (DJNekkid) @
20:59:53  *** andythenorth_ has quit IRC
21:04:37  <Brot6> 2cc train set - Feature #2184 (Closed): HŽ Class 51 (DJNekkid) @
21:04:37  <Brot6> 2cc train set - Feature #2081: More Graphical Improvements (Voyager1) @
21:13:26  <Brot6> 2cc train set - Revision 725:31ad07062f89: Change: New Shinkansen700 gfx. Close #2125 (DJNekkid) @
21:13:26  <Brot6> 2cc train set - Revision 726:31e28ec4198f: Add: Two more units, close #1744, Close #1926 (DJNekkid) @
21:13:26  <Brot6> 2cc train set - Feature #2125 (Closed): Shinkansen Series 700 redrawn (DJNekkid) @
21:13:27  <Brot6> 2cc train set - Feature #1744 (Closed): Railbus 670 (DJNekkid) @
21:13:30  <Brot6> 2cc train set - Feature #1926 (Closed): Le Brugeoise (DJNekkid) @
21:16:32  <Brot6> 2cc train set - Feature #2128 (Closed): American B-unit needs proper implementation (DJNekkid) @
21:20:44  <DJNekkid> and then it were that god damn vehicle ID scheme
21:23:17  *** frosch123 has quit IRC
21:56:25  *** andythenorth__ is now known as andythenorth
22:07:00  *** andythenorth has left #openttdcoop.devzone
22:29:27  *** ODM has quit IRC
22:30:18  *** dihedral has quit IRC
22:42:53  *** DanMacK has quit IRC

Powered by YARRSTE version: svn-trunk