ToliburtiX
Member-
Posts
75 -
Joined
-
Last visited
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Everything posted by ToliburtiX
-
Having more than a handful of npcs render the server unplayable
ToliburtiX posted A Support Report in Support
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. -
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
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
-
Suggestion config combination "Lock container, but don't delete on death."
ToliburtiX posted A Support Report in Support
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.
-
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
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 ... }
-
I already did this and as I said before, without RoamingNPCs constantly calling "IsDeployableNature" everythink is fine.
-
If you tell me what I can do, I'd like to try a few things.
-
Yes, of course.
-
Well, as far I can see they define a method and use it in their code. I will only give this small general code example, because it's not open source. I asked them to have a look here in this support ticket an maybe contact you. ... public bool IsDeployableNatureEntity(BaseEntity entity) => DeployableNature?.Call<bool>("IsDeployableNature", entity) ?? false; ... ... private bool CheckResources(BaseEntity resource) { if(resource == null) return false; if (instance.IsDeployableNatureEntity(resource)) return false; ... }
-
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
Hi, regarding the high memory consumption, it's seems a problem between RoamingRPCs and DeployableNature. I filed a bugreport there, maybe you could have a look at it, too. https://codefling.com/files/sc/26471-memory-leak-and-hook-flooding/ Best regards, Toli -
Well, looking deeper I think I found the problem. It's the plugin RoamingNPCs which constantly calls the hook "IsDeployableNature". I have only 8 NPCs configured to run around on the map and collecting resources, which seems to create this huge overload. Is this a problem of DeployableNature or RoamingNPCs? Who will solve it?
-
Wow, see attached plugins.txt, after 3 hours of runtime, DeployableNature consumes 8 GB of "hook memory". Without a single Item deployed. plugins.txt
-
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
Hello, okay, I do not have a problem with filtering the messages, if they are clearly "informative", cause it takes some attempts to find a good spawning point. But my observation was, the longer the server runs, the more messages arrive during a burst. For example, it takes a while 'til the first message-flood comes with lets say 10 messages. Then after a while, 20 messages come at once. Then, maybe after a longer pause, 30 or 40 messages come at once. (Numbers are roughly estimated) Overall it blowes up the logfile and I hoped it's some sort of exception you can catch in your code. As I said in an other ticket, SpawnsDatabase integration works for me like a charme. I will use this most of the time. Thanks again for implementing. I think the high memory consumption is not a problem with RoamingNPCs, but with DeployableNature. I filed a bugreport. Best regards, Toli -
Hello, I saw this behaviour on my production server, but proved it with a fresh installation of rust-server and carbon framework. The map (3000) is new procedural generated. No players are on the server (except me as admin) and no items deployed at all. But: As the carbon-console-command "plugins" shows, DeployableNature consumes 1000x more hook events than other plugins, and the memory is constantly growing. On my production server it was 3GB after 2 or 3 days, and it will lead to a out of memory crash, if you are not restarting the rust-server at a regular basis. Greetings, Toli plugins.txt
-
Is there any way to separate them and take different routes?
ToliburtiX replied to laodu's Support Report in Support
Having a group all doing the same and going the same route may happen, if they spawn at the same time at nearly the same spot. It also happens, if you use the new "SpawnsDatabase" option as respawn mode, and only have one spawn point. I mitigated it by defining a couple of slightly different spawn points. Best would be a spawn-cooldown of about 10 seconds between two spawns, so the first already ran away when the next spawns. -
I just tested it and it works like a charme. Thanks for implementation.
-
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
Hi there, for the sake of debugging this odd problem, I did a clean and fresh install of a rust server and carbon framework, going with the default options where possible. The server generated the 3000 map with seed 4548765 by itself. I installed only RoamingRPCs and three other plugins for logging (see plugins.txt). But after a while I still get this flooding message in the log file (see console-log file). Greetz, Toli console.log.zip plugins.txt -
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
My plugin list and a slightly anonymized logfile covering 2 hours from start to shutdown of the server are attached. It's my testserver (copy of the production server), so only one player (me) logs on. console.log.zip plugins.txt -
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
Dam it, the messages came back. It seems that after a restart of the server (not just reload of the plugin) it takes a while 'til they occur. What I also noticed, while there is not much traffic an the new server, it's slowly eating up the free memory/RAM. Feels like a memory leak. Is there anything I can do to help debug this problem?