arramus

I shall try them out this instance - And I certainly did. Everything you set out to do looks great. Very functional indeed and I am so ready to try the Gamma Gun in a dual with a feral zombie cop.

The pair of you are really bringing this together. Just that Kronos. Interesting code onSelfPrimaryActionUpdate and a good find. Good tracking!

Hey Slawa, I checked out the mod and see what you mean about visual bugs. It's as if some of the prefabs in the buffs, entitytypes, and items xmls are not attaching or not attaching and remaining attached. The buff code for this mod and the vehicle code appear to be slightly different for checking and updating while the items and entityclasses entries do not appear to have any checking code to double check things are being applied. Maybe A19 is not performing the prefab incorporations as well as it could be for mods. The vehicle code may need the occasional vehicle to be picked up and placed again for the first instance but after that it seems to hold well. The weapons could occasionally appear properly but this was the exception. I could see: - Unknown particle effect for the m60 (Rocket launcher icon weapon) - Railgin, PP-19 Bizon, Polearm, Vulcan mesh prefab is not applying I couldn't duplicate the error from your image but wasn't sure what weapon/ammo action it related to. Can you add a list of all the weapons and issues you are aware of so we can see where things need looking at? Such an awesome mod overall and it would be great to restore. It looks like oakraven made some great strides to get it going again and updates may have introduced some new challenges.

Try this one. lasse11121_entitygroups.xml with it renamed to remove your username. This is just an edit of one I'm testing now with a few deleted in batch using Notepad++ to get just the Scarecrow listing. It covers the whole list of game stages but the default settings related to the GS you're close to look like this: <append xpath="/entitygroups/entitygroup[@name='feralHordeStageGS59']"><entity name="zombieScarecrow"/></append> <append xpath="/entitygroups/entitygroup[@name='feralHordeStageGS64']"><entity name="zombieScarecrow"/></append> Not adding any probability at all gives the Scarecrow a 100% probability of spawning in rotation with the other default zombies for that gamestage. I didn't add a maxcount setting because it is typically taken care of in the spawning.xml or serverconfig.xml (for BM) files for the whole group. I have never attempted to use maxcount="1" in the entitygroups.xml for an individual and your feedback on that will be helpful if it noticably keeps things balanced in case a group of scarecrows overwhelmed the horde numbers. As BM count is based on each individual player it will be good to note if that maxcount="1" applies to everyone or each individual.

The normal zombies will have their own regular default settings based on the standard game files, although there is one more useful action you can take in entitygroups.xml At the top section, you can see a variety of groups that will spawn in specific biomes during the day and night along with their probabilities. By using <entitygroup name="ZombiesWastelandNightHard"> as an example, it's possible to increase the challenge. For example, change <entity name="ZombieUndertaker" prob="0.01" /> to <entity name="ZombieUndertaker" prob="0.1" /> to increase the chance of spawning from 1 in a 100 to 1 in 10 for its own individual chance of spawning within the parameters of all the other zombies in the list as well. And to spice things up even more, add <entity name="zombieDemolition" prob="0.3" /> to the bottom of the list and this will allow the Demolisher to pay you more frequent visits during non Blood Moon gameplay. Ya, as BubbaJoe says, tweaking these settings can really mix it up and keep your server regulars content. I like to drop the BM block damage down to about 75% but increase the probability of hard hitters proportionally so that the base remains about the same while only the players are going to really suffer.

