High ammount of Low poly NPCs vs Low amm Created 8 years ago2016-08-07 14:36:40 UTC by abbadon

Hello, its been a long time since I don´t post anything here, but those months have been a chaos and I have had to rethink most of the features of the MOD I´m doinghttp://www.moddb.com/mods/zion-warcry
https://www.youtube.com/watch?v=QgahvxOYpSc
https://www.youtube.com/watch?v=l-0bpC0JFvg

In fact, after making a lot of essay-error coding, braking my brain thinking about how to bypass the engine limitations for entities (HL GoldSource), etc.I quited in April because the game always crashed with the same error (ED_ALLOC etc. ) So, I have discovered myself playing alone in the main map of the mod for about one hour afer an entire day fighting against continuous crashes of the MOD; I was looking here and there and examining every corner of the map without a clear idea of what I was doing until I realized that the map on which I was playing was an earlier version of the map with a lot of models (sprite_cyclers) that aren´t polished at all and with a huge ammount of polys; but what impresses me most was the fact that the system on which I was playing was an old P4 with a 6 years old 1 GB graphic card, and all that was running at a 60-80 FPS!!.

I remembered how the game lagged even on a Corei5 with 4 GB of DDR2 RAM and a Radeon H6750M with 512 MB of RAM when the waves of sentinels filled the screen (more than 150-200 entities).

Phew!!, First of all thank you for reading that "brick", but here´s my question:

According to the capabilities of modern computers, most of them can double or triple the ones of my old rig (P4 3,2 Ghz, 3 GB RAM DDR 400, GT 220 1GB)...

Would it be better to show on screen:

20 Hi Poly models or 200 Low Poly models?
What will be the problems of doing this?
Should be some code be added to avoid problems?

Thanks in anticipation!!

More models = more entities, and it's probably better to have less entities on a map. But you can try to test your map for real results of both alternatives, to check how every of variants affect a performance (or maybe other moments).

Or I can use a better engine like Xash3D?, pity is that ZWC is not supported...

It's supported, just some issues which can be fixed. As I remember, you used some model names with spaces (or something like that), so Xash doesn't load them. I reported about this to Unkle Mike, but he refused to fix this directly in the engine because another mod (which is also currently in development) will have problems. But you just can fix model names and they will be loaded properly.

Oh, afaik I did use regular names :rly: but I'll take a deep look and see if that's the problem! (cross fingers). ;). Tomorroll I'll give you a full list of the models' names I use and then you can point me to the problem.

Additionally, while it's probably not a problem on modern computers, more AI means a higher workload on the CPU, I believe.

Oh, the AI is the one of the ichthyosaur, like "see, circle, check melee, melee, circle" nothing fancy or complicated.

Honestly you need to find a balance of number of entities vs quality / polygons in the models. If a model is just a decorative piece, it can have less polys and a smaller texture map. If a model is an object of focus, it needs to look good = more polys or a better texture map. There's a balance and unfortunately it's really hard to find it.

most of that big model geometry could be made from wise func_detail brushes... could help

This is the full list of models used in my MOD.

Directorio de G:\DevZWC20\HL\ZWC\models

