I don't think GMod has a concept of "ownership" - so it's likely something your prop protection addon needs to figure out.

It's easy to disallow the toolgun for it however - just check for vehicle_jeep which have a .ZAPC property I believe and then use GMod's vanilla hooks.

This isn't Brian's or my responsibility. It's yours. Entities can be spawned in any arbitrary way and there is no way to get the supposed owner of an entity from ents.Create.

This is exactly what CPPI is for
http://facepunch.com/showthread.php?488410-Common-Prop-Protection-Interface-(CPPI)-v1.1

Every prop protection has it, here is its implementation in FPP:
https://github.com/FPtje/Falcos-Prop-protection/blob/master/lua/fpp/sh_cppi.lua

You are to use the ENTITY:CPPISetOwner(ply) function.

I beg to differ. First of all, you can do this on your own using PlayerSpawnedSENT[wiki.garrysmod.com], a sandbox hook that is just for these occasions. It will give you the player and the SENT (or maybe the jeep, I'm not certain right now). You should be able to prop protect the jeep easily after that. If you're not using a sandbox derivate or that hook has been removed, you need to figure out where SENTs are spawned and request a hook to be added there.

Now about it being "my responsibility": The APC is a standalone product. It doesn't require third party modules, never did, and I'm not going to start. Not every server uses prop protection (and in those two and a half years, nobody ever mentioned these issues you're currently having), so I would either need to add a check (which adds another point of failure/maintenance) to see if CPPI is available and if it is do stuff, or I require CPPI/equivalent to be installed.

It's "No" to both answers. I'm not going to create dependencies and I'm not going to start adding third party APIs unless 1) there's a very good reason, 2) there's a popular demand and 3) it's not possible to implement it outside the APC (as hook/patching) easily.

In this case, your solution likley has five lines of lua for the hook, a check if it's an APC and the call to CPPISetOwner.

Sorry, I made the assumption that this addon somehow spawns itself. FPP listens to PlayerSpawnedSENT and should set the owner of the entity automatically.

There is still a problem though: your APC creates passenger seats in the ENT:Initialize method. You cannot expect FPP to hack into your entity to see if you're creating any extra entities. You also can't expect me to check for variables like ent.DriverSeat, ent.Turret and ent.GunnerSeat. That would only work for YOUR vehicle.

There's a standard for this, and it's called CPPI. All respectable prop protection mods support it. Making your APC compatible with all prop protections and none is as easy as:

Have some properties:

• Works if CPPI isn't installed.
  
• Little effort, the code is already given to you
  
• Fixes ownership problems of subentities
  
• Compatible with ALL respectable prop protections because CPPI is a standard

Now, on your worries:

there's a very good reason

There is. Your mod creates subentities that any prop protection cannot possible deal with unless specifically checking whether your addon is installed.

there's a popular demand

I am popular and I demand it, hahaha!

it's not possible to implement it outside the APC (as hook/patching) easily.

Yes it is, see code above. It's literally a copy paste job.

I see and agree on the issue (albeit I don't quite understand why anything besides the driver seat needs prop protection - they're invisible entities inside the APC and cannot, and should not, be modified or used without the script knowing it).

However, my stance remains. It's a design decision: The APC, for all intents and purposes, is supposed to work with vanilla content, containing vanilla content. My reasoning:

• Although having no impact, registering a hook callback for a third party addon just seems wrong on all those (local) servers where it isn't used. CPPI has been around for seven years, this entry for almost three and just now the issue of prop protection comes up. Let's just assume for a second that over 110'163 people (current subscriber count) did not require prop protection, did it themselves or didn't report it. Knowing and loving the Steam community a lot, I doubt the latter.
  
• It creates a pseudo dependency on CPPI. While it would still work without CPPI installed, I'm suddenly responsible for updates on the interface. If (or when) CPPI decides that the hook ought to be called differently, or the function should be renamed, it's suddenly my job to fix (my) hook.
  
• CPPI may be used by "all respectable prop protection" but no king rules forever [my son]. Whenever there's another prop protection standard suddenly fancying the community or even when there's some other standard coming up, I'll probably be immediately prompted to implement that one too, because "you did CPPI". I'm already being asked if I can help adding this to X or Y or if I couldn't do Z, I don't want to imagine what it would be after that.
  
• Implementing CPPI could hint towards "This SENT supports prop protection". And suddenly, I'm in for a whole lot of pain because every misconfigured prop protection addon is my responsibility because "I can't use your APC!!". That's one can of worms I certainly don't want to open.
  
• Regarding the three points: 1) My mod does create sub entities, but those are very easily accessible within the SENT (up to a level where I would say even more immediate beginner can do it); 2) I see what you did there, but think of "popular demand" of something else than "two guys" (regardless of who they are or what they did); and here's the thing: 3) because it's really easy to fix without me doing anything at all, I don't see why this should be in the SENT.

