arramus

For the silencer, removing the noSilencer tag from the Hyper Blaster tag will place it in the first location on your image. This is a Snufkin weapon, and out of consideration for his original concept, it was left as close to its original state as possible and will remain this way unless he requests otherwise for where it is currently packaged. However, feel free to share your end result and methods as that was always something Snufkin promoted with his mods.

As for the scope(s), there will be something specific connected to the Hyper Blaster in the item_modifiers.xml which governs placement settings.

I can appreciate the reason you are considering this action to possibly increase availability. I'm guessing it's not to lower the limit. I posted this elsewhere to a reasonable comment, and just overlooked others as they were a 'touch' unfair relating to the SPIFSAL update. I hope you'll read it and consider it, and if it doesn't work out, I'll be the first to assist you with your request. -------------------------------------------------- This is a very fair and understandable comment. The first release candidate of SPIFSAL was tested thoroughly over a prolonged period of time to check the impact on a wide range of dynamics (logical progression linked to GS, overall challenge and core needs, fun factor, ability to play solo, existing additional Wasteland gains beyond Vanilla, etc). The feedback was that there were a few primary areas that could do with placing a little earlier on the SPIFSAL list to allow them to be more accessible. This was in consideration of fundamental activities that are critical to survival, particularly in early GS. However, adding ALL of what we have become accustomed to as being fundamental in the Vanilla build, into the 21 would make SPIFSAL redundant and go against where it can be most appealing, especially because a number of these suggested 'fundamentals' compound (Miner 69er-Motherlode / Master Chef-The Huntman-Living off the Land). This current release is a balanced compromise. After testing this current build with a variety of trade-offs, there are 3 clear modes of play that stand out: - A balanced load out. This was carefully calculated to available SPIFSAL and gives the player access to most, but not all key survival elements. Players can thrive from very early GS. In fact, they can reach Skill levels quicker than in Vanilla for many traits and this may come as a surprise. Players new to the Wasteland Mod will recognize these choices when choosing SPIFSAL and this can provide them with a sense of security and familiarity to ease them in. More experienced players may also prefer this load out for what it offers. - Semi-balanced load out. This still offers many primary survival features, but players will need to be more considerate of where they will need to put in a bit more work. The trade-off will be that specialization that can make all the difference in certain situations. And players can manipulate their game-play to increase these certain situations. - Specialized load out. Players who really want to be a master of some very specialized feature(s) will feel the challenge in primary survival activities early on and will need to adapt. However, once established, those specializations will be clearly useful, and some may say excessively useful. On top of the SPIFSAL 21, we are going to find the additional statues to give a permanent +1 to each attribute. As players test a few load outs, they may reconsider that initial SPIFSAL 21 in the knowledge that these statues are to come, and possibly at a time when they are more relevant. In addition, 'time' sensitive or 'inventory' sensitive items will also provide those attributes, as players have become accustomed to in Vanilla, as well as the unique ones we can find in the Wasteland, such as 'Happy-go-Lucky', 'Braintats', and their cousins which I won't mention so as not to spoil the surprises. Players will see how these additions can be used at the right time and for the right purpose when they are most needed. And with all the Wasteland 'health' drinks from Nuka, customized items, custom general weapons and ammo, abundance of Wasteland food choices to offset the change in Vanilla farming, supplementary Wasteland books also integrating skill features that are fundamental to survival, Power Armor and the abundance of mods, and last but certainly not least 'Legendary Weapons', life will remain pretty good out there for players who are getting their quests complete, looking out for those high value looting opportunities, and making considered choices. The update is very new. Subjective and impulsive concerns are noted but given very limited consideration. However, constructive feedback based on objective tangible observations based on putting in some time to test things out are not only welcome but will be acted on where re-balancing may be appropriate. Give it a chance The Wasteland Mod and Bdub's Vehicles run together without any issues at all. I have been using them both since the first release of The Wasteland. It's as convenient as placing 'Bdubs Vehicles' mod in your 'Mods' folder in your 7 Days to Die main directory.

