WEAPON_UNKNOWN conflicts with existing samp libraries

[NexiusTailer]

WEAPON_UNKNOWN is already exist in samp libraries like weapon-config and has a different value defined.

[shierru]

I don't quite get it, but what does that have to do with this repository?

As for me weapon-config should fix this incompatibility, after all omp-stdlib is a standard "library" for writing game modes in Pawn for open.mp platform.

And third-party "libraries" should take care of compatibility with omp-stdlib themselves, not trying to change something in the standard "library".

[shierru]

Alternatively, if the game mode developer wants to use the _WEAPONUNKNOWN value from weapon-config, just make #undef _WEAPONUNKNOWN.

After all, the _WEAPONUNKNOWN macro serves more of a stylistic function than any functional function.

[NexiusTailer]

And third-party "libraries" should take care of compatibility with omp-stdlib themselves, not trying to change something in the standard "library".

weapon-config has those define names for years, omp includes added it after the last major release.

At the same time, it does let modify (and even possible break) pretty basic things like with reason parameter in OnPlayerDisconnect where the two additional values were added. One of them, 3, "because some libraries used it as custom reason". So, those "some libraries" are a thing to consider, why not weapon-config then?

It's already had it before the same was added in omp includes, it's already pretty popular include to be bothered to check recent omp-lib's changes with it if they're not conflicting, it's already were adapted to omp includes as for RC2 release version, and omp-stdlib break it again, not weapon-config.

after all omp-stdlib is a standard "library" for writing game modes in Pawn for open.mp platform.

If talking "after all", let's remember this statement once again which is like already became hilarious because of such logic as above:

[shierru]

You should realize that it is simply impossible to maintain "full backward compatibility" in the future. There will still be such changes that will violate this thesis.

In this case, there are different types of backward compatibility, on the server side and on the Pawn side. If from the server side it can be supported well, but from the Pawn side it is very difficult to support it without violating the thesis of "full backward compatibility".

Why can't it be done? Because samp-stdlib is written with some inaccuracies, both in wording and in their entries.

In this vein, I fully support the way of "Pawn life" that is emerging now. For me, I'd rather not have "full backwards compatibility", but more detailed documentation and all that other stuff.

[NexiusTailer]

but from the Pawn side it is very difficult to support it without violating the thesis of "full backward compatibility".

Why should it? There is no any intelligible reason for now (when it's only a server replacement yet) to break anything even with a bunch of new features which were done. If you look at the includes right now, you'll see pretty much critical stuff changed "just because I want it lol" like renaming some of natives into british english. So, you're now either justifying an obviously irrelevant things or not entirely familiar with the current changes in the standard omp libraries.

Why can't it be done? Because samp-stdlib is written with some inaccuracies, both in wording and in their entries.

Ok, the previous statement again then:

[weapon-config] is already pretty popular include to be bothered to check recent omp-lib's changes with it if they're not conflicting

when it was firstly in wc for years, not vice-versa.

[shierru]

Why should it? There is no any intelligible reason for now (when it's only a server replacement yet) to break anything even with a bunch of new features which were done. If you look at the includes right now, you'll see pretty much critical stuff changed "just because I want it lol" like renaming some of natives into british english

It's always been the case that if critical changes are made, everyone tries to adapt to those changes rather than sit around and trumpet that it violates "full backwards compatibility". If you don't agree with these changes, you can always use samp-stdlib instead of omp-stdlib (I've been doing that most of the time and haven't had any problems).

So, you're now either justifying an obviously irrelevant things or not entirely familiar with the current changes in the standard omp libraries.

I am quite familiar with the changes going on in omp-stdlib.

[NexiusTailer]

It's always been the case that if critical changes are made, everyone tries to adapt to those changes rather than sit around and trumpet that it violates "full backwards compatibility".

Yes, it's always that when it's samp (when it was developing and something during that was obviously changed at least a little), but not really when it's another project whose aim is to bring compatibility first to make a smooth transition possible at some noticeable period.

If you don't agree with these changes, you can always use samp-stdlib instead of omp-stdlib (I've been doing that most of the time and haven't had any problems).

Already do that, but it's not about my agreement, it's about a library which was already adapted for omp-stdlib and now it's broken again because of omp-stdlib changes which wasn't tested with any popular includes to prevent any of such occasion. If there are major changes even between minor commits, then it should be at least indicated as WIP, pre-release, alpha or in any similar way to show that the project's dev stage is not production ready yet.

I am quite familiar with the changes going on in omp-stdlib

Then you should clearly understand that this is very funny statement talking about current omp releases:

but from the Pawn side it is very difficult to support it without violating the thesis of "full backward compatibility"

[shierru]

Already do that, but it's not about my agreement, it's about a library which was already adapted for omp-stdlib and now it's broken again because of omp-stdlib changes which wasn't tested with any popular includes to prevent any of such occasion. If there are major changes even between minor commits, then it should be at least indicated as WIP, pre-release, alpha or in any similar way to show that the project's dev stage is not production ready yet.

With that, I completely agree.

Then you should clearly understand that this is very funny statement talking about current omp releases:

My use of metaphors in one vid or another often leads to misunderstandings. This case is no exception. By what I said above, I meant a different meaning.

I wanted to say that the C++ side was always closed from the SA-MP side, and there was no convenient API, which is now in open.mp.

In this regard, on the Pawn side, open.mp developers, and in particular whoever is doing omp-stdlib or any other users who want to make changes to the repository should consider backwards compatibility, but should not allow hyperbole (a complete rejection of new changes that might break backwards compatibility). In such a direction open.mp will not go far, and especially when there will be its own client, which will primarily fix the problems of SA-MP Client and add some new features. And there is a 100% chance that we will have to break compatibility in one way or another to fix some flaw that has been present in SA-MP for years.

[shierru]

I'm not ruling out the possibility that I may be talking some nonsense. I'm looking at situations from my angle, that related to Pawn in open.mp, that and a related component I'm making that will allow the use of Lua in open.mp (not a statement that the work will be finished and released to the public, it may remain dusty on the computer)

[shierru]

@NexiusTailer What solution to this situation would you suggest?

[NexiusTailer]

Probably rename it to something like "unused" or "invalid"