Your code is missing the passenger pods (the property Passengers, a table, each value being a passenger pod) but regardless, it's not about the effort to do it, it's about the code design.

I do see the issue however, namely that the APC currently has no interface for "What belongs to me", and could offer you a function on the SENT that returns a table containing all entities owned by the APC (and maybe another one for shot rockets if required). That would make wriitng the hook code a lot easier and robust because there would be a proper interface. But I won't mess around with CPPI myself. If CPPI for the APC is direly required, it should probably be done properly (up to the point where multiple functions in the APC's own hook system are wired to CPPI) and therefore in an own addon/workshop entry/autorun file.

CPPI has been around for seven years, this entry for almost three and just now the issue of prop protection comes up

The discussion can stop here with that attitude. This reasoning can be applied to any and every bug and or feature request reported from now on. This is an outright refusal to update your mod.

You're also contradicting yourself:

Whenever there's another prop protection standard suddenly fancying the community...

I [...] could offer you a function on the SENT that returns a table containing all entities

You DON'T want to adhere to a recognised standard, but you DO expect me and every other prop protection author to hook to a function that you are "willing to provide" us because you don't want to implement 10 lines of harmless code? And you call that a "proper interface"!?

The code literally has 0 impact. The pseudo dependency is bulIsh¡t, the people who made the CPPI standard are actually competent people with university background. They wouldn't fu©k you over and break backwards compatibility. CPPI has updated several times, the latest update actually made that hook available. Each update was documented and did not break backwards compatibility.

If anyone ever complains to me that they can't pick up the APC, but can pick it up by the gun or by one of the passenger seats, I can now honestly say that it's not my damn responsibility. You refuse to make your crappy vehicle compatible with prop protections, giving weak xenophobic "not-invented-here" excuses about why you don't want any references to other people's work in your code. All while you expect me to specifically tailor FPP for your addon.

You're correct, it is a refusal to update my mod because as I've reasoned, I don't see it appropriate to add it - which is within my right to do.

I'm not contradicting myself, I'm offering a compromise. I thought I've explained myself properly, but it's possible that my English is a bit rusty.

Honestly, I think it's kind of funny how you express my thoughts from the opposite point of view. The same way you don't think that FPP should have a special implementation for my APC, I think the APC shouldn't have a special implementation for CPPI/FPP. The cleanest and in my opinion only clean solution is to have a third, independent addon/script/whatever that ties the two things together. Because it's not my responsibility to deal with prop protection issues and it isn't CPPI's/yours to deal with APC problems.

