Interesting topic, it also underlines a crucial point in general programming : the logic behind it.
GET_PED_NEARBY_VEHICLES, GET_PED_NEARBY_PEDS are are standard natives used when trying to collect entites in order to handle them. Yet they are the "most simple" way to achieve it. When a user has other scripts running in parallel, it can but only overload the CPU if it's called too often.
This is why I never leave the entites' handles out of range. If I need to work with a huge amount of peds, I must know exactly which list they belong to and what are the instructions run behind. OOP allows it, create a separate ped class, make an exclusive ped thread for them, run the code logic inside. Any entity you want to handle must be handled by your own script before they get collected from within the game.
Unfortunately, every "beginner" jumps on pre-built functions such as World.GetNearbyEntites
because it saves a lot of extra-time but at the cost of extra-performance.
@EnforcerZhukov The drive task does not work good on planes. I only use it to taxi on runways. Use TASK_PLANE_MISSION not part of SHVDN so you need to use function calls and unsafe code. In visual studio go to properties build and check Allow unsafe code(if you dont know). Also you can apply force to get them moving after they spawn so they dont dive as much.
Yes it is possible. The problem is if you do you would have to remove those mods that change your skin. And loose all of there features. So you would have to make a mod to change the skin as well as keep the skin until the screen fades then switch, wait to resurrect, and switch back.
There is no set of rules that will get a mod featured. At the end of the day, I generally look through the most liked, most downloaded and highest rated mods from that day and try to feature some that represent each category of the site. I'll go through some concerns I usually get:
"My mod has X likes and that featured mod has fewer, but mine wasn't featured!"
I look at more than just likes, and I look at them within a one day period. Sure a mod from a month ago will have 50+ likes and the one from today might have 10, but the rate at which it gained likes was higher, and I usually only feature files from the past day or two. Also if all four of the top liked mods from the day are vehicles, I generally don't feature all four.
Community interaction on what gets featured
I never really understand this request - the featured mods are already decided by the community. They are based off downloads, likes, comments and ratings, all things that require the community to interact with a mod. Do you really want yet another mechanism for voting? I don't think that's the solution. The only thing missing here is an automatic trigger that features something when it gets to a certain like + download count. And this is a favor to everyone who isn't a vehicle modder - you probably wouldn't get featured without admin intervention because vehicle mods generally dominate in terms of likes and downloads.
That all said, I will admit that I used to not be good about this, and a lot of great mods in the past went unfeatured. I'm trying to make up for this by featuring them now when they get updated with new versions.