arramus

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.

Here is an update to fix an issue as well as introduce a new spawning decoration for the Turret Guards. https://github.com/arramus/Oaks-Pet-Animals-and-Guards-A20-2022Jan10 Changes are as follows: 1. @RoronoaDroagon kindly reported an issue with the new spawning feature for the 4 new guards. This appears to be something that changed from A19 to A20 and didn't function as hoped. The new guards have been added to the older system which proved reliable, beyond the plates occasionally not being destroyed on uneven terrain. It appears we will have to live with that since other destructive methods can cause issues. 2. All turret guards have been given a new texture for their spawn pad that matches the newer version. Just a cosmetic change. 3. All Turret Guards see a Quest Marker drop through their body and sink to through the ground as they spawn. This reflects their quest completion status. 4. The 'killall' Admin command used to kill all of the Turret Guards. They are now protected from harm when a server admin needs to troubleshoot zombie issues but keep their Turret Guards safe. As the blocks for the Turret Guards changed back to the older format, it is not recommended to change to the new upload unless you start a new World. If you do decide to update without starting a new World, expect some of the new Guards to potentially change into other objects; especially Darkstardragon (Turret Guard 09) as this character required a slight name change in one part of the code. In your case, it may be best to try that suggestion first before you potentially upgrade because those airblocks will still be there even with the new update as the Turret Guards were already gone. If they cannot be removed, we can look for another solution as air blocks have been reported as a Vanilla bug from earlier A builds and it appears they still persist. Some mods/admin mods can delete them.

cntRetroFridgeVer1Closed Here is a temporary fix. Go to your blocks.xml Change: <block name="TestGuardPlate"> <property name="Extends" value="air" param1="CustomIcon"/> <property name="CreativeMode" value="None"/> <property name="MultiBlockDim" value="1,2,1"/> <property name="StabilitySupport" value="false"/> </block> to <block name="TestGuardPlate"> <property name="Extends" value="cntRetroFridgeVer1Closed" param1="CustomIcon"/> <property name="CreativeMode" value="None"/> <property name="MultiBlockDim" value="1,2,1"/> <property name="StabilitySupport" value="false"/> </block> This changes the air to a tangible asset that can be destroyed. In this case a retro refrigerator. It also cover the 1 block across and wide with the 2 blocks high. I am just about to upload a full permanent fix as well with the new guards switched back to the older system.

Correct!! Yes, regardless of the block, traders do not like these to be added at all.

The current setup has only added the guards to Air Supply Drop loot and not through any other means. At 72 hour drops and players competing to access the resources, and also with them being set to medLow probability, the Turret Guards could be quite a novelty on a server. With periodic loss, they were being replaced but not really being added to unless they were setup hidden away and in relative safety. The concept was temporary mercenaries. The reality though is typically, greater than 100% loot chance, 24 hour drops of which they sometimes come in 3's, and some Server Admin further adding them to other loot groups which soon mounts up to be quite an army.

Thank you for reporting this issue as these things can sometimes slip through and it's only through feedback that they come to light. I could also replicate this issue in Single Player Nevezgane. I shall report it to the develop @oakraven. I tested a guard from 2 guard types. Guards 1 - 8 which use an older spawning system, and Guards 9 - 12 which use a new spawning system as follows: The two types were placed on top of a trailer. The left is the new type and the right is the old type. The 2 guards were eliminated. The older type of spawning guard accepts a block where the guard was. The new type of spawning guard does not for the two blocks they were stood. Thank you for reporting, and we'll see what can be done to resolve it.