Nikedemos
-
Posts
139 -
Joined
-
Last visited
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Everything posted by Nikedemos
-
Changed Status from Pending to Work in Progress
-
@ChardaZAR I'm really sorry you had to wait such a long time, I have no idea why the notification about this ticket has been buried under other notifications (I've had quite a few of those recently). I definitely don't blame Codefling as a platform, but rather my ineptitude at using it. Usually the best way to get things resolved as quickly as possible is on Discord directly (link included on the very top of the product page, or if you don't want to join my tech support discord server, my DMs on Discord are always open). On Discord, I respond within 2-3 days max. So this issue of disappearing portal doors has been on-going for a while - but what's frustrating is that it only happens for a small minority of servers. Even though I have never figured out the exact reason why the portal door entity is being ent-killed, in Pocket Dimensions, I've implemented 3 countermeasures. First, as long as the plugin is loaded in, a hook simply prevents the killing of portal doors. Second, on plugin load/reload/server load, the plugin detects missing portal doors and replaces them with the same net ID as before. And third, killing of portal doors (if it happens while the plugin is loaded in) is logged to text files. Clearly that's not enough in your case. Something out there is killing portal doors, still. I'd like to have a look at your PD log files and also the list of all the other plugins to see if there's a potential conflict - mainly plugins that also utilise the portal doors, but also plugins that have the ability to kill entities. Would you please hit me up on Discord about this problem? It would make communication much easier since I'd be expecting some back-and-forth. I'd like to resolve this as quick as possible. You don't even need to join any extra servers, I'm on the Codefling server (as well as Carbon) under the same nickname
-
1) Not yet because nobody really requested it, but could be easily implemented - DM me! 2) Dimensional Pockets are just like regular bases, stored in the wipe's savefile. When the server is wiped, the Dimensional Pockets are wiped as well 3) Unfortunately, no. It would require CopyPaste files to be a 100% faithful recreation which sadly is not the case yet with the CopyPaste plugin, which doesn't support all entity types 4) Yes. You can assign any Small Wooden Box skin from the Workshop to correspond to a particular VALID copypaste file which represents a Pocket Dimension. You can create those CopyPaste files yourself and then it's just a matter of connecting the skin ID with the filename in your server config 5) No. Dimensional Pockets will always be 3x3 and there's many reasons for that - the biggest one is checking for validity of a CopyPaste file as well as a base currently built by a player later to be converted into a PD. Handling variable base sizes would introduce an unmanageable level of complexity 6) Yes they can, since about a year ago! Inside the plugin's zip bundle, there's an entire CopyPaste file of a 3x3 included by default, consisting of 0 foundations, 4 walls (each made of 9 door frames) and the ceiling made of 9 floor grid frames. Let some fresh air in I guess? 7) Unfortunately it's not possible because just like with normal vanilla bases, multiple players can be authorised on multiple dimensions, and one dimension can have more than 1 player authorised on it - there's no top-level "owners" recognised. It is not a 1-to-1 relationship where an individual player equals 1 assigned Dimensional Pocket. Dimensional Pockets as well as boxes containing them can be taken over, have the ownership transferred, players authed/de-authed at any time, etc. Hope this helps! Well I wouldn't go as far, but cheers for that mate -
Howdy! Thanks for reporting the issue. Would you be able to contact me on Discord? It would definitely make things easier as far as real time communication goes. I'm on the CF server or you can join mine at https://discord.nikhub.dev
-
I would definitely trust the console version rather than whatever says in your user panel. I think your user panel might be showing the latest AVAILABLE version rather than the one actually installed?
-
And when you type o.version in your server console, does it also show 2.0.7022 as well?
-
Btw I just checked my o.version: Oxide.Rust Version: 2.0.7022 Oxide.Rust Branch: master So it looks like your Rust Server is up to date, but not your Oxide installation. @moulinch you said your o.version is: Oxide. Rust Version: 2.0.7008 Which seems out of date (should be 2.0.7022) I think this must be the answer right here. Have you tried manually forcing the install of latest Oxide build?
-
This is utterly bizarre and honestly I'm flabbergasted. I tested both 1.0.18 and 1.0.19 on Oxide and Carbon and 1.0.19 compiles fine. On 1.0.18 I get this message: [CSharp] Started Oxide.Compiler v successfully Error while compiling CustomEntities: 'CustomEntities.CustomBaseEntity' does not implement interface member 'CustomEntities.ICustomEntity.Kill(BaseNetworkable.DestroyMode)' | Line: 2829, Pos: 53 I guess we'll have to wait for the next Rust server update and see which version works then
-
Here's the 1.0.18 version - does it compile for you both? https://www.dropbox.com/scl/fi/xgbjgynpiwauovxz481ea/CustomEntities.cs?rlkey=nkyvcnkw8kfavx0uyu1rj6mva&st=68pkisbi&dl=1 @LeDonjon59 do you also have Oxide by any chance?
-
Changed Status from Pending to Fixed Changed Fixed In to 1.0.23
-
Thanks for reporting the issue! Sorry it took me a while until I figured out what was wrong. Pushed out the 1.0.23 update to address this. Turns out, Ghost Ships are just larger Junkpiles - who knew!
-
Yeah looks identical to mine. Honestly I have no idea why it doesn't compile on your server and it does on mine. So what about version 1.0.18? Does that one compile for you?
-
Ah, I had no clue Oxide didn't print the game protocol version as well - but you can check that with the `version` command. Mine is Protocol: 2621.281.1 Build Date: 02/08/2026 19:24:07 Unity Version: 2022.3.41x1 Changeset: 142893 Branch: release What about yours?
-
Weird, it compiles just fine on my test server. Do you have Carbon installed? Could you please check the version with the `c.version` command? Here's mine for comparison Carbon 2.0.232.0/linux/2026.02.05.1 [production] [production_build] on Rust 988/2621.281.1 (02/08/2026 19:24:07)
-
The 1.0.19 version was for the Hotfix 5 update earlier today released by FP. Is your Rust server up to date?
-
Changed Fixed In to 1.0.19
-
Changed Status from Pending to Closed
-
Hi there! Thanks for reporting the issue. The 1.0.19 fix has been released on GitHub and Codefling, give it a go!
-
Any spawnable entity you add to your plugin, will be registered under a completely separate prefab path, like "/assets/custom/myattackheli.prefab". It won't override the vanilla prefab. That being said, designing a new attack heli from scratch might be way easier if you use Karuza's plugins, rather than doing it from scratch -
Changed Status from Pending to Not a Bug
-
Hi there! Yes it's possible to disable all the Power Line poles, although this is the main functionality of the plugin and the reason people purchase it! However, if you're sure, what you need to do, in order: 1) Load GridPower 2) Type the command `gp_emergency_cleanup` in the server/RCON console 3) You will see a message informing you about removing all the Power Line entities 4) Unload GridPower completely (NOT reload) 5) Edit your /config/GridPower.json file and set `GeneratorChancePowerlineFunctional` to `0.0` (as opposed to default 0.33), save the config file 6) Delete your /data/GridPower.json file completely from the server 7) Load GridPower After you load, no Power Lines will become usable, and won't allow players to connect to them. You can then look at each pole and use the command `/gp_pole add` to manually make them functional, or `/gp_pole remove` to disable them. Now to your second question: the streetlights becoming active (i.e. actually producing light) rely on the generated map itself. EVERY SINGLE pole on the map that has the static streetlights prefab on them will start shining - no more, no less. Which poles have the static streetlights, and which don't, relies on the vanilla random map generation which cannot be controlled by a plugin. The only way to increase the number of poles that have those streetlight "extensions" on top, and thus allowing too shine, is to create your own custom map and explicitly utilising the appropriate prefabs. There's also no way to change the intensity/size of the lights produced by Grid Power, as modding is purely server-sided and we rely on entities existing in-game that we spawn. We can't really change the properties of those entities. Hope this helps!
-
Hi there! Thanks for reporting. Sadly this doesn't tell me much, it's a generic hook error with many possible causes. Please hit me up on Discord and let's see what's going on! You can find me on the Codefling Discord or you can join mine at https://discord.nikhub.dev - make sure you quote your CF username and the purchase date to get verified!
-
To my knowledge, everything is working as expected, i.e. there's a good reason why precedence is decided in the way it is right now (i.e. based on the order in the config file). I also already explain the precedence in the section "Permission Profiles" in the product description: Would you have any suggestions on how to re-phrase this better, or perhaps add some additional info so that there's no doubt about how the permission profile precedence works? My goal here is to avoid any confusion in the future. I wrote this several years ago without perhaps fully realising that it might not be obvious to everyone. In any case, I appreciate your idea, and I will try to workshop some sort of a solution, like an extra config value that will help determine the precedence "sorting", for instance "by config order", "ascending order", "descending order". Oh and good luck with the wipe tomorrow!
-
Changed Status from Pending to Closed
-
Hello again, The issue with introducing any sorting based on priority here is deciding which tier is "higher" and which is "lower"! Some server owners treat "vip1" as "the best", some treat it as "the worst". Hence I decided on the compromise, i.e. there's no "alphabetical" or rather "alpha-numerical" sorting; the first item on the list is the first granted. If you'd like your Vip5 to take precedence over Vip4, Vip3 etc, I'd suggest swapping their order in your config file so that "admin" comes first, then Vip5, then Vip4 etc. That way, each server owner can decide which permissions take precedence over which, i.e. the sorting order. The "default" profile is not a permission, but a fallback to when the user hasn't got any admin/vip permissions, so its position in the order doesn't matter. Hope that helps!
