Real time combat?

[FER]

you know, no hit/miss chance.

 

[Caluminium]

How about 0.25-0.5 of the normal damage done instead of a miss

 

[zeus9860]

Well you obviously can't hit everything all the time. Should have said something like "Stronger hit vs weak hit" as in stronger if the hit was successfully connected, if not then it would cause minor damage to a target (scratches and the likes), hence the reason why it's weak... Then there's also stamina coming into play, if you ever plan on changing gameplay that is...

 

[Orochi]

You'd need a far less laggy system than the one MS:C currently has, and one with far less buggy hit detection. Also, given that nearly all high-end enemies hit 99.9% of the time anyway, this would really only help players.

 

[Wishbone]

You'd need a far less laggy system than the one MS:C currently has, and one with far less buggy hit detection. Also, given that nearly all high-end enemies hit 99.9% of the time anyway, this would really only help players.

Welcome back! Anyways,, Orochi is right the monsters hit 99% of the time, so the hit ratio on the NPCs is unrealistic has it is. Though maybe instead of doing this, we could lower the hit ratio that monsters have instead of redoing the combat system.

 

[Thothie]

With the exception of AOE attacks and projectiles, SFAIK, we have no monster who hits more than 90% of the time. Unlike the players, they are kinda capped there.

But yes, I would very much like to eliminate the miss chance and have a more skill reliant game.

...Alas, it'd mean re-balancing entire weapon lines, several of which are completely dependant on miss chances to retain their uniqueness.

Wanted to rig up a system where you could parry attacks and stun with perfect blocks, but it'd mean editing every monster model to que when their attacks began, and then tracking that client side, so that it wouldn't be lag dependant. Dodging blows with side leaps by double tapping strafe keys, and that sort of thing, would be nice too, but it'd require new player anims and some coding tweaks.

One of the things I've been looking into doing this patch, is getting a functional dual-wield system in order, and switching the weapon charge system up so it just charges whenever you hold the button (no double click), and a partly charged attack has its damaged partly raised (on those weapons where the secondary attack is the 2x dmg), if there's enough stamina available (thus making stamina meaningful). Also was going to look into adding a secondary kick ability with cool down.

In short... I'm all for fundamental game play changes (within reason), it's just some are trickier to implement than others.

 

[Wishbone]

With the exception of AOE attacks and projectiles, SFAIK, we have no monster who hits more than 90% of the time. Unlike the players, they are kinda capped there.

But yes, I would very much like to eliminate the miss chance and have a more skill reliant game.

...Alas, it'd mean re-balancing entire weapon lines, several of which are completely dependant on miss chances to retain their uniqueness.

Wanted to rig up a system where you could parry attacks and stun with perfect blocks, but it'd mean editing every monster model to que when their attacks began, and then tracking that client side, so that it wouldn't be lag dependant. Dodging blows with side leaps by double tapping strafe keys, and that sort of thing, would be nice too, but it'd require new player anims and some coding tweaks.

One of the things I've been looking into doing this patch, is getting a functional dual-wield system in order, and switching the weapon charge system up so it just charges whenever you hold the button (no double click), and a partly charged attack has its damaged partly raised (on those weapons where the secondary attack is the 2x dmg), if there's enough stamina available (thus making stamina meaningful). Also was going to look into adding a secondary kick ability with cool down.

In short... I'm all for fundamental game play changes (within reason), it's just some are trickier to implement than others.

Well, when you and MiB get time then you guys should try doing the skill based thing, because some of the weapons could use updating/re-balancing... Anyways, the deal wield system would be awesome to have, so good luck on to you and MiB on that.

 

[Drathamus]

Would you be able to use the "launch" animation from Half-Life used by the jump pack, for dodging?

Could be scaled down a tad, as the distance wouldn't be that far... just an idear :X

 

[FER]

Didnt you said it making weapons use charges with stamina wouldnt be way to extensive to actually try to implement it?

I was thinking of using normal attacks with the stamina bar, with each blow draining all the current amount. different weapons would have different stamina reffiling rates.

 

[Thothie]

Well, the weapon charges can have their stamina drain set independently, but they don't current *require* stamina to operate. It's true, if we made stamina mean something, we'd have to rebalance all the stamina drain on all the attacks, as right now they are set fairly arbitrarily, for the most part. Might be worth the effort. Gotta see if I can follow MiB's tips and tweak out the charge system to allow you to do it without double clicking first though.

Downside to this is that you'd no longer be able to hold a button to attack. Also, it'd likely put an end to a certain all-to-common exploit, that I fear many players have come to rely on.

Would you be able to use the "launch" animation from Half-Life used by the jump pack, for dodging?

Could be scaled down a tad, as the distance wouldn't be that far... just an idear :X

Gordon's and the MSC player anims are about as far apart as can be at this point... TBH, I could probably make the animation myself - though it'd suck, as while I've picked up the animation skill, the results are really sub-par. Then there's the matter of figuring the double-click strafe thing. It'll be a requirement to get the dwarves going though, as the tumble ability was to be a big thing with them.

 

[Orochi]