The original silencer is potentially a decoration added to the Hyperblaster within the items.xml There sure is a lot of action going on in there to decorate it and Snufkin did enjoy this part of building the weapons. <effect_group name="Deco"> <triggered_effect trigger="onSelfEquipStart" action="SetTransformActive" active="false" transform_path="GunMesh"/> <triggered_effect trigger="onSelfEquipStart" action="SetTransformActive" active="false" transform_path="ClipMesh"/> <triggered_effect trigger="onSelfEquipStop" action="SetTransformActive" active="true" transform_path="GunMesh"/> <triggered_effect trigger="onSelfEquipStop" action="SetTransformActive" active="true" transform_path="ClipMesh"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Items/Misc/sack.fbx" parent_transform="Handle"/> <triggered_effect trigger="onSelfEquipStart" action="SetTransformActive" active="false" parent_transform="Handle" transform_path="sackMesh"/> <triggered_effect trigger="onSelfEquipStart" action="SetTransformActive" active="false" parent_transform="Handle" transform_path="sack_LOD1"/> <triggered_effect trigger="onSelfEquipStart" action="SetTransformActive" active="false" parent_transform="Handle" transform_path="sack_LOD2"/> <triggered_effect trigger="onSelfEquipStop" action="SetTransformActive" active="true" parent_transform="Handle" transform_path="sackMesh"/> <triggered_effect trigger="onSelfEquipStop" action="SetTransformActive" active="true" parent_transform="Handle" transform_path="sack_LOD1"/> <triggered_effect trigger="onSelfEquipStop" action="SetTransformActive" active="true" parent_transform="Handle" transform_path="sack_LOD2"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflexPrefab.prefab" parent_transform="main1" local_offset="0,.06,-.22" local_rotation="-110,0,180"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflexPrefab.prefab" parent_transform="main2" local_offset="0,.1425,-.1" local_rotation="-110,0,0"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflexPrefab.prefab" parent_transform="main3" local_offset=".045,.164,-.13" local_rotation="70,0,90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflexPrefab.prefab" parent_transform="main4" local_offset="-.045,.204,-.13" local_rotation="70,0,-90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflexPrefab.prefab" parent_transform="main5" local_offset="-.045,.2325,-.175" local_rotation="70,0,-90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflexPrefab.prefab" parent_transform="main6" local_offset=".045,.2725,-.175" local_rotation="70,0,90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main1" local_offset="-0.003,.05,-.04" local_rotation="0,0,90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main2" local_offset="0.003,.09,-.04" local_rotation="0,0,-90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main3" local_offset="-0.003,.13,.06" local_rotation="0,0,90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main4" local_offset="0.003,.17,.06" local_rotation="0,0,-90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main5" local_offset="-0.003,.21,.16" local_rotation="0,0,90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main6" local_offset="0.003,.25,.16" local_rotation="0,0,-90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main7" local_offset="-0.003,.29,.26" local_rotation="0,0,90"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Mods/Scopes/scope_laser_reflex.fbx" parent_transform="main8" local_offset="0.003,.33,.26" local_rotation="0,0,-90"/> <triggered_effect trigger="onSelfEquipStart" action="AddPart" part="SideB" prefab="#Other/Items?Mods/Sides/pistol_flashlightPrefab.prefab" parentTransform="main1" localPos="0,.05,-.375" localRot="90,180,0"/> <triggered_effect trigger="onSelfEquipStart" action="AddPart" part="SideC" prefab="#Other/Items?Tools/flashlight02Prefab.prefab" parentTransform="main1" localPos="0,.0825,.01" localRot="0,0,0"/> <triggered_effect trigger="onSelfEquipStart" action="AddPart" part="SideC" prefab="#Other/Items?Tools/flashlight02Prefab.prefab" parentTransform="main2" localPos="0,.1225,.2" localRot="0,0,0"/> <triggered_effect trigger="onSelfEquipStart" action="AddPart" part="SideC" prefab="#Other/Items?Mods/Scopes/ak_mounting_bracketPrefab.prefab" parentTransform="main1" localPos="0,.015,.2" localRot="0,0,0"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Weapons/Ranged/Pistol/PistolPrefab.prefab" parent_transform="Handle" local_offset="0,-.03,-.15" local_rotation="0,0,0"/> <triggered_effect trigger="onSelfEquipStart" action="AttachPrefabToHeldItem" prefab="#Other/Items?Weapons/Melee/TaserBaton/TaserBatonPrefab.prefab" parent_transform="Handle" local_offset="0,.005,-.2" local_rotation="90,0,0"/> </effect_group> Systematically removing/commenting out these entries may bring the aesthetic result you are looking for.

