Selam.?

They broken

Hola comunidad lo que vengo a presentarles es un creador de TextLabels y Dialog por web,?tambien nos permite ver como va quedando cr?ditos?al creador _Zume.

Quote:Most people here know "Bullworth Town", and have played this great game, but hey, that is not the important thing in this thread.

I discovered that some people wanted to launch the map of this game on their servers, but the conversion for sa: mp did not exist, some servers work to convert this map and others doknow how to do it. I am doing this conversion, since I am possibly going to publish it at the end of the month (June), this is for people who are interested in using this place.



If you want to have more information about the conversion of this map, you can access my Discord.

I don't?know what other information to provide, but hey, I'll be adding updates to this thread over time.

Will o:mp be featured in?Discord Rich Presence ? So we can say like wich server we are on and server infos and some other infos?

I've installed the 5.x branch of the YSI library to get rid of the pesky const correctness warnings and followed the instruction of changing the syntax to include y_hooks in all my files and this was the result

Right, so I've been thinking about y_hooks.

This is the current syntax:

1. Exactly what's above, just an obvious function call. ?This has several downsides - verbose, variable parameters, string argument specifier (error-prone), string function name; and only one upside - not custom syntax.
   
   
2. Using indirection.inc with the hook name:
   
   
   PHP Code:

   return @.OnPlayerConnect(playerid); 

   
   Advantages: Established syntax, compile-time specifier determination (can be part of the `hook whatever` line, don't worry about that), less verbose, more clear.
   
   Disadvantages: Still no compile-time parameter checking, but none of the proposals have that.
   
   
3. Using indirection.inc with the `hook` keyword:
   
   
   PHP Code:

   return @.hook(playerid); 

   
   Basically the same as option "2", but more consistent across all hooks, and less likely to conflict with other variables. ?As for specifiers, there are two options - 1) none, which is not good, but means that the chaining is no longer tied to the hook function:
   
   
   PHP Code:

   Other(a)
{
    return @.hook(a);
}

hook stock MyFunc(a)
{
    return Other(a);
} 

   
   Or the other option is just make `hook` a local in exactly the same way as would be done in option "2a".
   
   
4. `continue`.
   
   I like this for one reason - it is quite clear on meaning:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    new b = continue(a  5);
    return b - 5;
} 

   
   `continue()` cannot conflict with `continue`, so this is a completely unambiguous overload of an existing keyword.
   
   
5. `hook continue`.
   
   Like "4", but using slightly more verbose, less confusing, syntax:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    new b = hook continue(a  5);
    return b - 5;
} 

   
   
6. `yield continue`.
   
   Again, like "4" and "5", but reusing the `yield` keyword, already existant in YSI. ?`y_iterate` uses `yield return`, so this would provide meaning to `yield continue` as well:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    new b = yield continue(a  5);
    return b - 5;
} 

   
   
7. Completely custom syntax:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    // Example custom syntax, probably not this, maybe `next()`.
    new b = next_hook::MyFunc<>!!!(a  5);
    return b - 5;
} 

   
   
8. Something I've not thought of.
   

Well i done this?


It isnt that great but just to give some ideas
Well i can explain what it stands for
The burger u know the burger and a scope aim for shot so burgetshot

Tried to do something like this

Burgershot old school

Hello everyone, I am a new mapper and I created a channel to present my maps, I hope you like it.

https://www.youtube.com/channel/UCiKcLLU...subscriber

Short version: Please use the?GNU Affero General Public License for open.mp

Long version:
If I understand correctly open.mp will be open source once it's released to the public. This is great! There's only a small detail I realize just now about the specific license terms open.mp choose and what it could mean for the players.

First, if open.mp uses a non strong copyleft license, this could allow for third parties to create closed source versions of open.mp, and with the correct marketing they could even become more popular than open.mp itself. This would be terrible for the players because they will lose the freedom, convenience and other advantages that only an open source development can give. To prevet this I suggest using a strong copyleft license such as the GPL. This way, third parties are still allowed to modify open.mp's source code to their heart's content. But they will required to share the full modified source code when distributing their modified version. This will be beneficial to the open.mp developers because they will be able to merge popular changes.

Second, the server part of open.mp will be just as important as the client part. Taking this into consideration, another point also related to the first?must be highlated. And this is the fact that most licenses?don't prevent server owners?from modifying the open.mp server source code and not?release the source code to their users. This is because connecting to a server does not count as distributing in the copyleft context. To prevent this I suggest using a license that prevents this, such as the?Affero GPL.?This way, third parties are still allowed to modify open.mp's server source code to their heart's content. But they will required to share the full modified source code to the players connecting to their server.

Using the?GNU Affero General Public License for free distribution?could allow open.mp a way of monetization?by selling non copyleft licenses, there's lots of companies developing open source using this kind of business model.

Finally, what I want to prevent is closed source forks of open.mp becoming incompatible with the original open source version, I dont have any issue with open source forks of open.mp being incompatible?because as long as they are open source too, then open.mp can simply merge the changes to keep? compatibility if necessary.

For more information on the?GNU Affero General Public License:?Why the Affero GPL