Approved Fougerite MC [Deleted]

[CorrosionX]

var y = World.GetTerrainHeight(Player.Location); That is all.

TY. allows me to remove several lines of code


Btw, I have been trying to use

World.SpawnAtPlayer(":wolf_prefab", Player)

However, it still fails to spawn wolf properly and causes the Navmesh placement error. I'm guessing the above code you suggested is preferred?

playery = GetTerrainHeight(Player.Location)
World.Spawn(":wolf_prefab", Player.X, playery, Player.Z)

 

[mikec]

Still having problem with World.Airdrop(); airplanes still getting stuck.

I guess you need to tell me more about when it gets stuck. I wrote a script to test all the variations of World.Airdrop* and couldn't get one to create stuck airplanes. I spawned as many as 20 (/airdrop 20), and it was spectacular when they all intersected overhead and dropped their loads at once. Several crates went spinning. I got squished once too. It says that on console "MC MC was squished."

I think it might be better if multiple airdrop spawns were spaced out about 1-2 seconds apart, and some fuzz added to the location so they don't directly cross each other's path.

But I couldn't get any stuck airplanes.

function On_Command(Player, cmd, args) {
    var test;
    var ad = 'airdrop';
    var blurt = function(s) {
        Player.MessageFrom(ad, s);
        };
    if(cmd == ad) {
   
        if(args.length == 1) {
            test = parseInt(args[0], 10);
            if(isNaN(test)) {
                blurt('Bad test');
                return;
            }
   
            switch(test) {
            case 1:
                blurt('Airdrop() test');
                World.Airdrop();
                return;
            case 2:
                blurt('Airdrop(3) test');
                World.Airdrop(3);
                return;
            case 3:
                blurt('Airdrop(6809.0, 360.0, -4304.0) test');
                World.AirdropAt(6809.0, 360.0, -4304.0);
                return;
            case 4:
                blurt('AirdropAt(6446.0, 360.0 -4667.0, 3) test');
                World.AirdropAt(6446.0, 360.0 -4667.0, 3);
                return;
            case 5:
                blurt('AirdropAtPlayer(you) test');
                World.AirdropAtPlayer(Player);
                return;
            case 6:
                blurt('AirdropAtPlayer(you, 3) test');
                World.AirdropAtPlayer(Player, 3);
                return;
            default:
                blurt('AirdropAtPlayer(you, ' + test.toString() + ') test');
                World.AirdropAtPlayer(Player, test);
                return;
            }
        }

    }
}

 

[mikec]

I'm running your EasyAirdrop now. Just downloaded it. No problem so far.

 

[mikec]

I changed your plugin to drop on me 20 planes every 20 seconds, and it took about 20 minutes for the server to crash, and I didn't get a single stuck airplane.

 

[Jakkee]

I changed your plugin to drop on me 20 planes every 20 seconds, and it took about 20 minutes for the server to crash, and I didn't get a single stuck airplane.

I spawn in about 700 Planes and not one got stuck. But it has happened on my server.
Just randomly it freezes and you can build up to it and sound of it never goes away.
They only way to remove it is by a restart.

 

[DreTaX]

Try to use the official legacy server from steamcmd and crack it if you need it with lumaemu

Sent from my Samsung Galaxy S4

 

[Jakkee]

Try to use the official legacy server from steamcmd and crack it if you need it with lumaemu

Sent from my Samsung Galaxy S4

It hasn't happened for a while now but it was offical server files, Hosted with streamline.

 

[DreTaX]

Humm. Now that you say streamline i gotta check mails for their upcoming support.

Sent from my Samsung Galaxy S4

 

[mikec]

I thought it might be planes spawning on top of each other but they don't seem to collide with other planes. If you spawn 20 at once on your location they all converge overhead like an impossible airshow and the supply drops go spinning wildly (they do collide with each other).

In the next MC release, calling multiple airdrops adds "fuzz" to each location so they all don't converge at the same spot, and they are spawned on timers to space them out a second or two.

 

[Jakkee]

When it happens it seems to happen around Mt Everust.
That was for me, Only happened around the Mount.

EDIT: Had a look on a rust map and the Mount is Called: Portugal Mountain
Last time the plane was flying from Mt Everust to Mt Portugal.
Might have something to do with location?

 

[CorrosionX]

When it happens it seems to happen around Mt Everust.
That was for me, Only happened around the Mount.

EDIT: Had a look on a rust map and the Mount is Called: Portugal Mountain
Last time the plane was flying from Mt Everust to Mt Portugal.
Might have something to do with location?