The Progression has certainly changed for this build and since we can no longer interact with the attribute tree, it can pretty much be overlooked. I spent 5 SPIFSAL on Strength and I will only concern myself with what's on the left side from hereon. Saying that, there is still some residual interaction since each SPIFSAL added to strength opens up a slot on the Backpack regardless of adding no Skill to Pack Mule. And now all the SPIFSAL unlocked Perk Skills have become level dependent there are some interesting trade offs compared to the regular system. For example, I can access Miner 69'er Skill Level 4 pretty quickly since there is no need to build the attribute tree and all those Skill Points can be dedicated to Miner 69'er based on Level. And since early Level increases come rapidly, our selected SPIFSAL options are going to be a real asset to offset the ones we didn't select. Choosing that initial SPIFSAL load out very carefully was something I found to be critical. I went with a very very balanced selection that provides for early game features with survival and 'body' features being predominant. This ensures I can take a knock from the zombies and get my base up and running without any slogging for resources. My understanding is we can find further SPIFSAL as we progress and I can unlock some specialised items later on. And that's what I like about this new system. We can choose either a very balanced set-up to give all the essentials right from the start, or slightly move towards a very specialist track. And players who can deal with that initial struggle who put all their SPIFSAL into something highly specialised are investing for latter Game Stage where that initial suffering will have paid off. It took me a couple of play throughs to get a feel for the SPIFSAL set up as with learning anything new, but I can appreciate its intricacies and 'manipulate' it to the way I play. What's up with your health? Are you carrying an injury from one of the Wasteland beasties?

From what I understand, we can find 'statues' which carry additional SPIFSAL attribute increases for individual attributes.

Nice tile choice. This one was placed at the edge of a town and looks right at home in the snow biome. Even looking back into town had no noticeable FPS hits even when the 'passengers' attempted to disembark. ^^

Decent, and much appreciated as always. I've been watching your creation flow over the past year in Discord and always appreciate how you share the process to the extent we could meet up on a live Discord stream. Learning how you created this floating effect, using a very novel approach, was enlightening. The same goes for the traps added to the rose-hued sandstone structure in the Petra POI last summer. Thanks for taking the time to specialise in this part of the game to bring us some very original ideas and techniques.

@SketchFoxsky Here is an update for the Server Side Vehicles: https://github.com/arramus/A20-ServerSideVehicles-2022Jan20 The Magic Bus returns to A20 and has received a small upgrade. As the image suggests, the Magic Bus can hold up to 9 players without the need for a seating mod. This will accommodate larger communities, or servers that use the extended party mod that typically allows 8 players to 'party up'. Players will need to enter the bus from the non driver's side via the sliding door. ^^ Player No.9 sitting in the last rear seat at the back of the bus. The Magic Bus can still accept all vehicle mods, even though the seating mod will have no effect, and see the benefits they provide. Since only the Magic Bus and the Whirligig use non standard seating, players can see the seat count as they approach these vehicles. As with A19, when the headlights are turned on, flames will appear from the front 'impalers'. Driving into a zombie will knock them over and set them on fire. There will be no XP gain for any eliminations using this method of zombie control.

