Hey there folks. Well, as I mentioned back in my dice rework thread, I have time to start working on some small projects. Yesterday I took a look at the docking module plugin, and I think I have a few suspicions as to why it was causing issues.
Docking Module Rewrite
I intend on keeping this thread updated with the progress that I make with the plugin. Yesterday I managed to get a large chunk of work done, so later today I should be able to see some results of testing. I make no promises that this approach to organizing the plugin will work, although we won't know until it's attempted I suppose.
I've noticed that there was a lot of extra code in the plugin. Some seeing to be intended for potential features. The backbone behind the plugin itself, is writing data to your ships save file. This information includes data on if you're docked to another ship or not, and data regarding if you're a carrier holding other ships. (Docking and undocking is handled by proxy bases, and the undock Hook)
While this has been proven to work with the event plugin (which uses this same method for some of its cases) - I've decided to replace that method of saving and and writing. Instead using separate file operations instead. (Much like how player bases are saved)
Because of this change, I've designed it so that files are actually saved and loaded a lot less frequently than they were previously, although rest assured, I'll do some extensive testing to make sure that saving less isn't causing bugs or problems
FLHook has never really had issues maintaining lists and maps internally. Will this approach work? Maybe? Maybe not. A lot of the extra features have been removed from the plugin, as I'll make sure it works barebones, before building on top of it.
I am still using some old code which I figure wouldn't cause any problems overall, so I can't be taking terribly much credit. A big thanks to Alley/Any of the other devs who worked on this previously.
I'll keep this thread updated as I work. Again, hopefully I'll be able to get some test results back later today. I'm concerned on how I'll be able to test this in a more populated enviroment. Sounds like something I'll be talking to the Admin team about provided things go well locally.
I salute you for your dedication, @Remnant! I would absolutely love to be able to hide a snub onboard my Bison. Docking modules are something I never got to play with, and they have good potential for smuggling people through areas that might otherwise be hostile to them. I wish you warm winds and highest luck in this endeavor!
The Gaelic Wyvern Inn
If you've interacted with us recently, please consider checking out our in-character Public Guest Reviews thread!
A large number of my ships that survived activity wipes have docking mods on them- so this working would be a great boon to my wallet
Kidding aside: docking mods were a great inclusion to the game and when they worked, made rapid strike deployment useful through the use of shared accounts. Best of luck in getting it working mate~<3
[ sci·am·ach ]
/sīˈamək/
A simple, angry man casually working his way through life on a personal quest to acquire copious amounts of street cred.
Alright, I've worked on and off for a few hours and have made some headway. Currently the plugin is functioning again with the following features
Can request dock on a vessel with docking modules
Carrier ships get a notification, and can approve said ship, docking the snub aboard
Carriers can dock as many ships, as the number of modules they have mounted.
Snubs can now undock and appear outside of the carrier (This was causing crashes for a while. Thank god that's fixed)
You might say that these are features which existed previously! - You're absolutely right. That's the core behind the plugin, more or less. I'm simply making some of the internal operations work differently, in hopes that the server bugs won't come up with this version.
Todo list
/jettisonship command - Allowing user to eject docked ships
If the carrier is currently docked, the nested ship should undock outside of the base the carrier is in.
If the carrier is blown up, all of the docked ships should be ejected out into space
Write saving/loading commands. (Handling if players disconnect, reconnect, or if the server restarts) -- I expect this to take the longest
That, and obviously porting over some of the anti-exploit functions of the old plugin.
This so far is still a re-write. Not an upgrade. Maybe some shiny features will appear on the list if the plugin is restored to the same functionality that it had previously, and is proven not to cause problems.
I've got some work for Uni' I've gotta deal with. I'll get back to this tomorrow.
Edit: Time to get to bed for real. Finished a few more features.
/jettisonship now works. - You may not use this command while docked. (Although this is probably gonna change)
If a carrier is docked, if you undock as a nested ship, you're automatically docked with the planet/station the carrier is on.
This is going a little more smoothly than I was expecting it to. All of the planned core features are now implemented, besides persistence between disconnects, reconnects, and restarts. - The framework for the remaining part is already in place, so I should have everything completed by tomorrow or the following day.
Afterwards, there'll be a small period of testing (quite literally me doing everything possible in an attempt to break the plugin) - Provided that things go well, I'll wrap things up and call this rework ready for implementation!
Properly functioning docking modules is a plugin in high demand. I'm really looking forward to being able to utilise them as intended. Let me know if you need help testing.
The issue with docking modules is that they were causing the infinite jump bug. Do you have any idea which piece of the code was causing this and why, and whether or not it can actually be replicated in singleplayer?
No. It cannot actually be replicated in singleplayer. Although you can't properly test/run the docking module plugin from singleplayer anyways. You kinda need FLHook running in the background.
Testing is being done on a local server with the plugin loaded. Regarding it being in a live setting, we'll simply have to try it. It takes 10 seconds to disable/remove the plugin if it still causes a server-wide bug.
Regarding the infinite jump bug in general, while I cannot say with 100% certainty that I know exactly what was causing it. However that being said, I did have a few ideas.
Yes. This is a stab in the dark (An educated one). Although I guarantee that enough of the internal fundamentals of the plugin have been changed enough, where I'd be rather surprised if the bug persisted. It may still happen, and if it does, we'll simply disable this rework as well.
The biggest difference between this version, and the old version, is ships save files are no longer being saved to. Instead, data is being stored to a directory in the filesystem much like how playerbases are saved currently. - The rate at which things are saved and loaded, is also drastically reduced. (I'll make sure that it's happening often enough, though. It comes down to figuring out which triggers are needed, and which are not)
FLHook has never had problems maintaining maps and lists before. I'm forcing the plugin to rely more on the standard FLHook functions, without constantly having it read the save files of each individual ship on the list.
@Mephistoles - I'll throw you a compiled plugin once I'm confident that things are all set. I'd really appreciate someone else looking around to see if I missed any bugs. - If you don't think you can do it easily on your own, I'll see about hosting a temporary server somewhere with it running.
![[Image: stDvDRX.jpg]](https://i.imgur.com/stDvDRX.jpg)
![[+]](/forums/images/collapse_collapsed.png "[+]")
StillNotEnoughScreensForThisCrap.jpg![[Image: image.jpg]](http://image.ibb.co/nB98Un/image.jpg)