ToliburtiX

They do both. Sometimes they spawn in closed prefabs, with no chance to get out. Sometimes, what looks really cool, they walk in buildings and roam for example the inside gasstation. In that situation they mostly find the way out again. Looking ahead for the update.

Billy is waiting in Oxums gasstation restroom for a day now. Wants to go to Satellite Dish, but does not find a way out. Please help him.

It's probably not on the rust server console. It's in the logfile you configure with the server-option "-logfile".

You are right, I already gave you the information and downloadlink for the map in the other thread. Will send you my config as pm, skin-ids for my bots dont need to be public.

Here a bot constantly running around a rock with wood-collectable unreachable on top. Testwise I lowered the suicide time to 120 Sec. It now seams, the bot makes a pause after that time, but not really dies. Just gets stuck and waits. When giving a gun shot or other kick its configured for, it starts again running around.

Hello, this issue is NOT FIXED ! if you want for some reason bots NOT to place boxes/stashes all over the map when inventory overflows, and disabled it, since update 0.3.2 the NPCs get stuck in the moment the inventory is full. They don't move, they don't die, just standing there forever. And no new NPCs spawns. Also setting "Suicide timer if the bot does not reach the destination point..." does not help. (I made a ticket for it) They stay forever. After a while all harvesting/collecting bots on the map are stuck. Before update 0.3.2 they just died and released the loot in a corpse/backpack like configured. As a workaround for now, you can enable the stash/box for inventory overload and set its lifetime to some seconds. Same stuck NPCs you get, when enabled inventory overload boxes, and set the max. number for example to 5 and the lifetime of the boxes to something about an hour or more. As soon as there are 5 boxes and the NPC has a full inventory, it gets stuck like described above. Waiting for the first box decay, placing a new one, getting stuck again, and so on. Greetings

My map is also procedural (seed 4548765, worldsize 3000) generated by my server itself. Without ever editiing it, I saved it on my webserver, and removed server.seed and server.worldsize from the config. My public levelurl is "https://rust.nullx2a.de/Maps/PrettyLittleMap.map". You may use it for reference and testing. I use carbon framework. Both server and carbon are updated as soon as an update is available.

Greetings, I do have more and more bots which for example constantly and forever running around a rock with a "wood collectable" on it trying to reach it, but never can. "Suicide timer if the bot does not reach the destination point ...": is on default 600.0. Setting "Enable periodic bot reinitialization? (can improve performance)": true does not matter, too.

It's not fixed, see ailed to create agent because it is not close enough to the NavMesh

I do agree! Don't know if it's got worse, but it's still there.

Hello, I love the simplicity of the plugin, much better than other horse/vehicle plugins. Great work. But I have one suggestion: Sometimes you will unclaim the horse immediately. Maybe sell it or give it to a buddy who is not in your team. Would be nice to do it with a key-combination like ctrl+space when dismounting, or just a chat-command like /horse unclaim. Greetings

Hello, thanks for the great testet update, again. Because the whole thing with placing stashes/boxes when inventory overflows does still not work (see Inventory overflow boxes are placed in a row) , I was glad 'til today the NPCs just died where they are and gave back the loot in their corpse in the way configured when inventory was full, and a new NPC spawns. This no longer works since update 0.3.2, either. They get stuck in the moment the inventory is full. They don't move, they don't die, just standing there forever. And no new NPCs spawns. And yes, I deleted the Bots.json and also did unload/load the plugin, and also rnpc init. Thanks a lot.

I literally wrote it in my post you are answering to.

Situation: Only one or two player on the server and speaking about server (not client) fps: Having 40 roamingnpcs spawned at random roadpoints (4 groups with 10 bots) nearly all are just walking around, some doing harvesting, the server fps drop from 80-90 down to 10-20. Unplayable laggy and unresponsive. Having 20 roamingnpcs spawned at random roadpoints (4 groups with 5 bots) nearly all are just walking around, some doing harvesting, the server fps drop from 80-90 down to 30-40. Drop not acceptable for having some fun npcs doing nearly nothing. My personal opinion: The software RoamingNPCs is a nice prove of concept, when used with the example configuration. However, considering the other errors found and the fatally poor performance, it is not usable in production. If possible, I like to have my money back and will no longer play tester for alpha stage software.

Despite setting ""Use only NavMesh navigation?": false" and spawnpoint only spawnsdatabase and roadpoint, having some players who actually shoot the roaming NPCs, the logfile is again heavely flooded with "Failed to create agent because it is not close enough to the NavMesh".

Hey folks, for example there are fuel_tank_a_300 fuel_tank_a_600 fuel_tank_a_900 fuel_tank_b_300 fuel_tank_b_600 fuel_tank_b_900 Because they are pretty much the same it would be nice to handle them with one lootable definition. Is there some way like fuel_tank_*_* ? Or much better using regular expression like fuel_tank_[a|b]_[0-9]? Or if that's too complicated, could the prefab filter be converted into a list? Thanks and greetings