Thank you. It looks like they are behaving liked spawned entities that can totally disappear when a player goes out of their range. I shall discuss this with the main creator to see if it's linked to something specific.

Is this for servers that are running the expanded 'Party' mods that often allow 8 people to all join together? We'll see what vehicle options are available and acceptable. It may not look pretty as the A20 vehicles got a pretty big update but we'll see what remains.

If this was a consistent and repeatable issue, it would be easier to troubleshoot and consider a solution. It certainly appears to be linked to a server restart, but there is nothing that stands out to point to any particular restart. One server where this happened enough to be an issue requested players to limit the amount of guards and pets per person. Reducing the overall amount could retain them longer, but it was not a totally perfect solution. In the end, this server simply increased air drops to every 24 hours to ensure it was easier for players to replace any losses.

The models are given a decorative 'buff' to give their customised appearance. The buffs are added as you get closer to them. The buffs.xml checks that the buff is constantly being applied on a regular basis. If a converted vehicle has the model/decoration applied but not the update which keeps checking on them, then it can look like it isn't added until picked up and placed again. However, even with the check to make sure they are updating, it can sometimes be finicky. This is especially true where a server is running a lot of other mods, has a lot of players, or is being pushed in any other way. It is intended that the vehicles will regularly check themselves to make sure the decorative buff is added but it is not always effective. The dog usually just stands still but depending on the server, netcoding and syncing, things can go a bit odd at times. The origin of this mod was very experimental and pretty much a single player thing. It responded quite well online and was released for us all to have fun with. But yes, there are limitations that are a trade off to many of the fun and enhancing things.

I tried to replicate this issue as follows: 1. Start the game with EAC off. 2. Join a dedicated server that also has EAC off to reflect the new trader .dll feature. Joining the dedicated server really puts The Wasteland to the test as the demands are typically higher. 3. Visit the remnant_wasteland_01 Prefab. The result was a clean spawn of the Mutant type entities. And yet another swing at me showed responsiveness after I upset their slumber. I checked the console and it was clean where it specifically related to The Wasteland mod. There was one warning though, but it was a Vanilla warning about the snake pain sound. It might have been suffering the same fate I was facing.

I get what you're saying here, but this really is something that could be said of the Vanilla default game as a whole, that The Wasteland could also benefit from. It's a big ask for the creator to implement something like this that the devs have opted to currently leave out. This release is actually very well balanced without needing to change anything or bring anything else in. It has got to this stage through the creator's vision of where things are heading as well as constant feedback from the community to share how that vision plays out in reality. On a personal level, I have put more hours playing The Wasteland than I care to mention, and have been able to see the direction it took to get to where it is now. It was a natural progression of bringing in a solid working base, periodic updates and additions, followed by the most recent level of sophistication which sees things move from 'DLC Add On' to standalone 'Overhaul' in its own right. There are a lot of games out there that provide untold configurable options which can be tweaked dynamically. Even some pre-2000 titles were well up on giving players/server hosts a whole array of options. What you are saying is a very valid request and maybe one that could be added into TFP's 'Wish List'. The Twitch pet project with 'dancing zombies', 'swollen heads', and 'firework displays' has certainly been given a lot of attention and its gone way beyond a few toggle-able game settings, so it is clearly well within TFP's means. Saying that, there are still numerous mods that will run alongside The Wasteland to provide Quality of Life changes specific to the end user's needs simply because an abundance of underlying code remains untouched Vanilla. And should there be something you can't find or get working, you can always ask Evil_Geoff and others for pointers.

I could upload an alternative zip version and rar version which are already compressed and won't be further compressed by the host Github. Just need to click on the second (rar) version or third (zip) version within this link to open it in its own window. Then you'll see the download tab. Hopefully that will resolve it. https://github.com/arramus/A20-ServerSideVehicles-2021Dec09

