Jump to content

arramus

Members
  • Posts

    2,208
  • Joined

  • Last visited

  • Days Won

    14

Posts posted by arramus

  1. 5 hours ago, magejosh said:

    Really excited to see these new zombies in action. Just installed them on my server when I went back and noticed the research camera addon in the first post. Is the base mod right above it just the zombie mod i got from github or something else?

    The github top top link is for the latest October A19 compatible build. This is just the Custom Zombies 'base mod' without the camera addon.

    https://github.com/arramus/Snufkin-CustomZombies-A19.2-b3-2020Oct10

     

    Snufkin's original base mod is here on dropbox and again it is only the Custom Zombies but it isn't the updated version and works on older builds on the game. (April/May 2020)

    https://www.dropbox.com/sh/3jr3t4shjxyg3lr/AACyUpKQQqFv4h-Y2DlHqBR4a?dl=0

     

    The research camera addon was built for Snufkin's original base mod for April/May 2020 and is here.

    I haven't tested it on the A19 update from github and if you try it pleeeeeeeeeease share your feedback so we can see how it gets on.

    https://www.dropbox.com/sh/6rzg5q1kmf180j7/AABfe5T0a8cN24ekggVjt8Wea?dl=0

  2. On 10/13/2020 at 7:53 PM, lasse11121 said:

    Thanks man!

    i still need to understand how GS work, can i only set feralhordestagegs1, gs 30, gs50 etc or do i not get any bosses if say i have gs 26 ingame? and do u write all the stages by hand or do you generate it?

    i have testet maxcount in entitygroup and it doesnt work. so now i am trying this in spawning:     

     

    <append xpath="/spawning/entityspawner[@name='NightHorde']">
            <spawn maxcount="1" respawndelay="1" time="Day" entitygroup="yourbossgroup" />
     </append>

     

    but do you have a tag for the all bosses, or how do i create one?

    also this respawndelay, what does value 1 means?

     

    GS

    I believe Snufkin did a combination of copying over the default from the game and editing it to the mod as it does share the same patterns. Either way, it can be a long and arduous process and I certainly appreciate the base one provided.

     

    You will get a boss even if your GS is not exactly the same as the one in the list. You will get the boss from the GS number that comes just below your personal GS.

    An example:

     

    1. GS 22 - Scarecrow (only the Scarecrow from GS 22 to gs 27 but he will appear for 23, 24, 25, 26, and 27)

    2. GS 28 - Scarecrow / Archon (both the Scarecrow and Archon from  GS28 to 32)

    3. GS 33 - Archon (only Archon from GS 33 to 38 as the Scarecrow takes a tea/coffee break)

    4. GS 39 - Scarecrow / Archon / Undertaker (from GS 39 onwards until the next listing is this trio)

     

    However, if a friend suddenly joins you and you battle together as a party, you will see a combined GS group. It is calculated on a few factors and will not just be a combination of your two current GS values added together. It also rounds things down. More on this can be found in the explanation added to the '7 Days To Die\Data\Config\gamesstages.xml' in your default game folder. Regardless of how this works, it makes things more of a challenge to accommodate both players but still keeps a balance.

     

    SPAWNING

    Any group you make in the spawning.xml file will require a partner group list in the entitygroups.xml to match conformity. And yes, this entitygroups.xml list will require a complete list of all the Bosses you want to introduce. The tag for the bosses is exactly the same for all other groups in the list with the boss name applied.

     

    Example from Snufkin to show the match:

     

    spawning.xml and its associated entitygroups.xml code for a totally new group made by Snufkin just built for this mod.

    <append xpath="/spawning/biome[@name='wasteland']">
      <spawn maxcount="1" respawndelay="1" time="Night" entitygroup="ZombiesWastelandNightHard" />
    </append>
    <append xpath="/entitygroups">
    	<entitygroup name="ZombiesWastelandNightHard">
    		<entity name="zombieFarmer" prob="0.3"/>
    		<entity name="zombieStripper" prob="0.3"/>
    		<entity name="zombieUtilityWorker" prob="0.3"/>
    		<entity name="zombieNurse" prob="0.3"/>
    		<entity name="zombieSteveCrawler"/>
    		<entity name="zombieFatHawaiian" prob="0.3"/>
    		<entity name="ZombieUndertaker" prob="0.01" />
    	</entitygroup>
    </append>

    Based on my experience, respawndelay is the amount of time it takes in seconds for a new zombie to appear after the last one is eliminated. If you set maxcount="2" respawndelay="2.9" then it should follow that 2 bosses/character will always be present and they will respawn every 2.9 seconds to fill the maxcount gap when one is eliminated.

  3. 7 minutes ago, Slawa said:

    Vulcan works now and the link above is updated. Thanks goes to @oakraven :)

    Kronos still left (visual bug/invisible sometimes).

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

  4. On 9/23/2020 at 5:54 AM, Slawa said:

     

     

    Hiho, can you try to fix it again for 19.1? They work but a few has a visual bug. 

    Would be nice 😃

    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.

  5. 10 hours ago, lasse11121 said:

    Okay i see, i just tried puzzling with the mod, but cant seem to make it work, maybe you could help me? 

    i am trying to get only 1 of the bosses spawn on the horde night. so i tried this code: <entity name="zombieScarecrow" prob="1" maxcount="1"/> at gamestage 62 as i was in game. but no bosses showed up everyone else was set to prob=0.

    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.

  6. 49 minutes ago, lasse11121 said:

    Haha Sounds insane XD, we didnt had any changes to the mod, so day 5 horde night, game stage 39, we had like 10 bosses at the same time doesnt really work with lvl 2 hunting rifles :D

    This is just what i needed to understand how to change it, thanks a ton.

    This mod also changes the normal zombies or?

    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.

  7. 14 hours ago, lasse11121 said:

    Hi i love this idea of the mod with bosses, but could it be possible to have only 1 boss at horde nights so it gets more special and awesome loot in maybe buff health on them?

    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.

  8. 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.

  9. 17 hours ago, TomGun42 said:

    Hey all, ive enjoyed this mod for some time in our server, ive edited the xml myself and created more zombies from it. If interest let me know. Ive just added the archon files to the files I have.

    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.

  10. 2 hours ago, BubbaJoe said:

    Is this under the original <extends="zombieWightFeral"> or the changed <extends="Zombie_Template"> you were testing? Just want to make sure I'm not tinkering with the wrong things. 😄

    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.

    6 hours ago, Robeloto said:

    Remember to apply the new buff over the old(buffShocked) ones in Entityclasses.xml and Items.xml.

    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.

  11. 3 hours ago, h0tr0d said:

    It's the ranges and sphere attached to the hand items.

    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.

     

     

     

     

  12. 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:

    20201009133926_1.thumb.jpg.4f382cc943ccf5f3e9b0a56b8e7c114e.jpg

     

    Which in turn causes looped warnings, for the client and the server, and has been noted to be detrimental to performance:

    20201009133944_1.thumb.jpg.a012de538c5084e236dab7eebc1d3bae.jpg

     

    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.

    20201009133044_1.thumb.jpg.b6b2b40a8787b1cc28559c88e75794e7.jpg

     

    Which in turn allows for no console warnings.

    20201009133417_1.thumb.jpg.5503446242758e9c9c4a43c48665bdc4.jpg

     

    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.

  13. 9 hours ago, BubbaJoe said:

    Just as a question for arramus and everyone else. Is anyone else having issues with the Archon not using its melee attack very effectively? What's happening is the Archon is aggroing a player and descending toward them like normal, but it just sort of twitches around their player model and really ineffectively tries to melee them. Most of the time it never even manages to hit them with melee, it just kills them via its projectile attack (used at close range) instead. I tried increasing the range of the melee attack for the Archon as I had tested this with good results on the Siren and the Geist, but it doesn't seem to be changing the Archon's behavior. I understand it's part of the core zombie AI to zero in on a player's exact position, even if the zombie has a projectile, but the Archon seems to be doing this to the exclusion of using its melee. Trying to figure out if this is something wonky I've done or if other people are experiencing this.

    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?

  14. 1 hour ago, Snufkin said:

    ...the Archon was intended to act as a support zombie in the Bloodmoon (I was inspired in the Archvile from Doom, that besides being able to set you on fire could also revive enemies).

    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.

  15. 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.

  16. 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.

  17. 20 minutes ago, BubbaJoe said:

    After reading your initial post about the Juggernaut projectiles I did some playing around with those as well. I definitely agree with your findings on the vehicle debris, not only were those throwing the most warnings in the console, players were reporting the biggest hits to performance on their end too. After some solo testing I opted for Value 6 on the projectiles and that's probably what we'll stick with. It's nice that such a small tweak adds so much customization! We're also running Slawa's "Baby Juggernaut" which we've assigned different values for, mostly because on our server we've turned the big Juggernaut into a mostly indestructible death machine that can level entire POIs in short order, so testing these tweaks via the Baby Juggernaut has been easier for the players to handle. 😅

    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. 😜

  18. 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.

    20201008110608_1.thumb.jpg.48b558a6ad0efcdab08cea66e5ff47ce.jpg

     

    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.

    20201008110437_1.thumb.jpg.674d01973aa4c04ce3ed665bd5be9591.jpg

     

    The effect is just as devastating and causes player shock.

    20201008110424_1.thumb.jpg.bbaad5343e389865117b967462beb232.jpg

    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.

    MeshIssue.jpg.e7bba1218bd77e56f5cf89d5b6a25c80.jpg

     

    Post-change

    MeshIssue2.jpg.9b60cc6a6a2233ca698ebbffd0759f37.jpg

     

    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.

  19. @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.

  20. @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.

  21. 1 hour ago, xxx73 said:

    hehe great work @arramus
    Im following your work on old bomber from StompyNZ and I like what I see, any chance you will release this fun guy when done?

    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.

  22. 5 hours ago, Robeloto said:

    Tip: If you switch the "p_onFire" particle to "p_fire_small" the console will not spam yellow errors when they hit the ground. They aren't as beautiful, but that is one solution atleast.

    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.

    20201007181955_1.thumb.jpg.0dd5c9a5cfe1f63bf56dab539c5fd440.jpg

     

    20201007181945_1.thumb.jpg.efb3e183fecec1de69906341009be8de.jpg

     

    20201007174806_1.thumb.jpg.5e38858421f0485e309f7ec53119bfa7.jpg

     

    20201007184033_1.thumb.jpg.78372b0caa711b5454d8f2e32434ea8f.jpg

  23. 21 minutes ago, Robeloto said:

    Tip: If you switch the "p_onFire" particle to "p_fire_small" the console will not spam yellow errors when they hit the ground. They aren't as beautiful, but that is one solution atleast.

    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.

×
×
  • Create New...