Add hedit

[jlillis]

hedit is an in-game vehicle handling editor. It is widely used to play with vehicle handling in development and freeroam environments. The code quality is on par with existing resources in this repo, with a number of the original authors also contributing to this repo regularly.

This commit adds hedit by performing a quick and dirty subtree merge. It is located under [editor].

[xLive]

I think [gameplay] is more suitable for it

[jlillis]

Based on feedback I've moved hedit to [gameplay]. If there aren't any objections, I'll be merging this in the next few days.

[jlillis]

Original documentation stated that this resource needs admin privileges to work properly, but I can't find any actual reason for that in my testing and review of the code.

Also note that the original hedit repository will be archived after this is merged.

[jlillis]

Could another repo member give this an approving review? Repo policy prevents me from merging this without one.

[Dutchman101]

Could another repo member give this an approving review? Repo policy prevents me from merging this without one.

I don't think hedit follows coding guidelines everywhere, and it's also not very optimized (just watch ipb for its memory usage and other metrics) but I personally think we should make an exception for hedit due to its gameplay value, even if we don't expect someone wants to work on those points first.

It's also more bloated than it needs to be for its functionality, having older bloated resources in official resources is 1 thing, but nowadays we aim for a change to good practises when it comes to adding new resources and code (would go against adding other resources, that happen to already be bloated).

Because i would like another opinion on whether or not we should make an exception, i will leave the approval review to another member (MTA team) to see if they agree. If no other opinion or objections arrive soon, then ill approve it anyways.

[jlillis]

I don't think hedit follows coding guidelines everywhere, and it's also not very optimized (just watch ipb for its memory usage and other metrics) but I personally think we should make an exception for hedit due to its gameplay value, even if we don't expect someone wants to work on those points first.

I'm not aware of any official coding guidelines for mtasa-resources. I have been trying to make some progress with them on #250 but it has been slow. If there is anything that jumps out at you I can probably resolve some of it, but I just don't see much work to do here. Code quality and performance seems to be "good enough". There is some bloat that could be cut (the translations stuff and logging come to mind) but it didn't seem urgent to me.

[Dutchman101]

There is some bloat that could be cut (the translations stuff and logging come to mind)

In my eyes, the bloat is everywhere.. rewriting the entire resource from scratch (it can be much tidier to do the same thing) seems like the only fix. But that is clearly not going to happen, and I feel letting hedit through is reasonable.

I'm not aware of any official coding guidelines for mtasa-resources

My bad.. it was loosely applied as the requirements you will meet during code review. Good to see the work on formal guidelines though

[Dutchman101]

If no other opinion or objections arrive soon, then ill approve it anyways

It's time

[Deltanic]

It would have been appreciated if the original author was at least informed of this decision. It kind of goes against community principles to blatantly steal an entire repository, even if a license is missing. I'd have happily added new maintainers if someone would like to improve my work. Sad.

[patrikjuvonen]

It would have been appreciated if the original author was at least informed of this decision. It kind of goes against community principles to blatantly steal an entire repository, even if a license is missing. I'd have happily added new maintainers if someone would like to improve my work. Sad.

In regards to this post, we apologized and resolved this issue on Discord earlier today with @Deltanic. It turns out this communication issue was a result of a misunderstanding between the hedit project developers.

The MTA team and this repository's maintainers are ultimately responsible for double checking attribution requirements and license compatibility etc. before a merge can take place. We absolutely do not tolerate any stealing or assumptions.

We found that our review process lacks two important parts:

1. Require a code license with code owners described to avoid misunderstandings and giving others the ability to confirm licensing and ownership through the source.

2. To avoid biased merges, require a maintainer unrelated to the pull request to review it and go through the licensing and to check if something stands out.

We promise to do better with vetting pull requests in the future to make sure everyone is satisfied.

We asked whether @Deltanic would like us to revert the merge but he said it is not necessary.

Sorry for any inconvenience from behalf of the team and thank you for reaching out to us to resolve the situation.

[ricksterhd123]

It's done now right?
/close