There is a setting called StaminaLoss in items.xml which may also be linked to food burn. There is no other specific property that directly describes hunger/food usage that jumps out. For Thor's Hammer: For regular melee <passive_effect name="StaminaLoss" operation="base_set" value="35" tags="primary"/> For power melee <passive_effect name="StaminaLoss" operation="base_add" value="75" tags="secondary"/> The regular steel sledgehammer settings are: <passive_effect name="StaminaLoss" operation="base_set" value="40.5" tags="primary"/> <passive_effect name="StaminaLoss" operation="base_set" value="81" tags="secondary"/> It might be worth testing if this setting has any impact beyond other food loss protective skills.

@ErrorNull This was the only mention of it from recent previous posts but it wasn't clear if it was inside a quest POI or outside. It was certainly a quest on the time I experience it and it's only been the once so far. I did try another quest with the Mutant spitter and it appeared just fine.

Would look at home as the front cover on a book. What a story that would make as well.

Each NPC pack should have an entitygroups.xml within the main Config folder. This is a good place to start tweaking the settings to match your requirements. For example, the 1-SoldierPack. There is an entry for the Rocket Launcher soldier like this: <entity name="npcSoldier1RocketL" prob=".1" /> He has a low probability to spawn compared to default entities but the same probability to spawn as other Soldiers in the pack. Your choices are to remove him totally or further reduce his chance to appear, and here are instructions to do that first. This will still allow him to be a feature but much more of a surprise than a guaranteed regular occurrence. For example, change his probability to: <entity name="npcSoldier1RocketL" prob="0.02" /> This only provides a 2% chance to spawn on an individual basis, but even less so when we take all of the other NPCs in the same spawning area with greater probability into account. If encounters are too common this can really balance it out and make it a lot of fun when he does appear on those much rarer occasions. I hope you'll try that method as he can be a cool character in smaller doses. ^^ However, to remove him, you can totally delete that line or 'comment it out'. Commenting out forces the game to disregard that line and skip to the next one. A commented out entry for this Rocket Man looks like this: <!--entity name="npcSoldier1RocketL" prob=".1" /-->

A third load out. It remained consistent for back to front placement on this occasion.

And if things could get more finicky. The guards which aren't spawning in the conger lines were placed from the front so a guard was placed behind them. The guards which are spawning well in the conger line were placed from the back so a guard was placed in front of them. Based on those scenarios, spawning stability when they are next to each other appears to be better when: - They are placed from the back facing forwards with the next guard placed in front of them. But that was certainly not the case on top of the trailer because I worked from front to back. However, that was on the previous load out. It is always possible there are also slight subtleties in each load out and also server syncing can effect placement collision as time goes by. It is hard to give a definitive answer when the results can vary so much.

Here are 2 examples of what can be expected when placing guards closely together. In this scenario they have been placed from right to left from front to back. They take well to being in front or behind of another guard but do not like to be beside each other when spawning. There are no limitations or features which would restrict them spawning side to side. In this scenario, they have been placed behind each other. Their ability to spawn is much more stable. I purposely stood close to the first spawn block area to show how things near to them can restrict spawning. For the remainder of the line I was always a coupe of blocks away. While there are no limitations set, they can be finicky. It is best to line them up all as if they were behind each other rather than beside each other and allow them to rotate once a threat is within range. It is possible their shoulders are causing some collision issues for their neighboring guards. This is actually an issue we see when placing Vanilla zombies in Prefabs. They will comfortably line up but do not like the side by side placement either and one of them may not spawn. It is not as noticeable as the Turret Guards though.

This simple Bond connection has been getting me through the first postings to ensure I remember the dependencies. What has been seen cannot be unseen. Well, it gets me through, anyways.

If the update isn't working out over the last version or the air blocks are causing big issues, let us know and we can look for another tool or method that can help with deleting the air blocks.