Basically I need some help. You can edit hl.dll to make the precache limit higher. You know, when you start a map and you get Host_Error: PF_precache_model_I: Model 'randommodehere' failed to precache because the item count is over the 512 limit. I know in hexedit you can go into the DLL, find the string that corresponds to the precache limit and alter it to make it higher. This is where I have the dilemma, the string that corresponds to it is 81 FF FF 00 (or 01) where FF 00 (or 01) is 511 in reverse byte order. I'm not sure what I should alter this to to make it higher. Thanks

The DLL is actually sw.dll

That's not so easy as you imagine.
You demand as long as satisfying the following :
1. There is no array (related to precache stuff) that declared using this hardcode number 512
2. make sure the client's dll can precache more than 512 and you don't need to modify client's dll
Edit:
right after this post, I found that at least one array associated with this,
it contains the model index and its max size is 512

I'm referring to You can patch your engine.dll with hex editor(search something like this: 81FFFF01 where FF01 is number 511 in hex with reversed byte order)and server will precache more

Where a moderator here said it worked.

Forget that, it's not that easy he said. The way it is I don't think you can change it.

Didn't you try it and said it worked but the client had problems precaching? That would mean that singleplayer could work

Even if it is a lost cause I would still like to know how you did it

How do we can set precache limit for model,sound, sprites for CS and HL ???

while ( dword_2166F90[v4] )
{
if ( !sub_1D355F0((signed int *)dword_2166F90[v4], v2) )
goto LABEL_20;
++v4;
if ( v4 >= 512 )
{
sub_1D4E8F0("PF_precache_model_I: Model '%s' failed to precache because the item count is over the %d limit.\nReduce the number of brush models and/or regular models in the map to correct this.", v2, 512);
return 0;
}
}

part of the precache model function, you see that "dword_2166F90[ ]" this array is declared using 512 for its size, so when v4 goes above 512, this array overflowed, how can you store value when index is over 512, enlarge the array? As I can see, there are more arrays using 512 and related to the precache stuff.

Then all you really need to do is find each array and change it accordingly to the same size. Where did you find this array?

@Jim : Do you know if it's possible to change the size array ? I know dword_2166F90[] is an array from a structure. Like you can see on the quake1SDK, something similar to :


typedef struct server_s
{
qboolean active; // false when server is going down
server_state_t state; // precache commands are only valid during load

double time;

int lastcheck; // used by PF_checkclient
double lastchecktime; // for monster ai

qboolean paused; // are we paused?

//check player/eyes models for hacks
unsigned model_player_checksum;
unsigned eyes_player_checksum;

char name[64]; // map name
char modelname[64]; // maps/<name>.bsp, for model_precache[0]
struct model_s *worldmodel;
char *model_precache[256]; // NULL terminated
char *sound_precache[256]; // NULL terminated
char *lightstyles[64];
struct model_s *models[512];

int num_edicts; // increases towards MAX_EDICTS
edict_t *edicts;
[...]


When you click on it, you don't see 512, though when you check the array size (*) you see well "Maximal possible size : 512". I've tried to print the bytes from this address but it doesn't help.

Do you have some ideas ?

well, changing original array's size is not a good idea, because in data section its size is fix when compiled using 512. you can change it using a hex editor, but the offsets after this array will change maybe, I haven't actually done this kind of operation before, so I can't say it's ok or not. I only can confirm that if this array is at the end of PE, you can enlarge it without errors.
and dword_2166F90[] is not alloc in swds, it's an extern var
Maybe alloc an native array yourself, and change some code while using the original array, redirect it to your own array.
I may do some test when I get home.

i understand only a half of them what jim_yang wrotes but its
awesome, to have such a coder here on this forums.

well, changing original array's size is not a good idea, because in data section its size is fix when compiled using 512. you can change it using a hex editor, but the offsets after this array will change maybe, I haven't actually done this kind of operation before, so I can't say it's ok or not. I only can confirm that if this array is at the end of PE, you can enlarge it without errors.
and dword_2166F90[] is not alloc in swds, it's an extern var
Maybe alloc an native array yourself, and change some code while using the original array, redirect it to your own array.
I may do some test when I get home.

Thanks I understand better. I got the same idea that somehow we need now to redirect the original one to a bigger. So I've searched where each array are used :

sound :


PF_precache_sound_I()
PF_ambiensound_I()
SV_BuildSoundMsg()
SV_LookupSoundIndex()
SV_BuildHashedSoundLookupTable()
SV_SpawnServer()


model :


PF_precache_model_I()
PF_setmodel()
SV_FindModelNumbers()
SV_ModelIndex()
SV_SpawnServer()


generic :


PF_precache_generic_I()


At the start, I though I could write a plugin which detect when you go over 512 then rewriting the functions to use my own dynamic array in pawn, but I guess it's almost impossible since there are vars of the main structure used in some functions and I can't access it. (I've tried to access it with orpheu without success). Also it would be a lot less efficient doing that.

So, I'm interesting on "alloc an native array". What do you mean exactly ? Changing the original address is easy and it would really efficient to do that, but the part to create such array, I really don't know how to do. Because I guess you need to create it in the engine dll ? It seems we need a new module. :mrgreen:


EDIT : I've discussed with joropito, and he made a module to allocate memory. I'm testing right now !

Oh boy.. good luck!

What about not necessarily precaching more, but tricking it, telling it it already has, or shouldn't precache regular game models like v_m4a1. Might seem risky,but I think it can be done.

What about not necessarily precaching more, but tricking it, telling it it already has, or shouldn't precache regular game models like v_m4a1. Might seem risky,but I think it can be done.

I actually wrote a plugin that does exactly that a year or two ago... if anyone is really interested I can dig it up and explain what it does. It's more practical on servers that run a restricted mod like a jump server, where they don't need many of the default precached entities.

And I doubt patching the game files is a good idea... like people have been saying, it gets quite complicated where you'd have to locate every single reference and alter it or coax the game to use your own memory space. And above all that, every client that connects to your server will have to have those files. And to put the icing on the cake, I think modifying certain game files gets you a tasty VAC ban! Bon appetit!

I'd love to see it if you don't mind. I'm just curious how exactly to do it. I understand my logic/theory, just now how to apply it. This might be useful cause I'm developing a CoD mod, and I'm trying to cut down the download as much as possible, but there are still many files to precache :P.

I mean, why precache files that your server will already have, and 99.9% of people can't modify their counter-strike.gcf (not even sure you can, I mean, whats the point?). So they should already have them.

Just a stab in the dark, but does it forward the precache and then return handled if the file is in a config/const array?

I might have misread what you were suggesting originally. Everything used by the engine (sounds, sprites, models and I think brushes in the map) has to be precached. Even though they're contained in the .gcf, they still need to be precached. As far as I know, there's no dynamic loading going on so what you load at map start is all you can use until map end. It was probably for performance reasons at the time, though the hardcoded 512 limit was sort of a stupid idea.

What my plugin does is hook the precache functions (model and sound are the important ones) to monitor what is being precached and decide when to block it. It has access to the name of the file being precached, so you can either filter by extension, or create an exhaustive list of files you want to avoid precaching and load that into memory.

I think you also have to hook the functions that associate entities with models and sprites and sounds, so that you can provide the game a suitable replacement or cancel the call. I don't remember if it's necessary for models/sprites, though my plugin does replace them with a dummy sprite (maybe just to see where precaches were blocked in a map). But for sounds, if you block the precache of the glock firing noise and you pull it out and shoot, the server crashes. I never actually got around to fixing that, but from parts I left commented out I can tell the idea was to hook EmitSound and EmitAmbientSound to cancel the call or emit a dummy sound of my own. You could also prevent the event from happening in the first place by restricing use of the weapon that emits the sound, but there are probably other sounds you can't block in the same way.

Originally I had trouble because returning FMRES_SUPERCEDE wasn't actually blocking the precache. I figured out (don't remember how) that you have to use the forward_return() function before returning, with the parameters (FMV_CELL, 0), which tells the engine that the function ran successfully if I remember correctly.

I hope that helps... if you need to see some actual code I'll have to clean up the plugin a bit; lots of debugging and logging and useless stuff I have to snip out.

Models need to be loaded because it returns some useful informations, see model_s struct, used by severals functions. Blocking the precache of useless resources is easy, though you need to search what resources are used. But not sure if it's worth to try to trick things like replacing blanks sounds and such. You can free much resources by removing all hl-related. Or in Cs, removing the shield and you free 20 models, you can remove weapons non used on specific maps and you can free a lot of resources.
I know Joaquim has done a private plugin which does that nicely, but I'm going to write my own plugin with more features, including the feature to increase the precache size if it works (right now half-working EDIT : proof (http://arkshine.pastebin.com/EPhezVXF) ).

that's so awesome

Don't let that encourage you too much until you see significantly more than 512 being precached. In my logs when I was testing my plugin I often saw slightly more than 512 assets being precached (maybe as high as 540 on occasion, don't recall). If you actually cracked that problem though I'd love to see how.