It's the server's issues if I'm bloody honest. If you wish to use X and Y, you are to make sure that X and Y are compatible - if necessary with some glue in-between. It's unreasonable to expect all addons to work nicely together (as I've sadly found out with just this SENT alone).

I couldn't care less that CPPI is supposed to be a "standard" made by people with "university background" and a fancy PDF. I'm not going to implement specific, completely unrelated interfaces (unless the three points I've mentioned above are fulfilled - so far we're at two people, which I don't see as "popular demand", although they're quite loud). I'm offering an independent, stable interface that can be used for whoever needs access to APC resources for whatever reason. This can be CPPI, this can be someone who wants to color every entity on the server fuchsia. It's a more generic interface than "dude owns this entity". Basically, it's a promise I make: I offer you this interface, and I won't change it. So you can depend on it, no matter what update will come in the future.

You can't force people to adhere to "standards" (relevant xkcd[xkcd.com]). The world isn't a happy place where every addon in existance plays nicely with each other. There's bound to be conflicts and there's bound to be missing or incomplete support of things. This is one of these things.

So, I don't expect you to support the APC the same way I ask you to not expect me to support CPPI. Because quite frankly, that's none of our business. Unless you truly want to go around and force every addon in existance to implement CPPI, you're never going to get a fully working prop protection with every addon.

However, I think your paragraph raises some good ideas. I'll probably push an update later on to fix these issues. It's something that was overlooked on my part, I believe, but you really shouldn't be able to interact with any seat/pod nor the turret. Cheers.

The cleanest and in my opinion only clean solution is to have a third, independent addon/script/whatever that ties the two things together.

CPPI isn't from APC, it isn't specific to FPP. That makes it a third party thing. What you ask for is EXACTLY what CPPI is. Look at the first sentence of the post publishing CPPI:
http://facepunch.com/showthread.php?488410-Common-Prop-Protection-Interface-(CPPI)-v1.1

standard interface for prop protectors to use for easy third-party integration with any prop protector.

It's the server's issues if I'm bloody honest.

Oh yes, put the responsibility on the end user, because they should know how mods are implemented and modify that to make them work together because the author refuses to take responsibility.

Any API you can offer is NOT independent. It's just a ♥♥♥♥♥♥♥♥ API for your addon. All my addons already have APIs and I'm not asking you to use them. I'm asking you to comply with a ♥♥♥♥♥♥♥♥ standard. The only standard by the way, so that smug xkcd link is irrelevant.

Also, CPPI really is a standard. Look at big players like wire using it:
https://github.com/wiremod/wire/blob/082a58dd176e7e51c8a7a2f0a079e48917ffb132/lua/entities/gmod_wire_expression2/core/e2lib.lua#L697

This makes Wire E2 compatible with ALL admin mods. DarkRP uses it too, so you can replace FPP with any other CPPI compliant pp.

Either way. I guess I can live with your solution. It works.

I've pushed an update that fixes a few things which hopefully should disable most interaction with the "odd" parts of the APC. As a side note, I don't honestly think that this was ever an issue - they should have been invisible and non-solid, so they shouldn't have been picked up by anything. But hey, better safe than sorry I suppose.

As my final statement to this whole prop protection/tooling issue, I won't add third party interfaces (unless there's a dire need and so forth, see above) if the same thing can be achieved with tools already here.

It's not my responsibility, it's the user's (not end user, which I would consider people joining the server). If you want to combine mods, you can't expect them to work together flawlessly. In this case, I'm not publishing information that another service requires, hence said service doesn't work as you expect. I'm not doing that because I'm an evil person or a lazy bastard, I'm doing it because GMod itself doesn't have a concept of "ownership".

Your argumentation is flawed. If I buy a player (VCR, DVD, BluRay, - feel free to pick one or more) and a telly, it's neither the player nor the TV manufacturer's responsibility to connect them. They merely offer interfaces that you, as end user, are to connect yourself. I see the same here for a simple reason: It just can't be expected that something that was created completely independently suddenly needs to be compatible with something else.

I don't care how big CPPI is, or who uses it, or how exactly it can cure cancer, end hunger and achieve world peace. You can use my APC with CPPPI just fine, as you've shown yourself. The whole thing can be broken down to half a dozen lua lines, without any modification to the APC.

With that being said, I'll leave the thread open for comments, but in all likelihood won't post unless there's some grave change that justifies it. I'll repeat what I've said at the beginning:

If you wish to use prop protection with the APC, you ought to tell your prop protection what an APC is. Use the .DriverSeat/.APC properties to deal with it. If you have specific needs, the APC's custom ZAPC_CheckAccess hook allows fine-tuning of what tools are allowed even in environments without a prop protection addon.

Sounds like a challenge. Accepted, and already beaten.

Link?