back when I made the kick animation, all I did was take it from the old MS 1.35 player model. This is relevant, because there also exists a dodge animation on the old player model. I could easily port it the same way.

 

[Srgnt Rehab]

We could make missing be something unique to specific weapons as a trade off for greater damage still, right? Daggers and fists and all the other baby weapons could be easily balanced that way, but Axes could be unique as the dice rolling weapon of massive damage or a full miss.

 

[FER]

Why not just compensate with slow attack speed?

 

[Thothie]

there also exists a dodge animation on the old player model.

Not on any copy of it I have... Although we changed the bone order at some point, which may also screw with porting over any such animation.

Why not just compensate with slow attack speed?

That'd probably be the way to go, although it'd mean tweaking the viewmodel... Then again, I think I managed to make the attack animation speeds adjustable when I added the Swift Blade potions.

 

[Orochi]

Thothie, we're talking the old old MS 1.35 player model.

 

[Thothie]

Thothie, we're talking the old old MS 1.35 player model.

I have those... I've player models going back to pre-Steam MS. :\ Even a few that were never released. :/

 

[Red Cell]

Even a few that were never released. :/

Show them plox.

 

[Thothie]

They... Don't look much different from the current one, except for having less anims, and having split seams...

Indeed, you can see the one just prior to release, with MSC anims added, in the current install, under: msc/models/human/male1/male1.mdl

There is an animation called "dodge" in a few of the old archives but the animation...

...doesn't really live up to its name.

Most of the models in the developer archives look like some step between that one and the current one (fixed seams being post con-artist, I suppose)... A lot have the duck animation at sequence #0 for some reason... Some have the arms, legs, and head as separate models, but they still look the same (aside from the MS 1.3 bare arms, of course)... One odd exception to the rule is this model, however:

For which there were only SMD's, so I had to hack up a QC to display... Not sure if it was actually intended for MSC - there's a lot of loose scrap stuff in the various dev archives.

Also a lotta crap like this...

That I just thank the gods Little-G never got his hands on.
(*shudders at the thought of elaborate inflatable loin-cloth goblin mythos*)

PS. Few other things I got reminded of, while I dug into the dev archives:
- We do indeed have a source for Keledrosprelude2. :\ (Granted, we've made so many ripent fixes that, at this point, it'd be hard to update it to work straight).
- We have a source for Keledrosruins... (Actually, think I knew this, it just slipped my mind...)
- We also have an archive of the original "ms-mp3.zip" Lanethan music set that we lost recently - but I suspect it's actually less exhaustive than the set we replaced it with.

 

[Tigerkev]

Is it just me or does the model look more high-res than the one ingame?
That goblin model freaks the hell outta me :/

Also, wouldn't it possible to remove the head from the model and put it as 'extra', to be able to add additional hair or stuff like that? I don't think it'd be to much work to align the extra model to the player model, given all the additional head models are on the same origin.

 

[Thothie]

Is it just me or does the model look more high-res than the one ingame?

Nope... Both 954 poly... May just be that I'm one of those few dinosaurs who still uses anti-aliasing (though the video and gif compression should kill most of that effect).

Putting more heads and such on the player model would be possible, if not for the damn submodel scramble bug (hell, if not for that, all the armor would be integrated into that model too.) Seems Half-Life starts flipping out when submodel systems get too complicated, and ends up randomly swapping combinations of submodels. Not absolutely sure if it's the engine or the code though.

 

[The Man In Black]

Maybe I'll have you (or someone) pull data on that for me. Kinda curious. Seeings as how it's just a complicated list, wondering if I can write a better equation for finding the submodel set. Of course, if it really is the engine, it won't help anything >_>

 

[FER]

Can we atleast put those goblin textures on the current goblin model?

 

[Thothie]

Maybe I'll have you (or someone) pull data on that for me. Kinda curious. Seeings as how it's just a complicated list, wondering if I can write a better equation for finding the submodel set. Of course, if it really is the engine, it won't help anything >_>

IIRC you found where the formula was, once upon a time... Seemed horribly complicated, for what it does.

edit: think this is it:

void SetBodygroup( void *pmodel, entvars_t *pev, int iGroup, int iValue )
{
	studiohdr_t *pstudiohdr;
	
	pstudiohdr = (studiohdr_t *)pmodel;
	if (! pstudiohdr)
		return;

	if (iGroup > pstudiohdr->numbodyparts)
		return;

	mstudiobodyparts_t *pbodypart = (mstudiobodyparts_t *)((byte *)pstudiohdr + pstudiohdr->bodypartindex) + iGroup;

	if (iValue >= pbodypart->nummodels)
		return;

	int iCurrent = (pev->body / pbodypart->base) % pbodypart->nummodels;

	pev->body = (pev->body - (iCurrent * pbodypart->base) + (iValue * pbodypart->base));
}

Can we atleast put those goblin textures on the current goblin model?

 

[Orochi]

That code....looks remarkably similar to the submodel code in Source, right down to the "studiohdr" naming convention.

 

[The Man In Black]

Oh, I know the code. Datas I would need to rewrite would be the contents of submodel arrays, essentially.

And, yes, Orochi, it's almost like they were programmed by the same dev team or something >_>