Search results

I refactored Rust++ back into the core this weekend, and it was easier than I thought it would be. The June 16 (approximately) version works (/share /friend, etc). It also saves and loads the friends and share data properly. I'm not really sure when it broke. Do any of the MC releases work...

FPSplayers had to move the server off of failing hardware. Effective now, the server's new address is: net.connect 192.200.111.163:28025 net.connect rust.clandestina.la:28025

...scooting a tumbleweed out of the way.... I learned from my testing this weekend (did anybody else test?) that wiping only avatar files and map save files isn't enough to restore the SteamID matching the OwnerID for structures and deployables. But wiping all server files and re-downloading...

It doesn't seem to have anything to do with having had your avatar.bin file loaded on a cracked server. I've wiped all player and map data on my FPS players server, and the probem remains. My structures and deployables have an ownerID that is different from my SteamID. So any commands that...

Yeah, that's fixed in the version I am trying to get in shape to release. Player names and item names in commands are matched with a suffix tree algorithm, similar to autocorrect. Slight misspellings are even tolerated.

Did you mean to comment the second timer? Because even though it's using SafeTeleportTo, it's still telling me it's doing it twice for safety reasons.

I had hit a wall trying to find the cause of the friend and share commands not working. I took a break and messed around with some other stuff for a while, including some of the ideas in this thread. The solution to the friend and doorshare commands surfaced while I was messing around with...

I believe I have discovered the reason /addfriend and /share don't work for many people, including myself on my own servers, public and private. If you have run a cracked server, the crack alters the SteamID stored in your avatar.bin file (changes the last digit to zero). It seems this is the...

Voting is closed. :rolleyes:

Please continue this thread at http://forum.pluton-team.org/

has a forum devoted to it now. Please click on over there and sign up to continue these discussions. Thank you for your support! forum.pluton-team.org

I'm 51.

You're doing it backwards. basePlayer.transform.LookAt() is called by the client using RPC to update the server-side player object, so it is looking where client-side player object is now looking.

System.Threading.Thread.Sleep(float milliseconds);

Thank you for reminding me. I have looked at that problem but don't have a fix yet. I'll take another look this evening after testing #6 some more.

Status report: 1. I have not forgotten about Fougerite. Look at the Pluton github. I haven't made any commits there. Fougerite code is the only code I am working on 2. I have fixed airdrops to avoid stuck planes and create a more pleasing distribution for multi-plane events. 3. Rust++...

DataStore has a new method ToIni. DataStore.ToIni("filename"); // saves it to the top-level Fougerite folder. Any data that was not a string is converted to a string. Null values are saved as the string "NullReference". You can't restore the DataStore from this ini, but it can help diagnose...

When lanterns can be turned off, I'll update MagmaFires for Pluton. :)

Not in the current version MC6 or earlier, it's not. I've fixed several issues in IniParser that were leading to data loss and/or plugin crashing that haven't published yet.

That's what a Vector3.ToString() looks like. To convert the string back to a Vector3, strip the parentheses and commas, and parse each number to a float. Then use them as arguments to instance a new Vector3. This is exactly what DataStore does when someone saves a Vector3 to it, and recalls...