porting kz_bhop_badg3s, a few questions

Hi badges, just a quick reply I think Immortal or Chuckles can help u with this.


1) It is indeed possible with a sourcemod plugin to pre-cashe particle systems, however it is not possible to remove them when the server changes maps. At some point with more maps that have particles the pre-cashe table becomes full crashing the server. The only solution would be restarting the server after each of those maps, to my knowledge this is not used/implemented by HOC (yet). Have to say that I would really like this feature tho, however the actual plugin is kind of buggy atm, and therefore don't expect many servers to have this feature.

http://www.pwnsource.com/tickets/particle-systems-precached-is-not-uncached-on-the-map-end
https://forums.alliedmods.net/archive/index.php/t-247897.html

2) don't know about the KZ servers, on the bhop servers this is not a problem, there are plenty of maps changing the gravity.

3)  
Most default bhop servers use the following settings
sv_enablebunnyhopping 1

sv_staminamax 0

sv_staminajumpcost 0

sv_staminalandcost 0

sv_staminarecoveryrate 0 

sv_airaccelerate 2000

sv_accelerate_use_weapon_speed 0

sv_maxvelocity 3500

Tickrate can be set with -tickrate 128 launch param, in hammer this would be somthing like:
-tickrate 128 -w 800 -h 600 +sv_cheats 1 +sv_airaccelerate 200 +sv_staminamax 0 +sv_staminajumpcost 0 +sv_staminalandcost 0 +sv_staminarecoveryrate 0 +sv_enablebunnyhopping 1

However you can not really bunnyhop on csgo locally because of the penalty that you get when you land from a high jump or after two consecutive bunnyhops. To solve this in CSGO sourcemod plugins are used, and therefore I also always test maps on a dedicated server with a bhop plugin. Furthermore HOC does not use the default settings, but those that are closer to CSS here I do not know the exact values.

http://forums.steampowered.com/forums/showthread.php?t=3207695

4) The KZ servers from HOC have 128 and 100 tick servers, overall i would assume 128 tick for a common server.
http://bans.houseofclimb.com/index.php?p=servers

----------- Edit -----------

just copied the console log of HOC2 as propsed by PLekz
sv_accelerate 6.5
sv_airaccelerate 100.0
sv_friction 5.0
sv_gravity 800.0
sv_enablebunnyhopping 1
sv_maxspeed 320.0
sv_maxvelocity 2000.0
sv_staminalandcost 0.00
sv_staminajumpcost 0.00
sv_wateraccelerate 10.0

 

KZ servers uses 100AA, not 2000. You can join any kztimer server (HoC2) and type !showsettings and all the settings will show up in your console.

Regarding #4, 90% of all servers use the KZtimer plugin, which has a setting enforcer option if that server wants to use global records, so all servers that run the global version are running on the exact same settings. Most on 128 tick, some on 102 and some on 64.

 

That is indeed a clever solution, ill try to keep the same notation when porting new maps, and ill experiment a bit to find out when such a limit is reached on a CSGO server.

 

The HOC servers now have a plugin that automatically reads particle systems from the bsp and precashes the relevant PCF files if the particle systems have names of the shape custom_particle_XXX. If some other notation has been used they can also be white-listed on a per map basis. This plugin is now also active on the regular servers such that these maps are shown in their full glory.

Regarding the limit of particle systems, after investigation it is true that there are not that many maps using them and hence the limit is probably never reached. Again thanks for the effort you guys put into perfecting these maps for CSGO.

 

Quick reply again, ill go more in depth some time soon

5) does this also show with a higher texture quality setting in ur menu
normally setting $nolod to 1 in the vmt will fix it, however i do still see a difference between quality settings in my menu. Ill experiment a bit in the following days.

"LightmappedGeneric"
{
"$basetexture" "logos/logoPiggies2"
"$nolod" 1
"$translucent" 1
}

6 + 7) thats the lighting i was talking about thats just different in CSGO, up to this point i am unsure how to fix it properly. Therefore i always compile CSS maps in CSS hammer and NOT in CSGO as long as that is possible due to triggers etc. So whenever some crouch gap is for example too low (cuz csgo character is taller) ill try to fix that using CSS hammer. Most maps will just run fine in CSGO if compiled in CSS hammer, as long as u don't set the player's classname, have all crouch heights 64 units tall, and make boosters with func_push or set_gravity. Sometimes i use an entity editor to edit the compiled CSS bsp a bit such that it works in csgo, by adding for example a shadow_control entity, or removing triggers. ill do some more research on how to make it similar in CSGO to CSS but at this point i don't have a clue.

In CSGO u have dynamic shadows + the prebaked shadows from vrad, thats what u see there, why it moves could be that at that point the dynamic shadow transitions to the static vrad shadow. Try using a shadow_control with the same direction as ur normal sun light, and then increase the Maximum Distance property (or decrease). Alternatively u could try to put a info_no_dynamic_shadow on that wall that disables all dynamic shadows all together and only use those computed by VRAD.

8) yes this is the limit, however it is possible to download the full bsp if >150 mb, so it just takes longer and takes up more bandwidth. really annoying tho, we try to make maps < 150 mb if possible, even if this means we have to replace water + skybox for example with CSGO default versions that look similar. Overall dont mind this limit as i already said it just takes longer to download because u have to download the full size bsp from the fastdl.

Gz eddy

 

Hi tony,

yeah that map is on HOC test server and will be rolled out soon, and yes you're particles are working fine there.
futhermore we are just testing the particles atm that it does not lag the server or any of the clients. The problem is that after X maps with Y particle systems, that if the map changes the clients still try to load those systems which are not present in their current BSP (cuz of the valve bug) this then introduces a large list of vmt files that cannot be loaded (ak errrors in the console upon connect) so i guess its no problem however its still in testing phase just to be sure.

PS, i saw immortal already beat me to it

 

"I just finished porting Aokis xc_tones, for anyone interested - http://csgo.gamebanana.com/maps/185693"

Thanks, I'm adding xc_tones to the Test server this morning. Does it / will it support Global times?

 

I'm not sure if Immortal has any idea why this happens, I feel like it was caused by something on our end, since the time tracks on yonkoma used to work fine on csgo.