ToliburtiX
Member-
Posts
106 -
Joined
-
Last visited
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Reels
Support Center
Everything posted by ToliburtiX
-
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 DuGe'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? -
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
No, there were no such related messages. Well, I spend the last days removing all my plugins from "carbon/plugins", restarting the server and putting them back one by one while watching the logfile for a while. RoamingNPCs was the first I put back and running all the time. Well, what should I say. The flooding message did not come back. I will now wait and see if it stays away or comes back after a longer runtime of the server. I think nothing must be done in the moment. -
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX replied to ToliburtiX's Support Report in Support
Hello, the map is procedural, seed was 4548765, size 3000. Config is attached. RoamingNPCs.json -
Failed to create agent because it is not close enough to the NavMesh
ToliburtiX posted A Support Report in Support
Hello, while most of the time the NPCs are happy respawning, from time to time the logfile is flooded with "Failed to create agent because it is not close enough to the NavMesh" messages. It's clearly caused by RoamingNPCs, because unloading the plugin stops the message. But a simple reload of the plugin does not solve the problem. I have to unload it, delete the file "data/RoamingNPCs/Bots.json" and load it again. Then everything runs fine until the next "flood". Best regards, Toli