I decided to take a look at the networking support between Windows and
Linux today, and want to see if what I found matches what other people
have found.
1. The Linux host runs fine, the Windows client crashes with an empty
random table. This is because it is unable to place its characters on
I'm replying through a webmail, so please bear with me.
Quoting Kyle <[EMAIL PROTECTED]>:
> 1. The Linux host runs fine, the Windows client crashes with an empty
> random table. This is because it is unable to place its characters on
> the map, and uses up all 1024 random numbers in the table tryi
Hi,
Alain TAUCH a écrit :
> the find path argument is mandatory on freebsd (at least), here's a fix:
Thanks for the info, I have applied your suggestion together with a
general clean-up. See r3001 for more details.
I hope it is still compatible, but I bet sed and xargs are also
available under
[EMAIL PROTECTED] a écrit :
> can't attach a patch nor commit right now, so I'll just explain. Action::Push
> has a weird way to do the memcpy, using &tmp instead of tmp. The same was
Fix in svn as of r3002. Not yet tested if it improves anything.
___
W
Hello,
in weapon/explosion.cpp, there's a strange calculus in
ApplyExplosion_common up to line 156:
double dmg;
if ( config.explosion_range != 0)
dmg = cos(M_PI_2 * distance / config.explosion_range);
else
dmg = cos(M_PI_2 * distance);
dmg *= config.damage;
obj->AddDamage (config.damage);
E
Hello,
you're right! It's commited in r3010 :-)
Matt (gentildemon)
Kurosu a écrit :
> Hello,
>
> in weapon/explosion.cpp, there's a strange calculus in
> ApplyExplosion_common up to line 156:
>
> double dmg;
> if ( config.explosion_range != 0)
> dmg = cos(M_PI_2 * distance / config.explosion_
Kurosu a écrit :
> However, this ends in a systematic deadlock under Windows. As simply
> removing the Disconnect() from ThreadRun, thus allowing the thread to
> immediately end, solves this deadlock, I'm wondering if it is really
> needed. If yes, considering this is the likely source of proble
> 3. Character placement fails because the client is always placing the
> character in the ground. The only reasons I can see for this happening
> is if either the random values are messed up or if what is considered
> ground is messed up. When debugging this, it shows that it is trying
> posi
Matthieu Fertré wrote:
>> 3. Character placement fails because the client is always placing the
>> character in the ground. The only reasons I can see for this happening
>> is if either the random values are messed up or if what is considered
>> ground is messed up. When debugging this, it shows
