-
Posts
866 -
Joined
-
Last visited
-
Days Won
1
Everything posted by Mr_Moose
-
A lot of people have been asking for the AI features seen in the original server which wasn't found in the Github project, until now. There's a new folder in the root directory simply named "traffic" which contains the bot system with peds and cars on the road by CrystalMV, and slothbot by slothman. Thanks to these two great resources a lot of new features is now available in the GTW-RPG project, simply named "the AI features". Features: Criminals can now kill bots to steal their money and they'll get wanted for it Criminals can hijack cars from bots and get wanted, the driver will also try to attack and kill you as a revenge (thanks to slothbot) Bots help's wanted players to hide since they can sneak into the back of a van or simply act like a bot and the cops won't see the difference until they get really close. Bots can create traffic jams or do unexpected things which makes police chases more interesting since either the cops or the criminals can crash at any time due to unexpected situations. Modifications: Some modifications to the original resources has been made, including calls to GTW resources, adjustments in traffic density and a function to make sure that bots won't spawn to close to a player or inside a player (which could happen to a player with high latency).
-
Well, dxDrawText itself it a pretty CPU hungry function and you got at least 5 of those (usually gives around 10% CPU usage), you could build your text as a single multi line string first and then send it to the draw function once to reduce your CPU usage to 2% maybe 3% if your lucky. Table unpack is quiet heavy too, maybe you could skip that and pass the data directly as it is using index numbers instead.
-
Are you running with the -t option? Ex: ./mta-server -t ...
-
First of all you need to understand the code, then you can describe your problem and finally solve it. Three basic steps which I should now try to help you with. As a start you should ask yourself from where you can get the current coordinate(s), hint: in the server side files you'll find a function simply named "get" which collects the coordinates from meta.xml, between the tags. Now here's your real problem, without even looking at the NG game mode it's obvious that you first of all need to change how you store the coordinates in order to map multiple coordinates to each others. So here's the steps you need to take in order to solve this: Consider a different storage solution for your coordinates that supports multiple locations, (i.e a table) Add some kind of index to these tables (i.e "LSPD" and/or "SFPD"). This way you know where a player got arrested and thus where to release. Consider where to store this index, (i.e as element data) Consider which coordinates you intend to use, if you want someone to do this for you this is a post you should provide yourself at least. And that's pretty much it, the solution is simple as long you know the problem.
-
Assuming that you run it in a screen session you simply need to reconnect to the screen session, to do so: screen -ls To show which screen sessions that is currently active, then: screen -r <name-or-id> Where is the name or process ID of the screen session seen in the list you requested earlier. CTRL + A then D is used to safely detach from the screen session if you wish to run another command without having to stop your server. For more info, see: screen --help
-
The problem here is that the function "findRotation" only returns the rotation in z axis while setElementRotation needs a vector with x,y and z, the solution is simple however. Change line 11 from this: setElementRotation(test, findRotation(x,y,rotX,rotY)) to this: setElementRotation(test, 0,0, findRotation(x,y,rotX,rotY))
-
Variable test can be local, it's in the same file so that's not the problem. The function however is called by a keybind you set during resource start (noticed this is a client side resource) so you should use localPlayer instead of source. Your first two errors are caused by the fact that there is no source defined in that function. Moving on to the third error which is caused by an undefined function called "findRotation", you may have spelled wrong or forgot to define it, in any case there is no such function built in.
-
Introducing the new 2D view (/2d to toggle) and the ability to zoom in and out in the view using +/- keys. In other news the help system has received some major updates as well and a introduction system will soon be published, all to help new players getting started and learn how to play in this game mode using pictures and very basic text information to provide enough information without making people bored from reading. Some misc features regarding registration, skins, hud components, radio stations in phone and much more has been updated as well. What's next? Some feature highlights to v3.0-beta3: Major GUI updates using DX components Implementation of perfect trailer synchronization and other vehicle related features Updates to vehicle system to make driving even more realistic, things like manual gearbox, damage vs engine power etc is already under construction Heavily improved help/support features for new players informing about how everything works in a simple way. Enjoy the game, and don't forget to follow us in social media for the latest news: https://www.404rq.com/
-
Ok did you install all needed libraries then: (64bit host and 32bit server for instance) apt-get install libreadline5 libncursesw5 unzip libncurses5-dev lib32z1 lib32ncurses5 lib32ncursesw5 lib32stdc++6
-
There are some *.so files in mods/deathmatch too, did you chmod them too?
-
You need to chmod the library files too like core.so, net.so and xmll.so. Giving one application right to execute doesn't allow that application to execute any other non executable application in your system, it's a matter of basic security even if the error message may seem a bit confusing. chmod u+x core.so net.so xmll.so
-
It is possible and you could get pretty good FPS on that as well, although let's list the pros and cons. Pros: It has a 900Mhz Quad-Core processor which provides fair performance 1GB RAM will also be sufficient enough for a mtasa server as it's pretty optimized in that area One time hardware costs, it works as long as it works and it's a cheap choice for a server Low power consumption, yearly costs will be just a few dollars Full root access and control over your own hardware etc.. And now the cons, and there are many of them sadly. This is compared to a normal VPS or a cloud VPS, if the specific feature doesn't matters for you then you can safely ignore that from the cons list, I'll just list everything that comes into my mind here. Cons: It has a 900Mhz Quad-Core processor, the mtasa server is single threaded (correct me if I'm wrong) so you'll just have 900Mhz on a single core to play with while most VPS solutions allow you to use up to 3-4GHz/vCore. A slow CPU could make your server laggy if you run badly optimized resources Bandwidth: you can't get away from this cost and you'll need some extra in order to run your server, note that anything else you do on that network will affect your players latency, if you download a file you'll overload your bandwidth causing your players to get timeouts, there's no ddos protection on a home network and you'll lose your connection on all your devices in case of a ddos attack. Power: although the power consumption is low there's no backup batteries if you loose the power and your raspberry pi might get damaged or corrupt it's SD card if it loose the power in the middle of something Not sure if mtasa has been compiled for the ARM CPU architecture yet, you may have to compile it yourself or it might not be possible to run it at all. No scaling options, if your server get's popular or lacks of players you'll always be there with your raspberry pi without possibilities to upgrade and support more players and if you lacks of players you may wanna find a different usage area for it. No support, if something happens you need to be on spot and solve the problem manually 24/7 if you plan to even get close to 100% up-time which you'll never reach. Storage: an SD card formatted to Fat32 will always be slower than most hard drives and nearly all ssd drives, not just in read and write but also in access time. Slow access times will be noticed by your players as lag. This occurs even on a SD card 16-32GB size in the $30 class. Safety: you'll need to find a safe place to store it at, the average temperature is 40-50 degrees Celsius, and most important the charger needs to be a good one (at least 2A). You may have heard all the stories about burning mobile chargers, that's what you'll have to use instead of a normal PSU. Although if you have an old PC nearby you could get your power from one of it's USB ports, even when it's turned off. And that's it for now, consider all that and decide what's best for you. If you change your mind and decide to use a VPS instead here's my two favorites starting at $5/month/vps: www.digitalocean.com and www.vultr.com both with rebate codes at $10 and $7 respectively. Good luck.
-
A free VPS may be hard to get but if you go for a cloud VPS they usually have generous offers for new customers like try it for free in 2 months or a rebate code that gives you some money to try the service for free for a limited time. They are usually relatively cheap too, not as cheap as a raspberry Pi but considering what you get for the money they are. A raspberry also needs some accessories like a charger, a chase, micro SD card, additional cables not to forget the extra bandwidth running a server on the home network requires. By using a cloud service wisely, i.e add swap space on their fast ssd drives for extra ram and not buying more performance than you need you could probably have that for about 2-3 years for the same price a raspberry pi plus all it's accessories would cost, (bandwidth not included). So with that said here's my recommendations: www.digitalocean.com ($10 rebate code included) www.vultr.com ($5 rebate code included + $2 if you follow them on twitter ) At the end I think the bandwidth as well as lack of security are the two main arguments against running a server on your home network, I mean if you download a file on another PC in that network you'll increase the latency for all your players, you would need at least 30mbit/s which would cost at least $20/month (a cloud vps in contrast provides you with a 1Gbit/s line included in the price of the vps starting at $5/month) and there won't be any latency increasing conflicts like the normal usage on a typical home network could cause. Another thing is the power, a data center usually has UPS for their servers as well as diesel generators to avoid going down, on a home network on the other hand you simply don't have that kind of protection, if you're out of power there's nothing you can do. Same thing if someone decide to launch a ddos attack against your server you're an easy target and nothing on your home network can access the internet. As a conclusion I think it's time to lock this thread now since it doesn't live up to peoples expectations anymore. I might start a new thread in order to collect all the reasonably priced hosting solutions in one place, unless someone else do it before me. There's obviously a big interest in reasonably pricing.
-
Depends what FPS limit you set, MTA supports 100 FPS theoretically, most displays support 60 FPS and that's what I would recommend you to use on your server, although 60 FPS causes a few bugs related to swimming making you swim slow if I remember right so to get the most out of the game from a technical perspective 36 FPS is recommended, although that would look and feel laggy on displays that support 60 FPS so go for 60 in your server configuration and connect with a display that runs at 60 on a proper computer. With all that in mind you could easily expect 60 FPS all the time. Lack of threading support may be the major threat since a raspberry comes with multiple cores running at low frequency. You may also consider a fast SD card as slow IO operations could cause noticeable lag as well (learned that from using a USB stick in the old laptop with slow access times even if the IO operations itself where faster than the internal hard drive). As a final note I would not recommend this solution anymore, mainly because power and bandwidth would cost almost as much as the new cloud based solution I'm currently working on, even if you use a raspberry pi which doesn't need much power at all. Lack of scale ability, ddos protection, ssd disk performance (SD cards are usually just as slow as normal hard drives), bandwidth and the ability to choose where in the world you would like to have your server at are all valuable arguments against using a raspberry pi as host for your mtasa server, although if you can live without that, if you already got proper bandwidth and the pi itself it's definitely a cheap solution in a long time perspective for a small server for yourself and your friends.
-
libncursesw.so.5: cannot open shared object filE.
Mr_Moose replied to artem1cat's topic in Linux-Server
That's a tricky one, the name seems to differ from the actual package name. My solution was to make an installation script out of it, so to make a long story short, these are the packages you need to run a 32-bit server on a 64-bit system (tested in debian): libreadline5 libncursesw5 unzip libncurses5-dev lib32z1 lib32ncurses5 lib32ncursesw5 lib32stdc++6 A quick guess would be this one: lib32ncursesw5 but it won't hurt installing them all just to avoid further errors. Good luck! -
Although catching the streaming events is a good start, it's also just the half answer. The complete answer is to also include client side positioning, meaning that during stream in you would have to set the towed vehicle's position to the exact right position behind the tow truck. Let's have a look at the code which would bee something like this (without positioning): addEventHandler("onClientElementStreamIn", getRootElement( ), function ( ) if not getElementData(source, "GTWvehicles.isTrailerTowingVehile") then return end local trailer = getElementData(source, "GTWvehicles.attachedTrailer") attachTrailerToVehicle(source, trailer) end ); addEventHandler( "onClientElementStreamOut", getRootElement( ), function ( ) if getElementData(source, "GTWvehicles.isTrailerTowingVehile") then local trailer = getElementData(source, "GTWvehicles.attachedTrailer") if isElementStreamedIn(source) and isElementStreamedIn(trailer) then detachTrailerFromVehicle(source, trailer) end elseif getElementData(source, "GTWvehicles.isTrailer") then local tower = getElementData(source, "GTWvehicles.towingVehicle") if isElementStreamedIn(tower) and isElementStreamedIn(source) then detachTrailerFromVehicle(tower, source) end end end ); Source: https://github.com/404rq/GTW-RPG/blob/master/%5Bresources%5D/GTWvehicles/vehicle_client.lua Assuming the towed vehicle knows the towing vehicle stored as element data and vice versa, this was originally written for trucks but the principle should be the same for tow trucks too. Now the problem with this is that even if it does work and attach and detach upon stream in/out the trailer doesn't know where the truck is and vice versa so the trailer could be in another lane of the road or even further away but still somehow attached to the truck. Even trains are affected by this streaming issue where the cars attach/detach in an apparently random way, but here's the interesting part. Since trains always corrects their position by following the tracks this idea works brilliantly so applying the same for trucks and remaining towing vehicles would require client side positioning during stream in. Now I haven't tried that yet but I'm 99% sure that's the solution, if you just manage to position the trailer/towed vehicle in the exact right position according to the towing vehicle. I don't have any screenshot of the problem but here's a server running this (without positioning) so that you can see the problem, bring some friends and follow a towing vehicle while it streams in and out to see what happens to the trailer: mtasa://lon.404rq.com:22005. I would appreciate if anyone can confirm the solution if they manage to make it work before me.
-
Seems like your server is running out of memory, check the Lua code executing during the join event and make sure it's not a memory leak there. Also make sure that your physical server has enough memory, you can find that out running Task manager (Windows) or Top/Htop (Linux) when it happens. If this random dude also has access to runcode somehow that might be the problem as well, check if he's in your ACL file, maybe he's been a member of the staff team previously with admin/dev access. Last option would be to update your server binaries to make sure you got the latest version, get it here: https://nightly.multitheftauto.com/
-
You could either store them in a table or assign a element data value upon spawn in order to identify them when looping through all vehicles to remove the player owned vehicles. If you create them using a map file you can identify them by which resource that owns them. -- Spawn part local veh = createVehicle(...) -- Table veh_table = { } veh_table[veh] = true -- Element Data setElementData(veh, "isPlayerOwnedVehicle", true) -- To remove for k,v in pairs(getElementsByType("vehicle")) do if getElementData(v, "isPlayerOwnedVehicle") or veh_table[v] then destroyElement(v) end end
-
It's not sure that onClientVehicleCollision will trigger when a player tries to push the vehicle as it's the player colliding to the vehicle and not the opposite, it's worth a try however. And once it triggers, the controls of the player may toggle temporary to force the player to stop using: SetControlState and ToggleControl. I've been using these for players with high latency for a while with good results so it might be a useful combination if implemented right. Good luck.
-
You're welcome. As mentioned earlier the main focus of December 2015 has been on core improvements and optimization, now in January 2016 the main focus will be the GUI's and documentation to improve the overall user experience and simplify the gameplay for new players. Due to that the release before Christmas 2015 was beta2 rather than the final 3.0 release, we wanna make sure the GUI's and user experience is perfect in the final release. v3.0-beta2 can be downloaded here. Enjoy.
-
The problem appears to be in your database, first try to access your database using another client like phpmyadmin (if available) or a terminal window, if that doesn't work then you must login as root and grant your user all needed privileges to that database, don't forget to flush when you're done. Here's some further information that might help: http://stackoverflow.com/questions/10299148/mysql-error-1045-28000-access-denied-for-user-billlocalhost-using-passw?rq=1 It doesn't seem to be any issues in your Lua code, dbConnect is still preferable and shouldn't have any trouble connecting to a mysql database.
-
Now when I got your attention, the whole week 51, (from Monday 14 December to Sunday 20 December), we'll host a great event where all online (non AFK) players will earn $1000 in game each 5th minute. Money makes everything funnier so don't waste this great opportunity. Welcome! Join link mtasa://lon.404rq.com:22005 Server topic https://forum.multitheftauto.com/viewtopic.php?f=115&t=82049
-
Loop through all players quickly and compare their ping to each other, once this piece of code is finished you will have the player element with the lowest latency and the value of the lowest latency in the two variables on line 1. local plr_lowest,lowest_ping = nil,9999 for k,v in pairs(getElementsByType("player")) do if getPlayerPing(v) < lowest_ping then lowest_ping = getPlayerPing(v) plr_lowest = v end end Last but not least you will have to call: setElementSyncer(train, plr_lowest) Assuming "train" is your train element, if you have trailers attached run a loop there as well to make sure all pieces has the same sync element. Although I'm not quiet sure about the occurrence of this if It's fair enough to set it just once, if it overrides MTA's default choice or if MTA overrides this at a later time and if so for how long time. I guess it's something to experiment with until you'll find a suitable sync. I'm currently using a basic timer for this syncing with the train engineer so the code above is just a quick non-tested example but in theory it should work and hopefully provide a fair enough (but not perfect) sync.
-
Having everything synced for one player only is fairly easy, the problem is when multiple players are nearby a moving train, all with different latency and FPS. Each element has a "sync element" a player who is responsible to keep the element synced and this might work for vehicles and single cars but as soon trailers are involved, no matter if it's a train or a truck with a trailer attached there may be different element syncers for the engine and the attached trailers and that's the main reason for the bad synchronization. There's also an issue with trailers that detach once the engine is streamed out, obviously not for the driver but for players seeing the vehicle stream out and then in again it's noticeable. Two things to consider on that area I could recommend is to detach any attached vehicles when they stream out (client side only) and then attach them again when they stream in. Secondly, make sure that the element synchronizer is the same for all trailers in the chain, preferably the player with lowest latency or the driver. Although I haven't noticed this on trains very often it's a common issue with the trucks: Linerunner, Tanker and Roadtrain. It's encouraging to see more people trying to make use of trains in MTA, best luck
-
Well it might not be the best solution but what I do to keep my trains still is to check their distance to defined coordinates stored in a table, and as long the train is within the station area they are not allowed to move at all. The speed is set to 0 strictly, controls like ability to move back and forth are disabled and that's all it takes to keep them still. Of course this only occurs for a limited time thanks to an indicator which is set to true while the train is still, then when switched to false another value is set to true forcing the train to override it's acceleration so that it can continue it's ride. At the end of the track you do want it to stop. You may also find some inspiration here even if some features could have been implemented better, at least for the sync.