Also about blocking Half-Life precaches to save resources, I never saw any HL models/sounds in my logs but I clearly see some in yours so you could be right.

The method used is simply to redirect precache_model[] and model[] array (because right now, i'm testing only with model) to custom one. Joripito has made a simple module to allocate memory. Then, with orpheu, I've replaced the address of all array references to the new one and replace all the 512 check with the new limit. For example the new array is 1024. I've tried on fy_dangercity where I know the model count is near of the limit, I've added some custom models like you can see to go over 512. This part works fine. But there is a problem in-game :p ; you see no models/sprites ( even the default ones ) at all and the client console is flooding with message like "Tried to link edict 168 without model". That's why I've said half-working. Right now we try to figure out the problem. ( The output you see from the link is directly from precache_model[] array, after server start )

HL :

models/w_antidote.mdl
models/w_security.mdl
models/w_longjump.mdl
items/suitcharge1.wav
items/suitchargeno1.wav
items/suitchargeok1.wav
common/wpn_hudoff.wav
common/wpn_hudon.wav
common/wpn_moveselect.wav
common/wpn_denyselect.wav
player/geiger6.wav
player/geiger5.wav
player/geiger4.wav
player/geiger3.wav
player/geiger2.wav
player/geiger1.wav
sprites/zerogxplode.spr
sprites/WXplo1.spr
sprites/steam1.spr
sprites/bubble.spr
sprites/bloodspray.spr
sprites/blood.spr
sprites/smokepuff.spr
sprites/eexplo.spr
sprites/fexplo.spr
sprites/fexplo1.spr
sprites/b-tele1.spr
sprites/c-tele1.spr
sprites/ledglow.spr
sprites/laserdot.spr
sprites/explode1.spr
weapons/bullet_hit1.wav
weapons/bullet_hit2.wav
items/weapondrop1.wav
weapons/generic_reload.wav


That's something you can check easily by looking the gamedll with IDA for example.
For example, you can see in ClientPrecache() function. here the IDA decompiled output :



int __cdecl ClientPrecache()
{
signed int v0; // edi@1
signed int i; // esi@3
signed int v2; // esi@5
int v3; // eax@6
signed int v4; // esi@8
signed int v5; // esi@10
int v6; // eax@11
char v7; // bl@13
int result; // eax@33
int v9; // [sp+Ch] [bp-30h]@8
int v10; // [sp+10h] [bp-2Ch]@8
int v11; // [sp+14h] [bp-28h]@8
int v12; // [sp+18h] [bp-24h]@8
int v13; // [sp+1Ch] [bp-20h]@8
int j; // [sp+20h] [bp-1Ch]@8
int v15; // [sp+24h] [bp-18h]@8
int v16; // [sp+28h] [bp-14h]@8
int v17; // [sp+2Ch] [bp-10h]@8
int v18; // [sp+30h] [bp-Ch]@13
int v19; // [sp+34h] [bp-8h]@13
int v20; // [sp+38h] [bp-4h]@13

PRECACHE_SOUND("weapons/dryfire_pistol.wav");
PRECACHE_SOUND("weapons/dryfire_rifle.wav");
PRECACHE_SOUND("player/pl_shot1.wav");
PRECACHE_SOUND("player/pl_die1.wav");
PRECACHE_SOUND("player/headshot1.wav");
PRECACHE_SOUND("player/headshot2.wav");
PRECACHE_SOUND("player/headshot3.wav");
PRECACHE_SOUND("player/bhit_flesh-1.wav");
PRECACHE_SOUND("player/bhit_flesh-2.wav");
PRECACHE_SOUND("player/bhit_flesh-3.wav");
PRECACHE_SOUND("player/bhit_kevlar-1.wav");
PRECACHE_SOUND("player/bhit_helmet-1.wav");
PRECACHE_SOUND("player/die1.wav");
PRECACHE_SOUND("player/die2.wav");
PRECACHE_SOUND("player/die3.wav");
PRECACHE_SOUND("player/death6.wav");
PRECACHE_SOUND("radio/locknload.wav");
PRECACHE_SOUND("radio/letsgo.wav");
PRECACHE_SOUND("radio/moveout.wav");
PRECACHE_SOUND("radio/com_go.wav");
PRECACHE_SOUND("radio/rescued.wav");
PRECACHE_SOUND("radio/rounddraw.wav");
PRECACHE_SOUND("items/kevlar.wav");
PRECACHE_SOUND("items/ammopickup2.wav");
PRECACHE_SOUND("items/nvg_on.wav");
PRECACHE_SOUND("items/nvg_off.wav");
PRECACHE_SOUND("items/equip_nvg.wav");
PRECACHE_SOUND("weapons/c4_beep1.wav");
PRECACHE_SOUND("weapons/c4_beep2.wav");
PRECACHE_SOUND("weapons/c4_beep3.wav");
PRECACHE_SOUND("weapons/c4_beep4.wav");
PRECACHE_SOUND("weapons/c4_beep5.wav");
PRECACHE_SOUND("weapons/c4_explode1.wav");
PRECACHE_SOUND("weapons/c4_plant.wav");
PRECACHE_SOUND("weapons/c4_disarm.wav");
PRECACHE_SOUND("weapons/c4_disarmed.wav");
PRECACHE_SOUND("weapons/explode3.wav");
PRECACHE_SOUND("weapons/explode4.wav");
PRECACHE_SOUND("weapons/explode5.wav");
PRECACHE_SOUND("player/sprayer.wav");
PRECACHE_SOUND("player/pl_fallpain2.wav");
PRECACHE_SOUND("player/pl_fallpain3.wav");
PRECACHE_SOUND("player/pl_snow1.wav");
PRECACHE_SOUND("player/pl_snow2.wav");
PRECACHE_SOUND("player/pl_snow3.wav");
PRECACHE_SOUND("player/pl_snow4.wav");
PRECACHE_SOUND("player/pl_snow5.wav");
PRECACHE_SOUND("player/pl_snow6.wav");
PRECACHE_SOUND("player/pl_step1.wav");
PRECACHE_SOUND("player/pl_step2.wav");
PRECACHE_SOUND("player/pl_step3.wav");
PRECACHE_SOUND("player/pl_step4.wav");
PRECACHE_SOUND("common/npc_step1.wav");
PRECACHE_SOUND("common/npc_step2.wav");
PRECACHE_SOUND("common/npc_step3.wav");
PRECACHE_SOUND("common/npc_step4.wav");
PRECACHE_SOUND("player/pl_metal1.wav");
PRECACHE_SOUND("player/pl_metal2.wav");
PRECACHE_SOUND("player/pl_metal3.wav");
PRECACHE_SOUND("player/pl_metal4.wav");
PRECACHE_SOUND("player/pl_dirt1.wav");
PRECACHE_SOUND("player/pl_dirt2.wav");
PRECACHE_SOUND("player/pl_dirt3.wav");
PRECACHE_SOUND("player/pl_dirt4.wav");
PRECACHE_SOUND("player/pl_duct1.wav");
PRECACHE_SOUND("player/pl_duct2.wav");
PRECACHE_SOUND("player/pl_duct3.wav");
PRECACHE_SOUND("player/pl_duct4.wav");
PRECACHE_SOUND("player/pl_grate1.wav");
PRECACHE_SOUND("player/pl_grate2.wav");
PRECACHE_SOUND("player/pl_grate3.wav");
PRECACHE_SOUND("player/pl_grate4.wav");
PRECACHE_SOUND("player/pl_slosh1.wav");
PRECACHE_SOUND("player/pl_slosh2.wav");
PRECACHE_SOUND("player/pl_slosh3.wav");
PRECACHE_SOUND("player/pl_slosh4.wav");
PRECACHE_SOUND("player/pl_tile1.wav");
PRECACHE_SOUND("player/pl_tile2.wav");
PRECACHE_SOUND("player/pl_tile3.wav");
PRECACHE_SOUND("player/pl_tile4.wav");
PRECACHE_SOUND("player/pl_tile5.wav");
PRECACHE_SOUND("player/pl_swim1.wav");
PRECACHE_SOUND("player/pl_swim2.wav");
PRECACHE_SOUND("player/pl_swim3.wav");
PRECACHE_SOUND("player/pl_swim4.wav");
PRECACHE_SOUND("player/pl_ladder1.wav");
PRECACHE_SOUND("player/pl_ladder2.wav");
PRECACHE_SOUND("player/pl_ladder3.wav");
PRECACHE_SOUND("player/pl_ladder4.wav");
PRECACHE_SOUND("player/pl_wade1.wav");
PRECACHE_SOUND("player/pl_wade2.wav");
PRECACHE_SOUND("player/pl_wade3.wav");
PRECACHE_SOUND("player/pl_wade4.wav");
PRECACHE_SOUND("debris/wood1.wav");
PRECACHE_SOUND("debris/wood2.wav");
PRECACHE_SOUND("debris/wood3.wav");
PRECACHE_SOUND("plats/train_use1.wav");
PRECACHE_SOUND("plats/vehicle_ignition.wav");
PRECACHE_SOUND("buttons/spark5.wav");
PRECACHE_SOUND("buttons/spark6.wav");
PRECACHE_SOUND("debris/glass1.wav");
PRECACHE_SOUND("debris/glass2.wav");
PRECACHE_SOUND("debris/glass3.wav");
PRECACHE_SOUND("items/flashlight1.wav");
PRECACHE_SOUND("items/flashlight1.wav");
PRECACHE_SOUND("common/bodysplat.wav");
PRECACHE_SOUND("player/pl_pain2.wav");
PRECACHE_SOUND("player/pl_pain4.wav");
PRECACHE_SOUND("player/pl_pain5.wav");
PRECACHE_SOUND("player/pl_pain6.wav");
PRECACHE_SOUND("player/pl_pain7.wav");
v0 = 12;
if ( !sub_100C7EF0("czero") )
v0 = 10;
for ( i = 0; i < v0; ++i )
PRECACHE_MODEL(*(&off_1010D06C + i));
v2 = 100;
do
{
v3 = sub_10036050(v2);
if ( !v3 )
break;
PRECACHE_MODEL(v3);
++v2;
}
while ( v2 <= 199 );
PRECACHE_MODEL("models/p_ak47.mdl");
PRECACHE_MODEL("models/p_aug.mdl");
PRECACHE_MODEL("models/p_awp.mdl");
PRECACHE_MODEL("models/p_c4.mdl");
PRECACHE_MODEL("models/w_c4.mdl");
PRECACHE_MODEL("models/p_deagle.mdl");
PRECACHE_MODEL("models/shield/p_shield_deagle.mdl");
PRECACHE_MODEL("models/p_flashbang.mdl");
PRECACHE_MODEL("models/shield/p_shield_flashbang.mdl");
PRECACHE_MODEL("models/p_hegrenade.mdl");
PRECACHE_MODEL("models/shield/p_shield_hegrenade.mdl");
PRECACHE_MODEL("models/p_glock18.mdl");
PRECACHE_MODEL("models/shield/p_shield_glock18.mdl");
PRECACHE_MODEL("models/p_p228.mdl");
PRECACHE_MODEL("models/shield/p_shield_p228.mdl");
PRECACHE_MODEL("models/p_smokegrenade.mdl");
PRECACHE_MODEL("models/shield/p_shield_smokegrenade.mdl");
PRECACHE_MODEL("models/p_usp.mdl");
PRECACHE_MODEL("models/shield/p_shield_usp.mdl");
PRECACHE_MODEL("models/p_fiveseven.mdl");
PRECACHE_MODEL("models/shield/p_shield_fiveseven.mdl");
PRECACHE_MODEL("models/p_knife.mdl");
PRECACHE_MODEL("models/shield/p_shield_knife.mdl");
PRECACHE_MODEL("models/w_flashbang.mdl");
PRECACHE_MODEL("models/w_hegrenade.mdl");
PRECACHE_MODEL("models/p_sg550.mdl");
PRECACHE_MODEL("models/p_g3sg1.mdl");
PRECACHE_MODEL("models/p_m249.mdl");
PRECACHE_MODEL("models/p_m3.mdl");
PRECACHE_MODEL("models/p_m4a1.mdl");
PRECACHE_MODEL("models/p_mac10.mdl");
PRECACHE_MODEL("models/p_mp5.mdl");
PRECACHE_MODEL("models/p_ump45.mdl");
PRECACHE_MODEL("models/p_p90.mdl");
PRECACHE_MODEL("models/p_scout.mdl");
PRECACHE_MODEL("models/p_sg552.mdl");
PRECACHE_MODEL("models/w_smokegrenade.mdl");
PRECACHE_MODEL("models/p_tmp.mdl");
PRECACHE_MODEL("models/p_elite.mdl");
PRECACHE_MODEL("models/p_xm1014.mdl");
PRECACHE_MODEL("models/p_galil.mdl");
PRECACHE_MODEL("models/p_famas.mdl");
PRECACHE_MODEL("models/p_shield.mdl");
PRECACHE_MODEL("models/w_shield.mdl");
v4 = 0;
v15 = dword_10158E0C;
v16 = dword_10158E10;
v17 = dword_10158E14;
v9 = -1038614528;
v10 = -1044381696;
v11 = -1037828096;
v12 = 1108869120;
v13 = 1103101952;
for ( j = 1109655552; v4 < v0; ++v4 )
PRECAHE_MODEL(2, &v9, &v12, *(&off_1010D06C + v4));
v5 = 100;
do
{
v6 = sub_10036050(v5);
if ( !v6 )
break;
PRECAHE_MODEL(3, &v9, &v12, v6);
++v5;
}
while ( v5 <= 199 );
PRECAHE_MODEL(0, &v15, &v15, "sprites/black_smoke1.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/black_smoke2.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/black_smoke3.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/black_smoke4.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/fast_wallpuff1.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/smokepuff.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/gas_puff_01.spr");
PRECAHE_MODEL(0, &v15, &v15, "sprites/scope_arc.tga");
PRECAHE_MODEL(0, &v15, &v15, "sprites/scope_arc_nw.tga");
PRECAHE_MODEL(0, &v15, &v15, "sprites/scope_arc_ne.tga");
PRECAHE_MODEL(0, &v15, &v15, "sprites/scope_arc_sw.tga");
v7 = sub_100C7EF0("czero");
v9 = -1052770304;
v10 = -1061158912;
v11 = -1045430272;
v18 = 1094713344;
v19 = 1086324736;
v20 = 1102053376;
v12 = 1094713344;
v13 = 1086324736;
j = 1102053376;
if ( v7 )
{
v9 = -1051721728;
v10 = -1061158912;
v11 = -1045430272;
v18 = 1095761920;
v19 = 1086324736;
v20 = 1102053376;
v12 = 1095761920;
v13 = 1086324736;
j = 1102053376;
}
PRECAHE_MODEL(2, &v9, &v12, "models/p_deagle.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_p228.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_elite.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_usp.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_fiveseven.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_glock18.mdl");
v9 = -1043857408;
v10 = -1047003136;
v11 = -1045954560;
v18 = 1103626240;
v19 = 1102577664;
v20 = 1101529088;
v12 = 1103626240;
v13 = 1102577664;
j = 1101529088;
if ( v7 )
{
v9 = -1043333120;
v10 = -1047003136;
v11 = -1045954560;
v18 = 1104150528;
v19 = 1102577664;
v20 = 1101529088;
v12 = 1104150528;
v13 = 1102577664;
j = 1101529088;
}
PRECAHE_MODEL(2, &v9, &v12, "models/p_xm1014.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_m3.mdl");
v9 = -1044905984;
v10 = -1056964608;
v11 = -1046478848;
v18 = 1102577664;
v19 = 1090519040;
v20 = 1101004800;
v12 = 1102577664;
v13 = 1090519040;
j = 1101004800;
if ( v7 )
{
v9 = -1044905984;
v10 = -1055916032;
v11 = -1046478848;
v18 = 1102577664;
v19 = 1099431936;
v20 = 1101004800;
v12 = 1102577664;
v13 = 1099431936;
j = 1101004800;
}
PRECAHE_MODEL(2, &v9, &v12, "models/p_mac10.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_mp5.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_ump45.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_tmp.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_p90.mdl");
v9 = -1040711680;
v10 = -1056964608;
v11 = -1045954560;
v18 = 1106771968;
v19 = 1094713344;
v20 = 1106771968;
v12 = 1106771968;
v13 = 1094713344;
j = 1106771968;
if ( v7 )
{
v9 = -1038614528;
v10 = -1039925248;
v11 = -1045430272;
v18 = 1108869120;
v19 = 1097859072;
v20 = 1108082688;
v12 = 1108869120;
v13 = 1097859072;
j = 1108082688;
}
PRECAHE_MODEL(2, &v9, &v12, "models/p_ak47.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_aug.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_awp.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_g3sg1.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_sg550.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_m4a1.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_scout.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_sg552.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_famas.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_galil.mdl");
v9 = -1044381696;
v10 = -1054867456;
v11 = -1046478848;
v18 = 1103626240;
v19 = 1092616192;
v20 = 1101004800;
v12 = 1103626240;
v13 = 1092616192;
j = 1101004800;
if ( v7 )
{
v9 = -1041235968;
v10 = -1054867456;
v11 = -1046478848;
v18 = 1106247680;
v19 = 1093664768;
v20 = 1101004800;
v12 = 1106247680;
v13 = 1093664768;
j = 1101004800;
}
PRECAHE_MODEL(2, &v9, &v12, "models/p_m249.mdl");
v9 = -1059061760;
v18 = 1088421888;
v10 = -1059061760;
v19 = 1088421888;
v12 = 1088421888;
v13 = 1088421888;
v11 = -1049624576;
v20 = 1097859072;
j = 1097859072;
PRECAHE_MODEL(2, &v9, &v12, "models/p_c4.mdl");
v9 = -1065353216;
v10 = -1056964608;
v11 = -1069547520;
v18 = 1077936128;
v19 = 1088421888;
v20 = 1077936128;
v12 = 1077936128;
v13 = 1088421888;
j = 1077936128;
if ( v7 )
{
v9 = -1048051712;
v10 = -1056964608;
v11 = -1069547520;
v18 = 1099431936;
v19 = 1088421888;
v20 = 1077936128;
v12 = 1099431936;
v13 = 1088421888;
j = 1077936128;
}
PRECAHE_MODEL(2, &v9, &v12, "models/w_c4.mdl");
v18 = -1059061760;
v19 = -1073741824;
v20 = -1047527424;
v9 = -1059061760;
v10 = -1073741824;
v11 = -1047527424;
if ( v7 )
{
v18 = -1059061760;
v19 = -1069547520;
v20 = -1047527424;
v9 = -1059061760;
v10 = -1069547520;
v11 = -1047527424;
}
v18 = 1088421888;
v19 = 1073741824;
v12 = 1088421888;
v13 = 1073741824;
v20 = 1099956224;
j = 1099956224;
PRECAHE_MODEL(2, &v9, &v12, "models/p_flashbang.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_hegrenade.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/p_smokegrenade.mdl");
v18 = -1063256064;
v19 = -1063256064;
v20 = -1063256064;
v9 = -1063256064;
v10 = -1063256064;
v11 = -1063256064;
if ( v7 )
{
v18 = -1063256064;
v19 = -1063256064;
v20 = -1059061760;
v9 = -1063256064;
v10 = -1063256064;
v11 = -1059061760;
}
v18 = 1084227584;
v19 = 1084227584;
v12 = 1084227584;
v13 = 1084227584;
v20 = 1096810496;
j = 1096810496;
PRECAHE_MODEL(2, &v9, &v12, "models/w_flashbang.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/w_hegrenade.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/w_smokegrenade.mdl");
v9 = -1059061760;
v18 = 1088421888;
v10 = -1053818880;
v19 = 1086324736;
v12 = 1088421888;
v13 = 1086324736;
v11 = -1047527424;
v20 = 1099956224;
j = 1099956224;
PRECAHE_MODEL(2, &v9, &v12, "models/p_knife.mdl");
v9 = -1048576000;
v10 = -1056964608;
v11 = -1034420224;
v18 = 1098907648;
v19 = 1086324736;
v20 = 1103101952;
v12 = 1098907648;
v13 = 1086324736;
j = 1103101952;
if ( v7 )
{
v9 = -1045954560;
v10 = -1043857408;
v11 = -1034420224;
v18 = 1101529088;
v19 = 1102577664;
v20 = 1103101952;
v12 = 1101529088;
v13 = 1102577664;
j = 1103101952;
}
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_deagle.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_fiveseven.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_flashbang.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_glock18.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_hegrenade.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_knife.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_p228.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_smokegrenade.mdl");
PRECAHE_MODEL(2, &v9, &v12, "models/shield/p_shield_usp.mdl");
PRECACHE_SOUND("common/wpn_hudoff.wav");
PRECACHE_SOUND("common/wpn_hudon.wav");
PRECACHE_SOUND("common/wpn_moveselect.wav");
PRECACHE_SOUND("common/wpn_select.wav");
PRECACHE_SOUND("common/wpn_denyselect.wav");
PRECACHE_SOUND("player/geiger6.wav");
PRECACHE_SOUND("player/geiger5.wav");
PRECACHE_SOUND("player/geiger4.wav");
PRECACHE_SOUND("player/geiger3.wav");
PRECACHE_SOUND("player/geiger2.wav");
PRECACHE_SOUND("player/geiger1.wav");
if ( dword_1015A804 )
sub_100C51B0("enemy_terrorist");
LOWORD(word_101289C8) = PRECACHE_MODEL("sprites/shadow_circle.spr");
PRECACHE_MODEL("sprites/wall_puff1.spr");
PRECACHE_MODEL("sprites/wall_puff2.spr");
PRECACHE_MODEL("sprites/wall_puff3.spr");
PRECACHE_MODEL("sprites/wall_puff4.spr");
PRECACHE_MODEL("sprites/black_smoke1.spr");
PRECACHE_MODEL("sprites/black_smoke2.spr");
PRECACHE_MODEL("sprites/black_smoke3.spr");
PRECACHE_MODEL("sprites/black_smoke4.spr");
PRECACHE_MODEL("sprites/fast_wallpuff1.spr");
PRECACHE_MODEL("sprites/pistol_smoke1.spr");
PRECACHE_MODEL("sprites/pistol_smoke2.spr");
PRECACHE_MODEL("sprites/rifle_smoke1.spr");
PRECACHE_MODEL("sprites/rifle_smoke2.spr");
PRECACHE_MODEL("sprites/rifle_smoke3.spr");
dword_10158FF8("sprites/scope_arc.tga");
dword_10158FF8("sprites/scope_arc_nw.tga");
dword_10158FF8("sprites/scope_arc_ne.tga");
dword_10158FF8("sprites/scope_arc_sw.tga");
result = PRECACHE_EVENT(1, "events/decal_reset.sc");
word_101289D0 = result;
return result;
}

So did you patch the .dll or is this all in a plugin?

I think HE'S making the plugin while Joripito made a module.

Right now we are testing only on linux, so engine.so. Like I said, a module to allocate memory and in a plugin, using orpheu to patch the memory to change the address with the new got from the module and changing the check value.

Amazing work the both of you

Wow, really nice research you are doing, keep it up! I would be very curious about a solution aswell.

This is the update:

We can resize arrays in memory to support more than 512 models
We've tested with 750+ models and client can connect.

The problem now is, when we touch those arrays in memory, the client don't see anymore non-brush models (included game specific models). Even if we allocate for 512 models with the new memory locations.

I think the problem is not the model count. There should be a reference we are missing.

Tomorrow we (Arkshine + me) will test resizing model_t static structure but really I don't think will fix that issue.

If someone knows or has any idea about that would be nice.

Arrays what we're touching:
(char *)sv->precache_model[512]
(model_t *)sv->models[512]

Tomorrow:
(model_t)mod_known[512]
and others...

I did a test with base builder to find the max visible brush entities, and after about entity 255 no more were visible. Hope that helps

So amxmodx is allowed to manipulate memory on the client side? I had no idea, thought it could only modify server memory for security reasons.

Where did you see we modify the client side ? The client can't be accessed.

Oh, well I thought that if the client needed to precache more than the hardcoded limit that the client's engine would need its memory space patched. I'm not that familiar with how the engine works but I figured the server generates a list of assets to be precached based on the map, mod and plugins, which it passes on to the client, who is then responsible for loading them from local files. Maybe it's not like that at all but in my mind you would have to convince the server to keep generating the list of items to precache after the 512th instead of crashing, and then manipulate the clients so that they could actually hold and access the bigger list of references.

Totally wrong?

Well, to be honest, we either don't know how exactly client/engine work. We got an idea and we need to start from somewhere. By reading a lot the engine we start to understand step by step, testing new things etc. Maybe all we do is pointless because the client would need to be modified at the end, we don't know. From our test we can lost more than 512 models without problems. Like said by joripito, about the issue where you don't see the models in-game, when we test with the same size, it happens too. So we miss something or doing something wrong. Looking at the current state, we have some hope it would world fine after fixing this issue. We will see. ;)

Maybe all we do is pointless because the client would need to be modified at the end, we don't know.

i dont think so, then if i change to a map with much precache stuff then
the server crashes, not the client, the map with all the plugins can used
on the client side without any problem (i got no problems as i tested it)
but who cares, valve do things we never know :)

