I am newbie. I am surprising how flexible is HL.
Can be posible a zeroping mod for HL?
A mod where hit/nothit is calculated clientside. All weapons instahit.
And, a unrelated question. Whats about to add QuakeC support clientside to write small
apps for
console in QC. This way people will make something powerfull than console scripts and
will
write full apps. And has QC is multiplataform, recompile will not be need (a MacOS/X
conprog.dat will
work for windowsXP ...)
Any proyect to add QuakeC support for Half-Life?
TIA.
--Tei
Example:
A small console app can provide smooth zooming, mod independant (will work for all
mods), easy to
recode to finne tunne. I think QC is the appropiate "scripting" lang for any Quake
based engine.
commands:
con_zoomon
con_zoomoff
con_zoomreset
cvars:
con_fovnormal "90"
con_fovmax "20"
con_fovforspeed "5%"
con_fovrewspeed "25%"
con_fovclicksound "snd/click.wav"
con_fovmovsound "snd/zuuum.wav"
( sensitivity also need to be handled, maybe with
Cvar_Setf ("sensitivity", (normalsens * (currentfov / (normalfov + 30)))); )
This is QC code, something similar what can be done (not use the cvars):
float timebomb /* = 0.000000 */;
float timehell /* = 0.000000 */;
float zoomode /* = 0.000000 */;
float normalfov /* = 0.000000 */;
float normalsens /* = 0.000000 */;
float targetfov /* = 0.000000 */;
float zoomtime /* = 0.000000 */;
void () con_debug =
{
bprint ("z: ", ftos (zoomode), "\n");
};
void () con_zoomon =
{
if ((zoomode == 0.000000))
{
normalfov = cvar ("fov");
normalsens = cvar ("sensitivity");
zoomode = 1;
zoomtime = (time + 0.1);
LocalSound ("zoom.wav", 1, 1);
return;
}
};
//TODO: recode this function, somethimes loss mode withouth normalfov set (Why?)
void () Run_Zoom =
{
local float currentfov;
if (!zoomode)
{
return;
}
if ((zoomtime > time))
{
return;
}
currentfov = cvar ("fov");
if ((zoomode == 1))
{
if ((currentfov > 20))
{
zoomtime = (time + 0.01);
Cvar_Setf ("fov", (currentfov - 1));
Cvar_Setf ("sensitivity", (normalsens * (currentfov /
(normalfov + 30))));
}
else
{
Cvar_Setf ("crosshair", 9);// targeting :D
Cvar_Setf ("mod_lsig", 2);//Activate laser sight
}
}
else
{
if ((currentfov < normalfov))
{
zoomtime = (time + 0.05);
currentfov = (currentfov + 10);
Cvar_Setf ("fov", currentfov);
if ((currentfov >= normalfov))
{
Cvar_Setf ("fov", normalfov);
zoomode = 0.000000;
Cvar_Setf ("crosshair", 5);
Cvar_Setf ("mod_lsig", 0.000000);
Cvar_Setf ("sensitivity", normalsens);
}
else
{
Cvar_Setf ("mod_lsig", 0.000000);
Cvar_Setf ("fov", currentfov);
Cvar_Setf ("sensitivity", normalsens);
}
}
else
{
zoomode = 0.000000;
}
}
};
void () con_zoomoff =
{
zoomode = 2;
zoomtime = (time + 0.1);
LocalSound ("bip.wav", 1, 1);
};
void () CalledByEngineEveryFrame =
{
Run_Zoom ();
Foo();
Bar();
};
El Mon, 18 Aug 2003 22:57:48 -0700
"Nate 'LPlasma' Purkeypile" <[EMAIL PROTECTED]> dijo:
> You can alter the code to accept a far far higher submodel limit. We
> did this in desert crisis and have literally millions of possible
> combos. You just need to alter the compiler and some engine code.
> Email ikkyo (DC coder [EMAIL PROTECTED] ) and I'm sure he'd give you
> the specifics, but it definitely can be done. (And yes the default
> limit is 255 possible combos,# of submodels in each group multiplied
> against each other gives you how any you have).
>
>
> >On Sat, 16 Aug 2003 21:12:18 +0200, Rockefeller
> ><[EMAIL PROTECTED]> wrote:
> >
> > >> Its called limitations of 32bit archetecture.
> > >
> > >You can encode 8 combinations within 3 bits. And a model with 8
> > >combinations works.
> > >
> > >But with 4 heads, 2 main bodies, 4 extensions ( == 32 possible
> > >combinations, 5 bit encoded) you are FAR from any int, byte or
> > >whatever limit, and that does NOT work.
> > >So i guess it's not an 32 bit architecture limitation. :)
> > >
> > >body seems to be a byte in the engine, for StudioModelRenderer sets
> > >it to 255 for MP hires models.
> > >I commented out that line, added a debug output, and that shows
> > >that the value set in the server dll gets to StudioModelRenderer
> > >correctly.
> > >
> > >I'm quite sure that this is an engine limitation or bug...
> >
> >I don't remember off the top of my head how it's encoded or if there
> >is a hard limit in the engine, but you might try fiddling with
> >delta.lst. It looks like the default is to send to the client 8 bits
> >for body. Increasing that might solve your problem. If not, you're
> >probably out of luck.
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
