A new bow with arrows?
- Thread starter miko2386
- Start date
- Admin
- #2
There's some models set aside, but the other weapon lines still need some time to catch up. Meanwhile, there's plenty of powerful bows 25-35 that use bolts and other projectiles.
- Thread starter
- #3
it would be glad if there is a 30+ bow using arrows
seems nowadays only tork bows are the bows that do good damage to hostiles
i think the arrows can be remade after a new high-end bows with arrows comes out
the arrows may do pierces damage + elemental damage from different arrows + elemental dots
for example, fire arrows to pierces damage like jagged arrows do and having fire damage + dots so that it could do good damage to single hostile
seems nowadays only tork bows are the bows that do good damage to hostiles
i think the arrows can be remade after a new high-end bows with arrows comes out
the arrows may do pierces damage + elemental damage from different arrows + elemental dots
for example, fire arrows to pierces damage like jagged arrows do and having fire damage + dots so that it could do good damage to single hostile
- Joined
- Sep 6, 2009
- Messages
- 1,213
- Reaction score
- 42
- Age
- 35
The vast, vast majority of bows in all level tiers should use arrows. That is, if we want archery to be interesting at all.
New arrows would also be awesome to have.
New arrows would also be awesome to have.
TheOysterHippopotami said:
Actually i disagree, patterns for certains bows could be more magic related than arrow projectile based. But i do think we need more bows like the frostbow in-game soon, bows with knockback would be a nice addition, because you know... we have to endure alot of knockback spam in this game, it's only reasonable to give the same ability to the player and laugh at their faces like "LOL YOU CAN'T TOUCH THIS" :roll:
I've suggested alot of stuff... top 4 ones i can think off and were beast (imo), silver winged bow (suggested by gorynich if i'm not mistaking) then i suggested silver arrows that would work best on demons/unholy and hit anything else equally. Holy bow, some reskin Avacado made except i think my suggestion for the item was better than his (osnap!), the magical crossbow, that shoots mana bolts and has the ability to shoot charged shots for more mana & damage (no reload, mana consume instead, kind fast-paced shooting, but not as fast as steam xbow) and for last, the heavy modified crossbow (dont think i got to post this one but i discussed in steam chat a couple of times with random people)... which works like a shotgun/cannon (lots of pain at close/medium range, slow ass reload time to make it a strategical hit and run device, aim carefully, shoot, retreat!, reload, repeat process, ???, profit)
- Admin
- #8
Actually, that kinda goes with something I keep meaning to look into that Lord K himself kinda suggested ages and ages ago... Namely, client side arrows.
The idea would be to switch up the arrow projectile with a client side effect - which, in itself, wouldn't help much but to make the arrows travel more smoothly... If, on the other hand, I could get said arrows to return the index of any model they struck, and convert that index into an entity ID, we could make the hit prediction entirely client side as well, and then the arrow hits would be dependable regardless of lag. In other words, as long as it looked like it hit on your client, it'd count.
Re-enabling the system for detecting headshots would be another mystery entirely though, and involve a lot of model editing.
The idea would be to switch up the arrow projectile with a client side effect - which, in itself, wouldn't help much but to make the arrows travel more smoothly... If, on the other hand, I could get said arrows to return the index of any model they struck, and convert that index into an entity ID, we could make the hit prediction entirely client side as well, and then the arrow hits would be dependable regardless of lag. In other words, as long as it looked like it hit on your client, it'd count.
Re-enabling the system for detecting headshots would be another mystery entirely though, and involve a lot of model editing.
If you are pulling that one out, do the same with spells. Playing on my own server vs 100+ ping servers really makes alot of difference, there were things i never noticed untill i actually tried them on lan, like projectiles making certain effects when shot (trail effect for example, you can't see this at all on FN), same goes with the raven mace speed effect, it's meant to make some sort of effect, that never shows up on FN, all more than likely to be caused to high ping issues.
- Admin
- #10
Actually, that's part of the core plan behind the new spell system...
...Although, part of the problem, is with spells, it's not so difficult, as long as they have some AOE. I can, for instance, tell where a client side projectile landed, pass that info back to the server, and then tell the server to scan the area around that point... But, for an arrow, that has to hit something directly, that's a bit trickier. The client only has a set of model indexes, it doesn't have the entity ID's that those indexes are tied to - and to affect an entity on the server, the server needs that info. So, the sticking point is, I don't have, at the moment, a way to convert a model index back into a server side ID.
...Not sure if any of that made any sense though... >_>
Eh, to put it another way, the client doesn't have nearly as much info as the server does. It only knows where models are, and what model they are - it doesn't know, for instance, that's a monster, its race, or hitpoints, etc. That sort of thing has to be processed server side. The client just indexes these models with numbers, say a skeleton might be model #24, while the server looks at them as fully function entities, with special long-string ID's (eg. $pent[1,35892]), to reference all their associated properties. So, I'd need to figure a way to sort through the model indexes (the only info the client can give us), to find the associated entity on the server.
I'm also a little uncertain if the current collision functions are setup to return the index of the model the client side projectile collided with... It may just know it got stopped and where, but not by what - beyond "the collision hull".
...Although, part of the problem, is with spells, it's not so difficult, as long as they have some AOE. I can, for instance, tell where a client side projectile landed, pass that info back to the server, and then tell the server to scan the area around that point... But, for an arrow, that has to hit something directly, that's a bit trickier. The client only has a set of model indexes, it doesn't have the entity ID's that those indexes are tied to - and to affect an entity on the server, the server needs that info. So, the sticking point is, I don't have, at the moment, a way to convert a model index back into a server side ID.
...Not sure if any of that made any sense though... >_>
Eh, to put it another way, the client doesn't have nearly as much info as the server does. It only knows where models are, and what model they are - it doesn't know, for instance, that's a monster, its race, or hitpoints, etc. That sort of thing has to be processed server side. The client just indexes these models with numbers, say a skeleton might be model #24, while the server looks at them as fully function entities, with special long-string ID's (eg. $pent[1,35892]), to reference all their associated properties. So, I'd need to figure a way to sort through the model indexes (the only info the client can give us), to find the associated entity on the server.
I'm also a little uncertain if the current collision functions are setup to return the index of the model the client side projectile collided with... It may just know it got stopped and where, but not by what - beyond "the collision hull".
ceriux
Adventurer
i know this is a different language. but im sure it would work similarly since the language is based on C and the engine is built from the same engine that uses this code.
but basically you make a shared entity. you only update the position and attack information server side, then client side you do all your movement,drawing,hit detection.
maybe the link can be somewhat useful. http://qexpo.tastyspleen.net/booth.php?id=165&page=317
but basically you make a shared entity. you only update the position and attack information server side, then client side you do all your movement,drawing,hit detection.
maybe the link can be somewhat useful. http://qexpo.tastyspleen.net/booth.php?id=165&page=317
- Admin
- #12
I've not read it too thoroughly yet, but I only see the client side of the rocket there, and the write message that starts it. I think it reports back where an explosion is to take place. That we can all do (and have - that's how the volcano works now)... The sticky bit is how to get the client to tell the server what it hit, when it has to hit a specific model, since the client doesn't use the same reference system.
Server tell client: "You spawn arrow, make go this way."
Client tell server: "It hit model #63!"
Server go cross-eyed and think to self: "WTF is model #63!?"
But as the origins between the two systems are consistent, if not the way they reference models, *maybe* I can just move the server end of the projectile (since, atm, there still is one) over to where the client says the arrow stopped and see if it touches anything. Simply scanning for the nearest target doesn't work, as such a scan may not work if the target is large, or may hit when it shouldn't have. Though it *might* be possible to simply scan the reported origin of the client model so struck.
One bugger up with our CURRENT arrows, I notice, is that they use the width/height defined collision box, rather than the model hitbox. The upside to this is that hitting mobs with projectiles should be fairly consistent, provided you aim for their bottom center... But the obvious downside is that, quite often, arrows will go through their heads with no effect, for their collision boxes rarely reach that high.
This, I was reminded of, when I recently played with the idea of this suggestion. I got the mobs and player to return the index of the last hitbox that was struck just fine... But while the player's hitboxes seem to work alright (indeed, it's sometimes used to determine which pain sound you'll make), the mob's hitbox always come up 0, as none of the MSC player to monster damage procedures rely on hitboxes.
Server tell client: "You spawn arrow, make go this way."
Client tell server: "It hit model #63!"
Server go cross-eyed and think to self: "WTF is model #63!?"
But as the origins between the two systems are consistent, if not the way they reference models, *maybe* I can just move the server end of the projectile (since, atm, there still is one) over to where the client says the arrow stopped and see if it touches anything. Simply scanning for the nearest target doesn't work, as such a scan may not work if the target is large, or may hit when it shouldn't have. Though it *might* be possible to simply scan the reported origin of the client model so struck.
One bugger up with our CURRENT arrows, I notice, is that they use the width/height defined collision box, rather than the model hitbox. The upside to this is that hitting mobs with projectiles should be fairly consistent, provided you aim for their bottom center... But the obvious downside is that, quite often, arrows will go through their heads with no effect, for their collision boxes rarely reach that high.
This, I was reminded of, when I recently played with the idea of this suggestion. I got the mobs and player to return the index of the last hitbox that was struck just fine... But while the player's hitboxes seem to work alright (indeed, it's sometimes used to determine which pain sound you'll make), the mob's hitbox always come up 0, as none of the MSC player to monster damage procedures rely on hitboxes.
ceriux
Adventurer
i cant honestly say how the detection works engine side esp. since quake models only have one individual hitbox, but this is a projectile touch snippit :
that tutorial i sent you only teaches you how to make a shared entity converting the majority of orginal ssqc to csqc. this isnt the rocket touch script, but the nail and the rocket are essentially the same type of entity till it hits.
edit: T_Damage :
also heres the entire quake source code (not the engine side code, just the ss game logic) hosted on the web, incase you wanted to look through the tutorial step by step to see whats done when making an ss entity communicate with a cs one.
oh! you also mentioned it returns an index value? each model has its own index number? does it change? if not why not just store the index value and if (model.index == x) {dostuff();};
Code:
.float hit_z;
void() spike_touch =
{
local float rand;
if (other == self.owner)
return;
if (other.solid == SOLID_TRIGGER)
return; // trigger field, do nothing
if (pointcontents(self.origin) == CONTENT_SKY)
{
remove(self);
return;
}
// hit something that bleeds
if (other.takedamage)
{
spawn_touchblood (9);
T_Damage (other, self, self.owner, 9);
}
else
{
WriteByte (MSG_BROADCAST, SVC_TEMPENTITY);
if (self.classname == "wizspike")
WriteByte (MSG_BROADCAST, TE_WIZSPIKE);
else if (self.classname == "knightspike")
WriteByte (MSG_BROADCAST, TE_KNIGHTSPIKE);
else
WriteByte (MSG_BROADCAST, TE_SPIKE);
WriteCoord (MSG_BROADCAST, self.origin_x);
WriteCoord (MSG_BROADCAST, self.origin_y);
WriteCoord (MSG_BROADCAST, self.origin_z);
}
remove(self);
};that tutorial i sent you only teaches you how to make a shared entity converting the majority of orginal ssqc to csqc. this isnt the rocket touch script, but the nail and the rocket are essentially the same type of entity till it hits.
edit: T_Damage :
Code:
/*
============
T_Damage
The damage is coming from inflictor, but get mad at attacker
This should be the only function that ever reduces health.
============
*/
void(entity targ, entity inflictor, entity attacker, float damage) T_Damage=
{
local vector dir;
local entity oldself;
local float save;
local float take;
if (!targ.takedamage)
return;
// used by buttons and triggers to set activator for target firing
damage_attacker = attacker;
// check for quad damage powerup on the attacker
if (attacker.super_damage_finished > time)
damage = damage * 4;
// save damage based on the target's armor level
save = ceil(targ.armortype*damage);
if (save >= targ.armorvalue)
{
save = targ.armorvalue;
targ.armortype = 0; // lost all armor
targ.items = targ.items - (targ.items & (IT_ARMOR1 | IT_ARMOR2 | IT_ARMOR3));
}
targ.armorvalue = targ.armorvalue - save;
take = ceil(damage-save);
// add to the damage total for clients, which will be sent as a single
// message at the end of the frame
// FIXME: remove after combining shotgun blasts?
if (targ.flags & FL_CLIENT)
{
targ.dmg_take = targ.dmg_take + take;
targ.dmg_save = targ.dmg_save + save;
targ.dmg_inflictor = inflictor;
}
// figure momentum add
if ( (inflictor != world) && (targ.movetype == MOVETYPE_WALK) )
{
dir = targ.origin - (inflictor.absmin + inflictor.absmax) * 0.5;
dir = normalize(dir);
targ.velocity = targ.velocity + dir*damage*8;
}
// check for godmode or invincibility
if (targ.flags & FL_GODMODE)
return;
if (targ.invincible_finished >= time)
{
if (self.invincible_sound < time)
{
sound (targ, CHAN_ITEM, "items/protect3.wav", 1, ATTN_NORM);
self.invincible_sound = time + 2;
}
return;
}
// team play damage avoidance
if ( (teamplay == 1) && (targ.team > 0)&&(targ.team == attacker.team) )
return;
// do the damage
targ.health = targ.health - take;
if (targ.health <= 0)
{
Killed (targ, attacker);
return;
}
// react to the damage
oldself = self;
self = targ;
if ( (self.flags & FL_MONSTER) && attacker != world)
{
// get mad unless of the same class (except for soldiers)
if (self != attacker && attacker != self.enemy)
{
if ( (self.classname != attacker.classname)
|| (self.classname == "monster_army" ) )
{
if (self.enemy.classname == "player")
self.oldenemy = self.enemy;
self.enemy = attacker;
FoundTarget ();
}
}
}
if (self.th_pain)
{
self.th_pain (attacker, take);
// nightmare mode monsters don't go into pain frames often
if (skill == 3)
self.pain_finished = time + 5;
}
self = oldself;
};also heres the entire quake source code (not the engine side code, just the ss game logic) hosted on the web, incase you wanted to look through the tutorial step by step to see whats done when making an ss entity communicate with a cs one.
oh! you also mentioned it returns an index value? each model has its own index number? does it change? if not why not just store the index value and if (model.index == x) {dostuff();};
- Admin
- #14
ceriux said:
That thar be server side code, so not helping much with this particular conversation. The MSC server side projectile isn't too different.
Code:
void CGenericItem::Projectile_CheckHit( void )
{
if ( ProjectileData->IgnoreNPC ) return;
TraceResult tr;
Vector vMoveDir = pev->angles;
vMoveDir.x = -vMoveDir.x;
UTIL_MakeVectors( vMoveDir );
Vector vecEnd = pev->origin + pev->velocity.Normalize() * 36;
int trflags = MSTRACE_SOLIDSHIELDS|MSTRACE_LARGEHITBOXES;
MSTraceLine( pev->origin, vecEnd, dont_ignore_monsters, edict(), tr, trflags ); if ( tr.flFraction < 1.0 )
{
CBaseEntity *pEntity = MSInstance(tr.pHit);
if( pEntity )
{
ProjectileTouch( pEntity );
}
}
}
Code:
void CGenericItem::ProjectileTouch( CBaseEntity *pOther )
{
//if ( ProjectileData->IgnoreNPC ) return;
startdbg;
TypeCheck;
if( pev->owner == pOther->edict()
|| pOther->MSMoveType == MOVETYPE_ARROW
|| !FBitSet( MSProperties(), ITEM_PROJECTILE ) )
return;
float dmgMultiplier = 1.0f;
//Thothie - trying to fix sounds of arrows always coming from 0x0x0
Vector old_location;
old_location = pev->origin;
Vector vForward;
if( pev->velocity.Length() ) vForward = pev->velocity;
else
{
UTIL_MakeVectorsPrivate( Vector(-pev->angles.x,pev->angles.y,pev->angles.z), pev->velocity, NULL, NULL );
pev->velocity *= ProjectileData->Speed;
}
if( (pOther->MyMonsterPointer() && !pOther->IsAlive()) )
return; //Hit a dead monster, keep going
damage_t Damage;
CBaseEntity *pDamageEnt = NULL;
CBaseEntity *pOwner = RetrieveEntity( ENT_EXPOWNER );
if( pOwner && !ProjectileData->IgnoreNPC )
{
if( pOwner->IsPlayer() )
{
CMSMonster *pMonsterOwner = (CMSMonster *)pOwner;
dmgMultiplier = pMonsterOwner->GetSkillStat( ProjectileData->StatPower, ProjectileData->PropPower ) / STATPROP_MAX_VALUE;
dmgMultiplier = max( dmgMultiplier, 0.001f );
}
clrmem( Damage );
Damage.pInflictor = this;
Damage.pAttacker = pOwner;
Damage.vecSrc = pev->origin;
Damage.vecEnd = pev->origin + vForward;
Damage.flRange = ProjectileData->flDamageAOERange;
Damage.flDamage = ProjectileData->Damage * dmgMultiplier;
Damage.iDamageType = DMG_NEVERGIB|DMG_NOSKIN;
Damage.flHitPercentage = 100.0f;
Damage.sDamageType = ProjectileData->sDamageType;
Damage.flAOERange = ProjectileData->flDamageAOERange;
Damage.flAOEAttn = ProjectileData->flDamageAOEAttn;
Damage.ExpUseProps = true;
Damage.ExpStat = ProjectileData->StatExp;
Damage.ExpProp = ProjectileData->PropExp;
hitent_list Hits;
DoDamage( Damage, Hits );
pDamageEnt = Hits.ClosestHit( );
}
if( pOther->IsMSMonster( ) && ProjectileData->CollideHitBox && !pDamageEnt )
{
//Just keep going if I hit a npc bounding box but not an actual hitbox
return;
}
pev->origin = old_location; //Thothie AUG2011_15 - move back to location so sound plays from right spot
CallScriptEvent( "game_projectile_landed" );
//if( pDamageEnt )
if ( !ProjectileData->IgnoreNPC ) pev->origin = Damage.outTraceResult.vecEndPos;
if( pDamageEnt &&
pDamageEnt->pev->takedamage && !ProjectileData->IgnoreWorld )
{
if( FBitSet( pDamageEnt->pev->flags, FL_GODMODE ) && !ProjectileData->IgnoreNPC ) //Monster has godmode
{
//Delay removal, so further arrow code doesn't crash
DelayedRemove( );
return;
}
dbg ("Params List");
static msstringlist Params;
dbg ("Clear List");
Params.clearitems();
dbg ("PDamageEnt");
Params.add( EntToString(pDamageEnt) );
dbg ("SendEvent");
pev->origin = old_location; //Thothie AUG2011_15 - move back to location so sound plays from right spot
CallScriptEvent( "game_projectile_hitnpc", &Params );
dbg ("IgnoreNPC");
if ( ProjectileData->IgnoreNPC ) return;
if ( ProjectileData->IgnoreNPC )
{
pev->owner = NULL;
}
else
{
pev->solid = SOLID_NOT;
//ExpireTime = ProjectileData->TimeStickTime;
MSMoveType = MOVETYPE_STUCKARROW;
}
}
else {
//No monster or monster I hit is dead or doesn't take damage
pev->owner = NULL;
pev->origin = old_location; //Thothie AUG2010_26 - move back to location so sound plays from right spot
CallScriptEvent( "game_projectile_hitwall" );
}
m_TimeExpire = gpGlobals->time + ExpireTime;
ClearBits( Properties, ITEM_PROJECTILE );
pev->movetype = MOVETYPE_NONE;
SetTouch( NULL );
enddbg;
}Granted, I've no idea how client side projectiles go about determining collisions either - they may be just as bad at head shots.
Yeah, I has not only the Quake SDK code, but the engine code as well... And have indeed been using to Quake 1 code to track down what Half-Life1 is doing, in places we can't normally look... Granted, this doesn't apply to all the new crap they added.cerix said:
ceriux
Adventurer
so it's not possible to keep hit detection over on server side code on half-life? also it's not possible use the index you get back as a flag?
also after class i could possible hop on irc and ask around if anyone knows anything about client side hit detection and half-life . the guys over at i3d mess with quite a few engines.
also after class i could possible hop on irc and ask around if anyone knows anything about client side hit detection and half-life . the guys over at i3d mess with quite a few engines.
- Admin
- #16
This hit detection, in this code, is server side. The client has its own collision detection for tempents.ceriux said:
Not sure if yer talking about the model indexes or the hit box indexes... Or how putting either into a flag would help... For the model indexes, the problem is I've no way to turn a client side model index into a server side ID. The client can determine whether he hit or not, but eventually, something's gotta happen server side, and the server needs to know who got hit. ...and for the hitboxes... The function seems to work fine, it's just these projectile trace lines aren't doing what they should be.ceriux said:
ceriux
Adventurer
ahh okay i was misunderstanding the problem. the mod knows that it hit someone but not who/what. so why are your projectiles based on traces? are you calling a traceline thats follows/is spawned front of the arrow until hit? i know in quake that would be pretty laggy, considering you would essentially be calling a new trace each time the arrow/projectile had moved.
does half-life have a touch function? if so wouldnt using that for arrows instead of a trace save us some from a bit of lag?
also i may have found someone with the actual source to half-life and still mods it to this day. now i just have to wait to see if he will become active on IRC and if he'd be willing to lend some knowledge.
does half-life have a touch function? if so wouldnt using that for arrows instead of a trace save us some from a bit of lag?
also i may have found someone with the actual source to half-life and still mods it to this day. now i just have to wait to see if he will become active on IRC and if he'd be willing to lend some knowledge.
ceriux
Adventurer
this is what he said
basically he says you still do everything server side, you just make the arrow invisible serverside and just do the arrow rendering clientside. no data should be transfered from client to server.
basically he says you still do everything server side, you just make the arrow invisible serverside and just do the arrow rendering clientside. no data should be transfered from client to server.
- Admin
- #19
Yeeeah... We've done that for some projectiles... The only real advantage is that the server doesn't update it every frame (which makes it look a bit smoother) - but the server still determines where it landed, not the client, so the two can get really out of sync with lag, and thus it doesn't help with aim. (Actually makes things a bit worse.)
If our arrows fired in quick straight lines, it'd be alright (and the xbows already do this), but as they fire in slow lazy arcs, while it'll look better, the end result will be the same. It does cut down on net traffic abit though, and this was Lord K's original idea.
Hope here is to have the client dictate where it landed and tell the server what it hit.
...and then there's this stupid hitbox problem.
If our arrows fired in quick straight lines, it'd be alright (and the xbows already do this), but as they fire in slow lazy arcs, while it'll look better, the end result will be the same. It does cut down on net traffic abit though, and this was Lord K's original idea.
Hope here is to have the client dictate where it landed and tell the server what it hit.
...and then there's this stupid hitbox problem.
ceriux
Adventurer
well you said the client side stuff works with aoe attacks with magic? why not just give the arrow a really small aoe affect? just make it small enough to where you wont be hitting close enemies. if you can make the arrows near complete cs. i bet it would be worth it.
- Admin
- #22
Like I alluded to earlier, the AOE would have to reach the center-bottom of the mob for it to be caught by the scan. This means for larger mobs (ice reavers, for instance), you could never hit them with arrows, as the arrows would be stopped before they got close enough to the mob's center. Providing a larger scan radius to compensate for that would result in hitting monsters you were no where near.
But, *if* I can get the client to return the location of the model it struck to the server, and scan just that point, then maybe we can do something.
Arrows fired by monsters would still have to use, at best, the Lord K ommit the model method, as it'd be screwy trying to figure which client to handle the arrow - and it'd look really off, if it was one of the laggier clients.
Also not sure what the client uses for model bounds... Obviously it's not the server's width/height definition, as they aren't part of the model data - but I dunno if it uses hit boxes, bounding boxes of some sort, or what. Will have to 'spariment and see.
But, *if* I can get the client to return the location of the model it struck to the server, and scan just that point, then maybe we can do something.
Arrows fired by monsters would still have to use, at best, the Lord K ommit the model method, as it'd be screwy trying to figure which client to handle the arrow - and it'd look really off, if it was one of the laggier clients.
Also not sure what the client uses for model bounds... Obviously it's not the server's width/height definition, as they aren't part of the model data - but I dunno if it uses hit boxes, bounding boxes of some sort, or what. Will have to 'spariment and see.
- Admin
- #23
Wow, well I impressed myself today... I kinda got this working.
Didn't involve too many code hacks to get the tempents to report what model they hit... And turns out there's a function, built into MSC, to convert client model indexes back into server ID's... So that helped a lot. Don't even have to do a hacky scan.
The script end got uglier though... So I'm a bit worried... It involves passing a lot of info to the client, and back again to the server. I not only have to pass all the projectile info (start origin, angle, velocity, gravity, model, submodel), but also the statistic info it'll need when the arrow hits (the skill it uses, the idx of the weapon that created it, the damage, and damage type - all of which needs to be passed back to the server on hit)... I had to condense some of the data sets into token strings just to squeeze it down to the nine parameter limit, and I'm a bit worried of what stuffing that much data down the pipe all at once may do...
I've been testing with the generic arrows, but think I need to pick out one arrow for testing for the next patch, and see what happens - and it probably shouldn't be that default fall back arrow.
But yeah, for players, it's an entirely client side arrow... The monster variant does the "mostly" client side bit as well.
Granted, an evil thing Dogg did, that I doubt I can undo, is make the projectile you fire, and the one you pick up, one in the same - the item script kinda "transforms" into a projectile when fired by a bow. So there's still some extra overhead I can't undo without fubar'ing the inventory system end of things.
The one major disappointment in this whole effort, however - this does NOTHING to fix the effing hit boxes! Near as I can tell, the server must alter the client data for models when it defines monster height/width, and thus, as far as the client is concerned, the damn things are still simple boxes that by no means match up with their models or animations. The hitboxes built into the model still seem to be ignored. :\
Didn't involve too many code hacks to get the tempents to report what model they hit... And turns out there's a function, built into MSC, to convert client model indexes back into server ID's... So that helped a lot. Don't even have to do a hacky scan.
The script end got uglier though... So I'm a bit worried... It involves passing a lot of info to the client, and back again to the server. I not only have to pass all the projectile info (start origin, angle, velocity, gravity, model, submodel), but also the statistic info it'll need when the arrow hits (the skill it uses, the idx of the weapon that created it, the damage, and damage type - all of which needs to be passed back to the server on hit)... I had to condense some of the data sets into token strings just to squeeze it down to the nine parameter limit, and I'm a bit worried of what stuffing that much data down the pipe all at once may do...
I've been testing with the generic arrows, but think I need to pick out one arrow for testing for the next patch, and see what happens - and it probably shouldn't be that default fall back arrow.
But yeah, for players, it's an entirely client side arrow... The monster variant does the "mostly" client side bit as well.
Granted, an evil thing Dogg did, that I doubt I can undo, is make the projectile you fire, and the one you pick up, one in the same - the item script kinda "transforms" into a projectile when fired by a bow. So there's still some extra overhead I can't undo without fubar'ing the inventory system end of things.
The one major disappointment in this whole effort, however - this does NOTHING to fix the effing hit boxes! Near as I can tell, the server must alter the client data for models when it defines monster height/width, and thus, as far as the client is concerned, the damn things are still simple boxes that by no means match up with their models or animations. The hitboxes built into the model still seem to be ignored. :\
ceriux
Adventurer
quake i think kind of does this with hull sizes. theres one for the player, the dog, and i think the shambler. maybe thats it? with quake all of thats coded both into the bsps and the engine.
- Admin
- #25
Yeah, but one of the improvements we got in Half-Life was the skeletal animation and hitbox system... Sadly, I think the way Dogg coded this up has undone it... It'll take me quite a bit of exploring to figure out if there's a way to get the classic Half-Life hit detection back. I know it's still there for the players though, so... But, player hit detection works quite a bit differently than when NPC's are the targets, so it maybe the only reason he didn't do the same thing to them is because it woulda been a lot more complicated. :\
Similar threads