The client can't crash, because hlds crashes first.

If the DLL works alone then I can live with that. The plugin should be a secondary project if anything

Good news ! It works. :)

After some headaches, dumb errors, we have finally get working it successfully.
To make sure, tried to set model with an index > 512, and it appears fine in-game.

Big thanks to joropito who made the module to allocate memory. He will post later. Without his help it would not even possible !

Now, the plugin is not finished. Only models are supported. I need to add sound and generic, clean up some things, making signatures of bytes, etc. It will be posted another day.

It was just an update.

I'm soooo happy :mrgreen:

After 4 days, it's working :3

But It was funny and we have gained more knowledge about the engine. :mrgreen:

I love you guys.

{No Homo}

This will be EXTREMELY useful :)

Sounds fascinating, I can't wait. I'll test and see if it can maybe help me run some insane BB maps with like 500 objects.

Sounds fascinating, I can't wait. I'll test and see if it can maybe help me run some insane BB maps with like 500 objects.

This will not fix max visible entities. Only max precached models.

when will u (Arkshine) and (Joropito) code a really better Engiene ? :shock: haha

gj both of u. awesome what u do to do things working :)

The module is for linux only?

For the moment, yes. But once he will post the module, I'm sure someone will compile for windows. I will need it to test before releasing because things are handled differently.