1. For the purpose of spawning one boss during a Blood Moon event: This is possible by manually editing the entitygroups.xml file. There is a long long section at the end which specifically tells the host what to spawn, when to spawn it, and what chance of probability it will have to spawn. For example, in the very first line: <append xpath="/entitygroups/entitygroup[@name='feralHordeStageGS1']"><entity name="ZombieArchon" prob="0.1"/> This tells the host that during a Blood Moon, for Game Stage 1, the Archon character has a probability of about a 1 in 10 chance, in relation to itself and the whole default game list of other zombies, of appearing. You can delete and edit entries in this list to specify which single special zombie you would like to appear. 2. For the purpose of ensuring the selected boss zombie drops special loot: This is possible by manually editing the entityclasses.xml file. If you look under the <entity_class name="ZombieArchon" extends="zombieWightFeral"> area, there is a property with the following properties. <property name="LootDropEntityClass" value="EntityLootContainerBoss"/> <property name="LootDropProb" value="1"/> The game already appears to feature a loot drop option. In this case, Archon will drop a 'boss' type loot offering at a probability of once (100%) when eliminated. A setting of 0.5 would be 50% of the time. 3. For the purpose of buffing health on the character: In the same area as for number. 2, but further up, you will see. <passive_effect name="HealthMax" operation="base_set" value="2000"/> Changing this value allows us to specifically set a character's health. 4. If you are going to buff the character's health you may also want to give players more XP for completing the elimination: In the same area as for number. 2, and just below you will see. <property name="ExperienceGain" value="5000"/> This property can be changed at a level proportional to the increase in health to maintain balance. If there are any errors in this short instructional, I'm sure other community members will provide corrections. All the best with your tweaks to customise the settings to your liking.

Here is the recent update based on feedback from the community. https://github.com/arramus/Snufkin-CustomZombies-A19.2-b3-2020Oct10 As Snufkin's Custom Zombies acts as a base mod, it is kept as close to the original as possible. Community members have added, or are in the process of adding, their own expansion builds which will be added to the main introductory post for the base mod. Community expansions will take the base to new realms and offer the community additional variety. However, Snufkin's Custom Zombies as a stable base will always be there . Changes for this build were as follows: 1. Archon Particle for the projectile While this was not a mod breaker, it does cause server console warnings to produce in a constant loop and this creates instability. The effect is 6 individual balls of fire instead of the full volley. - items.xml name="ammoProjectileArchon" Changed the following property to a comment and updated it to an alternative particle effect to avoid mesh warnings when the projectile is active. <!--property name="Meshfile" value="particleeffects/p_onFire"/--> <property name="Meshfile" value="particleeffects/p_fire_small"/> 2. Archon melee capabilites - items.xml <item name="meleeHandArchon"> Melee settings were tweaked with the following properties as the close proximity melee attacks were inconsistent. This change brings Archon more in line with Geist. <property name="Range" value="1.75"/> The original parent was set at 1.65 and based on a different model type. This now gives Archon a strike arc that changed from about 30 degrees to almost 180 degrees. Archon was designed as a support character for his minions and typically stays more in the background. This just gives him a little more of a fighting chance when he comes into close proximity with a player.

There will certainly be interest from server hosts who like to mix things up and keep the experience going. If you were to bundle up everything you've created, give it a name with all the creators credited appropriately, and upload it, we can add it to the link with the base mod. Slawa has created something special by integrating the Custom Zombies, some of Roboloto's collection, and Slawa's very own creations. It looks like you have followed a similar route. Basically, we'll have the base mod from Snufkin which is as close to the original as possible with as much stability as we can incorporate. On top of that are community versions that expand in their very own way. Doom has been around for a long long long time and continues to follow this successful model. BASE - Snufkin's Custom Zombies EXPANSIONS - Slawa V.3 (Expansion) EXPANSIONS - TomGun's Terrors (Expansion) This will stay true to Snufkin's concept but still allow the community to experience variety. This can become a recipe where everyone is a winner. Naturally, it will be important for server hosts to experiment with what combinations maintain stability just as with any other mods.

Hey BubbaJoe, I ran an experimental with the Archon by changing <property name="Range" value="1.65"/> for its hierarchical parent to <property name="Range" value="1.75"/> and could feel a lot more hits making contact from a 180 degree arc which is the same as Geist is capable of. I'm going to upload these from now. For your reference, the change was added in: items.xml <item name="meleeHandArchon"> and <property name="Range" value="1.75"/> was added just underneath <property name="Magazine_items" value="ammoProjectileArchon"/> so that it's grouped together with 'familiar' properties. Thank you Robeloto. This is a new expression of coding for me to learn about and I have some homework to do. Sharing this with us all is very valuable and, I for one, sincerely appreciate it but I know others will as well.