Hi folks, I am trying to mimic the behavior of the blue garbage dump scientists when they die. The death corpse still wears the blue hazemet, but you can only loot the inventory, not the hazemet/wear. Because the roaming NPCs have the stage of "wounded", where the NPC is fully lootable, you have to set belt and wearing inventory to "locked". Thats fine. But even if you set death-corpse to NpcCorpse, where wearing and belt inventory are not accessible, you get a naked player corps, because lock also means delete an death. If I don't set it to locked, the death NpcCorpse is fine still wearing it's hazemet, but belt/wear can be lootet while the phase of wounded. I see two options: First make "lock container" and "delete on death" two seperate options for belt and wear. Or second, make the wounded phase skipable. First one would be more nice. It would a be a great enhancement, not only for hazemates, but especially for more complex individuell skins/wear. So the death NPC still looks like it was intended, but the normal player cannot loot this wear and running around with it. Greetings

I have this problem too, see Failed to create agent because it is not close enough to the NavMesh It seems only to happen when "What respawn mode to use?" is set to RandomPoint. Other like RoadPoint or SpawnDatabase work without Logfile-Flooding. Regardless of setting "Use only NavMesh navigation?" to false or true. Could someone please give a short explanation what "Use only NavMesh navigation?" does an how the performance impact is when set to true or false. Thank you.

Logfile Flooding still there. It seems only to happen when "What respawn mode to use?" is set to RandomPoint. Other like RoadPoint or SpawnDatabase work without Logfile-Flooding. Regardless of setting "Use only NavMesh navigation?" to false or true. But the extraordenary high amount of api calls to deployablenature still exists.

Hello, nearly all overflow boxes from different bots and different definitions of bots are placed in one row like pearls on a string. The line is exactly the horizontal half of the map, from west to east. When the inventory if full, the bots may run over the whole map just to go to this spot and place the box or stash. My partial config: "Inventory overflow": { "Stash setup (bot will put items in the stash)": { "Enable?": false, "Hide stash?": true, "Life time (0 - will exist until restart)": 3600.0, "Maximum amount to use (0 - without limit)": 10 }, "Box setup (bot will put items in the box)": { "Enable?": true, "Use small box?": true, "Box skin": 3565696561, "Life time (0 - will exist until restart or until it dies)": 10800.0, "Maximum amount to use (0 - without limit)": 5, "Another container prefab (you can leave it empty)": "" } },

Hello, I tried to give my bot a MP5 with Laser and Holo. It creates the MP5 at combat situation, but without the attachments. Partial config: "Items for fights": { "Enable random order instead of priority?": false, "Use ammo?": false, "List of items (in priority order)": [ { "Allow to create item if it is not in inventory?": true, "Allow to give item when respawning?": false, "Item": { "Item shortname or ID": "smg.mp5", "Item skin": 0, "Attachments": [ { "Item shortname or ID": "weapon.mod.lasersight", "Item skin": 0, "Attachments": [] }, { "Item shortname or ID": "weapon.mod.holosight", "Item skin": 0, "Attachments": [] } ] } }, { "Allow to create item if it is not in inventory?": true, "Allow to give item when respawning?": false, "Item": { "Item shortname or ID": "bow.hunting", "Item skin": 0, "Attachments": [] } } ],

Thanks for your answer. An advise for other users: If "Allow to create item if it is not in inventory?" is set and the bot gets in combat situation, the weapon is NOT created, if there is not already suitable ammunition in the inventory, or "Use ammo?" is set to false.

Hello, please clarify the two config options a) "Allow to create item if it is not in inventory?" and b) "Allow to give item when respawning?" For my understanding, if b) is set to true, the NPC gets 1 piece of the item at spawn/respawn. It will use it if applicable, and throw it away once it is defective. With only b. set to true, the NPC will only get a new one at respawn, or it finds one. But what does a) mean if set to true? In which cases is the item created? At what time? When it needs one, or prior? Does the NPC need to have the right resources for crafting in the inventory? if a) is set too true, does the value of b) matter? A question regarding priority order: Does it mean use/create the best one you have out of the list? Or does it mean, begin with the least one, and get better from time to time? So for example, first use the stone-axe, and when it's done, create a hatched, and so on. A little wish/suggestion: Would be nice if the list of wear items at spawn would be a list of lists [[...], [...], ...] . So we can have different clothing-sets (one set randomly selected at spawn) with only one NPC definition. Same for the box-skins when inventory overflows. Thanks for your time and greetings, ToliburtiX

Hello Folks, what would be the best/efficient way to call IsPlayerVanished of the vanish module from an other plugin? I tried it this way, but get always false. Thanks for your time. using System; using System.Collections.Generic; using Oxide.Core.Plugins; #if CARBON using Carbon.Modules; using Carbon.Base; #endif namespace Oxide.Plugins { ... #if CARBON private bool canBypass(BasePlayer looter) { var vanishMod = Carbon.Base.BaseModule.GetModule<VanishModule>(); return null != vanishMod ? vanishMod.IsPlayerVanished(looter.userID) : looter.isInvisible || looter.limitNetworking; } #else private bool canBypass(BasePlayer looter) => looter.isInvisible || looter.limitNetworking; #endif ... }