The module is for linux only?

At this time yes.

I will improve it and then post in modules section requesting to someone compile for windows.

Source code will be available.

Good to know!Both of you keep up the good work!:)

Apparently, great modules must start in Linux-only :P

This time it's because joropito could compile only for linux. :P

Linux is da best :mrgreen:

Does one of you know the reason for the max visible entities?

Same question as tirant. Get's really annoying in like blockmaker or something where you create your models. Because they just start disappearing :(

Fck yeah, so, we can have more than 512 Models on a Server?

@Tirant, no idea. But it sounds like more something related to the client.

@meTaLiCroSS: yes, models, sounds and generic.

congrats arkshine & joropito , this module is amazing , its a really good notice, waiting version to windows ... :D

linux module how is it done? how to change the preache limit ? do not understand please help

They will release it for everyone when it is finished with the source, so you can see for yourself.

Linux is usually the easiest to code on so It's understandable.

Windows is going to be a pain

How is work on this plugin going? What is there left to fix on it before release? I definitely need it :)

Working on it. We had many trouble. At the start we wanted to try to patch one time at server start, then cleaning the array before the map change. Because of this method, we had many problems. Now, the method is different : the patch is done at each map, then before the map change a rollback is done and the memory is freeing. It seems to work better this way and it's actually what I wanted to do at the very start : allocating dynamically depending the need. The part for linux is almost finished. Windows will be more boring.. Not tested yet btw under windows.

