r1ch.net forums
* Home Help Search Login Register
r1ch.net  |  General  |  General Discussion  |  Topic: Trying to fix the Siamese Twins problem...
Pages: [1] 2 3  All
Print
Author Topic: Trying to fix the Siamese Twins problem...  (Read 37385 times)
hajas
Member

Posts: 44



« on: June 04, 2007, 11:43:15 am »

WTH is Siamese Twins problem?

in RA2 sometimes we have 2 or more players been spawned at the same spawnpoint, then they start glued and can't move!

. this only happens in some maps
. all default maps are FREE of this bug
. yes, we have more spawnpoints than players

seams that I found the cause of the siamese twins problem with help of a mapper friend.

the only difference in the maps that happens this problem to the maps that didn't are the spawnpoints in the buggy maps are a little below the floor, seams created to hide the spawnpoint mark on the floor.

we made thousands of tests, and created a map from zero to test this....

we made a small map with only 4 spawnpoints... and playing with 6 players.

1st try:

spawnpoints in default way, appears a mark, like a step on the floor (like q2dm1)

NEVER happen the problem, everything is 100% right! even with more players than spawnpoints.

2nd try:

we put the spawn a little below the floor, but the mark still appearing on the floor aside in the same level.

sometimes the players born glued, but jumping and with hook we can go away from each other.

3rd try:

we put the spawn a little more on the floor, so don't appear any spawn mark on the floor.

then we got the siamese twins problem... 

Maps That have this bug

Almost the most beautiful ones... here few classics: tltf, tltf2, marics33 & marics37

Solution:

I think if I can spawn the players a little above the point they are marked to spawn, will fix this problem in all the maps... what do you think?

My Try

well, I tryed... but nothing really changed... here the code that I changed (BOLD lines) in p_client.c

