IRC logs for #opendune on OFTC at 2012-12-04
            
01:20:45 <TrueBrain> Xaroth: why did you break our commit style? Pfff :P
01:20:50 <TrueBrain> -Fix (#141): .... ;)
01:21:07 <TrueBrain> lolz, we have our first fork
01:21:09 <TrueBrain> scary
01:25:04 <TrueBrain> Qt implementation
01:25:05 <TrueBrain> lolz
01:30:01 <TrueBrain> we have to see how we are going to make new commit messages
01:30:20 <TrueBrain> I really hate the 'default' github way, where you put 'fixes #N' and 'closes #N' at the end
01:30:30 <TrueBrain> often it falls off (As it cuts commit messages after N chars)
01:30:35 <TrueBrain> while it is one of the more important things
01:30:43 <TrueBrain> so maybe: -Fix #141: blabla
01:30:47 <TrueBrain> -Close #141: blabla
01:30:56 <TrueBrain> something like that ... well, always -Fix for us I am sure
01:31:04 <TrueBrain> github should pick up on that ...
04:53:06 *** glx has quit IRC
08:08:20 <Xaroth|Work> rgr
08:08:38 <Xaroth|Work> (it was your idea to end with 'closes #N' anyhow :P )
09:59:20 <Xaroth|Work> and I don't get that fork's commits
09:59:30 <Xaroth|Work> src/script/unit.c . src/script/scriptunit.c
11:03:10 <TrueBrain> unique names
11:03:14 <TrueBrain> often an issuein old compile systems
11:04:01 <TrueBrain> it mostly means object files end up in the same directory
11:04:05 <TrueBrain> fixable, 90% of the tmie
11:06:41 <Xaroth|Work> ah
11:06:46 <Xaroth|Work> looks weird tbqfh
11:07:03 <TrueBrain> just limitations of systems
11:07:16 <Xaroth|Work> true that
11:07:26 <TrueBrain> MSVC6 was most known for it
11:07:30 <TrueBrain> as there was no hack around it
11:17:41 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=141 :: New Status: closed (fixed)
11:56:50 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=129 :: New Status: closed (fixed)
11:57:06 <TrueBrain> ha, my -Fix #129: syntax is accepted
11:57:07 <TrueBrain> good
11:57:56 <TrueBrain> then again, -Fix (#129) might also work, but possibly it had to known the issue beforehand
11:59:00 <TrueBrain> yeah, most likely
15:00:24 *** glx has joined #openDune
15:00:24 *** ChanServ sets mode: +o glx
15:01:03 <glx> hello
15:02:16 <Xaroth|Work> o/
16:21:54 <TrueBrain> trying to figure out what GetSpecialXY does, for real
16:22:01 <TrueBrain> but ... hmm .. it is one odd function
16:23:21 <TrueBrain> euh ... no ... it simply swaps X and Y
16:25:58 <Xaroth|Work> love the original comment on that function
16:28:37 <TrueBrain> now .. why would you want to swap them
16:32:39 <TrueBrain> hmm, no, it does swap offset and position
16:32:42 * TrueBrain is a bit lost now :P
16:33:36 <TrueBrain> ah, yes, I was looking wrongly
16:33:36 <Xaroth|Work> it looks odd to say the least :P
16:33:37 <TrueBrain> oops :D
16:34:03 <Xaroth|Work> well, spill it :P
16:34:06 <TrueBrain> its ..... just so weird
16:35:26 <TrueBrain> it has to be a conversion error ... there is no other way ...
16:36:24 <Xaroth|Work> heh
16:38:58 <TrueBrain> hmmmmm
16:39:05 <TrueBrain> that would make much more sense ... hmmmm
16:41:12 <TrueBrain> it is more like Tile_MakeXY
16:41:18 <TrueBrain> you feed it an x and y, and it makes a tile32
16:42:13 <Xaroth|Work> then, for the sake of me being confused slightly, what does tile.c @ line 283 do, exactly?
16:42:19 <Xaroth|Work> tile.tile = Tile_GetSpecialXY(tile)
16:42:27 <TrueBrain> its wrong
16:42:30 <TrueBrain> tile is 0x6/0x8
16:42:36 <TrueBrain> but it should be -0x6/-0x8
16:42:40 <TrueBrain> which are x and y
16:45:19 <TrueBrain> and it seems the only reason that Special function is so complex, is because they were lazy or something ...
16:51:13 <TrueBrain> more than one mistake was made there
16:51:15 <TrueBrain> lol
16:51:16 <TrueBrain> funny :)
16:54:12 <TrueBrain> how do I reference a git commit?
16:54:42 <Xaroth|Work> er, note its hash iirc
17:03:42 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=122 :: New Status: closed (fixed)
17:04:25 <TrueBrain> the whole tile bla should get a good overhaul ... it seems more than one team worked on OpenDUNE, or maybe these two functions got added later by others ....
17:04:37 <TrueBrain> nothing else uses MakeXY, and all go via PackedTile ... very odd these don't
17:04:50 <TrueBrain> but a lot can be cleaned up, and avoid going by packed tile ..
17:08:34 <TrueBrain> btw, commit style should just remain what it always was .. -Fix (#123): blabla
17:59:08 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=124 :: New Status: closed (fixed)
17:59:19 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=123 :: New Status: closed (duplicate)
17:59:43 <TrueBrain> 32 left
18:06:50 <TrueBrain> funny. due to how firedelay is calculated, playing in fastest gives you a totally different gameplay
18:07:12 <TrueBrain> say, normally, it takes 180 ticks between firing
18:07:20 <TrueBrain> at fastest, everything goes twice as fast
18:07:25 <TrueBrain> euhm .. hmm ... fast
18:07:30 <TrueBrain> no, playing on slowest is wrong :P
18:07:38 <TrueBrain> as it goes twice as slow ... so 360 ticks
18:07:42 <TrueBrain> but ... it is clamped to 255
18:07:53 <TrueBrain> so while your units move twice as slow, they only shoot 1.5 times as slow
18:14:26 <glx> of course #131 won't be easy to fix
18:27:22 <TrueBrain> yup ...
18:27:31 <TrueBrain> well, I am happy we didnt refactor the noop call out completely :P
18:27:40 <glx> :)
18:29:58 <TrueBrain> #125 and #126 are also nasty to fix ...
18:30:23 <TrueBrain> first they clamp the value betwee 1 and 255
18:30:24 <glx> doing #135 now
18:30:29 <TrueBrain> then add a random 0/1 ...
18:30:38 <glx> I again made a conversion error ;)
18:30:55 <TrueBrain> I gave #130, #132, #135 and #136 to Xaroth to commit, if he wants to
18:31:01 <TrueBrain> they are all correct and one-liners
18:31:24 <TrueBrain> (well, the suggested solution is correct, not the bug itself :P)
18:32:22 <TrueBrain> I wonder why they do: fireDelay * 2
18:32:44 <TrueBrain> structures fire at * 1 (with that I mean turrets)
18:32:48 <TrueBrain> and units at * 2 ...
18:33:00 <TrueBrain> would be fine I guess, where structures fire twice as fast, but ... why not divide by 2
18:33:09 <TrueBrain> maybe they added the values, then notice units fire too fast?
18:33:12 <TrueBrain> a balance thing?
18:33:53 <glx> possible
18:42:54 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=135 :: New Status: closed (fixed)
18:43:28 <TrueBrain> glx: doesnt that change the code?
18:43:35 <TrueBrain> hmm, no
18:43:36 <TrueBrain> nevermind
18:43:38 <TrueBrain> lalalalalalalaaaa
18:43:39 <TrueBrain> :P
18:43:41 <glx> :)
18:43:51 <glx> I just grouped the two things
18:43:55 <glx> cleaner
18:45:38 <TrueBrain> I think I am going to make fireDelay an uint16 to resolve the issues ....
18:46:04 <TrueBrain> problem is ofc savegames
18:46:05 <TrueBrain> hmm
18:53:33 <TrueBrain> I Wonder, it is stated that this is not observed in original game
18:53:36 <TrueBrain> which seems highly unlikely
19:01:19 <TrueBrain> a moving or shooting unit is more tempting for a sandworm :D
19:30:12 <TrueBrain> I don't really see an easy solution for fireDelay
19:30:15 <TrueBrain> it is wrong, that is for sure :P
19:30:45 <TrueBrain> seems to be caused mostly by that multiplication which makes all unit shooting slower
19:35:31 <TrueBrain> if I patch it up a bit, is it an enhancement or not
19:35:34 <TrueBrain> where do you draw the line :)
19:37:52 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=125 :: New Status: closed (fixed)
19:38:49 <TrueBrain> down to 30
19:51:52 <TrueBrain> this is just odddddddddd
19:51:59 <TrueBrain> trying to fix 64bit compile warnings
19:52:11 <TrueBrain> uint8 * - uint8 * returns a size_t ofc
19:52:12 <TrueBrain> now the kicker
19:52:27 <TrueBrain> size_t > (uint8 * - uint8 *) gives a signed/unsigned error
19:52:55 <TrueBrain> ah, not size_t, but __int64
19:52:56 <TrueBrain> fine
19:54:00 <TrueBrain> well, those warnings can go take a hike
19:54:02 <TrueBrain> silly
20:05:55 <TrueBrain> @base 10 16 48
20:05:55 <DorpsGek> TrueBrain: 30
20:16:14 <TrueBrain> hmm, smoke from structures can only happen in very few situations ... odd
20:16:32 <TrueBrain> only when you launch missiles at it, it seems
20:25:15 <TrueBrain> lolz, another wrong converted function
20:25:25 <TrueBrain> right ... it first sign extends a 12bit value
20:25:42 <TrueBrain> then it makes it into a tile32, runs Tile_GetXY over it .. sounds redundant
20:30:43 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=119 :: New Status: closed (fixed)
20:30:51 <TrueBrain> there we go
20:31:37 <glx> was me again ?
20:31:52 <TrueBrain> no clue
20:31:56 <TrueBrain> I rarely care who made the boo-hoo
20:32:10 <TrueBrain> we both made some pretty bad mistakes ... but no wonder with the many many many many lines we did :D
20:32:27 <glx> yes it's surprising
20:32:59 <TrueBrain> yeah; there are much fewer issues than I expected :D
20:33:08 <TrueBrain> sometimes we picked the wrong field ... happens
20:33:23 <TrueBrain> like #119, that is a bit worse; we just misunderstood (and misread) the function completely
20:33:25 <glx> often for me :)
20:33:42 <glx> like forgeting the offset added at the begining
20:33:49 <TrueBrain> same
20:34:26 <TrueBrain> I am so surprised how far we got ....
20:34:31 <TrueBrain> like, I build a freakig EMC to Python
20:34:34 <TrueBrain> I forgot all about that :P
20:34:36 <glx> it was a function with many shifts ?
20:34:50 <TrueBrain> which one, sorry?
20:34:57 <glx> the #119 one
20:35:01 <TrueBrain> ah, no
20:35:04 <TrueBrain> a very small function
20:35:15 <TrueBrain> the main mistake was that it was done as set, not as add
20:35:27 <TrueBrain> and as it was always used with a negative value
20:35:29 <TrueBrain> it ended up nowhere
20:35:31 <glx> I hated the functions with shifts, and rotations
20:37:23 <TrueBrain> hmm, I wonder where the tool itself is, that converted EMC to PYthon ...
20:38:21 <TrueBrain> ah, tools/emc/
20:38:23 <TrueBrain> ofc
20:46:32 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=139 :: New Status: closed (fixed)
20:50:45 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=111 :: New Status: feedback (open)
20:51:42 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=98 :: New Status: confirmed (open)
20:52:11 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=131 :: New Status: confirmed (open)
20:52:19 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=126 :: New Status: confirmed (open)
20:52:29 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=109 :: New Status: confirmed (open)
20:58:31 <TrueBrain> running out of bugs to 'easily' fix ..
21:05:22 <Xaroth|Work> hehe
21:24:50 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=136 :: New Status: closed (fixed)
21:34:27 <glx> I experienced #109, it's nice to explore the map :)
21:41:54 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=132 :: New Status: closed (fixed)
21:54:50 <glx> hehe again a forgotten offset :)
21:55:10 <TrueBrain> and one more coming up :P
21:55:32 <glx> ha no it was a failing hex to dec
21:55:48 <glx> I was "good" at that :)
21:58:20 <Xaroth|Work> right, MSVC is being nice to me tonight
21:58:25 <Xaroth|Work> straight compiles, no fuss
21:58:32 <Xaroth|Work> it even starts without trouble
22:06:02 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=130 :: New Status: closed (fixed)
22:06:45 <TrueBrain> 25 left ... time to go away for a few days .. more next weekend ;)
22:38:03 <Xaroth|Work> and even better, I managed to commit useful stuff
23:27:50 *** TrueBrain has quit IRC