[http://sourceforge.net/p/ufoai/bugs/310 Item 310] imported from sourceforge.net tracker on 2013-01-28 18:18:28

We have, what seems to be, a crash at too many
employees. Over 31?

Here are parts of IRC logs related to this.

<ubequitz> I got a "ufo: client/cl_campaign.c:433:
CL_CampaignActivateStageSets: Assertion `set->def&#039;
failed.",
"Received signal 6, exiting..." after finishing the
Wellington mine
mission though on my latest run [01:46]


<freakyd> ufo: client/cl_campaign.c:2364:
CL_UpdateCharacterStats: Assertion
`chr&#039; failed.Received signal 6, exiting... [02:04]
<freakyd> Revision: 3433
<freakyd> URL:
https://svn.sourceforge.net/svnroot/ufoai/ufoai/branches/ufoai_2.0
<freakyd> it happened just as I won the base mission
<ubequitz> hmm [02:06]
<freakyd> when I clicked continue
<Bandobras> any other interesting message before the
error message?
<freakyd> nothing wierd just some regular
CL_PlaceItem [02:07]
<freakyd> it happens every time
<Bandobras> freakyd: thank you, I&#039;ll test then
<freakyd> ok and also I only have 1 base and 1
dropshi[ [02:20]
<freakyd> dropship
<freakyd> plus the interceptor
<freakyd> ok I did the killteam 7 and it crashed still

<Bandobras> CL_UpdateCharacterStats: numTeamList: 0
[05:24]
<Bandobras> ufo: client/cl_campaign.c:2364:
CL_UpdateCharacterStats: Assertion
`chr&#039; failed.
<Bandobras>
<Bandobras> Program received signal SIGABRT, Aborted.
<Bandobras> [Switching to Thread -1213012288 (LWP 26496)]
<Bandobras> 0xb7c4f947 in raise () from /lib/tls/libc.so.6
<Bandobras> (gdb) bt
<Bandobras> #0 0xb7c4f947 in raise () from
/lib/tls/libc.so.6
<Bandobras> #1 0xb7c510c9 in abort () from
/lib/tls/libc.so.6
<Bandobras> #2 0xb7c4905f in __assert_fail () from
/lib/tls/libc.so.6
<Bandobras> #3 0x0805ccc8 in CL_UpdateCharacterStats
(won=1) at
client/cl_campaign.c:2364
<Bandobras> #4 0x0805cf8d in CL_GameResultsCmd () at
client/cl_campaign.c:2457
<Bandobras> #5 0x0808d68c in Cmd_ExecuteString
(text=0xbfb4cc84 "game_results
1")
<Bandobras> at qcommon/cmd.c:793
<Bandobras> #6 0x0808c9d5 in Cbuf_Execute () at
qcommon/cmd.c:263
<Bandobras> #7 0x0806e26b in CL_SendCommand () at
client/cl_main.c:1330
<Bandobras> #8 0x0806e9b9 in CL_Frame (msec=1) at
client/cl_main.c:1543
<Bandobras> #9 0x080965c2 in Qcommon_Frame (msec=1) at
qcommon/common.c:1538
<Bandobras> #10 0x080ad24d in main (argc=10,
argv=0xbfb4d204)
<Bandobras> at ports/linux/sys_linux.c:424
<Bandobras> (gdb)
<Bandobras> not base defence...
<ubequitz> wow [05:25]
<ubequitz> what is going on there?
<ubequitz> that is freaky&#039;s bug?
<Bandobras> seems so
<Bandobras> I tried to crash by overflow of soldiers
<Bandobras> but I couldn&#039;t [05:26]
<Bandobras> so I went to a mission
<ubequitz> ok
<ubequitz> ahh...
<ubequitz> and killteam 7
<Bandobras> after killteam 7/Continue this happened
<ubequitz> I think that was freaky&#039;s problem
<ubequitz> I asked him
<ubequitz> how many soldiers he had
<ubequitz> hireable
<Bandobras> oh!
<ubequitz> he had lots...
<ubequitz> but he wasnt sure if basedefense was the
first mission of the month
<ubequitz> or not
<Bandobras> /* these are 31bit masks FIXME: still? */
<Bandobras> /* NOTE: we only use the first 19 (because
we can only select
from 19 soldiers) */
<Bandobras> /* see cl_numnames cvars */
<Bandobras> int teamMask[MAX_AIRCRAFT]; /* Soldiers
assigned to a
specific aircraft. */
<Bandobras> int teamNum[MAX_AIRCRAFT]; /* Number if
soldiers
assigned to a specific aircraft. */
<Bandobras> int deathMask; /* Mask of soldiers
(relative to gd.employees) that have died in the
current
mission. Needed so soldiers are resurrected on
mission-retry. */
<Bandobras>
<Bandobras> cl_basemangement.h [05:27]
<Bandobras> :)
<Bandobras> the masks are used in CL_UpdateCharacterStats
<Bandobras> or something
<ubequitz> looks interesting
<Bandobras> hoerer lately tried [05:28]
<Bandobras> to get rid of the masks
<Bandobras> but he failed
<ubequitz> :)
<Bandobras> perhaps we can report the error
<Bandobras> and ask him to try once more :)
<Bandobras> he knows the code there



===== Comments Ported from Sourceforge =====

====== bandobraz (2006-09-08 22:35:00) ======

Logged In: YES
user_id=1557623

I have an idea: perhaps instead of the deathMask, add a flag
to each employee that marks him for death. At the end of
mission clear the flags, mark dead soldiers, check for
retry, if retry, do nothing, if no retry, remove those marked.
====== nobody (2006-09-09 11:04:07) ======

Logged In: NO

Actually, i really hate to touch code that involves
bit-handling&bitmasks, so I know the code there good enoguh
to avoid every looking at it again. ;)

That said, i&#039;ll try to find this bug, but i really hate this
part of the code (not only the bitmasks, but the whole
battlescape code), so I&#039;ll probably do this when I find
myself in a surplus of happiness. Not to speak of replacing
it ... brrrr.


Werner

====== nobody (2006-09-09 11:08:17) ======

Logged In: NO

Concerning a &#039;death&#039; flag for every soldier ... that&#039;s what
the HPs are for, no? ... If HPs are 0 he is dead, clean and
simple. At least that&#039;s what _I_ would have used if I wrote
this from scratch.

The whole "retry" code is a pain to read and understand,
that&#039;s one reason i hate touching it.

Werner
====== bandobraz (2006-09-09 15:57:02) ======

Logged In: YES
user_id=1557623

A brilliant idea. This is, more or less, a RC5 stopper bug,
so I think we have to do something, anyway.
====== bandobraz (2006-09-09 20:58:56) ======

Logged In: YES
user_id=1557623

Some more IRC insights:

The bug can be easily reproduced by increasing initial
employees in base/ufos/campaign.ufo.

<Rani> Here&#039;s the offending line:return
baseCurrent->teamMask[aircraft_idx] &
(1 << employee_idx);
<CIA-18> cassiterite * r3491 /ufoai/trunk/src/game/q_shared.c: *
src/game/q_shared.c fixed "crash trying to equip a
solider&#039;s torso
with non-armor items" issue.
<Bandobras> Rani: baseIdHired may indicate if the soldier is
assigned to
aircraft
<Rani> cl_team, line 874
<Bandobras> Rani: ok [20:57]
<Bandobras> Rani: just remove the line :D
<Rani> if employee_idx >=32 you get overflow, i guess.
<Rani> Returns "true" when it should be false.
<Bandobras> ok
<Bandobras> Rani: what do you propose?
<sheldonh> ubequitz: one more backpack question [20:58]
<Rani> *thinking*
<sheldonh> ubequitz: should i be able to switch a rocket
launcher and a
shotgun from hand to backpack, without first dropping
the rocket
launcher on the floor?
<ubequitz> sheldonh, in the current code you would have to
to the latter or
move the shotgun to your holster then move the rocket
launcher to
your right hand&#039; [20:59]
<sheldonh> ubequitz: "in the current code"... so there&#039;s a
possibility a more
TU-expensive "in the air" swap might be considered? [21:00]
<ubequitz> sheldonh, in reality if you had to move an item
out of a backpack
and another item in, you would temporarily have to have
one on the
ground
<CIA-18> bandobraz * r3492 /ufoai/branches/ufoai_2.0/
(base/ufos/menu_althud.ufo src/client/cl_actor.c): *
merged 3490 into
branch 2.0 (Jiten&#039;s altHUD tweak)
<ubequitz> sheldonh, it is a bit arbitrary
<sheldonh> ubequitz: yup. this is more about user
convenience than about
efficiency of soldier movement :) [21:01]
<Bandobras> ubequitz: please mark the bug as fixed
<ubequitz> sheldonh, this is true... with the current
complexity of the
inventory code I wouldnt want to add that feature... but
it would
be possible
<ubequitz> Bandobras I didnt realise one was open for that
issue [21:02]
<ubequitz> Bandobras, are you referring to the IR goggle crash?
<ubequitz> oh... I see
<ubequitz> he tried to put it on the soldiers head
<ubequitz> makes sense :)
<ubequitz> I like his idea... goggles should go on the head
after all :)
[21:03]
<sheldonh> i love this game
<CIA-18> bandobraz * r3493
/ufoai/branches/ufoai_2.0/src/game/q_shared.c: *
merged 3491 into branch 2.0 (armor equipment crash fix)
<Rani> Bandobras: well, the whole "mask" system in
shortsighted. It assums max
soldiers hired. and assumes a low number. [21:04]
<Rani> Bandobras: If we keep it in the current form, it
could be make unsinged
long, which will up us to 64, maybe 128 soldiers.
<Bandobras> a quick dirty fix
<Rani> Bandobras: my thoughts exactly. [21:05]
<Bandobras> for 256 I would go, though... :)
<sheldonh> more linked lists, i say
<Rani> Bandobras: maybe it can be replaced with long[4] or
long[8].
<Bandobras> uhmmm
<Rani> Bandobras: thats more then 100 soldiers. [21:06]
<Bandobras> and let the trunk guys resolve it later...
<Bandobras> that would be brilliant for branch 2.0
<Rani> Bandobras: but that means combing all the code for
the use of that var
<Bandobras> oh
<Bandobras> then, don&#039;t
<sheldonh> ctags
<Bandobras> sheldonh: ? [21:07]
<sheldonh> with ctags, combing&#039;s pretty easy
<Bandobras> what are ctags?
<Bandobras> Rani: is there a way without combing? [21:08]
<sheldonh> Bandobras: ctags analyzes your c code, so that
tools that know how
to use it (like vi) know about the tokens in your source
tree,
massively improving the navigability of your source tree
[21:09]
<Bandobras> oh, thanks
<Bandobras> I thought this is a type with more bits than 64 :D
<ubequitz> I remember using ctags once [21:10]
<sheldonh> wouldn&#039;t that be nice
<Rani> Bandobras: I dono. What happens when you shift elft
an array?
<ubequitz> I should look it up again
<sheldonh> usually, when you find yourself wanting larger
bitmasks, there&#039;s a
collection you&#039;re missing (hence my "more linked lists"
chirp)
<ubequitz> does mattn use an IDE?
<ubequitz> he fixes stuff like lightning, but maybe that is
because he is elite
[21:11]
<sheldonh> but i get that you&#039;re talking about a minimal
impact hack for a
release
<Bandobras> Rani: perhaps only compiler warnings?
<Bandobras> Rani: but perhaps it works?
<Bandobras> sheldonh: yes
<Rani> Bandobras: i&#039;ll give it a shot.
<Bandobras> minimal hacks take longest :P
<sheldonh> ixnay on the shifting array
<sheldonh> ansi C mandates that each of the operands of the
bitwise shift
operator shall have integer types [21:12]
<Bandobras> oh
<Bandobras> makes sense...
<Bandobras> it puts them into registers, etc.
<Bandobras> we&#039;d have to use MMX, or somethings [21:13]
<Bandobras> for such long registers
<ubequitz> the whole idea of teamMask and deathMask etc in
my opinion is not
an elegant hack
<sheldonh> i haven&#039;t really been listening, but it sounds a
lot like you&#039;re
just missing a member in some struct [21:14]
<Rani> Bandobras: if only it was properly abstracted...
* ubequitz agrees with sheldonh
<Rani> I dont see any other way then to change it. [21:15]
<Bandobras> Rani: go ahead
<ubequitz> it is too deeply nestled into the core code
<Bandobras> Rani: how?
<Rani> Its alot of work. :)
<Rani> Make that bitmask thing bigger
<Rani> alot bigger
<Rani> and replace those shits with a proper set/get function.
<Bandobras> Rani: I&#039;d trash it
<Rani> shifts*
<Bandobras> :D [21:16]
<Bandobras> Rani: I&#039;d go for the HP idea
<Rani> What hp idea?
<Rani> Its not the deathmask
<Bandobras> the one in the bug report
<Rani> its the "who is on which dropship" mask
<Bandobras> use HP instead of the mask
<Bandobras> Rani: oh my
<Bandobras> really?
<Rani> it thinks soldier 32 is on the drop ship [21:17]
<Rani> even if its not hired
<ubequitz> wow
<Rani> becouse the line i gave you overflows
<Rani> and returns true
<ubequitz> be careful...
<ubequitz> in a basedefense
<ubequitz> we may change the code not to look at aircraft
members at all
<Rani> so when you finish a mission
<ubequitz> because you can defend a base with soldiers
stationed at a base
without any aircraft
<Rani> and it wasnt to upgrade skills for soldiers on the craft
<Rani> it gets number 32 as "onboard" [21:18]
<sheldonh> are the initial characters in the campaigns
randomized?
<Rani> but then tries to get the chr for it
<Rani> and since he&#039;s not hired he returns "null"
* ubequitz is afk
<Rani> and you get assertation fail.
<Rani> And thats your bug.
<Bandobras> sheldonh: yes [21:19]
<Bandobras> Rani: now I get it
<Bandobras> is teamMask relative to all employees?
<sheldonh> okay, that would explain teh suck weapon
assignment :) [21:20]
<Rani> No, soldiers only
<Bandobras> only in the base, or in all bases?
<Rani> One base.
<Rani> Should be solved if you limit 30 solderis per base
<Rani> or
<Rani> change to long
<Bandobras> then 64 can be enough for a start... [21:21]
<Rani> and limit to like 60
<Bandobras> but I fear deathMask is relateive to all
employees in all bases...
<Bandobras> I may be wrong, though
<Rani> The comment near it says you&#039;re right [21:22]
<Bandobras> Rani: I can write the limits (but I&#039;ll not check
for tweaked
campaign.ufo)
<Bandobras> Rani: the comment was mine ;P
<freakyd> why do you need to make a limit on the number of
dudes? [21:23]
*** mattn2 (n=mattn@p5484A4C4.dip0.t-ipconnect.de) has quit:
"Ex-Chat"
<Bandobras> because we are lazy :P
<Rani> Bandobras: no, its for soldiers only. [21:24]
<freakyd> hah hah
<Bandobras> Rani: the deathMask?
<Rani> Bandobras: yes.
<Bandobras> Rani: so please change the comment
<freakyd> it should be some kind of list
<Bandobras> Rani: and change things to long or something
<Bandobras> Rani: and please test
<Bandobras> Rani: and then I&#039;ll add the limits...
<Bandobras> Rani: is that sensible? [21:25]
<Bandobras> freakyd: code it in 12 hours and you&#039;re in RC5,
agreed?
<Rani> Bandobras: I&#039;ll give it a shot, see if it even
works. [21:26]
<Bandobras> :)
*** Winterslice (n=no@212-127-168-8.cable.quicknet.nl) has
joined channel
#ufo:ai [21:28]
<Bandobras> Rani: also please test if you have 63 workers
and then you get 2
soldiers from the nations...
<sheldonh> i&#039;d like to suggest that "Equip aircraft" be
renamed to "Man
aircraft", complaints about sexism notwithstanding [21:33]
<Bandobras> good idea -> SF -> FR [21:34]
<Rani> Bandobras: Btw, who made this code originally? He
isnt around anymore?
<Rani> Maybe split to "equipe team" and "mean aircraft"
[21:35]
<Rani> incase you want to equipe soldiers not on aircraft?
<Rani> man aircraft*
<Bandobras> another good idea
<sheldonh> that&#039;s it. there&#039;s already "Equip", which equips
the craft itself
<Bandobras> I don&#039;t know it the oldest developers remember
who wrote that
code... [21:36]
<sheldonh> http://phpfi.com/150715 [21:37]
<sheldonh> :)
<Bandobras> sheldonh: therefore I propote you from SF -> FR
to SF -> Patches
[21:39]
<Bandobras> promote
<Bandobras> please submit it (even better with the Rani
suggestions, too)
[21:40]
<freakyd> my dude vanished for the mission again [21:41]
<freakyd> it&#039;s always team member 8
<Rani> Bad new, it doesnt fix it. I probably misunderstood
the reason for the
overflow.
<sheldonh> Rani: just explain how you&#039;d like to improve on
the Man aircraft
idea?
<Winterslice> A separate screen for equipping troops at the
base and assigning
troops to an aircraft. [21:42]
<Bandobras> freakyd: bad news :(
<Rani> Well, in the ver i have, i need to go into an
aircraft screen to equipe
soldiers.
<Rani> Id like it to have its own screen [21:43]
<sheldonh> Winterslice: interesting idea...
<Rani> and a differant screen to assign soldiers to aircrafts.
<freakyd> bad news?
<sheldonh> Winterslice: might not be as useful as you&#039;d expect
<Winterslice> sheldonh: -Good- idea.
<Bandobras> freakyd: your guy vanishing
<freakyd> ohhh
<sheldonh> Winterslice: because you tend to equip a team,
not individuals
<Bandobras> freakyd: is it game start, or only when you have
many soldiers?
<Winterslice> Say your base gets attacked while your
soldiers are out.
<freakyd> it&#039;s when I have many soldiers
<Winterslice> Your remaining troops won&#039;t have any equipment.
<sheldonh> lol [21:44]
<freakyd> I am pretty far in the game
<freakyd> I am clearing out downed UFOs
<Rani> I equipe based on skills
<freakyd> and researching tachyon sniper
<Rani> And rename them to reflect role
<Rani> then i assign to aircraft as a team
<sheldonh> yeah, renaming helps a LOT
<Rani> .. us x-com veterans.
<Bandobras> freakyd: perhaps the fix we are currently
working on will fix it...
[21:45]
<sheldonh> :)
<freakyd> ok
<Rani> can com_printf handle longs? [21:47]
<Bandobras> I guess so [21:50]
*** acardenas (n=ACM@201.240.197.172) has joined channel
#ufo:ai [21:51]
<sheldonh> what is com_printf? [21:52]
<ubequitz> just pretend com_printf is printf... except it
prints to the
console, a log and stdout [21:53]
<sheldonh> sorry, i meant where does it come from?
<sheldonh> can&#039;t find it in trunk/src or /usr/include [21:54]
<Bandobras> Com_Printf
<sheldonh> ah
<Bandobras> Rani is a windows guy :P
<Bandobras> case does not matter...
<sheldonh> c is c :) [21:55]
<ubequitz> so we have any girl hackers yet?
<Bandobras> we have one, but she is busy...
<ubequitz> I mean do we
<sheldonh> i&#039;ve hacked the odd girl
<ubequitz> well i tis past my bedtime again... good night
[21:57]
<Rani> *problem* [21:58]
<Rani> Looks like ansi c defines long as 32 bits?
<Bandobras> ubequitz: good night :D
<Rani> Crap [21:59]
<Rani> Its 64 bit on 64 bit machines only [22:00]
<Bandobras> oh [22:01]
<sheldonh> Rani: there&#039;s not much you can assume about bit
widths of c types,
because c is an arch-specific language
<Rani> There&#039;s a minimum size i can assume
<sheldonh> Rani: if you&#039;re sure your code will never run on
a processor with a
native word size smaller than 32 bits, then long long is
guaranteed
to give you at least 64 bits :)
<Rani> But thats 32 in this case, which doesnt help much.
[22:02]
<sheldonh> not really, no
<sheldonh> not unless you limit your code to certain
architectures
<Rani> c is so fucked up :)
<Bandobras> i386 is 32, so long should be 64...
<sheldonh> that&#039;s because hardware is so fucked up :)
<Rani> Any ideas , guys? [22:03]
<sheldonh> Bandobras: no. mostly long and int are the same
width :)
<Bandobras> oh
<sheldonh> Rani: what&#039;s the question?
<Rani> 1 << employee_idx this overflows
<Rani> if idx>=32
<Bandobras> sheldonh: we want a type that is >= 64 bits and
shifts work on it
<sheldonh> still on the silly bitmask stuff
<Bandobras> yes
<sheldonh> what type is employee_idx? [22:04]
<Rani> It has to be a quick fix if they want it on the rc5 :)
<Rani> int.
<Rani> This is too fucked up. There&#039;s no salvaging this.
[22:05]
<sheldonh> so you&#039;re taking some number and raising it to
the power of 32,
effectively, and then you&#039;re disappointed the result
doesn&#039;t fit in
a 32 bit integer?
<sheldonh> assign the result to a long long
<Rani> I&#039;m disappointed its 32 bits integer.
<Bandobras> sheldonh: long long? [22:08]
<sheldonh> yes, double the architecture&#039;s native word size.
usually stored in
a pair of registers [22:09]
<Rani> No go. The compiler still makes the calculations at
32 bits.
<sheldonh> Rani: typecast :)
<sheldonh> Rani: from the C standard: The result of E1 <<
E2 is E1
left-shifted E2 bit positions; vacated bits are filled
with
zeros. If E1 has an unsigned type, the value of the
result is E1 x
2E2, reduced modulo ULLONG_MAX+1 if E1 has type
unsigned
long long, ULONG_MAX+1 if E1 has type unsigned long,
UINT_MAX+1 otherwise. [22:10]
<sheldonh> you get overflow because you&#039;re operating on
an int [22:11]
<sheldonh> so operate on a long long
<sheldonh> ((long long)idx) << 32
<sheldonh> probably ((unsigned long long)idx) << 32, but
then i don&#039;t know
what you&#039;re trying to get to
<Rani> Did you like invent c, or something? [22:13]
<sheldonh> Rani: lol [22:14]
<Rani> Well, it doesnt crash anymore... but i forsee this
"solution" coming
back and biting us in the ass.
<sheldonh> Rani: i spent some time as a freebsd developer
<sheldonh> Rani: got some solid coaching from some very
hardcore c hackers
<Bandobras> wow
<sheldonh> man builtin on any macosx box and scroll down to
the AUTHORS
section :) [22:16]
*** kratz00 (n=kratz00@unaffiliated/kratz00) has joined
channel #ufo:ai
<sheldonh> of course, this is all academic knowledge. i&#039;m
not a great c
developer :) [22:17]
<CIA-18> bandobraz * r3494 /ufoai/branches/ufoai_2.0/src/
(client/cl_parse.c
game/g_client.c): [22:18]
<CIA-18> * src/client/cl_parse.c Rani&#039;s patch 1555228 hacked
by me; "owners"
of a floor entity are no longer only the first found
actor, but all
of them (some of them may be dead)
<CIA-18> * src/game/g_client.c changes similar to those in
patch 1555228
<Bandobras> Rani: please test this!
<sheldonh> i wrote the truncate(1) utility for freebsd, and
that&#039;s about all
the c coding i did (&#039;cept for a little work in inetd(8)
and jot(1))
<Bandobras> sheldonh: so how many bits have we gained?
<Bandobras> sheldonh: is it 64 now?
<sheldonh> Bandobras: on a 32bit architecture, yes
<Bandobras> cool, thanks :) [22:19]
<Bandobras> 64 should be enough for everyone :P
<Bandobras> 64 soldiers, that is
<sheldonh> long long isn&#039;t actually guaranteed to be any
bigger than long, but
practically speaking, that&#039;s how it is on 32bit platforms
<sheldonh> we can get rid of the bitmasks in 2.1 :) [22:20]
<Bandobras> we will :)
<sheldonh> assuming i ever finish equipping this team :)
<sheldonh> flashbangs [22:21]
<Rani> Blah. Not good. [22:23]
<Rani> Wont work.
<sheldonh> flashbangs will be awesome :)
<Rani> Talking about fix.
<Rani> not your flashbangs :) [22:24]
<sheldonh> oh :)
<Rani> If you have soldier with id>64 it will crash again.
<Rani> Waht was i thinking?
<Rani> Damn damn damn... [22:25]
<Bandobras> why would a soldier have id>64?
<Bandobras> oh, you mean that&#039;s nor relative to soldiers
only, after all?
<Rani> The mask is
<Bandobras> but to all employees?
<Rani> But it shits by the id
<Rani> which isnt
<Bandobras> ;>
<Rani> and the shift zeroes out.
<Bandobras> that&#039;s insane [22:26]
<Rani> shifts!
<Bandobras> how can it be relative to soldiers but shift by
employees?
<Rani> "Fruidian slip is when you say one thing and mean
your mother"
<sheldonh> it&#039;s legacy code -- it can do anything :)
<Bandobras> so we are limited to 64 employees total, right now?
*** dugan (n=dugan@rdu-nat.rpath.com) has joined channel #ufo:ai
<Rani> Yes, pretty much.
<Bandobras> that&#039;s much worse than 4 * 64... [22:27]
<Bandobras> and harder to code the limits when hiring more...
<sheldonh> you can do more complex bitmask operations, you
just can&#039;t use a
simple << or >> for them
<Bandobras> too much hacking
<Rani> Bascly, you&#039;r limited to 64 soldiers if you can make
sure they get the
lowest ids.
<Rani> :)
<Bandobras> shift
<Bandobras> shift!
<Rani> and any number of employees, unless theres some other
"mask" hiding
somewhere. [22:28]
<Rani> lol
<Bandobras> no other masked code :)
<Bandobras> (employee-related)
<Rani> Riiight. :) [22:29]
<Bandobras> what do we do?
<sheldonh> we need a model face that wears a skimask and
dies when the 65th
employee arrives :)
<Bandobras> that would keep players occupied for a moment
<Bandobras> needed to fix it properly :D [22:30]
<Rani> Limit the game to 64 soldiers, and make a pool of
them at the start?
<Rani> :D
<Rani> "Sorry, the earth is out of soldiers"
<Bandobras> one more problems, we have to limit not the
number of current
[22:31]
<Bandobras> employees but a all employees, including dead ones?
<sheldonh> maybe you could use an array of bytes as a
bitmask, and offset into
it with the employee/solder id?
<Bandobras> or are the ids recycled?
<Rani> How should I know? I started messing with this three
days ago. [22:32]
<Bandobras> I guess we should fix it properly, then
<sheldonh> Rani: you have a huge head start :)
<Bandobras> any hack that involves finding all places the
mask is touched
<Bandobras> means lots of work, anyway
<sheldonh> Bandobras: earlier, someone said it&#039;s the minimal
impact hacks that
take the longest ;)
<Bandobras> shift!
<Rani> It appears in approx 20 places.. for the planemask
at least. [22:33]
<Bandobras> we delay RC5 for a year and start coding, then :D
<Rani> Deathmask another 8 or so.
<Bandobras> make it 2 years
<Rani> Naah. another wekk or two. [22:34]
<Rani> But what solution do we want?
<Bandobras> I vote for HPs
<Bandobras> least work
<sheldonh> Rani: employees grow a dead attribute
<Rani> Thats for deathmask..
<Bandobras> oh
<sheldonh> actors, even
<Rani> what about who&#039;s on board which plane?
<Bandobras> ha
<Bandobras> is it even needed? [22:35]
<sheldonh> rani: each plane has a carrying capacity
<Rani> It&#039;s used in a couple of places, so i guess so.
<sheldonh> Rani: use that to dynamically size an array of
pointers to occupants
<Bandobras> pointers in crafts are bad, because crafts get saved
<Bandobras> to savegames [22:36]
<sheldonh> Bandobras: sooner or later, something&#039;s gotta give :)
<Bandobras> :DDDD
<Rani> sheldonh: who ever made this code tried to go for
speed... maybe he
knew something we dont? lists are very slow.
<sheldonh> Bandobras: but okay, store the ids of the
occupants, not pointers
to them
<Bandobras> and he worked on 486DX2 :)
<sheldonh> Rani: dude, with a game like this, the
performance impact of
maintainable code is sooo not an issue :0 [22:37]
<sheldonh> Rani: you&#039;re worried about a few hundred lost
clock cycles
<Rani> again, What do i know?
<Rani> I&#039;m not worried, the guy who wrote this was.
<sheldonh> Rani: but we&#039;re playing ogg theme music in the
background
<sheldonh> Rani: smells like premature optimization if you
ask me
<Bandobras> Rani: I guess one can rewrite the code with
the teamMask [22:38]
<Bandobras> Rani: so that is does not use the mask
<Rani> If it was up to me, each game object would have ahd a
unique id.
<Bandobras> Rani: at the cost of some for or while
<Rani> instead of using pointers.
<sheldonh> these masks need to go
<Bandobras> Rani: without even changing the structures
<sheldonh> pointers are faster, ids are easier to persist
<sheldonh> typically, the right answer is both :)
<sheldonh> use pointers in game, and when it comes time to
save, use the
pointers to discover ids and save those [22:39]
<Rani> Some sort of smart pointers that convert one to the
other on load/save.
<sheldonh> crippling your data structures to make them easy
to save gets you
into all sorts of trouble
<sheldonh> as seen here :)
<Bandobras> it&#039;s already a hack similar to this
<freakyd> where is MAX_EMPL defined?
<Bandobras> but not systematic
<freakyd> can&#039;t find it
*** dugan (n=dugan@rdu-nat.rpath.com) has quit: "Ex-Chat"
<Bandobras> in the savefile code
<sheldonh> src/client/cl_basemanagement.h
<Rani> Well, I&#039;ll work on this the following week, I
guess. [22:40]
<Rani> This will take a while.
<Bandobras> ./client/cl_employee.h: MAX_EMPL
/* for c
<_Bnu> Set it to 5266.
<sheldonh> MAX_EMPL as opposed to MAX_MEPLOYEES? [22:41]
<sheldonh> it&#039;s just an enum
<sheldonh> it has no meaningful integer value
<Rani> probably used in some array arr[max_empl]
<_Bnu> Set it to 5266 anyway.
<sheldonh> Rani: hopefully not [22:42]
<Bandobras> _Bnu: we&#039;ve already thought about it
<freakyd> yes it&#039;s used in an array for employees when it&#039;s
defined
<sheldonh> Rani: since it has no meaningful integer value,
using it as an
array offset is meaningless ;)
<Bandobras> _Bnu: but it does not work
<sheldonh> this code is beginning to scare me :)
<Bandobras> sheldonh: you&#039;ve seen nothing yet 8O [22:43]
* Bandobras afk
*** Winterslice (n=no@212-127-168-8.cable.quicknet.nl) has
quit: "You gon&#039; get
hurt by my pimp cane one way or &#039;notha."
<sheldonh> i&#039;m talking shit about enums, sorry
<sheldonh> too much java [22:44]
<sheldonh> from the spec: The expression that defines the
value of an
enumeration constant shall be an integer constant
expression that
has a value representable as an int.
<Rani> sheldonh: its probably an array holding alot of
values, where each cell
is a max_something
<sheldonh> Rani: yeah, probably array of pointers

====== bandobraz (2006-09-18 21:14:41) ======

Logged In: YES
user_id=1557623

Rani has fixed it in SVN and RC5, fortunately.