Quote
/*
===========
PutClientInServer

Called when a player connects to a server or respawns in
a deathmatch.
============
*/
void PutClientInServer (edict_t *ent)
{
vec3_t mins = {-16, -16, -24};
vec3_t maxs = {16, 16, 32}; <--------------------------------------------------------- Is this the max values of XYZ???
int index;
vec3_t spawn_origin, spawn_angles;
gclient_t *client;
int i;
client_persistant_t saved;
client_respawn_t resp;

// find a spawn point
// do it before setting health back up, so farthest
// ranging doesn't count this client
SelectSpawnPoint (ent, spawn_origin, spawn_angles);

index = ent-g_edicts-1;
client = ent->client;

// deathmatch wipes most client data every spawn
if (deathmatch->value)
{
char userinfo[MAX_INFO_STRING];

resp = client->resp;
memcpy (userinfo, client->pers.userinfo, sizeof(userinfo));
InitClientPersistant (client);
ClientUserinfoChanged (ent, userinfo);
}
else if (coop->value)
{
// int n;
char userinfo[MAX_INFO_STRING];

resp = client->resp;
memcpy (userinfo, client->pers.userinfo, sizeof(userinfo));
// this is kind of ugly, but it's how we want to handle keys in coop
// for (n = 0; n < game.num_items; n++)
// {
// if (itemlist[n].flags & IT_KEY)
// resp.coop_respawn.inventory[n] = client->pers.inventory[n];
// }
resp.coop_respawn.game_helpchanged = client->pers.game_helpchanged;
resp.coop_respawn.helpchanged = client->pers.helpchanged;
client->pers = resp.coop_respawn;
ClientUserinfoChanged (ent, userinfo);
if (resp.score > client->pers.score)
client->pers.score = resp.score;
}
else
{
memset (&resp, 0, sizeof(resp));
}

// clear everything but the persistant data
saved = client->pers;
memset (client, 0, sizeof(*client));
client->pers = saved;
if (client->pers.health <= 0)
InitClientPersistant(client);
client->resp = resp;

// copy some data from the client to the entity
FetchClientEntData (ent);

// clear entity values
ent->groundentity = NULL;
ent->client = &game.clients[index];
ent->takedamage = DAMAGE_AIM;
ent->movetype = MOVETYPE_WALK;
ent->viewheight = 22;
ent->inuse = true;
ent->classname = "player";
ent->mass = 200;
ent->solid = SOLID_BBOX;
ent->deadflag = DEAD_NO;
ent->air_finished = level.time + 12;
ent->clipmask = MASK_PLAYERSOLID;
ent->model = "players/male/tris.md2";
ent->pain = player_pain;
ent->die = player_die;
ent->waterlevel = 0;
ent->watertype = 0;
ent->flags &= ~FL_NO_KNOCKBACK;
ent->svflags &= ~SVF_DEADMONSTER;

VectorCopy (mins, ent->mins);
VectorCopy (maxs, ent->maxs);
VectorClear (ent->velocity);

// clear playerstate values
memset (&ent->client->ps, 0, sizeof(client->ps));

client->ps.pmove.origin[0] = spawn_origin[0]*8;
client->ps.pmove.origin[1] = spawn_origin[1]*8;
client->ps.pmove.origin[2] = spawn_origin[2]*8; <--------------------------------------------------------- I tryed (spawn_origin[2]+15)*8

if (deathmatch->value && ((int)dmflags->value & DF_FIXED_FOV))
{
client->ps.fov = 90;
}
else
{
client->ps.fov = atoi(Info_ValueForKey(client->pers.userinfo, "fov"));
if (client->ps.fov < 1)
client->ps.fov = 90;
else if (client->ps.fov > 160)
client->ps.fov = 160;
}

client->ps.gunindex = gi.modelindex(client->pers.weapon->view_model);

// clear entity state values
ent->s.effects = 0;
ent->s.modelindex = 255; // will use the skin specified model
ent->s.modelindex2 = 255; // custom gun model
// sknum is player num and weapon number
// weapon number will be added in changeweapon
ent->s.skinnum = ent - g_edicts - 1;

ent->s.frame = 0;
VectorCopy (spawn_origin, ent->s.origin);
ent->s.origin[2] += 1; // make sure off ground <--------------------------------------------------------- tryed change 1 for 5, 15, 20, 200, 2000...
VectorCopy (ent->s.origin, ent->s.old_origin);

// set the delta angle
for (i=0 ; i<3 ; i++)
{
client->ps.pmove.delta_angles = ANGLE2SHORT(spawn_angles - client->resp.cmd_angles);
}

ent->s.angles[PITCH] = 0;
ent->s.angles[YAW] = spawn_angles[YAW];
ent->s.angles[ROLL] = 0;
VectorCopy (ent->s.angles, client->ps.viewangles);
VectorCopy (ent->s.angles, client->v_angle);

// spawn a spectator
if (client->pers.spectator) {
client->chase_target = NULL;

client->resp.spectator = true;

ent->movetype = MOVETYPE_NOCLIP;
ent->solid = SOLID_NOT;
ent->svflags |= SVF_NOCLIENT;
ent->client->ps.gunindex = 0;
gi.linkentity (ent);
return;
} else
client->resp.spectator = false;

if (!KillBox (ent))
{ // could't spawn in?
}

gi.linkentity (ent);

// force the current weapon up
client->newweapon = client->pers.weapon;
ChangeWeapon (ent);
}



well, all my tries seams ignored.... am I in the wrong place?Huh

or worst, the only way to fix is via the MOD source?

thanks again!
Logged
QwazyWabbit
Member

Posts: 402


« Reply #1 on: June 05, 2007, 08:16:37 am »

The pads are 8 units tall. If they are buried they might be 1 or more units below the ground. Players are held in place briefly upon spawn and it may be a race condition between spawn events when having more players than pads. I don't know why it would happen more often if the pads are buried.

Seems to me ent->s.origin[2] += 9; should do it.

This is a really old problem and it would be nice to finally see it fixed.
Logged
hajas
Member

Posts: 44



« Reply #2 on: June 05, 2007, 11:25:58 am »

I made it! but was only tested in DM... I'll need to work more on it... the problem was at this line:

Quote
vec3_t maxs = {16, 16, 32};

I was thinking was that (like I asked in every forum but no one seams to know that) but I'm was afraid to change and make the game abort or something....

well, to hell with fear! I'll change to see! then I changed to a a very high value!

Quote
vec3_t maxs = {16, 16, 1000};

then changed the line

Quote
ent->s.origin[2] += 1; // make sure off ground

to

Quote
ent->s.origin[2] += 900; // make sure off ground