Yeah, I agree with this, seems its always the same spot/area. I could be a specific spawn point cause the plane to fail clip through the mountain and instead get stuck near or on it. It's odd. Glad my plugin wasn't causing the issue. Maybe I should spawn many onself while on top of Mt Everust..

 

[mikec]

Interesting that it occurs near Mt. Everust. I will try to reproduce it, and if that's the association, then I'll make sure it avoids calling them in areas where they get stuck.

Although, I ran many tests from location x= 3600, z = -5100 which I call Ballzack Corner because it is at the end of the boulder decorations on the Ballzack side of the map, at the foot of Mt. Everust. Planes clipped through the mountainside no problem, from that location.

 

[mikec]

I just successfully tested spawning repeat airdrops from timers with escalating intervals. And I got my first stuck plane. I also got a plane stuck on a supply crate, and it drifted down to the ground. But I clip right through it.

This is all detectable and fixable after-the-fact. I'll make the last timer check 30-45 seconds after the last plane, and despawn any planes it finds still hanging around.

 

[CorrosionX]

I just successfully tested spawning repeat airdrops from timers with escalating intervals. And I got my first stuck plane. I also got a plane stuck on a supply crate, and it drifted down to the ground. But I clip right through it.

This is all detectable and fixable after-the-fact. I'll make the last timer check 30-45 seconds after the last plane, and despawn any planes it finds still hanging around.

Glad to hear it! Very odd bug. Even eluded you for a bit XD

 

[mikec]

Airdrops have a very nice distribution now. The larger the drop, the more spread out it is.

Do not call World.AirdropAt() from a loop in your script. Your script loop can't run fast enough to spawn a multi-plane drop safely. Instead, pass it a number indicating how many you want. Stuck planes happen when you call an airdrop while another one is still in progress. But if you call them in a foreach loop in C#, it works and they all spawn at once. I added code to make sure only one airdrop is in progress at a time.

 

[mikec]

If people want to spawn multiple airdrops at a specific set of locations, rather than at random locations, or on a player, then I can add a method that takes an array of Vector3 and spawns airdrops at each.

 

[mikec]

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++ chat name is customizable.
4. Rust++ command choices work again.
5. In the process of fixing Rust++ command choices, I broke the /i and /give commands. They don't recognize the item name.
6. To fix this, I have written a new item name parser, which is a lot more forgiving. No quotes or capitalization is required anymore. You can abbreviate item names to the 1st three letters, if those are unique. For example "/i exp cha" give you 1 Explosive Charge while "/i explosives bp 10" gives you 10 Explosives blueprints. "/i leathervest 1" "/i lea ves" "/i leather vest 1" are all equivalent.

I need to test #6 a bit more with the /give command, and then I am ready to release.

Are there any other major outstanding issues with MC6 that I did not address in the list in this post? Speak up now or wait until MC8.

 

[Jakkee]

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++ chat name is customizable.
4. Rust++ command choices work again.
5. In the process of fixing Rust++ command choices, I broke the /i and /give commands. They don't recognize the item name.
6. To fix this, I have written a new item name parser, which is a lot more forgiving. No quotes or capitalization is required anymore. You can abbreviate item names to the 1st three letters, if those are unique. For example "/i exp cha" give you 1 Explosive Charge while "/i explosives bp 10" gives you 10 Explosives blueprints. "/i leathervest 1" "/i lea ves" "/i leather vest 1" are all equivalent.

I need to test #6 a bit more with the /give command, and then I am ready to release.

Are there any other major outstanding issues with MC6 that I did not address in the list in this post? Speak up now or wait until MC8.

Was /AddFriend and /share fixed?
I think with every restart the data is lost

 

[mikec]

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.

 

[mikec]

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 ID that is applied to structures and deployables. If you updated your cracked server to the official Legacy server files, and did not wipe your map, your structures are still owned by the altered SteamID. If you updated your server and did wipe your map, but did not wipe your avatar.bin, your new structures are still being assigned the altered SteamID from the avatar.bin. I'm in this situation. My test server on my PC used to be a cracked copy. I had downloaded my save dir from my FPSplayers server to my local copy, played on the local copy and then copied it back to the public server since. So both now have a avatar.bin for me with the altered SteamID, and buildings I start today get owned by the cracked SteamID, even though there's no crack and both servers have the official Legacy server files and have clean new maps.

I had taken a break from banging my head against the wall trying to figure this one out. I discovered the underlying problem while messing around with some other ideas. I'm going to get back to fixing Fougerite now that this blocker has been moved. Sometimes you just have to step away and let a problem sit for a while. I hope I can get a release out with this fix and the others very soon.

Now... where was I....