IRC logs for #opendune on OFTC at 2010-04-27
⏴ go to previous day
13:30:10 *** ChanServ sets mode: +v Yexo
19:18:57 <TrueBrain> glx: does the Windows versions compile without warning?
19:19:12 <TrueBrain> tneo: would you be so kind to try in the next few days if the game still works the same, by doing 2 or 3 missions or something?
19:19:29 <TrueBrain> planetmaker: would you be so kind to compile OpenDUNE on OSX, see if it still works for you?
19:20:03 <tneo> sure TrueBrain is friday ok (queensday after all :-))
19:20:26 <TrueBrain> you are not going out?
19:20:36 <tneo> nah too much work to be done
19:20:59 <TrueBrain> too bad .. always so nice :)
19:22:25 <tneo> anything special to keep an eye out for?
19:22:34 <glx> no warnings (MSVC and mingw)
19:22:59 <TrueBrain> tneo: not really; general gameplay .. speed of vehicles, building damage .. air units .. the a global thingy :)
19:23:02 <TrueBrain> we touched a lot :p
19:23:30 <glx> grr my game gear has the game gear syndrome :(
19:24:15 <glx> so no sound and weird angle to see the screen
19:25:45 <TrueBrain> I know O1 so good, I can run it in seconds :p
19:25:52 <TrueBrain> know what to kill where and when :p
19:26:12 <glx> hehe I can't get more than 69 in A1
19:26:46 <glx> but I can do it in 5 minutes
19:26:57 <glx> and every conversion reduce the time
19:27:01 <TrueBrain> 2 buildings and 1 full harvester :)
19:27:17 <glx> and while it harvests, 7 kills
19:27:30 <TrueBrain> too much effort for me :)
19:27:33 <TrueBrain> 3 kills .. plenty :p
19:28:19 <TrueBrain> k, A1 itself seems intact
19:28:32 <glx> I guess converting "get landscape type" can improve time too :)
19:29:30 <glx> f__B4CD_0750_0027_7BA5() <-- this one IIRC
19:29:41 <TrueBrain> something to pick up next week ;)
19:29:47 <TrueBrain> this week is the most boring week of all development :p
19:30:42 <glx> will we enable sound for the release?
19:31:40 <glx> 41D2: was wrong anyway ;)
19:33:11 <TrueBrain> that was a nasty backlog of bug reports :p
19:34:07 <TrueBrain> only need to test OpenDUNE on OSX, and then my part of the test-phase is done, all green as far as I can tell
19:36:24 <glx> hmm sound is not implemented on OSX IIRC
19:38:32 <glx> but voices should be ok (SDL)
19:58:51 <TrueBrain> hmm .. that didn't happen for a long long time
19:58:56 <TrueBrain> tneo: which OS do you use?
19:59:11 <TrueBrain> can you run OpenDUNE in 'gdb'?
19:59:18 <TrueBrain> as in that case, you can backtrace it
19:59:28 <TrueBrain> a 'core' file is also enough, but ...
20:00:30 <tneo> just gave the order to move over harkonnen units
20:01:10 <glx> we need to know how to reproduce for assets ;)
20:03:26 <tneo> gdb complains to be missing something :|
20:04:16 <tneo> the ornicopter dropped units in exact same spot
20:04:34 <tneo> and it keeps circling before drop
20:04:45 <TrueBrain> ornicopter dropping units?
20:07:00 <tneo> can't upload screenshot + save game :-(
20:07:17 <tneo> unless you don't mind zip
20:07:19 <TrueBrain> why not? What is the error?
20:08:32 <tneo> can only select one file to upload with report
20:08:37 <TrueBrain> as you should be able to upload such files, and if not, Xaroth|Work should be slapped :p
20:09:05 <Xaroth> tneo: no option to upload another file with a comment?
20:09:06 <TrueBrain> upload one, add comment with other? Dunno ... strange limitation
20:10:41 <Xaroth> I have an upload form on it :o
20:11:02 <tneo> i need to comment my own bug report to upload additional files :-/
20:11:22 <TrueBrain> it is not the best system available :) Just the only one that 'works' :)
20:12:11 <TrueBrain> 2 units on the same spot .. that will go horribly wrong
20:12:17 <TrueBrain> Xaroth: wrong content-type :p
20:12:43 <TrueBrain> glx: sounds like one of the 0F3F functions was called wrong (the one that randomizes the position)
20:12:53 <TrueBrain> most likely in a Unit script functions .. any ideas where to look?
20:13:47 <TrueBrain> the irony .. screenshot twice as big as the data to produce the screenshot (the savegame)
20:19:42 <tneo> tomorrow an other day :-)
20:20:16 <glx> you should have tested it sooner ;)
20:24:47 <glx> btw 'unknown chunk in savegame'
20:25:18 <Xaroth|Work> TrueBrain: try now
20:25:36 <Xaroth|Work> had to install pecl fileinfo for mime type support to work :/
20:32:18 <TrueBrain> Xaroth|Work: now it wants to downlaod .. also not optimal
20:32:25 <TrueBrain> glx: weird .. any clue why?
20:33:15 <TrueBrain> the unknown chunk I mean
20:33:20 <TrueBrain> can't see any reason why there would be any :p
20:33:34 <glx> ha I don't know, but it's with tneo save
20:33:41 <Xaroth|Work> TrueBrain: it -always- wants to send the file
20:33:52 <Xaroth|Work> fixing that means re-doing the whole download script :P
20:33:58 <TrueBrain> Xaroth|Work: it should just let the browser decide based on content-type
20:34:07 <glx> Unknown chunk in savegame: <p s (length: 1954114661). Skipped.
20:34:32 <TrueBrain> I just truly hope uploading failed for one reason or another
20:36:27 <TrueBrain> XB, really, please fix this :)
20:36:39 <TrueBrain> <p style="color:red">SYSTEM WARNING: Cannot modify header information - headers already sent by (output started at /var/www/bugs.opendune.org/htdocs/file_download.php:173)</p>
20:36:46 <TrueBrain> that is just ... wrong
20:37:43 <glx> hmm ok 1087 seems ok, 1090 seems wrong
20:37:58 <glx> what can be wrong in 1090 :/
20:38:21 <TrueBrain> glx: there is nothing in those revisions doing anything with where things have to be placed :p :p
20:38:38 <glx> I just check script functions ;)
20:38:45 <Xaroth|Work> it sends a header AFTER sending the content?!?!?!?
20:38:54 <glx> so only changes in script/unit.c
20:38:55 <Xaroth|Work> header( 'Content-Length: ' . $v_filesize );
20:39:21 <TrueBrain> glx: then your test failed, as r1090 does nothing that is important :)
20:39:23 <Xaroth|Work> TrueBrain: try now?
20:40:01 <glx> yup but in 1087 it placed the 3 harkonnen units correctly ;)
20:40:21 <TrueBrain> Xaroth|Work: one last, would it be possible to add a param like &filename="name-of-file"?
20:40:28 <TrueBrain> makes many things easier :p
20:40:31 <glx> anyway it seems to use randomrange for that (so not deterministic)
20:40:54 <TrueBrain> glx: it seems like the test if something is on the tile fails or something
20:41:23 <TrueBrain> how long between load of savegame and unit drop
20:41:32 <TrueBrain> Xaroth|Work: well, nevermind that request for now in total, not that big of an issue atm
20:42:01 <Xaroth|Work> for me it does that,TrueBrain
20:42:15 <TrueBrain> Xaroth|Work: in the URL I asked :p
20:42:29 <Xaroth|Work> Screenshot-OpenDUNE+-+Pre+v0.3.png
20:42:51 <TrueBrain> you are reading, but not really reading :p
20:42:59 <TrueBrain> glx: lol, I have a harvester that is stuck in its station
20:43:58 <glx> I hope it's related to the bug
20:45:45 <TrueBrain> glx: harvaster also stuck in r1087
20:46:47 <TrueBrain> yeah, XB made a nice SVN viewer
20:46:48 <glx> theorically it's in scripts, else it's unit functions
20:48:20 <TrueBrain> r1086, harvester is stuck
20:48:23 <TrueBrain> waiting for reinforcement
20:49:01 <TrueBrain> I hate it when loading a game twice gives different results :p
20:49:05 <TrueBrain> carry-all broken too
20:49:39 <glx> yeah randomrange is nasty (its seed is GetTime() based)
20:49:53 <TrueBrain> then why did you implement a real GetTime for? :p
20:50:00 <glx> random256 is deterministic
20:50:24 <TrueBrain> the issue remains that when you play a game, save, load, you have a different seed btw :)
20:50:28 <TrueBrain> something for us to fix ;)
20:50:53 <TrueBrain> trick is used a lot for house missile :)
20:51:15 <TrueBrain> r1081, harvester broken
20:51:56 <TrueBrain> on the other hand, that a load does something different is good .. else you know where enemies come from every single time
20:52:15 <TrueBrain> fuck, was not paying enough attention to see if the carry-all was fixed :p
20:52:17 <Xaroth> they always come from the same place...
20:52:28 <TrueBrain> Xaroth: no, reinforcement is different
20:52:38 <TrueBrain> the location is only set when it is launched
20:53:29 <glx> in r1082 reinforcement is half broken (3 units on 2 tiles)
20:54:04 <TrueBrain> in all versions there is a small chance of it going correct
20:54:10 <TrueBrain> so I think there is a too high shift of some kind :)
20:55:15 <TrueBrain> hihi, every time I build the hi-tech and a windtrap :p
20:55:17 <TrueBrain> just because I am bored
20:56:07 <TrueBrain> r0180, harvester broken
20:58:35 <glx> harvester broken in r1077
20:59:37 <TrueBrain> so lets hope it is r1076
20:59:57 <glx> well 1076 should be ok if it's a script issue
21:00:29 <TrueBrain> 1076 doesnt' compile for me, so I leave thatone for you :)
21:00:40 <TrueBrain> doing 1070, just to be sure
21:03:08 <glx> indeed 1076 broken for harvester
21:04:14 <TrueBrain> if you can take 1060 or something
21:04:33 <TrueBrain> ah, the funny movement was in 1050 :p
21:04:56 <glx> we really need regression tests ;)
21:05:11 <TrueBrain> if I had any idea how .... I would have made them long ago :;p
21:06:33 <glx> ok I go to r1000 directly
21:12:09 <TrueBrain> neither dat 1030 :p
21:14:05 <TrueBrain> which is more luck, as we have a few more revisions fixing the date stuff :p
21:15:41 <TrueBrain> trying 1040 if the connection allows me ...
21:16:22 <glx> r1043 is not enough for me
21:16:56 <TrueBrain> then give me a sec to test 1040 ..
21:17:50 <TrueBrain> 1040 breaks for harvester
21:18:04 <TrueBrain> so that is failure in structure script function most likely
21:18:45 <TrueBrain> carry-all is broken too
21:18:51 <TrueBrain> so 10 revisions left
21:20:02 <TrueBrain> I guess 1037 or 1039 is to blame
21:20:05 <glx> (first change in unit after 1030)
21:20:29 <TrueBrain> r1036, harvester works
21:20:47 <TrueBrain> which suprises me ...
21:20:53 <TrueBrain> not structure related after all
21:25:23 <TrueBrain> should conclude which version it is for sure :)
21:25:49 <TrueBrain> r1038 harvester works
21:29:05 <TrueBrain> lol, nice bug-fix in r1039 :p (sp + 2 instead of + 4)
21:29:38 <TrueBrain> emu_push(s->position.s.y + 0x80); emu_push(s->position.s.x + 0x80);
21:29:43 <TrueBrain> u = Unit_CreateBullet(s->position, type, s->houseID, damage, target);
21:32:03 <TrueBrain> seems not corrected anywhere, so something to fix nevertheless :)
21:32:56 <TrueBrain> I guess bullets now fly from 0,0 :p
21:33:11 <TrueBrain> will check that later, as I think something else ensures it starts at the center
21:33:49 <TrueBrain> no, not that I can see
21:34:00 <TrueBrain> but okay, not primary bug
21:38:10 <glx> if ((g_global->variable_3A3E[emu_ax + ui->variable_3C][2] & 0xFF) == 0) return true; <-- this array is nasty
21:38:28 <TrueBrain> yes, and it seems you made a boo-hoo
21:38:31 <TrueBrain> ax is multiplied with 28
21:38:42 <TrueBrain> so 2 + var_3C seems more likely
21:40:59 <TrueBrain> and it seems you mixed the next inner-if
21:42:02 <TrueBrain> harvesters deploy again
21:43:17 <TrueBrain> carry-all appeared outside screen
21:44:28 <TrueBrain> best guess the function is: IsTileOccupied :p
21:44:30 <glx> ,...locdi = g_global->variable_3A3E[loc08][2 + (ui->variable_3C / 2)]; <-- I guess it should look like this indeed
21:44:41 <TrueBrain> hmm, divide by 2, yes
21:45:13 <glx> c/p from another function ;)
21:45:42 <glx> did a quick search for 3A3E in latest trunk
21:46:00 <glx> ,...locdi = g_global->variable_3A3E[loc08][2 + (ui->variable_3C / 2)];
21:46:00 <glx> ,...if (ui->variable_3C % 2 == 0) {
21:46:26 <TrueBrain> - if (ui->variable_3C == 1 && g_unitInfo[u->type].variable_3C != 0) return true;
21:46:27 <TrueBrain> + if (ui->variable_3C != 1 || g_unitInfo[u->type].variable_3C != 0) return true;
21:48:38 <TrueBrain> does not fix the carry-all
21:48:40 <glx> right, another mistake ;)
21:48:54 <TrueBrain> it now doesnt place 2 units on eachother
21:48:58 <TrueBrain> but ... it doesn't scatter enough :)
21:49:03 <TrueBrain> owh, it does place 2 units :p
21:50:41 <TrueBrain> one minor issue ...
21:50:47 <TrueBrain> if 3C is odd, it should do the higher bits
21:51:54 <glx> well it should be a struct indeed
21:54:06 <TrueBrain> still carry-all fails
21:55:55 <glx> I have similar (but using % 2)
21:56:10 <TrueBrain> compiler should fix that anyway :p
21:56:41 <TrueBrain> new patch, fixing the other issue in r1039
21:57:13 <TrueBrain> glx: I hope you can find it :) Make sure to name the #<bug-number> in the commit :)
21:58:05 <TrueBrain> updated patch, this looks better :p
21:58:12 <TrueBrain> loc02 &= ((ui->variable_3C & 0x1) != 0) ? 0xFF00 : 0x00FF;
22:01:36 <planetmaker> everything still works quite smoothly for me
22:01:50 <TrueBrain> thank you planetmaker
22:02:40 <TrueBrain> glx: did a check of the other function, I can't find anything wrong in it
22:02:47 <planetmaker> you're welcome :-)
22:02:54 <TrueBrain> what you can try, is revert Unit_Unknown0E2E only, and see if that fixes all problems :)
22:03:08 <TrueBrain> as if soo, we are missing another glitch
22:03:42 <TrueBrain> I also don't get the function
22:03:49 <TrueBrain> if the unit is friendly, it can return false
22:06:46 <TrueBrain> I think 3C is movement type
22:07:06 <TrueBrain> as these exceptions allow bigger units to drive over smaller, I guess :)
22:08:59 <DorpsGek> SVN: truebrain (r1104) -Fix (r1039, #36): a few glitches in one function which turned out to be pretty critical for a lot of small stuff
22:09:03 <TrueBrain> now I am off to bed :)
22:20:35 <planetmaker> good night now here, too :-)
continue to next day ⏵