then, I was be spawned really higher! in some maps out of the map! hehehe Cheesy
or inside the wall that was above the spawn, etc...

well, the importand that I found the point that do that.... Cheesy

after many tests I found this values:

Quote
vec3_t maxs = {16, 16, 50};
ent->s.origin[2] += 30;

and is working PERFECT in DM! Cheesy

soon as I have a free time, I'll try with RA2!!! Tongue

I'm only afraid that RA2 have his own spawn code, not only find a spot and spawn the player...
and since I don't have their source, I'll be lost! Sad

let's pray! Cheesy

well, r1ch... you have here the answer to fix this bug in DM/TDM... and probally CTF too...  wink
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #3 on: June 05, 2007, 11:46:23 am »

Uh, if you change the mins or maxs, you do realize you are changing the players bounding box? You probably don't want to do that.
Logged
hajas
Member

Posts: 44



« Reply #4 on: June 05, 2007, 11:48:36 am »

yes! was why I was afraid to do... but if you didn't, you can't spawn them little above...got it?
Logged
hajas
Member

Posts: 44



« Reply #5 on: June 05, 2007, 11:50:22 am »

that's why my first try was ignored! Cheesy
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #6 on: June 05, 2007, 12:05:08 pm »

The origin is the only thing that alters the players position, adjusting mins or maxs simply changes their size.
Logged
hajas
Member

Posts: 44



« Reply #7 on: June 05, 2007, 12:47:22 pm »

well, I think I'm with the same size... and spawning a little higher...  wink

if I don't change this value, I can't be spawned above, because I'll pass through the box, so is ignored...
then I turn the box a little bigger in the Z, then works.

if what you are saying was right, so when I add 1000 to the size, should I become a japanese monster? but this not what happened.

when I was testing I found the size to born before the box size... I was with 1000/30 values... and was spawning right...
I only turn the value down to avoid some other problems in game... which I didn't tested enough like I sad above.

if with my final values I only become a little higher, I'll not see me falling when spawned... right?

well, I really don't have 100% sure that I got the same size with 50 on the box, but with 1000 I'm sure that had the same size of 50...
I think nothing was changed about the size of player... well, I'll test more anyway...  cheesy

so why not try for yourself? and you'll see if that really works and if your size will be the SAME! Cheesy

take a shot!  grin
Logged
hajas
Member

Posts: 44



« Reply #8 on: June 05, 2007, 01:06:23 pm »

hmmm... I did a fast test here at work... and we both are 50% right and 50% wrong...   huh

so we only need to change this line to fix the spawn problem in DM/TDM/CTF:

Quote
ent->s.origin[2] += 30;

so you don't need to change this one:

Quote
vec3_t maxs = {16, 16, 32};

but that one don't make difference in your size, is just about your box what I see...

well, I was testing with RA2 at home, and was not working... then I tested here and changed this values and start to work, than I thought was that but I'm wrong...

so my deepest fear become true...  cry angry

seams is ignored because RA2 have his own spawn...  shocked

so I gonna jump into the lava...  grin
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #9 on: June 05, 2007, 03:11:45 pm »

Unless you have the RA2 mod source you can't fix this in RA2.

If you only need to increase the origin, it's possible to edit the RA2 binary directly assuming the code still exists to lift the players origin. This will then cause problems for maps that have properly positioned teleporters with low ceilings. The bug isn't really with RA2, it's with the maps that try and hide teleporters. You can probably fix the maps using R1Q2 .override support.
Logged
hajas
Member

Posts: 44



« Reply #10 on: June 05, 2007, 04:15:39 pm »

Quote
If you only need to increase the origin, it's possible to edit the RA2 binary directly assuming the code still exists to lift the players origin. This will then cause problems for maps that have properly positioned teleporters with low ceilings.

I tested with this value until below very low ceilings, and works great... probally a less number like 15 or even 10 will be already enough to fix this problem.... about edit the binary you mean with a hex editor? or how?

Quote
The bug isn't really with RA2, it's with the maps that try and hide teleporters.

sure! I know that! I only want to try to fix that without fix map by map... Sad

Quote
You can probably fix the maps using R1Q2 .override support.

hmmm... tell more about it?  rolleyes
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #11 on: June 05, 2007, 07:02:04 pm »