12/08/2016 08:58 <DIR> .
12/08/2016 08:58 <DIR> ..
18/07/2006 23:40 20.024 agibs.mdl
15/05/2006 21:06 266.012 ammo.mdl
27/12/2015 20:45 1.785.936 argos.mdl
27/06/2016 00:09 612.024 ascari.mdl
24/12/2015 00:24 1.279.552 bordext.mdl
22/12/2015 01:54 1.450.664 center.mdl
15/02/2016 17:19 1.124.620 crane.mdl
23/02/2016 02:02 113.020 focos.mdl
19/02/2016 10:42 1.124.636 grua.mdl
18/07/2006 23:40 20.024 hgibs.mdl
16/06/2015 18:06 655.168 monster_gunner.mdl
12/07/2015 18:47 649.332 monster_trolley.mdl
08/07/2015 23:12 59.276 monster_trolley01.mdl
08/07/2015 23:12 59.204 monster_trolley02.mdl
08/07/2015 23:12 17.240 monster_trolley03.mdl
08/07/2015 23:12 57.248 monster_trolleyT.mdl
22/12/2015 23:37 1.481.200 muelles1a12.mdl
02/05/2006 13:33 270.892 node.mdl
27/12/2015 20:04 2.336.752 player.mdl
03/12/2015 23:36 1.234.384 porton.mdl
19/12/2015 01:30 1.223.540 puentes.mdl
17/01/2007 23:33 6.424 p_crowbar.mdl
19/12/2015 01:52 6.424 p_dummy.mdl
17/01/2007 23:33 6.424 p_femp.mdl
17/01/2007 23:33 6.424 p_mjolnir.mdl
17/01/2007 23:33 6.424 p_shoryuken.mdl
17/01/2007 23:33 6.424 p_shredder.mdl
17/01/2007 23:33 6.424 p_siege.mdl
17/01/2007 23:33 6.424 p_twohand.mdl
05/02/2016 11:17 555.804 sentinel.mdl
03/05/2005 18:41 6.568 shell.mdl
24/10/2015 23:46 475.792 soportes.mdl
05/06/2007 20:46 812.112 torre.mdl
28/05/2006 11:55 269.488 torre2.mdl
25/06/2006 12:47 291.728 tow.mdl
23/10/2015 23:16 501.464 turbinas.mdl
21/02/2007 15:28 20.268 turret.mdl
21/02/2007 15:28 263.240 turretT.mdl
31/05/2015 19:14 897.116 v_crowbar.mdl
31/05/2015 19:13 882.564 v_femp.mdl
31/05/2015 19:12 888.596 v_mjolnir.mdl
31/05/2015 19:12 889.012 v_shoryuken.mdl
31/05/2015 19:10 889.520 v_shredder.mdl
31/05/2015 19:11 888.184 v_siege.mdl
31/05/2015 19:14 891.568 v_twohand.mdl
19/04/2006 21:14 6.568 w_9mmarclip.mdl
03/05/2005 18:40 14.296 w_9mmarclipT.mdl
01/06/2007 16:59 278.072 w_battery.mdl
15/05/2006 21:07 266.012 w_chainammo.mdl
19/12/2015 01:52 6.568 w_dummy.mdl
03/05/2005 18:41 6.568 w_femp.mdl
03/05/2005 18:41 6.568 w_mjolnir.mdl
03/05/2005 18:41 6.568 w_shoryuken.mdl
03/05/2005 18:41 6.568 w_shredder.mdl
03/05/2005 18:41 6.568 w_siege.mdl
03/05/2005 18:41 6.568 w_twohand.mdl
03/05/2005 18:41 6.568 w_weaponbox.mdl

If you see any problem with their names, tell me so I can fix it ASAP!!! ^_^

Oh, and I have also tried to use func_detail, but it´s more flexible for me to use cyclers, and because I can model more rapidly and apply better textures to them without the need of compiling a whole map to see how they´ll look. And also because I´m a bit lazy with the map editor...

Error: Mod_ForName: models/ tronera.mdl couldn't load
Error: Mod_ForName: models/ escala.mdl couldn't load
Error: Mod_ForName: models/ puente_largo.mdl couldn't load
Error: Mod_ForName: models/ grua.mdl couldn't load
Error: Mod_ForName: models/ pared1.mdl couldn't load
Error: Mod_ForName: models/ pared2.mdl couldn't load
Error: Mod_ForName: models/ puente_corto.mdl couldn't load
Error: Mod_ForName: models/ puente_centro_inferior.mdl couldn't load
Error: Mod_ForName: models/ modulo2.mdl couldn't load
Error: Mod_ForName: models/ modulo1.mdl couldn't load
Error: Mod_ForName: models/ misil.mdl couldn't load

This what I'm talking about. Your props in maps have spaces in their paths, so Xash3D can't find them. Besides that v1.0 is working. 2.0 Beta is also working, but only with crappy screen resolution.

By the way, your 2.0 patch contains an error - you've named client dlls folder cl_dll (instead of cl_dlls), so some people can have problems with launching your mod at all (game will use updated zwc.dll and outdated client.dll this way).