Thank you. For the current parent of Archon, meleeHandMaster, the default goes up the hierarchy (including dev comments) to: <property name="Range" value="1.65"/> <!-- This not what "clientside melee combat" means. 😃 This is the adjustment afterwards due to code changes. --> <property name="Sphere" value=".1"/> Tweaking and results to follow. Once this is appropriately balanced to correspond to other characters it should create a level of conformity.

Just in case any Custom Zombie users were also following the Custom Vehicles thread and want to test them out for stability or add your own touch.

In the interests of further enhancing server and client stability and to reduce overheads which members in the community noted can cause lower end systems to suffer, here is a test of the Archon projectile moving over to the same particle effect that the Scorcher has already received. The description of the Archon is that he launches 6 fireballs and this will stick closely to the original concept. Using the current setting of particleeffects/p_onFire, the effect is certainly 6 firewalls and they are in a repeating volley. As thus: Which in turn causes looped warnings, for the client and the server, and has been noted to be detrimental to performance: The alternative setting of particleeffects/p_fire_small as is already implemented to solve the scorcher audio issue appears as: A launch of 6 single fireballs. Which in turn allows for no console warnings. While not critical at present, this seems to be a decent update for the next release. @BubbaJoe is also just tinkering with the Archon's melee settings which, while certainly not his primary weapon, could be tweaked a touch to increase impact performance. Archon's role is generally to sit back, buff his minions, and fire projectiles when appropriate which he does ever so well. However, it would be helpful to just give him a bit more of a fighting chance up close. This mod is incredibly eclectic in nature and incorporates so many wonderful combinations. As such, these things can inadvertently be introduced. The trade off is something incredibly special and the reason for the restoration in the first place. Too good to waste.

I tested both in client host and dedicated server host and could replicate the melee attack limitations. Archon is good when exactly in front of the player at about chest height. His limitations come from when his arc of attack falls outside a 30 degree or so angle from in front of the player. Not only that, but also the height is also an important factor. Maximum melee efficiency comes right in front of the player while Archon's feet are about player chest height. Anything out of that specific location can register a null hit. I think the major culprit is the entity class extension. By switching from entityclasses.xml entity_class name="ZombieArchon" extends="zombieWightFeral" to entity_class name="ZombieArchon" extends="Zombie_Template" as is common for Geist, I could move around Archon and his hits were making better contact from a wider arc. This will bring its own issue of probably needing to make a new Archetype if it's no longer applied to a specific character. Can you also try this initial change to see if it brings a change in the melee range and efficacy?

Interesting. Yes, I can recall the Arch-vile would sit back in the background and attempt to prologue its own existence while acting as the healer. We would specifically have to take him out to weight the odds back in the players favour. The addition of the Archon's potential to retreat adds to that trait and extends his presence. He is a cool support character and with the concept in mind has more of a background role while the frontline Z take on a very aggressive role.

Interesting. I shall spend some more time checking on this as it hasn't been a priority so far but is an important game feature. The only major comparable points between Archon and Geist seem to be the character they extend from and given model type and Archon's probability to retreat when hurt.

Just something for the future. xcostum_Villa (by Topminder) is looking superb but after being unable to initiate a fetch quest I took a peek in the editor. It didn't display any satchels or a rally marker although the game could at least set up the rally marker at ground level as it sometimes does. Almost a week with over 60 quests and also getting feedback from other server buddies and this is the only one we've been stumped on.

Yes, something like that on lower end systems may be all it takes if calculations get a touch overwhelming. You went for 6! I love that effect. And that's the beauty of this mod, server/client hosts can tweak the xmls to fully customise the experience and there will always be someone here to answer questions while they build their knowledge. If I knew how to randomise 2, 4, and 6, I would. 😜