Yes, you can use a hex editor / disassembler to find the appropriate place to change in the binary. If you post the .so or .dll you are using, I can point it out.

See here for more information on .override files: http://www.r1ch.net/forum/index.php?topic=1072.0
Logged
hajas
Member

Posts: 44



« Reply #12 on: June 05, 2007, 07:18:01 pm »

I found about the override....

Quote
Server-side entity replacement and map overriding support. Using this you can create "virtual" maps that exist only as a .override file on the server, but load up an existing map with a modified entity string. Example: q2dm1.bsp is your normal q2dm1. To add some excitement, you want to put a quad in the map, but don't want clients to have to download a whole new .bsp. So you edit the entity string for q2dm1 to include a quad, then generate a .override file specifying "maps/q2dm1.bsp" as the map to load with the new entity string. Then you save the .override file as 'maps/q2dm1-quad.bsp.override' and you can use 'q2dm1-quad' as if it were a valid map, eg in map rotations, 'gamemap q2dm1-quad', etc. Upon loading it, the server will change the real map back to q2dm1 and use the modified entity string specified in the .override file.

The .override file format is a proprietary R1Q2 binary format including a bitfield specifying what is present. This allows it to be extended at a later date without breaking compatibility. I've created a PHP script to generate a .override file since explaining the format here would take too long. Generate the .override file at http://r-1.ch/r1q2gen.php. If you don't know how to get an entity string from a .bsp, try entdump: http://r-1.ch/entdump.c (Win32 binary: http://r-1.ch/entdump.exe, runs from cmd prompt, eg entdump q2dm1.bsp > q2dm1.txt). Note that the server will very likely crash if you use a bad .override file so be careful! Please don't ask me about this feature if you aren't sure how to use it, it's pretty complicated and amazingly hacky but it does work. I think.

sounds very cleaver m8...

I generated this with our small test map....

Quote
{
"classname" "worldspawn"
}
{
"origin" "-256 248 16"
"classname" "info_player_deathmatch"
}
{
"classname" "info_player_deathmatch"
"origin" "248 256 16"
}
{
"origin" "248 -256 16"
"classname" "info_player_deathmatch"
}
{
"classname" "info_player_deathmatch"
"origin" "-264 -256 16"
}
{
"origin" "-176 -200 24"
"classname" "weapon_rocketlauncher"
}
{
"classname" "weapon_rocketlauncher"
"origin" "-184 192 24"
}
{
"origin" "168 184 24"
"classname" "weapon_rocketlauncher"
}
{
"origin" "-184 -264 24"
"classname" "ammo_rockets"
}
{
"classname" "ammo_rockets"
"origin" "192 -256 24"
}
{
"origin" "184 128 24"
"classname" "ammo_rockets"
}
{
"classname" "ammo_rockets"
"origin" "-184 128 24"
}
{
"origin" "216 -192 24"
"classname" "weapon_rocketlauncher"
}
{
"light" "400"
"origin" "-8 0 208"
"classname" "light"
}

so is just put this code on the override file generator on your site at http://r-1.ch/r1q2gen.php

then change the Z from the spawns then generate a override file.

then when people connect will spawn a little above? sounds good... the biggest problem is that I'll need to add this feature in our Q2E Sever...

and you remember, r1q2 not worked well with Q2E... unfortunately... Sad
« Last Edit: June 05, 2007, 07:20:45 pm by hajas » Logged
hajas
Member

Posts: 44



« Reply #13 on: June 05, 2007, 07:22:31 pm »

Quote
Yes, you can use a hex editor / disassembler to find the appropriate place to change in the binary. If you post the .so or .dll you are using, I can point it out.

wow! thanks m8! are the RA2 files...

well, I'll zip them and host at my site, 1 min!  wink
Logged
hajas
Member

Posts: 44



« Reply #14 on: June 05, 2007, 07:27:21 pm »

here all the files, server/client inclued

http://q2a.hajas.org/files/arena.zip

which program do you use for that?

thanks again!
Logged
Pages: [1] 2 3  All
Print
r1ch.net  |  General  |  General Discussion  |  Topic: Trying to fix the Siamese Twins problem...
Jump to:  

Powered by SMF 1.1.19 | SMF © 2013, Simple Machines