Can you give us an ETA? I'm kinda lookin forward to testing it and throwing thousands of entities at it. It makes running a nice map and a nice mod hard with a max of only 512.

Okay, sad news.

We knew there would be a small possibility it will fail.
Allocating new array and patching new address work fine, and we can go over the limit. Server doesn't crash. But What we have done is server side.

Yes, that's the problem.

A list of precached items is sent to the clients. The limit is applied as well on the client. By creating a list > 514 items, the content will overwrite the next array. For example, we have 528 models, and the models after the 514th will overwrite in the sound array. So, for these sounds, it won't work. You will get and "Missing RIFF/WAVE chunk" message in the client console because it tries load a model instead of the sound.

It won't work properly.

The last solution, like suggested joropito, would be to create an injecter so to resize to the client too. But, that's something each client would need to install on their computer. Not a nice solution. It could be acceptable for small community, though...

That's all.
I have to say I'm quite disappointed after all the work we have done, but we knew it could be happen.

That's sad!:cry:
Yesterday i connected to a server running a big map(maybe it was your test server),and i saw "Missing RIFF/WAVE chunk" messages in my console and i was going to ask what exactly is that here on AM.Anyway,any possibilities of making a plugin similar to joaquimandrade's?

Yes, will do it. I wanted to do it anyway. I thought it would be useless with the Dynamic Precache Control plugin, but now, it would be useful.