Updated to Snufkin_CustomZombies_A19.2b3_test_2020Oct08 with stability in mind. Here is a link for the update. https://github.com/arramus/Snufkin-CustomZombies-A19.2-b3-2020Oct08 This has also been added to the thread post linked to from the opening post by Snufkin. This update has 3 changes for issues and a potential issue. 1. items.xml - Scorcher name="ammoProjectileScorcher" Changed the following property to a comment and updated it to an alternative particle effect to avoid looping audio at the point of origin when the first instance of a projectile was triggered. <!--property name="Meshfile" value="particleeffects/p_onFire"/--> <property name="Meshfile" value="particleeffects/p_fire_small"/> Just catching the tail end of the regular streaming barrage. The flow has a higher density. 2. items.xml - Geist name="ammoProjectileGeist" Changed the following property to a comment and updated it to an alternative particle effect to avoid looping audio at the point of origin when the first instance of a projectile was triggered. <!--property name="Meshfile" value="particleeffects/p_electric_shock"/--> <property name="Meshfile" value="particleeffects/p_electric_shock_small"/> The effect in game is a subtler plasma state. The effect is just as devastating and causes player shock. 3. items.xml - Juggernaut Changed the following property to a comment for the time being as this can cause potential issues when a player is being attacked while inside a building in a confined space as the Juggernaut is on the outside. It can lead to debris passing through solid walls. The explosion particle has changed from vehicle debris to the standard rocket blast. <!--property name="Explosion.ParticleIndex" value="4"/--> <property name="Explosion.ParticleIndex" value="5"/> The effect of these changes for server hosts is as follows. Pre-change using Scorcher as the test subject. Post-change Thank you very much to members of the community for your valuable feedback and tips/hints/advice as the pooled effort brought a quicker turn around on a tentative fix.

@BubbaJoe You went far and beyond with your methodical checking and put a lot into clarity. It looks like this type of change is a known issue and Slawa has implemented in using a preferred method. I also know Roboloto uses the alternative fire particle as he suggested it for another zombie which has flames railing behind him. The small electric particle has lost some zap but still applies shock and it will work as a temporary fix until otherwise. Archon is very special in that the particle doesn’t cause the same issue and no need to change what isn’t hurting. I’ll add a patch and get these released. The additional change will be for the Juggernaut projectile to change from vehicle debris to regular rocket effects. I tested him a lot while inside a building and as he attacked from outside, based on feedback, and in confined spaces any vehicle debris was quite invasive and upset the game physics with warnings. A lot for the server to calculate and cause for potential crashes. For the future, it would be nice to know the cvars for the particles and projectile impacts to set any looping to false and turn off collision with the biome terrain so they don’t interact. For now, these patches will at least keep stability and reduce gameplay annoyances.

@h0tr0d @BubbaJoe @Bisawen Attempting to isolate the issue with Scorcher and Geist's looping particle sound at their initial projectile activation point has been a real test... The first approach was to compare Geist, Scorcher, and Archon, as Scorcher and Archon share the same fire particle, whereas Geist has the electrics. Archon was working just fine, in my case, and I couldn't spot any anomalies. However, changing Geist and Scorcher's particle effect has worked for me. For Geist, changing from: items.xml <item name="ammoProjectileGeist"> <property name="Meshfile" value="particleeffects/p_electric_shock"/> to items.xml <item name="ammoProjectileGeist"> <property name="Meshfile" value="particleeffects/p_electric_shock_small"/> has seen a positive result with the sound not looping. However, going from full on concert electrics to only touching an electric fence on the farm, well maybe weeing on it, has been a bit of a step down. BubbaJoe suggests this isn't an issue and I wonder if this is related to our rigs/set up environment. For Scorcher, changing from: items.xml <item name="ammoProjectileScorcher"> <property name="Meshfile" value="particleeffects/p_onFire"/> to items.xml <item name="ammoProjectileScorcher"> <property name="Meshfile" value="particleeffects/p_fire_small"/> has seen a positive result and actually looks decent. With all the recent changes, it's quite possible these particles got revised and introduced further issues. I hope you can apply this code to your own items.xml files and report back your own attempts. If you could see if the Archon is OK and not causing a loop even though it has the particleeffects/p_onFire property it would be helpful. I shall also test this new setting with Archon as see how it looks.

