Steenamaroo
-
Posts
3,670 -
Joined
-
Last visited
-
Days Won
208
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Everything posted by Steenamaroo
-
Hi, Thanks for pointing that out. Looks like I missed a few fixes from the Saturday fiasco. This won't affect actual Economics/Server Rewards balances - Just the PR reporting of it. I'll do an update soon to rectify it.- 447 comments
-
- 3
-
-
- #statistics
- #leaderboard
- (and 12 more)
-
Hi, I think I’m following. Are you talking about the minStack/maxStack options, and setting that min to zero? If so the plugin should just completely ignore any items where minstack, or maxstack, is zero, so they’ll never be picked or created. If you’re just talking about probability of zero then any category set to zero (and all of the items in it) will be ignored, and any item set to zero, regardless of its category’s probability, will be ignored. If there’s only one category and item (in it) with probability above 0, then that item will always be picked and created, cos there’s no other choice. I order to give that item a chance of not being picked, there needs to be at least one other viable item which could be picked instead. I.E. You can set the plugin up to create wood or stone, for example but you can’t set it up to create wood or nothing. It’s hard to describe but people usually get a feel for it. If everything was probability zero except for category tools 1 item timed explosve 1 category Resources 9 item wood 1 item stone 1 Then for every item created there’s a 9 in 10 chance it’s going to be a resource, and beyond that it’s a 50/50 whether it’s wood or stone. 1 time in 10 the item will be a tool and if it is a tool, it’s guaranteed to be c4, because there’s no other option. When people are starting out I often suggest that they pick a handful of common items that could make up their base common loot, and set the probabilities for those items to something a good bit above zero, to allow room for other things to be less common. Say you have wood with a probability of 10, for example, you could then have stone at 7 so it’s less common and scrap at 3 so it’s even less common. If the only category enabled was resources with those three items set that way, and the profile’s asking for one item (for simplicity) then, on average, you’d get scrap 3 time out of 20 stone 7 times out of 20 wood 10 times out of 20. Of course I don’t expect anyone to follow the actual fractions like but you get the idea - It becomes a ‘feel’ thing. -
Oh sorry, I misunderstood. If they're getting loot with a fresh table then you're right - It's coming from somewhere else. Sorry, I'm not sure what else to suggest other than maybe temporarily unloading everything except BotReSpawn and CustomLoot, just to prove?
-
Ok, that's good to know. If you made a new loot table and the bot inventory was completely blank, then that means CustomLoot is working, which almost certainly means the loot you saw came from CustomLoot. Any chance the loottable you wanted to use just isn't set up how you thought it was? Some copy/paste mistake or..something? I just tested here with SuperMarket BotReSpawn profile and a loot table with Ammunition 1 and ammo.grenadelauncher.buckshot 1 and nothing else changed, and the npcs had nothing but 40mm buckshot on them.
-
Ok, I'll fire up and test here in case there's something unique to that BotReSpawn profile.
-
If you reload CustomLoot and watch the console do you see any complaints? It's possible there's a mistake in the Market.json - If so CustomLoot should tell you when it loads/reloads.
-
It would be set true by default and probably should be true in most cases. You'd only set it false if you want CustomLoot to add to whatever is already there, be it vanilla loot or stuff from a kit. If you're seeing vanilla loot (or anything that's not from your CustomLoot table) in those npcs then either something else is giving them loot after CustomLoot, or CustomLoot just isn't firing for those npcs at all, although I'm struggling to see why one specific BotReSpawn profile wouldn't work when others do. I suppose a simple troubleshooting tip would be to change "Market" to a made up name - Some table name that doesn't exist, then when CustomLoot creates a file for that name, do not edit it. That way it'll be really obvious if it's working or not because the npcs should get absolutely nothing. CustomLoot should clear their container, and give them nothing. If you find loot in there that would definitely point to something giving out loot after CustomLoot has done its bit.
-
I see you've got ClearContainerFirst set to true so I'd guess something else is giving them loot after CustomLoot, or what you're seeing is stuff from their kit possibly?
-
I'm glad you got a solution and thanks for sharing it. Feel pretty bad that you've been doing all your spawnpoints manually every month for two years! I went to quite a bit of trouble to try to make it all as easy and seamless as possible. CustomLoot, on the other hand... Different story. -
Strange. That has to be something external renaming the file. Do you have any kind of automated backup system or something that could be doing it? It's certainly not something BotReSpawn is doing, anyway, but it makes sense that BotReSpawn would create a new blank file if something/someone renamed the old one.
-
Wow, that's a new one to me. Why was that happening, do you know? I'm relieved, lol.
-
That doesn't sound right. BotReSpawn only wipes custom spawnpoints in cases where the user has changed the setting for "Parent_Monument", just because of how it's written...setting parent monument needs to happen before spawnpoints are added. Certainly for default monuments, and custom spawnpoints you add should be good forever. If you set a bunch of custom spawnpoints for, say, the Airfield profile, no matter what map you change to those npcs should always be in the right place, relative to the airfield. Do you keep the same map wipe after wipe?
-
Hi, It depends what you mean. Custom spawnpoints added for default profiles (monuments) should never need to be updated or redone, because those spawnpoints will automatically move to where the monument is when you change to a new map. For Custom profiles with custom spawnpoints, BotReSpawn automatically disables these profiles when you change maps, because those spawnpoints will no longer make sense on a new map. The exception here is servers which recycle the same map over and over where, of course the points will make sense, so I provided the option Disable_Non_Parented_Custom_Profiles_After_Wipe for those users to set to false. For Custom profiles that you've added which are meant to supplement default profiles - I.E. additional profiles at the airfield, dome, etc, you should set "Parent_Monument" for your custom profile to the name of the default profile it's meant to be near. That can be done with clicks in the UI. If you do that, then add your custom spawnpoints to the custom profile afterwards, that custom profile will act just like a default one, meaning the custom spawnpoints and profile will always relocate to where the monument is on your new map. Basically default profiles are set and forget, custom profiles parented to default ones are set and forget and custom profiles "in the wild" will need to be redone if/when you change your map. Does that answer what you're asking, or are your circumstances different? Let me know.
-
No, I have a 'proper' update with quite a number of fixes and additions, but didn't want to push that for forced wipe, so the most recent update is literally just a patch for Rust's update.
-
@Tanki - I found it. I cache it with ImageLibrary in RustRewards so the url is only accessed by the plugin once a month. Should work fine if you right click and copy image address here, then use that in your config. I'll change the default value so it's hosted at Codefling for new users from now on. -
-
It could be a number of things - Maybe zone settings? If the issue is isolated to one type of npc / area that might be a clue. Is it a specific weapon you're having the problem with? Oh, cool. Well, if you have any questions just ask! -
Hey, sorry I didn't get back to this sooner. I've just tested and my NPCs are dropping their melee weapons on the ground no problem, with Death > Weapon_Drop_Percent set to 100.
-
Is this sorted in the most recent update?
-
Sounds like a great setup! My pleasure, and thanks for the kind words. Don't hesitate to ask if anything else comes up.
-
My pleasure. Glad to help. You've understood perfectly but there's an additional option in the global settings called Remove_BackPacks_Percent which may be set to 100. If you set that to zero all your BotReSpawn corpses will then leave backpacks and your timers in minutes will apply. You can use that Remove Percent option to make it that there's backpacks sometimes, and other times not, and balance it to your preference, or just go with 0 so backpacks always spawn. If you're gearing up to make them more difficult don't forget they can use (nearly?) every weapon. Bots with MGL or flamethrowers, rocket launchers, and even grenades, beancans, satchels, or c4! as backup weapons when line of sight is broken can be great fun.
-
Hi @ClockworkCat You found one solution. As long as that new profile remains parented to Airfield, the npcs from that profile will always spawn where you placed them relative to the airfield, so if you change maps and the airfield moves, that profile and its npcs will appear to be in the right place. There is another way just using just one profile. If you go into the UI and view the manually placed spawnpoints for the profile you should see an 'Edit overrides' button for each point. In there you can choose a kit (and some other settings) which are different from the main profile's settings. For example the main profile could be set to use kit 'soldier1' but one specific spawnpoint overrides that and uses 'soldier2', or whatever. On a per-point basis you can override the settings for stationary, Kits, Health, and RoamRange. If you need more control than that then the two profile approach is better.
-
BotReSpawn npcs can use bows. They can use bows, crossbows, nailguns, rocket launchers, flamethrowers, mgls, homing missiles...probably more.
-
Oh, Ok. I do have to store info on the items to recreate them for the corpse, so maybe it's happening at that stage. I'll add in the copying of item.name and item.text - That should probably sort it.
-
BotReSpawn relies on the free Kits.cs plugin from uMod. If custom item names in your kits aren't being applied that'd be a question for the current maintainer of that plugin, I'm afraid.