About your error, it's probably a plugin which precache mp3 file with precache_sound() where precache_generic() should be used.

Man, that sucks. But I applaud u and joropito on your hard work. Almost got it :)

Thanks a lot guys.

What about like, somehow tricking the precache. Like making them connect and precache, then reconnect and precache the rest. Not really sure how it would work, but just an idea. Or using 2 servers to precache all the files. Either a genius idea or a completely retarded suggestion, lol. The only way I see it failing is reconnecting the client and not being able to fix the precache. Or what about like having the client precache at different times. Like delaying some of the models/sounds. Basically, well, my idea sorta stems off of ingame sometimes you download files and then connect, then when you reconnect with the downloaded files, you end up downloading some more. Just an observation.

What about like, somehow tricking the precache. Like making them connect and precache, then reconnect and precache the rest. Not really sure how it would work, but just an idea. Or using 2 servers to precache all the files. Either a genius idea or a completely retarded suggestion, lol. The only way I see it failing is reconnecting the client and not being able to fix the precache. Or what about like having the client precache at different times. Like delaying some of the models/sounds. Basically, well, my idea sorta stems off of ingame sometimes you download files and then connect, then when you reconnect with the downloaded files, you end up downloading some more. Just an observation.

The problem is not the server, is the client.

Thinks like this:

You have 512 boxes to put everything you need. One piece per box.
We can add boxes to the server, but not to the client so the client will use all of those boxes and the overflow will use places in the room where you are...