Ok!!, I´ll fix all that crap I´ve done with prop´s names and the dll folder. Most of those models are no longer used, as you can see in the list I´ve posted, they´re not present, even some of the ones you see there are not used. But, should I do the same with weapon´s names?, I mean, "v_" and "w_" and "p_" names. The resolution is a limitation I´ve done in the previous version, so nobody could play at less of 1024x768, for playing at 16:9 resolutioins like 1980x1080 I have used the HiREs patch from MODddB, this way I´ve done the screenshots at 1920x1080. Thanks a lot!!!, you´re on credits now.

"Qwertyus --> Implementation counselor to the graphics engine Xash3D".

The problem is not in models' names themthelves. You've added those spaces in entity's properties on maps. Like:

{
"bodygroup" " "
"origin" "-750.6 750.8 -50.8"
"model" "models\ tronera.mdl"
"angles" "0 -45 0"
"rendermode" "0"
"classname" "cycler"
}

So there are should not be any issues with weapons' names.

Cool, im rly interested how this turns out and i was keeping my eye on your mod for awhile now XD

Oh, I didn´t realized that it could be the problem, I will check all entities in the new zion map (this map has far less models).

BTW: I will install Xash3D this days to see how ZWC works with it, but, I have a question, should the explosions change?, I mean, are there new sprites or particles applied to the explosions that will take effect on a MOD?.

I say this because of tis pic I´ve seen:

Nope, Xash3D itself doesn't add any particle effects. They can only be a part of custom renderer with custom game resources. Also, this picture looks for me absolutely normal (for GoldSource).

Mmmm, It looks like if it was an upgraded explosion. :/

This is the list of models of the actual version of the Zion map. The other maps will not be present on the v2.0 of the MOD.
{
"compiler" "ZHLT v3.4 VL30 (Nov 23 2012)"
"mapversion" "220"
"defaultteam" "0"
"MaxRange" "24000000"
"skyname" "2desert"
"classname" "worldspawn"
}
{
"renderamt" "255"
"rendermode" "4"
"model" "models/soportes.mdl"
"origin" "0 0 -3318"
"classname" "cycler"
}
{
"angles" "0 45 0"
"renderamt" "255"
"rendermode" "4"
"model" "models/turbinas.mdl"
"origin" "0 0 -2411"
"classname" "cycler"
}
{
"renderamt" "255"
"rendermode" "4"
"model" "models/puentes.mdl"
"origin" "0 0 -2414"
"classname" "cycler"
}
{
"renderamt" "255"
"rendermode" "4"
"model" "models/center.mdl"
"origin" "0 0 -2414"
"classname" "cycler"
}
{
"renderamt" "255"
"rendermode" "4"
"model" "models/muelles1a12.mdl"
"origin" "0 0 -3112"
"classname" "cycler"
}
{
"renderamt" "255"
"rendermode" "4"
"model" "models/bordext.mdl"
"origin" "0 0 -2413"
"classname" "cycler"
}
{
"renderamt" "255"
"rendermode" "4"
"model" "models/argos.mdl"
"origin" "0 0 -2413"
"classname" "cycler"
}
{
"TriggerCondition" "0"
"spawnflags" "128"
"model" "models/porton.mdl"
"angle" "360"
"origin" "-2740.8 0 -2407.9"
"classname" "cycler"
}
{
"TriggerCondition" "0"
"spawnflags" "128"
"model" "models/porton.mdl"
"angle" "90"
"origin" "0 -2740.8 -2407.9"
"classname" "cycler"
}
{
"TriggerCondition" "0"
"spawnflags" "128"
"model" "models/porton.mdl"
"angle" "270"
"origin" "0 2740.8 -2407.9"
"classname" "cycler"
}
{
"TriggerCondition" "0"
"spawnflags" "128"
"model" "models/porton.mdl"
"angle" "180"
"origin" "2740.8 0 -2407.9"
"classname" "cycler"
}
{
"angles" "0 135.91 0"
"renderamt" "255"
"rendermode" "4"
"model" "models/crane.mdl"
"origin" "0 0 -2414"
"classname" "cycler"
}

This is the list of cyclers. fortunately I see that they have no spaces before their names.

