IRC logs for #opendune on OFTC at 2009-11-15
⏴ go to previous day
10:58:58 <Xaroth> emu_orw(&emu_si, emu_si);
11:24:44 <TrueBrain> lol, we all should use a dead framework for our Dune2 clone! WHOHO! :) Sometimes .. people amaze me :p
11:40:47 <TrueBrain> yeah, some guy was suggesting some kind of framework for such games as Dune2, Starcraft, ... which has halted development back in 2007
11:40:59 <TrueBrain> 'you can write your own game in LUA' ... like that is such a good thing ;)
11:41:38 <TrueBrain> I never said any of that :s
11:42:34 <TrueBrain> and I lost PHP again in Apache2 ...
11:42:38 <TrueBrain> happens a lot .. after upgrades ...
11:46:58 <TrueBrain> SmatZ: I meant the 'Stratagus' project
11:47:05 <TrueBrain> (had to look up the name :p)
11:50:40 <Xaroth> heh, yes, technically you can make your own game in LUA
12:11:49 <DorpsGek> SVN: truebrain (r469) -Fix: comment was outdated
12:21:14 <TrueBrain> Xaroth: I need your Tile_Unpack :p
12:22:49 <Xaroth> Tile_Unpack is confusing :P
12:37:24 <TrueBrain> if you think that is confusing ... ;) :p
12:46:22 <TrueBrain> @calc 0xd * 0xc + 0x70
12:48:28 <TrueBrain> lovely .. string array not in the same order as internal array :(
13:06:32 <DorpsGek> SVN: truebrain (r470) -Add: actionInfo array, which has information about unit actions
13:06:47 <DorpsGek> SVN: truebrain (r471) -Add: emu_Scenario_Load_Units to more readable C
13:26:27 <DorpsGek> SVN: truebrain (r472) -Add: emu_Scenario_Load_Reinforcements to more readable C
13:46:43 <TrueBrain> MOVEMENT_SLITHER <- slither?!
13:48:21 <TrueBrain> @calc 0x3be2- 0x3b54
13:53:23 <TrueBrain> eeuuuhh ... it appears 'teaming' doesn't work in a lot of cases ...
13:54:49 <TrueBrain> scenarios use 'Track' and 'Wheel', while the Movement array expects 'Tracked' and 'Wheeled'
14:01:45 <DorpsGek> SVN: truebrain (r473) -Add: [TeamAction|Movement]StringToType and required arrays
14:02:01 <DorpsGek> SVN: truebrain (r474) -Add: emu_Scenario_Load_Teams to more readable C
14:02:59 <TrueBrain> how did those bugs go undetected in the testing of Dune2?
14:03:18 <TrueBrain> the more I read, the more I get the idea they had some deadline :p
14:03:33 <TrueBrain> well, doesn't explain why the bugs are still in 1.07 ...
14:12:04 <DorpsGek> SVN: truebrain (r475) -Add: emu_Scenario_Load_Choam to more readable C
14:12:10 <TrueBrain> k, enough scenario shit :)
14:12:36 <TrueBrain> there is still a lot of work to do there, but nothing which increases the understandability of the code :)
14:12:56 <TrueBrain> it now only contains processing of the ini file
14:36:43 <glx> need to find what broke it
14:37:55 <glx> no I reverted to 464 and it compiles
14:39:48 <glx> weird 467 fails to compile too
14:41:05 <glx> ok os/strings.h was not used before r467 :)
14:41:44 <glx> __MINGW_NOTHROW <-- mingw doesn't like that it seems :)
14:45:04 <TrueBrain> I ahve this idea Netbeans leaks memory :p Slowly I see the memory usage climb, while I haven't been using it for the past 10 minutes :p
14:49:34 <TrueBrain> so .. a variable called 'g_dune2_enhanced' I guess?
14:49:43 <TrueBrain> should I document the 'bugs' it fixes in some file?
14:56:21 <TrueBrain> suggestions / comments / ... ? :)
15:07:08 <glx> src/scenario.c: In function 'emu_Scenario_Load_Teams':
15:07:08 <glx> src/scenario.c:626: attention : unused parameter 'key'
15:15:12 <DorpsGek> SVN: glx (r476) -Fix (r464): os/strings.h was not MINGW compatible
15:20:03 <Xaroth> [@TrueBrain]: so .. a variable called 'g_dune2_enhanced' I guess? << yep
15:21:11 <Xaroth> [@TrueBrain]: should I document the 'bugs' it fixes in some file? << would at least be usefult o keep track of it somehow
15:21:51 <TrueBrain> okay, I guess I phrase my questions wrong ... HOW should we name a file which contains such bugs
15:22:00 <TrueBrain> and: does anyone has a better suggestion then g_dune2_enhanced? :p
15:22:29 <Xaroth> enhancement_fixes.txt ? :o
15:23:02 <TrueBrain> fixed_dune2_bugs :p
15:23:15 <TrueBrain> sounds a bit weird all ;)
15:23:15 <planetmaker> dune2_improvements
15:23:32 <TrueBrain> what planetmaker says sounds good too
15:24:22 <Xaroth> they all sound good :P
15:24:49 <planetmaker> though "changes.txt" is what I naturally would look at
15:25:05 <Xaroth> yes, but changes.txt sounds more like a changelog for the project itself
15:25:19 <planetmaker> But that'd be a changelog for the user. It could contain a section of "improvements over original dune2", though
15:25:47 <TrueBrain> the changelog will be in changelog.txt, that for sure
15:25:53 <TrueBrain> but it can also be in a README.txt section :p
15:26:26 <planetmaker> well... readme.txt is what you *should* read, if you've got problems.
15:26:38 <planetmaker> a feature list... maybe
15:27:28 <TrueBrain> readme is not only for problems ;)
15:27:32 <TrueBrain> also how to install, play, ... ;)
15:28:40 <planetmaker> Then make sure that the first paragraph is: "Make sure that you have fun" ;-)
15:29:02 <planetmaker> I guess readme.txt is fine. Too many files are just... confusing
15:31:24 <TrueBrain> exacrtly why I wonder ;)
15:31:52 <planetmaker> if *you* wonder, then others will surely, too. Put it in the readme, then.
15:32:12 <planetmaker> section name then like "Improvements over Dune2" or alike
15:32:17 <TrueBrain> other comments on my patch? ( Xaroth / glx ?)
15:32:27 <TrueBrain> planetmaker: that sounds like the best approach :)
15:33:29 <Xaroth> temp.patch is for scen loading, the + ?
15:34:30 <TrueBrain> it fixes 3 bugs .. read the comments! :p
15:35:50 <Xaroth> got confused by the comments :P
15:36:00 <TrueBrain> how can they confuse you? :)
15:36:10 <Xaroth> spend an entire weekend with a woman?
15:36:20 <TrueBrain> that makes your brain cells disapear?
15:36:29 <TrueBrain> or how should I interprete the line?
15:36:46 <Xaroth> too much non-coding talk
15:36:57 <TrueBrain> ghehe, the comments are plain english, or so was the idea :)
15:37:03 <TrueBrain> should I mark the Dune2 bugs more clear in the code?
15:37:18 <Xaroth> tempted to say yes on that one
15:37:30 <TrueBrain> useful response to a question :p
15:37:35 <TrueBrain> something I can work with ;)
15:37:56 <TrueBrain> sure, hand it over to someone else :p
15:38:14 <Xaroth> delegating is the first rule of managing :)
15:38:50 <Xaroth> seriously tho, I prefer more comments for stuff like that
15:39:04 <TrueBrain> okay, again, I guess I asked the question wrong:
15:39:13 <TrueBrain> shald I mark the Dune2 bugs more clear in the code, and if so, HOW?!
16:15:59 <TrueBrain> a nice only doesn't cut it, you do understand that, right? :p :p
16:17:19 <Xaroth> the layout looks good, formatting as well
16:17:48 <TrueBrain> (mostly as it simply has to contain at least 1 error :p)
16:19:23 <Xaroth> #include std/disclaimer ? :P
16:20:09 <TrueBrain> I meant that you should at least find 1 error, else you haven't read it :p (simple statistic :p)
16:21:58 <Xaroth> no wait, nevermind, both are allowed
16:23:27 <TrueBrain> rewrote that section a bit
16:25:44 <TrueBrain> rewrote Requirements
16:30:32 <DorpsGek> SVN: truebrain (r477) -Add: a README.txt with some general blabla
16:30:38 <TrueBrain> you can now change it in the repos :p
16:31:35 <DorpsGek> SVN: truebrain (r478) -Fix (r473): forgot to update MSVC project file
16:32:11 <DorpsGek> SVN: truebrain (r479) -Fix (r477): set eol-style native
16:33:08 <DorpsGek> SVN: truebrain (r480) 1) '+' after reinforcement is ignored
16:33:08 <DorpsGek> SVN: truebrain (r480) -Add: fix 3 Dune2 bugs in Scenario loading (and document it):
16:33:08 <DorpsGek> SVN: truebrain (r480) 2) '% hitpoints' of structures is ignored
16:33:08 <DorpsGek> SVN: truebrain (r480) 3) 'Track' and 'Wheel' in Teams should be 'Tracked' and 'Wheeled'
16:33:26 <TrueBrain> LOL! Out of order reporting ... how cool :)
16:33:40 <TrueBrain> so there .. our first 3 enhancements :)
16:34:07 <TrueBrain> 2 of them make the game a LOT harder :p
16:34:15 <TrueBrain> tanks now group together before they attack ...
16:34:42 <TrueBrain> what to eat .. what to eat ...
16:34:47 <TrueBrain> Greek .. hmm .. yeah, why not
16:35:05 * SmatZ is going to eat some china
16:35:16 * Xaroth doesn't like the taste of dirt :o
16:37:19 <TrueBrain> I think SmatZ is a bit crazy ;) But good luck, let us know when you are in the news :)
16:37:45 <TrueBrain> reminds me about the episode of Monty Python, where he is going to jump to France from England, by walking really hard
16:39:04 <TrueBrain> either way, his second thing is that he is going to eat a church
16:39:12 <TrueBrain> so that is something for SmatZ too, I guess :)
16:42:28 <Xaroth> month after 0.7.3 0.7.4 RC1 O_O
16:44:59 <Xaroth> yeh, bit tooooo often :P
16:46:07 <TrueBrain> that really isnt too often ..
16:46:23 <TrueBrain> 0.7.4 will be in a month or so .. so 2 months between releases of a stable branch ..
16:46:39 <TrueBrain> and clearly there are a few issues which are worth the release
16:46:55 <TrueBrain> (in theory, 0.7 should be stable and no sub-release should be required .. somehow people keep on finding problems ;))
16:47:21 <Xaroth> or abusing problems, like PeterT likes to do on ottdc :P
16:52:50 <TrueBrain> I like how MrFlibble is trying to help out a lot :)
16:53:45 <TrueBrain> lots to do, lots to do
16:59:25 <TrueBrain> so what will I be doing next .. somehow I feel like looking into the scripting stuff .. but that is hard! :p
17:01:36 <Xaroth> just because it's being a bitch :P
17:02:20 <TrueBrain> so you should work on it harder ;) Ghehe :)
17:02:24 <TrueBrain> it is such an easy routine ... ;)
17:02:35 <TrueBrain> 12 bits to 32 bits .. that is all it does :)
17:07:07 <Xaroth> lemme first test Tile_Pack :P
17:10:11 <Xaroth> wonder when pack is called :o
17:34:27 <TrueBrain> okay ... I never order again by that Greek
17:34:32 <TrueBrain> that was .... not tasteful :(
17:36:04 <Xaroth> at least you didn't have to eat china :)
17:36:52 <TrueBrain> okay ... emu_Strcuture_CreatE() .. .where are you (ignore the typos)
17:38:05 <TrueBrain> concratz Xaroth, it finally works :)
17:38:11 <glx> bad luck, I had no problems with them :)
17:39:00 <glx> nice crash.bin is attached
17:39:06 <TrueBrain> what ever it was, it is already in latest trunk
17:39:25 <TrueBrain> by the looks it is the mouse of keyboard handler
17:42:06 <TrueBrain> within 4 minutes, how is that for a respnse time? :p
17:42:39 <tneo> it's been fixed while looking at it ;-)
17:42:40 <DorpsGek> SVN: truebrain (r481) -Codechange: remove silly newline
17:42:56 <TrueBrain> you should consider updating to trunk :)
17:43:48 <TrueBrain> good :) Then the problem should never happen again :) (let me know if it does ;))
17:55:36 <tneo> btw there are no sounds under linux is that correct?
17:56:12 <TrueBrain> nope .. we need someone to write sound emulation :)
18:05:57 <glx> there are no sound driver implemented ;)
18:06:01 <tneo> TrueBrain, do you want me to upload the crash.bin for entering the starport?
18:07:30 <TrueBrain> if it is with the latest trunk, sure :)
18:10:14 <tneo> Updated external to revision 18101.
18:10:15 <tneo> Updated to revision 480.
18:10:35 <TrueBrain> well, 481 is, but okay, good enough
18:13:18 <TrueBrain> hmm ... that is very strange ... it tells me here that it also already knows that function
18:13:24 <TrueBrain> did you also compile the latest revision? :)
18:19:08 <TrueBrain> euh .. hmm .. yes .. I have this idea :p
18:19:14 <TrueBrain> check the date of your crash.bin
18:19:20 <TrueBrain> I tihnk you just uploaded the same twice :)
18:20:00 <TrueBrain> hmm .. then I don't know :(
18:20:07 <TrueBrain> what was the crash report?
18:20:43 <tneo> Program Termination: jumped to 3FF1:197C, which is not decompiled.
18:20:43 <tneo> The jump was triggered at decompiled/cs__B495.c:4173
18:20:43 <tneo> The jump appears to originate from B495:197C.
18:20:44 <tneo> Please send the file 'memory/crash.bin' to upstream developers.
18:20:47 <tneo> Crash-dump in 'memory/crash.bin'
18:21:10 <TrueBrain> that is a valid crash-log ...
18:24:15 <tneo> it also takes a little time before the crash happens
18:24:39 <TrueBrain> it seems something is broken at my side
18:27:48 <TrueBrain> both crash logs are valid, I fucked up something over here :p
18:30:05 <TrueBrain> the latest is pretty interesting ..
18:30:38 <tneo> hmm now everything is moving but I can't select any thing :-P
18:30:58 <tneo> the gui is frozen, but game continues
18:31:18 <TrueBrain> sadly enough, that sometimes happens
18:31:38 <TrueBrain> euh ... the latest crash is an abort application ...
18:32:54 <DorpsGek> SVN: truebrain (r482) [JIT] -Fix: 1 more problem found by tneo
18:33:24 <tneo> you're quick in fixing :-)
18:33:38 <TrueBrain> this aint fixing ;) This is loading in a construct which returns me the new valid data :p
18:35:01 <DorpsGek> SVN: truebrain (r483) [JIT] -Fix (#10): 1 more problem found by tneo
18:36:11 <DorpsGek> SVN: truebrain (r484) -Update (r482, r483, #9, #10): update decompiled code
18:36:31 <TrueBrain> Xaroth: what did I do wrong for Mantis to not pick up that commit?
18:37:58 <TrueBrain> tneo: now they both really should be fixed :) Just I wonder why it terminates the game in the latest situation ...
18:38:29 <tneo> always did when it occurred first time to produce a crash log
18:38:55 <TrueBrain> this is a 'clean' termination .. in other words: Dune2 wants to quit, for some reason ..
18:40:27 <TrueBrain> "ERROR: No items in construction list!"
18:48:42 <TrueBrain> testing solution ...
18:51:11 <DorpsGek> SVN: truebrain (r485) -Fix (r453, #10): stupid typo caused StarPort to crash on opening (bug found by tneo)
18:51:28 <TrueBrain> tneo: sadly enough, you do need to restart your campaign
18:51:59 <TrueBrain> but I guess you weren't that far in the game, given you just built a starport :)
18:52:15 <TrueBrain> no, only the current level
18:52:19 <tneo> you need the starport for the XI
18:52:24 <TrueBrain> lol :) Not the whole house ;)
18:52:35 <TrueBrain> so via the menu, Restart blabla
18:52:52 <TrueBrain> scenario, is the word Dune2 uses :)
18:53:09 <TrueBrain> our first bug in C conversion :) WHOHO! :)
18:54:33 <tneo> I played this game way too often still remember each level :-P
19:26:40 <TrueBrain> stupid Make .. it doesn't recompile all changed files :s
19:41:34 <TrueBrain> and I somewhere broke something again ... sigh .. :p
19:48:52 <Xaroth> TrueBrain: mantis still acting up?
19:49:07 <Xaroth> I think it might have something to do with starting the r<X>
19:49:34 <Xaroth> did #9 get updated at all? :o
19:49:38 <TrueBrain> maybe it has to do with 2 #s
19:49:48 <Xaroth> i'll look through the code
19:50:15 <TrueBrain> my mobile interferce with my mouse :p Pretty funny :)
19:58:27 <TrueBrain> GRRRR! I can't find my bug :(
19:59:04 <TrueBrain> oh .. I have an idea .. hihi
19:59:43 <TrueBrain> accessing local 'cs' data is a bitch :p
20:00:36 <DorpsGek> SVN: truebrain (r486) -Add: added Structure_Create()
20:15:11 <DorpsGek> SVN: truebrain (r487) -Add: named another function
20:20:37 <TrueBrain> hmm ... MrFlibble shows another interesting problem .. errors in non-executable files ..
20:43:57 <TrueBrain> k, in the rar there is a very complete update of scenarios, which fixes most of the errors/problems we have seen :)
20:48:01 <TrueBrain> now I need a pak creator .. glx! :p :)
20:51:05 <TrueBrain> what do you guys think .. wouldit be better to make OpenDUNE accept the original scenario and patch it up as much as possible, or should we just supply a 'corrected' scenario pak, which fixes all the mistakes?
21:30:19 <boekabart> what a weekend... haven't been @ a pc all of it. see you have - lots of activity!
22:03:22 <TrueBrain> SmatZ: I assume you didn't mean 'back', but you meant the last option? :)
22:07:48 <DorpsGek> SVN: truebrain (r488) -Revert (r480): no longer 'alias' the movement type 'Track' with 'Tracked' and 'Wheel' with 'Wheeled' for scenario files.
22:08:10 <TrueBrain> so if I have a tool to make .pak files, we can publish a corrected scenarios.pak ;)
22:10:08 <DorpsGek> SVN: truebrain (r489) -Fix (r487): define emu_Structure_IsUpgradable() for Structure_Create()
22:12:43 <TrueBrain> hmm .. it would be nice if the game throws a warning in case it tries to read scenarios which have syntax errors .. how to .. how to ..
22:13:14 <TrueBrain> I guess there is need for a DEBUG() of some kind ..
22:47:50 <TrueBrain> I like first section, 3rd point :p
22:48:35 <Xaroth> oh, how nice, tortoisesvn 'merged' the vcproj changes with my local mods
22:49:04 <Xaroth> btw: lol @ atomic mass.
22:50:32 <Xaroth> removed the old attempts at Tile_Unpack
22:51:07 <TrueBrain> I am attempting a 700 line functions I have no clue about what it does :p
22:53:11 <Xaroth> i almost misread tile_packed as tile32....
22:53:45 <Xaroth> somehow that won't always work ^^
22:54:28 <Xaroth> ok, intellisense is fucked up
22:54:37 <TrueBrain> s->variable_09 |= 1 << s->houseID; <- interesting ...
22:54:53 <Xaroth> typing "tile32 Tile_UnpackTile(" .. when I do the ( it comes up with possibilities, "const tile32 & )"
22:55:20 <TrueBrain> and the next statement: if (s->houseID == g_global->playerHouseID) s->variable_09 |= 0xFF;
23:01:59 <Xaroth> before I go even more crazy again, ox/oy are *h and px+ux/py+uy are 8l right?
23:02:18 <TrueBrain> lol, you are going crazy
23:02:35 <TrueBrain> o = offset, is on the lower 8 bits
23:02:45 <TrueBrain> p = position, is on the 6 lower bits of the high bit
23:02:46 <Xaroth> that's what i messed up last time then ^^
23:02:51 <TrueBrain> u = unused, is the top 2 bits
23:06:06 <Xaroth> right, where's my notepad
23:07:42 <TrueBrain> sometimes .. the code is just plain stupid ...
23:07:53 <Xaroth> and sometimes, it's me :P
23:08:10 <TrueBrain> s->hitpoints = si->hitpoints;
23:08:12 <TrueBrain> if ((int16)loc0A < (int16)0x0) {
23:08:16 <TrueBrain> s->hitpoints = si->hitpoints;
23:08:46 <TrueBrain> clearly they did a lot of heavy modifying .... it appears originally it wasn't the idea to have structure degrate over time when build on slabs
23:09:08 <Xaroth> they made a fix for that on fed2k
23:09:29 <TrueBrain> if I read this correctly, they intentionally added the flag to make it degrate nevertheless
23:10:07 <TrueBrain> it can be part of 'game balancing'
23:10:11 <TrueBrain> which normally is done at a later stage
23:10:45 <TrueBrain> damn, I wish MrFlibble would just join IRC and be available often ... such questions are perfect for him :p
23:10:56 <Xaroth> or segra, for that matter
23:11:02 <Xaroth> heck, both would be awesome :P
23:11:33 <TrueBrain> segra has code knoweldge, not of much use to me
23:11:40 <TrueBrain> MrFlibble has gaming experience
23:11:50 <TrueBrain> I for example wonder if 1.00 was the same
23:11:52 <Xaroth> no, but Segra has also been looking at the code for ages
23:12:03 * glx is thinking about pak.c :)
23:12:15 <Xaroth> so he might have found out other 'wierd' stuff related to it
23:12:38 <TrueBrain> yeah, but that is knowledge we will get too .. but okay, nevermind :)
23:13:06 <Xaroth> ok, the Y bit I got now
23:14:36 <Xaroth> TrueBrain: the packed struct is in an uint16, first 6 for X, second 6 for Y... both need to fit into p*, y is easy, but what if I directly put the uint16 into px and reset ux
23:15:05 <DorpsGek> Xaroth: Error: '0x3F' is not a valid base.
23:15:09 <DorpsGek> Xaroth: Error: '3F' is not a valid base.
23:15:16 <TrueBrain> ux + px = uint8, so that won't work .. but I don't get why you are having such a hard time with this function :p
23:15:32 <TrueBrain> first 6 bits needs to go to px, next 6 bits to py ..
23:15:38 <TrueBrain> py is harder than px btw ...
23:16:14 <TrueBrain> then wtf is your problem with x?
23:16:26 *** ChanServ sets mode: +v glx_
23:16:49 <Xaroth> the fact it's in the ox section, while I want to have it in the px section straight away without it being a mess code wise
23:17:03 <TrueBrain> btw, nicest solution is: s.py = (packed >> 6) & 0x3F; s.px = (packed >> 0) & 0x3F;
23:17:27 <TrueBrain> as that immediatly shows what the packed part is, and where the bits are coming from
23:18:07 <Xaroth> and they directly set dx (y) and set dl to 0x80
23:18:16 <Xaroth> hence not the >> 6 but << 2.
23:18:46 <TrueBrain> you do not have to follow the original code
23:18:53 <TrueBrain> you have to make it readable and understandable :)
23:19:09 <TrueBrain> which in this case means taking it down to its elements :)
23:19:20 <Xaroth> for me getting it to work is harder than making it readable :P
23:19:38 <TrueBrain> wtf ... this is completely crazy ... I have code which is impossible to be called ... at begin of function is: if (position == 0xFFFF) return. Now I have: if (position = 0xFFFF) midway the function ...
23:19:47 <TrueBrain> getting it to work is easy: do not change anything :p
23:20:09 <Xaroth> position never changes?
23:20:48 <TrueBrain> I am afraid it is a bit worse .. I have to look what is exactly in the uncalled code
23:23:35 <TrueBrain> in that case a piece of 'script' I think is never called ... lol
23:24:47 <Xaroth> it appears to work o_O
23:28:03 <Xaroth> 0F3F getting smaller and smaller
23:28:06 <TrueBrain> you have to name the emu_ functions
23:28:15 <TrueBrain> (see emu_unit.c or something for an example)
23:28:22 <TrueBrain> I mean the doxygen comment
23:28:45 <TrueBrain> and remove the tailing '*\n'
23:30:01 <TrueBrain> end comment lines with dots '.' in doxygen comments
23:30:10 <TrueBrain> + * Check whether a tile32 is valid <- DOT :p
23:30:18 <TrueBrain> + * @param tile The tile32 to check for validity <- DOT
23:30:37 <TrueBrain> + * @return true if valid, false if not <- 'true' is the beginning of a sentence, so capital T
23:30:55 <Xaroth> I didn't capitalize that one due to it being a value
23:30:59 <TrueBrain> + return (tile.d.ux == 0x0 && tile.d.uy == 0x0); <- I think '0' instead of '0x0' is nicer in this case, as it is an integer you are comparing
23:31:08 <TrueBrain> True is also an english word :)
23:31:21 <TrueBrain> but you never made it a capital, so that is a bullshit reason :)
23:31:24 <TrueBrain> or 'the' is a value too? :p
23:31:34 <Xaroth> no, that one was me being lazy
23:31:37 <TrueBrain> many of your 'tile32' should be 'tile'
23:31:41 <TrueBrain> + * Returns the X position of the tile32
23:31:48 <TrueBrain> not of the 'tile32' but of the 'tile' (the parameter)
23:32:06 <TrueBrain> + * @param tile the tile32 to get it's X-position from <- 'the' should be 'The' too (else it looks really ugly in Doxygen output ;))
23:32:37 <TrueBrain> + * Returns the data of the tile32 represented in uint32 <- something like 'Returns the tile as an uint32 value'?
23:32:47 <TrueBrain> + * @param tile The tile32 use <- que?
23:33:09 <Xaroth> heh, I see you're feeling better :)
23:33:10 <TrueBrain> + * @param tile the tile32 to get it's X-position from <- it is X position from? :p
23:33:50 <TrueBrain> + * Packs the 32b tile32 struct into 12 bit <- what?! 32b? I leave at 101k4! :p
23:34:15 <TrueBrain> + tile.d.py = (packed >> 6) & 0x3F ; <- space too much :p (before the ';')
23:34:32 <TrueBrain> and no, this is just my proof-read-mode :)
23:34:55 <TrueBrain> this is 'normal' communication in the OpenTTD dev-channel (or at least was when I was there :p)
23:35:32 <Xaroth> last time I linked the patch you were ill, and they had the same comment flaws ;)
23:35:38 <Xaroth> so it's good to have you back alive :)
23:35:51 <TrueBrain> last time I only checked the C code :)
23:36:14 <TrueBrain> nothing silly about
23:36:17 <TrueBrain> I believe newer versions add it
23:36:22 <TrueBrain> still, it is much nicer to add them :)
23:36:32 <TrueBrain> more silly TrueBrain, or pedantic TrueBrain :p
23:36:50 <Xaroth> first time I work with anything similar to Doxygen
23:37:13 <Xaroth> and re: "many of your 'tile32' should be 'tile'"
23:38:15 <Xaroth> how to differentiate the use of the object's name (tile) and it's type name (tile32)
23:38:32 <Xaroth> main comment, object name, param type name?
23:39:05 <TrueBrain> the last line I don't follow, but my point here was that you often refer to tile32, while you mean the parameter, not the type
23:39:10 <TrueBrain> like: void a(int myparam)
23:39:19 <TrueBrain> and then you have as comment: set the integer to 12
23:39:23 <TrueBrain> no, it is: set myparam to 12
23:39:42 <TrueBrain> (strictly, both are fully correct, but the latter is what you mean)
23:39:54 <Xaroth> * Returns the Y position of the tile.
23:40:05 <Xaroth> * @param tile The tile32 to get it's Y-position from.
23:40:12 <TrueBrain> that 'tile' is a 'tile32' is just a minor detail
23:40:28 <TrueBrain> (just be consistant with Y-position and Y position)
23:40:46 <Xaroth> yeh, i had a 'waaaait a minute'
23:41:07 <TrueBrain> the latter is bullshit .. it is her, not hers :p
23:42:03 <TrueBrain> hmmm .... cool .. every windtrap you build, it does: emu_incw(&emu_get_memory16(emu_es, emu_bx, 0x1A));
23:42:14 <TrueBrain> so it doesn't add the amount of power a windtrap gives, just the amount of windtraps there are
23:42:34 <Xaroth> no wait, nevermind, that hack doesn't work :P
23:42:51 <Xaroth> and it doesn't do that
23:43:00 <Xaroth> as the windtrap's power generation is directly related to it's % hitpoints
23:43:11 <Xaroth> 50% hp windtrap generates 50 power
23:43:33 <TrueBrain> then explain to me why it keeps track of the amount of windtraps?
23:43:36 <TrueBrain> windtrapCount a good name for it btw?
23:43:55 <Xaroth> count total power generated, divide by amount of windtraps
23:43:57 <TrueBrain> fair enough, but then I should find an increase in a moment too of the real value
23:44:17 <Xaroth> since the game displays the 'average required'
23:44:40 <Xaroth> I think you'll find one related to silos/refineries as well
23:44:52 <Xaroth> that's also showing an average
23:45:10 <Xaroth> most likely credits / silo+refinery count
23:45:24 <TrueBrain> @calc 0x2e78 - 0x2C76
23:47:15 <Xaroth> heh @ emu_Tile_GetPackX()
23:48:33 <Xaroth> GetPackY() does exactly what you suggested for unpacking y, btw
23:55:21 <TrueBrain> okay, took care of most of this function .. it places the building .. but it has exception code for walls and slabs ... so lets do that now :)
23:55:37 <Xaroth> I'm making it Tile_UnpackX and Tile_UnpackY rather than Tile_GetPackX/Y as the names are somewhat confusing
23:56:00 <TrueBrain> your naming suggests it does something related to unpacking
23:56:28 <Xaroth> it takes a tile_packed (the uint16) and retrieves the X or Y from it
23:57:17 <TrueBrain> euh .. how to explain
23:57:21 <Xaroth> emu_Tile_GetPackY literally does, is return (arg1 >> 6) & 0x3F
23:57:34 <TrueBrain> you can unpack a uint16 to a tile32, as you make from something small something big
23:57:40 <TrueBrain> bug GetPackX does nothing remotely like that
23:57:57 <Xaroth> it unpacks half of the uint16 into a separate uint16 :P
23:58:03 <TrueBrain> that is not unpacking
23:58:13 <TrueBrain> (which your one-line exactly shows)
23:58:53 <Xaroth> as the input is packed, and you are getting the X(or Y )
23:59:32 <TrueBrain> I do understand what you try to say, but I like to keep Get/Set/Is for what they do :)
continue to next day ⏵