Of course, you are welcome to have these files right now. No need to wait He is still built into the larger mod with all the other characters at the moment. For the future he can be separated as a single entity and renamed so he doesn't conflict with other mods. The only changes I made are as mentioned above. Are you good to: - Separate him as a standalone. - Rename all the relevant areas. - Apply all of StompyNZ's previous assets? Maybe giving him a totally new name would work.

Once again, thank you for the tip. This particle fits the concept very well and is closer to the original. With a few tweaks, the flame has been rotated to trail the bomber and has also been moved down to match that starfish exhaust region. It is ever so slightly away from the body as well to give it that licking effect. However, all this is purely experimental as @xxx73 will have the final say. Here is the code and explanation. buffs.xml <triggered_effect trigger="onSelfBuffStart" action="AttachParticleEffectToEntity" target="self" particle="p_fire_small" local_offset=".3,0,-.2" local_rotation="270,0,0" parent_transform="Spine"/> <!--Robeloto's Tip--> local_rotation="270,0,0" - The 270 reflects degrees around the point of origin on a horizontal plain. The attachment was initially coming from his side. local_offset=".3,0,-.2" - This reflects moving slightly down the spine to the starfish and also a negative value to draw it slightly away from the body. entityclasses.xml <property name="Explosion.ParticleIndex" value="5"/> <!--Rocket Particle Exploding / 6 was default--> This just adds a 'little' more Kaboom. A few pictures to demonstrate the effect. What a coincidence to be located here.

Great tip Robeloto and thank you. This may be exactly what the effect needs and will make @xxx73's day as this has been a long process to restore. I can't speak for Snufkin's opinion of course, but Slawa has compiled some of your characters, Snufkin's characters, and some self created characters into a Custom compilation mod with full approval.

I tested scaling the Cowhead and while he does scale up, so does his floating distance from the ground and he looks odd as he walking on air. The alternative is to scale down the Cowhead skull if it's hard to get that looking right. I looked for an attachment scaling command for buffs and can't find one in default files or online. I also looked in the block files for the Cowhead to see if it can take a broad scaling property which would impact every instance though. <block name="decoCowSkull"> <property name="Extends" value="decoEntityPolymerMaster" param1="RepairItems"/> <property name="Material" value="Mrubble"/> <property name="MaxDamage" value="100"/> <property name="Model" value="Entities/OutdoorDecor/cowSkullPrefab"/> <property name="HandleFace" value="Bottom"/> <property name="FilterTags" value="fdecor,fother,ffurniture"/> <drop event="Harvest" name="resourceBone" count="1,4" tag="allHarvest"/> </block> I shall test some more on this. Scorcher occured just locally on a client SP, while the Geist occurred on a dedicated server.

This has been applied to Snufkin's Bomber which is utilising the same exploding cop principle as the suicide bomber. Applying the original archetype values from the original creator gets the cosmetic look about him. Replacing the buffs.xml barrel entry with this entry from the game default files and a body placement value from Snufkin's settings gets something, but it may not be as pretty as you hoped because that particle looks like it changed over time. <triggered_effect trigger="onSelfBuffStart" action="AttachParticleEffectToEntity" target="self" particle="p_onFire" local_offset="0,.1,-.2" local_rotation="0,0,0" parent_transform="Spine"/> It's something from nothing though and you've definitely waited a long time for something and can now tweak to your heart's content. Once again with updates, the issue was a change in syntax and formatting. All the best in there. Thanks Bisawen. There's a similar comment a few posts up and it's way up there on the list of to dos. Geist killed me earlier and the sound followed my player whereever I went after respawn... Now that was annoying and I had to leave and come back again.