Jump to content

FernandoMTA

Members
  • Posts

    370
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by FernandoMTA

  1. 1 hour ago, Carl Rayanitch DZ said:

    It's important to keep evolving instead of getting stuck in the past. can't keep it 2007 all the time.

    Let's not be extreme like that, MTA isn't exactly stuck in time, it has evolved a lot over the years, although slowly.

    A roadmap of this nature would be beneficial for showcasing the project's big goals and give people an overview and better understanding of the necessary progress. I can't see any cons/downsides.

    • Like 1
  2. Currently, you can find Milestones on GitHub that track the intended updates for the next MTA release, as well as other issues for future releases (backlog).https://github.com/multitheftauto/mtasa-blue/milestones

    There are also several project boards on GitHub that track the progress of certain topics like Framerate fixes. https://github.com/multitheftauto/mtasa-blue/projects?type=classic

    I feel like these methods of showing the goals for the platform are limited. The milestones are just plain lists of GitHub issues and pull requests, with no categorization other than basic labels (ie. enhancement or bug).

     

    I believe that Multi Theft Auto should have a central development roadmap, like any major work-in-progress project, that lists the general goals for the platform and its services: we are talking not only about MTA:SA-Blue (the GTA:SA multiplayer mod), but also about its web services (like community.multitheftauto.com that should be modernized), and other plans. It is not a small project. It seems crucial that the objectives are organized in categories, and also sorted by priority that is according to the MTA Staff, Contributors and the community's general interest, as well as how everything spans across time.

    Why not create a Wiki page, a forum thread or a dedicated web page for this purpose? MTA still has a lot of improvements to make, and this would be a step towards more transparency and coherence. Everyone would appreciate having easy access to such information on the development process & plans. I often see people criticize MTA Staff for their lack of communication on the development of the main MP mod.

    PS. I know this Roadmap wiki page exists, but it pointed to a Roadmap on the old Bug Mantis, which essentially just became the GitHub milestones we have today. I believe something more detailed is necessary, like described above.

     

    Opinions?

    • Like 3
  3. 11 hours ago, BranD said:

    In the end I saw your code and I liked it, but there is a small error that you could correct, when you use the gameSpeed above 1 the head will bug, the solution is simple, put the following: setPedLookAt(player, vx, vy, z, -1, 0)
    Anyway, I appreciate your contribution to the community.

    Ah that bug is unfortunate :( However, passing -1 as the time parameter in setPedLookAt will make the head face that direction forever, and this is not a good idea because you want the player's head to reset in some circumstances (when they're aiming, for example, as coded in the script). 🤔

    4 hours ago, Stan1y said:

    This is an undocumented bug, but changing localPlayer's look at position prevents them from grabbing onto particularly high ledges they normally can grab onto. If you care about players being able to perform parkour normally, just like they would do in a singleplayer, you should avoid using setPedLookAt() on localPlayer.

    That's interesting. I'll test it. You should report it here if you have proof :-)

  4. doesn't really make sense to pick a serial on installing MTA, it's just a thing for admins and server devs 😅

    However maybe one day when community.mtasa.com is revamped we will have Usernames & everyone will have their unique community account connected... with unique nicknames etc

  5. 4 hours ago, Zekotron said:

    Sure thing

    (problem is I can't, think I need 20 posts to able to send a PM. Discord is more convenient nonetheless, but I'll try to get a workaround)

    Rip. Send me a friend req I'll make an exception 🙈

    • Like 1
  6. It's possible to have custom new vehicle & skin models in the Freeroam default MTA gamemode while not replacing any GTA vehicles or skins!

    Download & Instructions: https://github.com/Fernando-A-Rocha/mtasa-resources/releases/tag/v3.3.0-newmodels-freeroam

    • detects all mods you have added in your newmodels resource so you don't have to edit the lists (XML) manually
    • runs this procedure automatically when you start the freeroam_newmodels resource
    • there is a command for you to scan for new models and update the lists
    • involves very few code changes to the original freeroam resource
    • works flawlessly with newmodels, syncing the models of your server's vehicles & skins to every player automatically

    PS. The concept is very similar to what I did for newmodels Map Editor.

  7. @BranD @SDabdlmounaim96 Sorry but what you guys are saying about element data doesn't make sense. Look at the script BranD posted. It does setElementData on the localPlayer with the sync value to true (default), it is synchronized and BrenD's comment above is wrong. All other clients have this synced to them and can do getElementData on their side, to retrieve other players looking at position. This is how he syncs the looking at position, it's with element data that is transferred from the client to the server and then to all clients.

    Doing this every 100ms is not a good idea period.

    I'll look into what you said about ped aiming.

    2 hours ago, BranD said:

    I recommend that you test the system with more than 30 players, you will notice that it does not produce any negative effect on the server, the synchronization is client to client, not client to server and server to client.

    Previously, the solution for some was to use triggers, but that has an impact on the server's CPU.

    There is no such thing as client to client synchronization 

  8. @BranD

    Your script spams element data every 100ms, this is not good for the server. Synchronization calls will be too excessive and it will result in horrible lag.

    Your script also won't work properly as it's obtaining Z position of 10 with getWorldFromScreenPosition(width/2, height/2, 10), resulting in players' heads looking down or up if they're not at that height on the map.

    I had come up with a simple optimized solution that is 100% clientside: https://community.multitheftauto.com/index.php?p=resources&s=details&id=18882

    Please take this as constructive criticism, no offense.

×
×
  • Create New...