The problem is not the server, is the client.

Thinks like this:

You have 512 boxes to put everything you need. One piece per box.
We can add boxes to the server, but not to the client so the client will use all of those boxes and the overflow will use places in the room where you are...

Would you still consider releasing the DLL?

If anything you should email your work to Valve so they could officially patch it in

Would you still consider releasing the DLL?

My module only handle memory like memhack but with some new functions.
I will release it.

If anything you should email your work to Valve so they could officially patch it in

Valve is not willing to release updates for exploits so I don't think they will release any patch to improve precache limits.

If anything you should email your work to Valve so they could officially patch it in

Valve know those shit, and Valve never change those shit.
But why ? well they never change this while they want that u use
newer games and pay for them much money.

and thanks god that they dont touch those things, we all know
that this would end up in an much more bugged steam ever, except
it is yet bugged but it would much more even if they cant fix it
like their try to change sound thingys:twisted:

Ok, I'll give you a couple reason why Valve never fixes anything anymore. First off, go look up what year HL1 came out. I think it was '98, and I think cstrike was '99. But around that time. The games are a decade old. How many games do people play that are that old and still supported? Maybe just Diablo II, but D2 is a good game, lol. Now take into account how much money they make off of the game still. The market isn't getting any bigger when they already created 2 games that are basically sequels (CZ and Source). You're pretty much bitching about them not updating Diablo 1, when everyone is already playing Diablo 3 (figuratively <3). Not to mention, why should they help a game this old when they would rather have you buy another game that has bugs like this fixed. You are trying to do things that didn't exist 10 years ago on a game that old. It wasn't built to do these things, cause they didn't plan on mods like these. Not to mention, I bet you 2/3 of the entire CS community is now non-steam which means they make 0 money off of them, so they would be screwing themselves over helping us. Basically what Valve has done is left it up to the CS community to keep the game alive. Very lengthy bitchy message, but I agree with every point. They have no reason to help us anymore. It's not like WoW where EVERYONE pays money annually to keep getting updates and stuff. Don't expect frequent updates in any one-time pay games. It's just common sense, they have no motivation to improve the game. It's for this reason that I like XBOX live, because you pay them to keep it looking good and updated, so theoretically, anything you get for free will always suck (PS3 network I'm talking to you, lol <3).

sigh, finally associated with client, don't know if there are some tech reasons that valve make this limit. or they just lazy to change a define from 512 to bigger.

I remember reading someone on the hlds_linux maillist who said Valve has to keep the specs written on the game box. If you increase the limit, a better computer woud need. Something like. But now, it should not matter, they could make an effort.

Alas, back to blocking precaches then...

I'm working on the plugin I wanted to do at the start.

Which one is that again?

Control the precache : removing useless stuffs precached by default (all defined by files), ability to remove whatever the weapon/item so blocking properly the precache/buy/give etc, blocking the crash when you go over 512, it informs you what exactly and it will pause/block the plugin which causes the crash, ability to create your own config to block these files, some commands to have a view of precaches files and from what plugins, another to get the current number of files for each array, also another to get the number of totals resources allowed to be sent to the clients (there is a limit of 1280), etc.. And probably another thing I have not thought yet. EDIT: There is probably something to do also for some maps, like detecting ambient sounds.

Now we know it's "impossible" in an easy way, I think such plugin will be useful.

Will be extremely useful Ark, even though patching to go above 512 is impossible thanks to Valve, this is the next best thing in my opinion and would be really helpful to a lot of server owners.

Arkshine, your plans sound awesome and I'm looking forward to that. It would be extremely usefull for a lot of people when they have control over it, because if you actually manage the entities, 512 is almost everytime enough.

@Tirant: cstrike was released on 2000 :crab:

any progress // ??
plugin,module for windows. etc

Excuse me for bumping an old thread - but is there any progress in the that module?

What module you are talking about ?

What module you are talking about ?Joropito's module for allocating memory.

I don't know. I doubt joropito has updated the module like he wanted. He's busy and wanted to do others things. The current state is probably the same when we were working on the plugin, specific to our need. I'm wondering what they want to do with such module.

Joropito's module for allocating memory.

Is it really useful?
Because it was intended to work for this thread but we found that there's some client issues trying to increase resources limits.

I can't find a useful application to have this module.

Is it really useful?
Because it was intended to work for this thread but we found that there's some client issues trying to increase resources limits.

I can't find a useful application to have this module.Yes,i agree with you.Since we know that some limits can't be passed because of client side issues,i don't think it will be usefull too.No idea why some people want it,even though they can't use it.

Topic died?

Read and you will know.

Arkshine, I would be extremely interesting in your "entity precache manager" plugin, which you mentioned one page before:
Control the precache : removing useless stuffs precached by default (all defined by files), ability to remove whatever the weapon/item so blocking properly the precache/buy/give etc, blocking the crash when you go over 512, it informs you what exactly and it will pause/block the plugin which causes the crash, ability to create your own config to block these files, some commands to have a view of precaches files and from what plugins, another to get the current number of files for each array, also another to get the number of totals resources allowed to be sent to the clients (there is a limit of 1280), etc.. And probably another thing I have not thought yet. EDIT: There is probably something to do also for some maps, like detecting ambient sounds.

Now we know it's "impossible" in an easy way, I think such plugin will be useful.

How is the progress on that? It would be extremely usefull.

First you say:


To make sure, tried to set model with an index > 512, and it appears fine in-game.

Big thanks to joropito who made the module to allocate memory.

Now, the plugin is not finished. Only models are supported. I need to add sound and generic, clean up some things, making signatures of bytes, etc. It will be posted another day.

Now you ask us, why we can't use this module? It would already do our specific need, having more than 512 files precached.

...

Again, read #63 (http://forums.alliedmods.net/showpost.php?p=1309155&postcount=63)

...

Again, read #63 (http://forums.alliedmods.net/showpost.php?p=1309155&postcount=63)

No problem:

So, for these sounds, it won't work. You will get and "Missing RIFF/WAVE chunk" message in the client console because it tries load a model instead of the sound.

It won't work properly.


Some people can live with that.

How is it with that:


The last solution, like suggested joropito, would be to create an injecter so to resize to the client too. But, that's something each client would need to install on their computer. Not a nice solution. It could be acceptable for small community, though...

You're right, it isn't a nice solution but it would work.

You don't understand, just because we can patch server-side means it works. If you read the link, it would need to patch client-side as well, since we can't, what we have done is just pointless.
Some people can live with that. : It seems you don't get, you have that error because it's overwritten on the model array. Of course, that's not good.

So, forget.

Sorry for maybe bumping an old thread but I would like to hear if either anyone is still working on a (possible) solution to get over the 512 limit or if it is even possible (I can live with it if it isnt but I just want it to be officially declared :P)

@Arkshine: and what about the plugin you mentioned before? (#78 (http://forums.alliedmods.net/showpost.php?p=1310205&postcount=78)) are you still working on it or made any progress?

And maybe this is a stupid idea but what if you take a look in (I believe) already "patched" .dlls? Im talking about Counter Strike Online (by Nexon), there are way more weapons, models and sounds ingame aviable so they must have fixed it somehow.
Maybe you could try modify and adapt them to 1.6?

There is another thread about that in the scripting section and the final answer. Please search. But if you want, that's not possible because it needs to patch the client too, and that's impossible.

Ok I did some research (before my post I just found 2 threads in this forum about the limit so I didnt know there was more) and found these two threads:
https://forums.alliedmods.net/showthread.php?p=1083879&highlight=512#post1083879
https://forums.alliedmods.net/showthread.php?t=137201&highlight=precache+limit&page=4 (at the bottom)

is one of them the one you were talking about?

so that means if it is hardcoded we dont have ever any chance do modify it (only valve can)?
and i guess my "idea" wouldnt work because valve modified it for nexon and they made a totally different client so that it wouldnt make any sense trying it, right?

now thats sad :( i assume there were also many attempts to convince valve to patch it...?

but if you had the source code it wouldnt be that hard to change the limit, or? if yes, i cant understand why valve just fixes it in a short time even if it wouldnt benifit them, they could at least make some users happy :)....

Sorry, I did not seen you were already in the right thread. :p

So, read this post : https://forums.alliedmods.net/showpost.php?p=1309155&postcount=63

but like you said The last solution, like suggested joropito, would be to create an injecter so to resize to the client too. But, that's something each client would need to install on their computer. Not a nice solution. It could be acceptable for small community, though... there could be a possible solution. i would at least like to try it and if its not appropriate, we can still annoy valve with mails :wink:

I have no idea how to do that, and I doubt joropito is willing to work on that. I don't think it's worth to waste time on it. Just learn to configure better your server.

okay then i will write a mail to valve asking for a patch (already knowing they wont do anything) and let this problem rest in peace.

i dont need it for my server, it would be just great to make more out of the game thats all (adding more weapons/models and mods, building bigger and more detailed maps etc).

and if someone thinks i just want better graphics and more up-to date game and suggests that i should take css then i say that i dont like css at all (i dont know, it just doesnt feel as good as 1.6, maybe because i grew up with it ;)). and there are also not so many plugins for css (specifically no plugin that adds weapons which i would really like to do in cs)

anyway thx for your help and your work to this point :D

I don't know if I should post this in here, but I don't think it needs a new thread.
I want to ask, is there an easy way (some plugin or cvar) to check how many resources are precached currently or how many are there left until I reach the 512 limit? I'm too lazy to count them one by one, and it's different in each map, but it would be helpful to know how much free resources I have left for modding.

..specifically no plugin that adds weapons which i would really like to do in cs..
You should come check my server :wink: I've been adding new weapons for some time now, that's why it's empty most of the time :D People are too lazy to wait until they download the new weapons :D Anyway, that's why I'm asking this question here, I'm planing to put about a 100 more real-life weapons to the game, and would like to see if I have enough free resources for that :)