Hi, tried Xash 3D ( Xash3D Version. 0.98 Build 3366) with some problems...

1st. The game has always gamma at full, and it changes also the gamma settings of my desktop, making almost impossible to see nothing

2nd. I can´t see smokes, beams, and glows.

3rd. Weird behaviour of the Nightvision mode

I must try the zion map with a true combat situation (I have tried on the zion_newlight.bsp version of the map, which I´ve done to test the lights of the map.

Probably it´s my fault, but If I can fix it and I can use as much of 2900 entities in my map, my MOD is saved!!

Make sure you have installed all files properly. Detailed guide is here:
http://www.moddb.com/engines/xash3d-engine/features/running-half-life-under-xash3d-users-manual-english

Gamma just have other settings than in GoldSource, so you should check Video options and set appropriate level with a corresponding slider. Or put in console "gamma 1.3", it's an average comfortable value for Xash3D.

Can't say what's wrong with Nighvision. It's definetly works for me, just maybe not so bright, like in GoldSourse, it's possibly can depend on ligthing settings in Xash3D, or it's just a gamma settings' effect. There are also some specific Xash3D's cvars which allow to adjust things like texture lighting, model lighting etc.

I've made entpatches for all maps and corrected model paths to load all models properly. Besides that I've found a couple of other issues.

1.

Error: No spawn function for sprites/lgtning.spr
NULL Ent in UTIL_PrecacheOther

Looks like precache error in dlls that can prevent to load lgtning.spr properly.

2. Those flying things can't damage me. It can be an issue of custom model (sentinel.mdl), maybe missing attachment or something else that the engine should discern as a contact point of making an attack on player. Or maybe it's a coding issue. Nevertheless GoldSource can manage with attacks without that kind of trigger, but Xash3D can't. I can try to check a model, but if it's a coding problem, I can't say anything.

HI!!. This is what my folder looks like:I don´t know if I should use another release. I have used another that directly does not show the HUD properly. BTW, the gamma settings didn´t stay, I mean, every time I start the game I have to adjust the gamma settings, and, worst of all, the settings affected the desktop gamma.This is how desktop looks like. There´s no way I can turn it back unless I start the game again and adjust gamma levels. But, no matter how I do it, gamma settings don´t stay.Nightvision works fine, the problem is that props don´t be lighted in red as before, but it´s not a real problem because the map will be illuminated in a better way as flames and explosions appear through the combat.

I will take a look to the dlls, but afaik, they are not modified in the way they precache basic things like the sprites... I will add them again to the main MOD´s folder.

Sentinels work fine, I forgot to mention that, maybe I´ve explained it bad
.

As I test this, I´ll post the results.

So, you still don't want to read the manual, that I linked? You don't have "valve" folder in your game directory, it's not how Xash3D is intended to work with Half-Life mods (with the exception of stand-alone mods, which already contain ALL files they need to work properly). You just put your mod directory here, that's why you've lost many files, which are necessary for your mod. Read the manual, really.

About gamma. Launch the game -> Set gamma to 1.3 via console or use that slider -> Quit the game normally -> Delete gamma.dat from your base directory (technically it should be "valve", but maybe you have this file in your mod's directory, "zwc"). Then you can go back to the game. Gamma on your desktop will slightly change when game starts. After normal exiting it will change back. If your game crashes, gamma will not change back. So you have to start game once again and quit it normally.

If you don't like that gamma affects your desktop settings, open file opengl.cfg in your mod's folder and find this inside:

setgl gl_ignorehwgamma "0"

Change "0" to "1". But the price will be that gamma in the game can't be changed as much this way, as with hardware method.

Oh, I have read the manual!!, I always follow expert's advices!! (sometimes my bad english makes me do things be like if I didn't), so I follow its advices and make sure that everything is on the zwc folder (checked twice, all things are there), maybe I checked the "read only" part on "properties", but I have unchecked this for the Xash3D folder and subfolders and will start testing tonight. I have gamma.dat on the zwc directory, but this file was read only (I'm sure this file is read only since the v1.0 release in 2007),probably this is what makes all things wrong with the gamma thingy; but now it isn't "read only" anymore, so I hope I can fix the gamma problem.

BTW: see what I mean with that my english is bad?, I misunderstood you when you said that sentinels didn't hurt you. I now understand that, in Xash3D, they don't do any damage to you. If you wish I can send to you the sentinel's source code, so you can see if there's a problem of compatibility with Xash3D.

Thanks for your patience

Hi again. I´ve finally done testings last night, the results?, here you are:

1. Gamma now works fine. I have renamed gamma.dat to gamma_.dat and now gamma setting stay normal after exiting the game.

2. Sprites now appear in game, I think that the "read only" flag was the culprit.

3. Console, before doing what you say (removing gamma.dat) showed all this crap......after that it now looks like this...4. Models are not rendered properly. Alpha channel swo an ugly black line (more or less thick) that ruins the transparencies of the models.5.I know muzzleflashes can iluminate a whole room, even they can be seen at distances of several kilometers, but I didn´t expect them to iluminate far zones of the map, which also look a bit weird, and does not look good. Look the wall beams being iluminated, that´s not supposed to happen, in GS doesen´t happen. Also look how the player model is lit, it is iluminated from below, like the flashlight trick that you do when telling horror stories!! XDIs there any way to make the renderer makes the game look like in the GS version?, I say that because I don´t like much how things are rendered, they look a bit ugly, lighting is not consistent, I mean , there are zones that look excessively lightened and others appear iluminated normally (see the pit pipes?, they´re ultra bright!). :/

Apart of that MOD works almost like a standalone game, only the two executables, the two dlls and the MOD folder itself, I love that.

I have to use the version of the map that contains the sentinels (I have to re activate the mostermakers and recompile all), so I can see what happen with their attack behaviour.

I think I can tell what is possible to do with all of those things you've mentioned only if I have a chance to test all issues on my own. Your mod is far from typical, so it's better to try the same beta-version that you use. Xash3D has extended lighting features, probably they should be disabled to give you GoldSource-like picture. Models can be edited to give them proper transparency (probably their rendering differs because of custom changes which you put in hw.dll, sw.dll, swds.dll, but it's a part of GS engine, Xash doesn't refer to them).

If you want I can send to you the version I was playing with, it´s not much "heavy" ( also, the MOD won´t be much different than already is now, It only lacks the adding of the new enemies and their code, which won´t modify complex things because they´re based on already existant code), and so you can test it without restrictions.

I have tried to make the "blue" parts bigger to cover the black parts, but they still look the same , maybe I should do some commands to the game´s cfg file?.

BTW, I didn´t modify hw, sw and swds.dll, in fact I have downloaded them to make the transparencies work with ZWC :/

Tell me if you want the ZWC game and I´ll send it to you ASAP, I wish to solve the max entities problem once and for all ^_^

For those who want to know: mod is officially ported to Xash3D, and now it looks like this:

http://www.moddb.com/mods/zion-warcry/videos

I didn´t read your post, point me to it, please!!. And I don´t lie, I swear it runs like that... Why should I lie?, even with FRAPS activated and a HUGE amount of polys now you can see in the video that v2.0 never goes below 46 fps even in very crowded situations, remember that fraps makes run any game 20 fps below its standards, it runs at 89 fps without fraps activated, the less value 65, and now sentinels, tower, bridges, etc. have more than three times those polys. I use sprite_cyclers because they served well to me until now, but if you say taht I should use env_models if I was wrong this years!!, I´m ager to learn!!

No, it crashes because it runs out of free_edicts, it happened when there are a lot of Bots and sentinels and bullets flying around, the game crashes also because monstermakers doesen´t stop of making sentinels and then the free_edicts issue comes. :), Maps compile perfectly with vluzacn´s Half-Life tools.

Hammer crashes with cycler_sprite just because the default halflife.fgd's cycler_sprite entity is set to render sprites only (hence why cycler_SPRITE).

To be able to load models with the cycler_sprite entity you need to edit the cycler_sprite line on the FGD as follows:

[quote]@PointClass base(Targetname, Angles, RenderFields) Studio() = cycler_sprite : "Sprite Cycler"
[

model(studio) : "Model / Sprite" : ""
sequence(integer) : "Animation # sequence (Models only)"
framerate(string) : "Framerate (Sprites only)" : 10[/quote]

Mmmm, that´s the answer, I never liked Hammer, so I used always QUark to make maps since year 2001, and I swear I´m using the same fgd and version of Quark that I used from 2004 to 2007 to make the ZWC maps, and the v1.0 maps have nothing but cyclers to show the map´s models :/

In fact, the only new thing I´m using is vluzacn´s tools, and only since february. BTW, I don´t know nor how to modify fgd files neither I did so in my life, I have just put what model I wanted in the cycler_sprite properties, in the cycler entity also appeard the flag model.

I don´t know if the 2004 version of Quark has the cycler_sprite with the possibility of using models added, but what I´m sure is that I am using the fgd that I have from a backup CD of the first programs I downloaded to make te mod, and I think it´s from the year 2004 or maybe 2006 not after.

Anyway, I will try to use env_models if with that I can make things work better, but, what´s the proper use of them?, I don´t want to ruin what is already done :(.

I will search my old betas and see if I´m wrong, but I´m 100% sure that when I satarted to use models instead brushes to do the bridges and all the stuff of my mod I used cycler_sprites, all because I have read about how to use them in a CS tutorial that teaches how to make the chicken of cs_italy.

If I´m mistaken, sorry, It wasn´t on purpose

Programs I´m using to make maps:

Quark_v6.3_snap042001

minipy15b

Why do they like to modify with models and sprites?

Because of the brush limit!!, yes I know that now you can use the func_detail entity, but in 2004 when I have started all it does not exist, and before I read about it here at TWHL half a year ago I make complex structures with Milkshape3D because to doing them I spent less than 6 or 8 hours, all without the brush limit problem, tiny brushes, leaks, bad scales of textures, etc, etc,etc. that make ZHLTools crash on and on, also, it is boring to make 12 separate textures and put them in a wad just to make a simple bridge!!, your map will result to be as heavy as the mount Rushmore if you use the nowadtextures comnand as I do, while all that could be done in a single bmp file in the modelling program...should I continue?. XD

Of course I must admit that I envy (envy corrodes me, I swear!!) what many of you mapers show us here at TWHL, but I prefer my method because it is the only way to make the things look like in the movie that inspired my mod, and because I tried making those things with brushes and, in 2004 and in latest betas in 2006, the result was ugly as hell.

Anyway, I'm glad you like what I've done

Oh, for making textures I use Photoshop CS!!, I was using PS since 1997 and cannot keep from using it, I'm so lazy to learn the slightest change in programs ^^

I have read a lot 'bout blender, and it is awesome!!, and which is better, it is free!!, but, I repeat, I'm a bit lazy and with MS3D it happen to me something similar than with PS.

Anyway, thanks for the information!!

Why do they like to modify with models and sprites? Thanks for nice explanations!

This trick has been first introduced by Turtle Rock Studios to make Counter-Strike: Condition Zero (and Deleted Scenes) maps by adding models with the cycler_sprite entity with the sole purpose of having models in the map without any sort of clipping, so that the level designer could create its own collisions on the models with brushes.
The cycler entity has bounding boxes, and if it would be hit with a weapon it would "bleed". Now think about adding a car model as a cycler entity and then the car starts bleeding everytime it takes damage. Not very realistic right?

Env_model is an entity that has more options, but the base has been taken by the cycler_sprite entity.

I don´t know nor how to modify fgd files neither I did so in my life

You can simply open an FGD file with any text editor program.

I don´t know if the 2004 version of Quark has the cycler_sprite with the possibility of using models added

It's not the editor that determines what entities you can use, but the FGD itself.
I could create an entity called func_b00bs that works exactly as (for instance) a func_door_rotating. I'd just need to copy the func_door_rotating flags in the FGD file and change its name to func_b00bs, and it will work perfectly.
That's why the new VHLT entities like func_detail or func_group works even without coding the engine, because it uses flags that already exist or that they can be used/mixed because the engine already support them.

Well, I am not able to find from where the fgd I used come from... What I know for sure is that it is almost 12 years old, lazy me for not browsing for a newer one! :/