bug in move.c?

I've written a parser for xdump in Java and am starting to write a
civmover tool that uses it. When reading the Empire source code, I
came across the following.

It seems to me that the calculation is taking mob1 - mob0. But mob0
is always higher than mob1. Is this a bug in move.c? Does it in fact
not matter what the eff is of a sector when you move into it?

double sector_mcost(struct sctstr *sp, int mobtype) {
double base, cost;

base = dchr[sp->sct_type].d_mob0;
if (base < 0)
return -1.0;

/* linear function in eff, d_mob0 at 0%, d_mob1 at 100% */
base += (dchr[sp->sct_type].d_mob1 - base) * sp->sct_effic / 100;
if (CANT_HAPPEN(base < 0))
base = 0;

P.S. I'll throw up my xdump parser on sourceforge when it's done

On Nov 7, 11:30 pm, Ken Stevens <khstev... RemoveThis @gmail.com> wrote:
> I've written a parser for xdump in Java and am starting to write a
> civmover tool that uses it. When reading the Empire source code, I
> came across the following.
>
> It seems to me that the calculation is taking mob1 - mob0. But mob0
> is always higher than mob1. Is this a bug in move.c? Does it in fact
> not matter what the eff is of a sector when you move into it?
>
> double sector_mcost(struct sctstr *sp, int mobtype) {
> double base, cost;
>
> base = dchr[sp->sct_type].d_mob0;
> base += (dchr[sp->sct_type].d_mob1 - base) * sp->sct_effic / 100;


I think what the author intended to write here is

base += (dchr[sp->sct_type].d_mob1 - base) * (100 - sp->sct_effic) /
100;

right?

Is this a real bug in move.c? I find it hard to believe that sector
efficiency doesn't affect mobcost and no-one has noticed...