I have no idea how to do that, and I doubt joropito is willing to work on that. I don't think it's worth to waste time on it. Just learn to configure better your server. Don't think its worth it? Don't think versatility is work it? Don't think expanding boundaries is worth opening a doorway to create more broadly? Man it is worth it. Bigger and more bad ass plugins and maps is always a good thing.

There is another thread about that in the scripting section and the final answer. Please search. But if you want, that's not possible because it needs to patch the client too, and that's impossible. Impossible or impossible with out client downloading? The client side metamod was made that way As seen here (http://forums.alliedmods.net/showthread.php?t=23515) so why not?

If your not fond of client having to download a binary or 2 so what? They just downloading files from the server anyways like maps models.

If .dll or .exe files is wrong to required to be downloaded same goes for maps and anything else that has to be downloaded.

Client still needs to download manually the injector or CM and executing something manually before playing the game. So, yes, that's not worth at all, considering a system like cheating-death is a pain, most of people won't care to go somewhere to download such shit to play to a server. I would rather prefer to configure intelligently my server, not flooding with a ton a models and such.

@SeriousSam:

Remove dproto.

I decided to upload a plugin I did to block useless precaches. I posted it in another thread because it was also relevant there. Though since it is even more relevant for this one, I'm gonna leave the link here so that in the future this thread can be used to find it.

http://forums.alliedmods.net/showpost.php?p=1506103&postcount=41

Bad idea.

#include <amxmodx>
#include <cstrike>
#include <fakemeta>

#define VERSION "0.1"

new const g_Sounds[][] =
{
"blablabla1.wav",
"blablabla2.wav"
}

new const g_Models[][] =
{
"blablabla1.mdl", // Ïèõàåì ñþäà ìîäåëè êîòîðûå íå õîòèì ïðýêåøèòü, ìîæíî ðàñøèðÿòü ìàññèâ
"blablabla2.mdl"
}

public plugin_precache()
{
register_plugin("UnPrecacher", VERSION, "Proo.Noob")
register_forward(FM_PrecacheModel, "PrecacheModel")
register_forward(FM_PrecacheSound, "PrecacheSound")
}

public PrecacheModel(const szModel[])
{
for(new i = 0; i < sizeof(g_Models); i++)
{
if( containi(szModel, g_Models[i]) != -1 )
{
forward_return(FMV_CELL, 0)
return FMRES_SUPERCEDE
}
}
return FMRES_IGNORED
}

public PrecacheSound(const szSound[])
{
for(new i = 0; i < sizeof(g_Sounds); i++)
{
if( containi(szSound, g_Sounds[i]) != -1 )
{
forward_return(FMV_CELL, 0)
return FMRES_SUPERCEDE
}
}
return FMRES_IGNORED
}

Lol this thread is over 1 year old :D

Did this really work like i think?

I can unprecache the old example "step sounds" and making a new step sounds with out increase
the limit count?

When it is a true then omg its just that what i want, I have many new sounds like footstep, ladder climb, weapon fire ...

Did this really work like i think?

I can unprecache the old example "step sounds" and making a new step sounds with out increase
the limit count?

When it is a true then omg its just that what i want, I have many new sounds like footstep, ladder climb, weapon fire ...
It is work.

i test the "precache control" on my windows server, it worked good.
than i did the same thing in my linux server, and it not work (server crash from the heavy map).
wy ?

How do I use the code spixe posted

do I put my own sounds/models where his says blablabla?

Joropito, can you share your memory allocating DLL's source code, and how to patch these address?