Intellectual debts

[Graf Zahl]

That'd require some parser extensions which would complicate the entire matter significantly. I'd prefer not to change the basic parser but only the meaning of some fields.

[printz]

This is super ambitious. I'd rather first see at least two ports with UDMF. I wonder what Quasar has to say on all this.

[Gez]

Graf Zahl said:

Another issue is actor names. ZDoom and Eternity use entirely different names so some translation table from a supposed common standard will be needed.

A common standard isn't really hard to come by: look at vanilla. Take the MT_ names, drop the MT_ part, and there you go, the imp becomes "troop", the cyberdemon becomes "cyborg", the arachnotron becomes "baby", they might not be the best names but they're impartial. The only place where new names would have to be created is for things that have no MT definition, such as player starts ("player1", "player2", etc. should be sufficiently uncontroversial, however) and a few other more obscure things.

[Graf Zahl]

Gez said:

A common standard isn't really hard to come by: look at vanilla. Take the MT_ names, drop the MT_ part, and there you go, the imp becomes "troop", the cyberdemon becomes "cyborg", the arachnotron becomes "baby", they might not be the best names but they're impartial.

MISC0, MISC1, MISC2 etc...
No, thank you. If everything was named decently I might find that acceptable but that naming system is not only confusing, we also may have clashes with the other games.
In that case, why even bother - the Doomednums are just as good as this crap - and allow easier engine-side remapping.

[Quasar]

printz said:

This is super ambitious. I'd rather first see at least two ports with UDMF. I wonder what Quasar has to say on all this.

I am still stuck trying to figure out how we are supposed to support two different semantics for tags throughout our entire engine.

[Graf Zahl]

Quasar said:

I am still stuck trying to figure out how we are supposed to support two different semantics for tags throughout our entire engine.

I'm sorry - but I really do not understand why this is such a big problem. I see it as a trivial issue that may need a certain conceptual leap.

I think if you let go of the term 'tag' entirely and instead start thinking exclusively about 'identifier' and 'argument' and restricting each one's function to what the name implies, the solution will present itself automatically, and it's just what I always have been suggesting. Just don't get hung up on the fact that in the binary Doom format both will get initialized from the same source value and better view that as a quirk in the map format, not an inevitable and insurmountable necessity (which it most definitely is NOT!)

And if you change it NOW - before exposing it to UDMF - you have the problem solved and will never have to think about it ever again! That's the entire point why I am so insistent on this issue. Once you set this in stone you'll be saddled with an issue that has become unresolvable forever (comparable to the 'lax monster activation' rule in ZDoom - that thing has been so ill-conceived I'd prefer to get rid of it if there weren't so many old maps depending on it.)

ZDoom has been strictly separating the tag(identifier) from the tag(argument) and still manages to cleanly map any of the affected Boom specials without a hint of a problem. On the contrary: By having them separated you have far more flexibility when doing something to a linedef that itself performs some action.

Regarding backwards compatibility: Since this concern only applies to binary Doom format maps, and here both identifier and argument are always the same (since both need to be initialized from the same value), there won't be any difference in behavior unless something is done wrong. But implemented correctly the only actual change for old maps is that the value is read from a different member variable in line_t.

[RestlessRodent]

Graf Zahl said:

I'd like to see something like OpenGL's extension mechanism:
The base namespace defines a certain behavior, with all non-compliant features DISABLED - even if said feature doesn't require any specific UDMF keys.

I was thinking of OpenGL's extensions also.

Graf Zahl said:

So if we are not careful, we might end up with something that's ultimately way too hard to maintain by the mappers because there's far too many feature bits.

Features could be named after their origin port (i.e. who did it first) based on compatibility. Say instead of just "feature_3dfloors" it becomes "doomlegacy_3dfloors". So if a user wants general run of the mill 3D floors then they choose that. This would kind of reflect how OpenGL standardization works (such as AMD being given the AMD_ prefix). This would be a bit more precise than just having "common_3dfloor". Initially when features are added to ports they will most likely be named in their own namespace anyway, so this would remove the later transition to a "common_3dfloor".

Another alternative would be a kind of versioning given to features (i.e. feature_3dfloors = 20120222), but that can be complex in and of itself also. I am not too sure I would want to go with date or incremental based versioning unless it were a minimum value specified. Of course users and map editors would need to know what features are actually available with a given number.

Graf Zahl said:

Naming all those Doom-type specials would add a lot of cruft.

Back before, I had this idea of "super extended specials", that is features which used the full 16-bits of the special flag which would then be mapped to bitfields (similar to Boom generics, except with categories). Many of the already existing Doom specials can be mapped to Boom types while the remaining would be mapped to these "super extended specials". There are slight differences though when it comes to demo compatibility as some Doom types even though they appear to have a 1:1 Boom mapping act very slightly different, not sure if it would break demos however. Something similar can be done for UDMF when it comes to specials however. I should note that since ReMooD lacks Hexen support that I did not have that in mind with these specials. The argument fields could also potentially even be merged into the special string itself.

Graf Zahl said:

But going Hexen-format only would leave some ports like RemooD behind.

I am thinking of supporting Hexen, but I am still not too sure about doing it. Hexen would require lots more work (need polyobjects, ACS, a hub system, etc.) and I have not released in about 6 years and I intend to release later this year with a stable and ported ReMooD.

Graf Zahl said:

Another issue is actor names. ZDoom and Eternity use entirely different names so some translation table from a supposed common standard will be needed.

ReMooD also has a different set of thing names also, although I have the advantage of being able to change all of them to say a standard UDMF style name format.

Graf Zahl said:

MISC0, MISC1, MISC2 etc...
No, thank you. If everything was named decently I might find that acceptable but that naming system is not only confusing, we also may have clashes with the other games.
In that case, why even bother - the Doomednums are just as good as this crap - and allow easier engine-side remapping.

There could be two types on the thing ID however, if it is a number then treat it as a doomednum, otherwise for a string treat it in this order: UDMF Thing Namespace, Port specific namespace. I would have to note that there should be standard thing names for team based multiplayer with CTF (i.e. team#start, team#flag, player#start) with a neutral for teamless players or flags. For these player starts and such, there should be an unlimited amount of them since some ports such as ReMooD support 32 player starts.

[printz]

Graf Zahl said:

Regarding backwards compatibility: Since this concern only applies to binary Doom format maps, and here both identifier and argument are always the same (since both need to be initialized from the same value), there won't be any difference in behavior unless something is done wrong. But implemented correctly the only actual change for old maps is that the value is read from a different member variable in line_t.

The problem is ExtraData backward compatibility: in there, you can set both arguments and tag, and you can set classic specials to linedefs, which under classic semantics would use the tag. After the change, maps with such elements would become unresponsive. The only hope is that nobody has released such maps yet.

Before you say "but why would you use vanilla specials in ExtraData": you may be using ExtraData just for the extended flags, while still putting a classic special on the line.

[Graf Zahl]

I think you are too cautious here.
The thing is, this can only possibly have an effect if some rather unlikely conditions exist.

First, there's this little line of code in there:

   // 03/03/07: id
   if(edline->id != -1) // haleyjd: only use this field when it is specified
      line->tag = edline->id;

which renders nearly all concerns moot. Effectively this means that the line identifier is always the ID if given - even now.

So if the same logic gets applied to the first argument. i.e.

   memset(line->args, 0, 5*sizeof(int));
   line->args[0] = line->tag;
   if(edline->argsdefined) // you'll need this flag to avoid false negatives.
        memcpy(line->args, edline->args, 5*sizeof(int));

the ONLY imaginable situation where some value could not be what you'd expect, is when a line-affecting special is combined with Extradata that actually contains some args, even though these would be perfectly useless for the given special. I think that's pretty unlikely and if something that hypothetical and inconsequential stands in the way of clean semantics it'd be a pity.

When facing such decisions in ZDoom in most cases I took a 'wait and see' approach, i.e. I made the change and waited for bug reports. In case it truly broke something they were quick to come. But you got the advantage that no released map would be affected - at least none of the Extradata lumps I have checked so far did. And if it affects some work in progress it's easy enough to direct those users to the proper setup.

The last time something like this came up in ZDoom was last month when I refactored the sector damage stuff. This had been on my wishlist for years as the old code was quite broken. But I held it off in fear of the odd map that actually did combine sector type damage with scripted one. Turned out when I did go through /idgames that it was completely unjustified. There were approx. 200 maps using Sector_SetDamage, and not a single one was affected.

I think this is comparable. If you solve it now, all WIP maps can be adjusted (provided that they actually did create some bogus definition with useless args) and the problem is gone.
On the other hand, if you leave it in, you have a major kludge that won't ever go away. The long term effects of this design decision will haunt you until Eternity! (pun intended :D) And if you wait with a decision until more maps get released it'll only get harder to do something about it.

[printz]

Another case: potential ACS internal functions that inspect the args and id of a linedef. Eternity has several advanced ACS functions reproduced from ZDoom, though I haven't looked which. "Thankfully" Small is gone, and no EDF codepointers that do this either...

EDIT: on one look, it seems that most of the existing ACS functions focus on things, less so for lines...

[Graf Zahl]

That's be another edge case (or to be more precise: stuff that's broken by design) that's far too unlikely to have an effect here.

If there were multiple mods out there which are using Extradata with such functions it may be a valid concern but as it stands, with Vaporware the only one and not doing such stuff to begin with) and everything else being demo maps (none of which does such stuff either), none of this is really relevant.

I can only repeat myself: You still have time to fix this design flaw. If you continue to find new pretexts not to do something about it, it'll be too late if you eventually WANT to do something about it.

Been there, having suffered from that multiple times, and regretted it each one of these occurences that I hadn't acted earlier.

Sorry to be blunt, but you are only shooting yourself in the feet by putting such a vague compatibility concern front and center of the discussion whose likelihood to happen is almost certainly zero in realistic scenarios.

So to summarise the cases which could go bad:

1. Someone uses such a line affecting special through Extradata (unlikely to begin with) and THEN puts some unused args on the same linedef (even more unlikely unless someone had unintentionally made a mistake)
2. Some ACS function reads the arg from the given line (does such a function even exist, I can't find anything from a quick search) and THEN has to use the same identifier as the given line effect. Not that SETTING args through SetLineSpecial does not count as it alters the special, too!

Both seem rather far-fetched to me as they both make no logical sense and fall squarely under 'mapping mistakes'.

I think you are 100% safe if you make the change and then put an announcement here, laying out the specific scenario that may cause problems (that'd be the single case that a line got both a line-affecting Boom special AND a set of args assigned.)
Makers of unreleased maps would notice soon enough if their map is affected by this and fix it. And released maps do not use this stuff.
And as laid out, that's all very unlikely to occur in the first place as it necessitates two or three unusual practices to coincide on the same linedef. (That is, if there was more material in the wild already. But since there isn't, it's even less likely than 'very unlikely' to have some effect.)

What's more: With all the Extradatas I checked so far, this is not only not a concern, the entire problem doesn't even remotely get touched, you'd be probably safe even when not doing any compatibility fallbacks at all (which even I wouldn't do.)

[printz]

Graf Zahl said:

line affecting special

Don't you also mean sector affecting special? I'll change for that as well.

UDMF said:

The id will be used to identify this line, and arg0 will be used to identify
the line or sector that this line is to affect or otherwise reference, i.e.
it is effectively a parameter to the line's special.

[Graf Zahl]

Ok, I didn't think about that - but that still won't change much - as it still requires putting args on a linedef that has no use for them. And that can be solved!

The important thing is, this can only become a problem if some map does something WRONG!

If you are so concerned, there's a very simple alternative solution:
Skip initializing the args for Doom format specials! As I said, they are useless and they cannot be accessed without changing the special.

That'd mean that with Extradata they'd be limited to how they act now but you got the design problem solved.

I'd consider Extradata deprecated anyway, the main goal should be to make this stuff ready for UDMF, once that is done nobody will need Extradata anymore, so any concern about that method should be solved by restricting it to what it can do right now.

And reading back the args clearly is not, there is no direct function for it, and the only way to change them is to change the entire special

So let's summarize again with these concerns being considered:

- the above means that the combination special/arg can be considered an unseparable entity when used on a linedef.
- since the special/arg combination is inseparable of course means that one cannot be changed with the other at run time.
- when using Doom format maps there are no specials using args so copying the tag to both is 100% safe.
- when using Extradata let's make the following distinction:
* if used with a Doom special, copy the tag/id to both the line's identifier and first arg, and ignore the Extradata args(since with the current special they are useless.)
* if used with a Hexen special, use proper semantics. Copy the tag/id to the identifier, and initialize the args from the extradata.

And that only could break if there was a method to get at the args without making use of the actual special - AND that method had been in existence for modders to use. If you can answer this question with a certain 'no', it should all be clear.



And in case you are still concerned, here's another approach that won't get you into headache territory at all:

Define a new linedef field, let's call it 'doomarg' for this discussion. Doomarg will be used in place of 'tag' for all search operations in the engine based on looking for targets Doom-format specials, i.e. both sectors and lines. (Not necessary but may be of help cleaning it up and find everything: Rename 'tag' to 'id' or 'lineid' and you can review each place where it's used and replace with the appropriate one.)

Now for the interesting part how this will help:

- Doom format data inits both 'id/tag' and 'doomarg' to the map's tag value and sets the Hexen args to 0 - i.e. there's no interference!
- Extradata will also set both 'id/tag' and 'doomarg' to the extradata's tag/id value and initialize the Hexen args from their respective property - i.e. there's no interference!
- and now the solution to all your problems: UDMF with Doom format specials will set 'id/tag' to UDMF's 'id' property, and init the first Hexen arg and 'doomarg' to arg0. As Hexen args are not normally defined for Doom-format specials, it's fully up to you what to do with the rest of them, but whatever that is, there's no interference!

[Altazimuth]

Yo @Graf Zahl seems like GZDoom still in violation of the GPL. I don't see any direct mention of SoM in portals.cpp, and the mealy-mouthed ass-covering copyright notice that you added the day this thread started looks more like denial to my eyes than actual attribution. I realise at the time you couldn't really get away with proper attribution due to you not being able to use GPL code and have it be actually OK with the stipulations of the GPL, but at this stage GZDoom is supposed to be GPL. I made a pull request and everything to try resolve this quietly and inoccuously but even that was shot down. Does the GZDoom team have no interest in righting past wrongs?

 

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R607
https://github.com/team-eternity/eternity/blob/6803319a34cc42cd6a9d18598d4fda752a9f4a6e/source/p_portal.cpp#L367

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R650
https://github.com/team-eternity/eternity/blob/6803319a34cc42cd6a9d18598d4fda752a9f4a6e/source/p_portal.cpp#L446

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R806
https://github.com/team-eternity/eternity/blob/6803319a34cc42cd6a9d18598d4fda752a9f4a6e/source/p_portal.cpp#L628

Edited August 21, 2019 by Altazimuth : Minor typo.

[Graf Zahl]

I see you brought up the same links as Quasar when this code was written. But like I said when he brought this up then I say the same thing now:

The code wasn't taken from Eternity. All I went from was the basic need to build a displacement table. And whatever you say here, you cannot copyright the concept of a displacement table - you might patent it but that hasn't been done. You can copyright a specific implementation, but that's it. You also cannot copyright the concept of portals - just your specific implementation.

 

That up-front to explain the rest.

 

The construction algorithm I used (second link) is actually very different than Eternity's so I cannot give SoM any credit for that part. Just because it produces the same data table does not automatically mean that the code shares the same origin.
 

To bring this in context let me cite another piece of GZDoom code that had a licensing issue and where I had to rewrite it, i.e. the middle layer in the OPL player which was based on the badly licensed MusLib.

What I did was tossing out the code, clean up the interface a bit and then implementing the same functionality based on Chocolate Doom. However, when all was said and done, the resulting code still had a striking similarity to the old code. Why? Because it implements the same thing. That meant it had to perform the same tasks, often in the same order, and many of these tasks were trivialities.

 

What we have here is exactly the same situation - the table that needs to be produced is dictated by the needs of the feature, so whatever algorithm gets used to create it, the generated data must be the same. They need the same sanity checks (links 1+3) which inevitably means that the code for the error checks needs to be for the most part identical,  because it is trivial checks. But just because both sets of code perform the same tasks does not automatically mean that the code shares the same roots. I was actually VERY careful when writing that code, NOT to take anything from Eternity. And that's precisely what I acknowledged in the source code.

 

The best I can give you above that is an acknowledgement that I did a bit of reworking of my error checking code and adding 2 or 3 more checks which I initially missed after comparing my code with Eternity's but that's really the extent of what can be done here.

 

 

 

[Rachael]

I'm sorry - violating the GPL? Sorry to burst your bubble, Altazimuth - but GPL only covers copyright law. You can't copyright an idea. Period. Additionally, in order for copyright to be in force, it requires substantial similarity - which is not present here. The only things that are similar are the basic ideas behind the implementations. In order for copyright to apply, snippets would have to be copied verbatim - to the point where even a lay man who has absolutely no understanding of code can look and see and say "yeah that's definitely copied" - and that never happened, here.
 

If what you're are saying is true then just by this same principle ReactOS would be illegal since it reimplements the Win32 API. And Compaq making IBM clones would have been illegal way back in the day, too. DR-DOS would have been illegal because it reimplements the DOS structures and whatever bare API that MS-DOS had.

As has been stated twice, now - this is a case for patents, not copyrights. And again - the GPL does not cover patents. In fact, it discourages them.

[Altazimuth]

8 hours ago, Graf Zahl said:

The code wasn't taken from Eternity.

 

https://github.com/coelckers/gzdoom/pull/901#issuecomment-523263842

So I guess this has devolved into a he-said she-said?

 

It's worth noting in this commit you also have a commented out BuildBlockmap https://github.com/coelckers/gzdoom/blob/126c80d597f340f5fc70fdfa74810d029baa51ef/src/portal.cpp#L839, which adds to my case. You're telling me you just happened to pick the exact same group table logic that SoM came up with, and also happened to pick the same solutions for problems you hadn't even began to solve yet that EE was well ahead on. On top of this you somehow did this all without making direct references to our code, happening to have some mild differences like recursion in EE being a do/while in ZDoom, which happens makes the similarities harder to spot? The sense of the algorithm is still the same though.

 

It's not like you haven't added EE code before without proper attribution before the switch to GPL, see https://github.com/rheit/zdoom/blob/4f21ff275c639de4b92f039868c1a637a8e43f49/src/p_setup.cpp. I can only assume that Quasar agreed at-the-time to waive the GPL on that code so it would be allowed to integrate with ZDoom at the time.

 

I was hoping that since you had nothing to lose by accepting the pull request this'd be resolved quietly and easily. I didn't even put a bit at the top of the pull adding SoM to the actual copyright-holders for the file.

[fraggle]

14 hours ago, Altazimuth said:

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R607
https://github.com/team-eternity/eternity/blob/6803319a34cc42cd6a9d18598d4fda752a9f4a6e/source/p_portal.cpp#L367

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R650
https://github.com/team-eternity/eternity/blob/6803319a34cc42cd6a9d18598d4fda752a9f4a6e/source/p_portal.cpp#L446

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R806
https://github.com/team-eternity/eternity/blob/6803319a34cc42cd6a9d18598d4fda752a9f4a6e/source/p_portal.cpp#L628

Hoping I don't lose any friends by saying this but in all honesty I don't see much similarity between these pieces of code. It's obviously entirely rewritten from what I can see. If the algorithms from EE were reused then it certainly deserves some credit - something like a prominent source code comment and a shoutout in the release notes and commit log for example. I personally always try to give credit in this way and thank the people whose shoulders I'm standing on. I don't see anything like that in the gzdoom files so that definitely seems inconsiderate. But calling this a copyright violation or GPL violation? Sorry, seems like a real stretch to me.

[Altazimuth]

The GPL violation accusation was the vestiges of an angrier post that I didn't do a great job of fully transitioning to something a bit more diplomatic. I'd rather we not just all focus on that one tiny besides-the-point detail that adds nothing to the conversation and just deflects off of the actual issues here.

 

I still am of the mind this doesn't change the fact that GZDoom was in violation of the GPL back when it wasn't fully GPL simply by having this code in there. Where it stands now regarding that is confused and not important.

 

I apologise for that part of the post.

[Jon]

This can be armchair lawyered to the moon and back but it seems we all agree that SoM did the hard work of figuring out the approach to take for portals, gzdoom implemented the outcome of his hard work, he's received zero acknowledgement for that which would be common courtesy, and cost you literally nothing to do. Meanwhile it's perhaps no coincidence that SoM, a fantastically imaginative coder and an asset to the community, has not spent much more time in it since this. 

[Graf Zahl]

I won't repost this so please read my comment at the Github PR: https://github.com/coelckers/gzdoom/pull/901

But let me state one thing very clearly: There is a major difference beween using other people's code and using other people's ideas, and the code clearly acknowledged that some idea were at least inspired by Eternity.

 

 

 

[Altazimuth]

33 minutes ago, Graf Zahl said:

If you think that isn't enough - please have a check of all the copyright headers in Eternity - they were all edited to remove the people previously working on - all those were offloaded to an external AUTHORS file - so in my opinion it's just appropriate to do the same here.

 

Yup Eternity definitely never directly credits commonly-used sources outside of AUTHORS in the actual source.

[Dark Pulse]

@Graf Zahl Just so you know, you tagged the wrong SoM in your comment there, unless SoM has suddenly became a Russian named Sergey Tupicin. (You're looking for somtwo.)

 

This really is way out of my league to respond to in any meaningful way, but I know that all this bickering and fighting is just not going to do anyone good. Compromise is going to be key here.

 

Everybody seems to agree that the concepts were inspired by Eternity, but now there's an argument over how it's credited. I feel Graf's got a point if the authors were removed from the code comments themselves and lumped into an AUTHORS textfile or whatever, but at the same time, seeing as most of the posts on this topic are three years old, it does bear questioning as to if that was the policy at the time that comment was written into GZDoom's code (I presume it is).

 

On the other side of the argument, it's very clear that much of this groundwork was laid by one particular person. Since it's his code, it's his right as to how he wishes to be credited, at least within Eternity itself. But how that credit gets represented within another product is frankly out of his hands - if he has reservations, then that's another problem entirely.

 

4 minutes ago, Altazimuth said:

 

Yup Eternity definitely never directly credits commonly-used sources outside of AUTHORS in the actual source.

Of all those links:

1. Mentions source port only.
2. Mentions source port only.
3. Mentions source port only (and who added the code to the codebase).
4. Source Port + Author.
5. Mentions source port only (and who added the code to the codebase).
6. Mentions who added the code to the codebase; code is derived from another project.
7. Source Port + Author.
8. Source Port + Author.
9. Mentions source port only.
10. Source Port + Author.
11. Mentions source port only.
12. Mentions source port only (and who added the code to the codebase).
13. Mentions author + derived source.

So at best, Eternity is inconsistent (as would be expected of a large project), but there are definitely more cases of mentioning where the code came from, as opposed to directly mentioning who wrote the original code that was reused elsewhere.

 

Essentially if you're going to make an argument like that, then you must decide what's proper attributation - crediting the source of the code AND its original authors, or crediting the source of the code in a more general way.

 

If the former, then Eternity has some work to do in cleaning up a lot of those old, source-mentioned-only comments, and in turn, GZDoom should mention the original author of the code that GZDoom's implementation is based upon.

 

If the latter, what GZDoom is doing is entirely similar and no further action is really warranted.

[Altazimuth]

It's worth noting the most major of instances where code is used, that being particles, does appropriately attribute Randi. Other examples of code are single lines or small snippets. To me this is parially is a matter of principle, doing what's right as well as what's required. Portals were for the longest time Eternity's big draw, so I'd certainly be willing to say that portals are easily just as important, if not moreso than particles. Based on that precedent I believe GZDoom should appropriately give credit to SoM for taking code and algorithms to implement the killer feature of a rival application, thus removing any benefits it might have over ZDoom.

 

51 minutes ago, Graf Zahl said:

To make it clear: The proposed change of the attribution presented a major problem for me because it plain and simply misrepresents the facts and would have indirectly forced me to having violated the license in a way I did not do.

To me this reads as an admission that even in a scenario where Graf had taken code and wanted to change the attribution on that file he knows he couldn't because he realises it would mean that he violated the GPL by having it in there, unattributed, and during a time where the project wasn't fully GPL.

[Dark Pulse]

1 hour ago, Altazimuth said:

It's worth noting the most major of instances where code is used, that being particles, does appropriately attribute Randi. Other examples of code are single lines or small snippets. To me this is parially is a matter of principle, doing what's right as well as what's required. Portals were for the longest time Eternity's big draw, so I'd certainly be willing to say that portals are easily just as important, if not moreso than particles. Based on that precedent I believe GZDoom should appropriately give credit to SoM for taking code and algorithms to implement the killer feature of a rival application, thus removing any benefits it might have over ZDoom.

Where was the CODE taken, though? Where can you point to a line and say "Yeah, this was directly lifted from here?"

 

As others have said, you can't really copyright an idea, only an implementation of that idea. Portals were hardly unknown before Doom, after all (anybody who remembers the mid-90s version of Prey will know that was supposed to be one of its killer features - as well as the one that probably sunk the project), so portals as a concept isn't really copyrightable. Implementation of them can be, but to prove copyright infringement, you have to prove where code was all but directly lifted and used (or minimally modified), uncredited, and from the pages of arguing I've seen in this thread, even the people who originally started it (namely, Quasar) conceded that they perhaps jumped the gun a bit.

 

Essentially, I feel Graf basically did clean-room design since he knew full-well that adding them to ZDoom would be having some people looking immediately at him. Eternity had portals; he then whipped up an implementation of them, that due to the end result doing similar outcomes, generally meant that a lot of the same concepts would be implemented similarly - or potentially identically, if there's only one given way to accomplish a given task. And therein lies the problem - since there's similarities to the original implementation as done in Eternity, some feel that anything similar to its implementation, no matter how little, means that it should be counted as "code from Eternity."

 

So in short, to prove a successful copyright claim, you have to prove two things:

1. That Graf lifted and tweaked code without attributation (which is already half-dead by the fact he does mention Eternity Engine as originating the concept), and
2. That there is more than one particular way to do this same end-result while functionally identical - otherwise, functionality constraints to implement them properly is going to result in basically similar (or identical) code to achieve the same task, and as a result, that can't be considered something to infringe on copyright.

Stuff like this was decided by Sega v. Accolade. Except here, Graf didn't need to copy it to create his own implementation of it, and much of it is different from the original code in the first place, excepting perhaps the places where it's only possible to implement a given functionality in a specific, given way. Essentially, the case ruling means that functional aspects of software aren't protected by copyright law, unless patents or trade secrets are in play, and that's certainly not the case here.

 

Of course, that only applies to the US; EU law may differ in this regard.

[anotak]

copyright is a legal concept and the things that everyone here should give a shit about are the moral & ethical aspects

Edited August 22, 2019 by anotak

[Dark Pulse]

22 hours ago, anotak said:

copyright is a legal concept and the things that everyone here should give a shit about are the moral & ethical aspects

Which, as far as I can see, have been addressed. He credited Eternity Engine via the comment, but said that the implementation would differ, and as far as I can see, for the most part it does, except for the parts that would have to be done identically to have a compatible implementation of it.

 

Try looking at it like it were a recipe. Let's say it's for sugar cookies.

1. The recipe is invented by you, and everyone knows you made it.
2. I see your recipe, but instead of following it exactly, I add in chocolate to make chocolate cookie dough and alter how the steps are performed a bit, for example, substituting butter with Crisco and regular sugar for brown sugar. The end result is my chocolate cookies versus your sugar cookies.
3. I note that I saw the basics of your recipe, but that I decided on my own methodology to create my recipe.
4. You claim that since you came up with it first, I'm stealing your work, because I still have to bake the cookies in an oven, and they're still cookies; thus, I'm stealing your work.

We do give a shit about the moral and ethical aspects of the thing, but the problem is that there's simply some things where you have only *ONE* way to do it if you want to maintain compatibility with another implementation of it. Graf could've chosen that, but lately the trend has gone towards making features get adopted by multiple engines, for example, stuff like DECORATE or UDMF. It's in the better interests of ALL source ports, IMO, if wide-ranging features such as this have a universal implementation for all ports that wish to support that feature, instead of "This one does portals by line specials, this one does it by placing Things, this third one does it by altering the level structure," etc. If anything I'd argue that GZDoom doing them in a similar way means that they are much more likely to get adopted by other source ports and engines as time goes on.

 

There's a world of difference between "I saw the code and stole it without credit" and "This code is going to have some similarities to this other code because it has to do some of it in the same way." Graf mentioned Eternity in his code comment, but you can't copyright the concept of portals - only the implementation, and even then, if there's only one way to achieve a given result, that aspect of the code isn't copyrightable. (To go back to my cookie example, it'd be akin to baking cookies without a source of heat.)

 

Basically, all it takes is a little research to know that the concept originated with Eternity, and that SoM is the author of that code within Eternity. But since Graf isn't directly reusing the code (not even a tweaked version of it) and the only things that wind up bearing similarity are the parts that MUST be similar for a compatible implementation, you can't really claim that it's "based on the structure and algorithms," because for that to be true, you need to be able to point at specific parts of the code, that aren't the only way to do a given result, and still see clear proof that this was taken from Eternity and modified, as it's basically saying "This code is directly based on this other code."

[anotak]

let's lay this out

 

1) graf builds some code using at the very least the concepts from EE as a reference. arguably based on altazimuth's links, it seems like he at least looked at the code.

2) when asked to credit SoM, he chooses to add a comment that does the opposite. and started talking about how the shit he did is extremely legal

 

you can quibble on precisely how far he went on all that. you can quibble on whether or not it's within the bounds of legality. legality is not morality.

 

let's compare the following hypothetical situation

1) i do something that seems reasonable at the time, but i did something to you that you feel hurt you. for example not adequately crediting you for something. you ask me to do something low-cost and low-effort to rectify it. the issue at this point is essentially "hey, i'd like an apology"

2) instead of doing that, i spend significantly more effort on declaring that actually the thing i did is actually extremely legal. therefore you don't deserve an apology?

3) now my friends come and post how you should actually be happy i did this thing you didn't like me doing

 

what the fuck?

 

seriously, what the fuck?

[Altazimuth]

57 minutes ago, Dark Pulse said:

Which, as far as I can see, have been addressed

After much gnashing of teeth it's been addressed, and not the the extent I'd have liked. I question the massive resistance to this in the first place. "I didn't steal code and also what I did was legal" isn't a normal response. Even beyond that, I'd call *ZDoom's grabbing of any an all features that make any other port unique, as well as the mods specifically targeted at those ports, at the least reckless and at the most disrespectful.

 

57 minutes ago, Dark Pulse said:

Let's say it's for sugar cookies.

Your example is inherently bad by being so much more simplistic than portals. Linked portals took SoM a very long time to develop, and not just any developer is gonna be capable of making them the same way any rando can back sugar cookies. Also you'll find there are lots of recipes to make individual things, but Graf just happened to use the exact same ingredients to make an incredibly complex dish. Fully working linked portals have so many moving parts, and are extremely specialised. Sugar cookies are made of such common and basic ingredients that most anybody who knows anything about cooking could come up with them.

 

1 hour ago, Dark Pulse said:

We do give a shit about the moral and ethical aspects of the thing

Who is "we"? Are you a GZDoom developer, or merely acting as a proxy for them?

 

1 hour ago, Dark Pulse said:

but the problem is that there's simply some things where you have only *ONE* way to do it

There's no way to prove this is the only way to do portals. This is disprovable by contradiction, but to contradict this would take a really long amount of time, so claiming this is the only way to do this is basically pointless.

 

1 hour ago, Dark Pulse said:

Graf could've chosen that, but lately the trend has gone towards making features get adopted by multiple engines, for example, stuff like DECORATE or UDMF.

"Lately" my left foot. Excluding BOOM features a small list: MBF helper dogs, 3D midtextures, fragglescript, 3D floors, MBF sky transfers? All of these were introduced to ZDoom yonks ago. What other engines adopt DECORATE? I'm genuinely confused by that one. As for UDMF that was intentionally created by Quasar with the specific intent of being a "Universal" cross-port standard.

 

1 hour ago, Dark Pulse said:

It's in the better interests of ALL source ports, IMO, if wide-ranging features such as this have a universal implementation for all ports that wish to support that feature, instead of "This one does portals by line specials, this one does it by placing Things, this third one does it by altering the level structure," etc.

I disagree. ZDoom absorbing every single feature of other ports makes it seem a lot less worthwhile to work on ports that aren't ZDoom, and so everything ends up revolving around a single port in terms of where the vast majority of development goes. Even then the "universal implementation" bit is bunk, because ZDoom's portals and Eternity's aren't compatible, and Graf explicitly stated that certain things that differentiate Eternity's portals will never come to GZDoom. Along with that there's also the consideration that, last I checked, Eternity's portals intentionally had some restrictions in place for easier processing that ZDoom's didn't and that also makes them not compatible.

Also again you make things seem far simpler than they are. Doing portals by line/things/level structure alteration is not the issue here. The issue is the methodology used to construct the portals at runtime. Where all the data is that defines this doesn't matter in the slightest.

 

1 hour ago, Dark Pulse said:

you can't copyright the concept of portals - only the implementation, and even then, if there's only one way to achieve a given result, that aspect of the code isn't copyrightable

I argued Graf stole the code and that was the copyright violation, not the idea of portals. As I said before it's a well-known fact that ZDoom and GZDoom will happily take unique and cool features from other ports, but I consider that a secondary issue, more tied into the morals and ethics that anotak mentioned which I'd be happy to discuss at-length.

 

1 hour ago, Dark Pulse said:

Graf mentioned Eternity in his code comment

Yes, I referred to this in an earlier post. "Mealy-mouthed ass-covering" is what I called it and I stand by that.

 

1 hour ago, Dark Pulse said:

Basically, all it takes is a little research to know that the concept originated with Eternity, and that SoM is the author of that code within Eternity.

Users aren't going to research this. How many GZDoom users to you reckon talk about early 3D floor implementations, like Julian Aubourg's in RORDoom, SoM in Doom Legacy, or DOSDoom and EDGE's? Given that in videos on Youtube I can recall users claiming Brutal Doom is what added things like freelook and jumping to Doom I seriously doubt at least 99% of GZDoom users will even know that SoM is the pioneer of portals in Doom and responsible for techniques that GZDoom uses (and I believe the code too). SoM had to do all the hard work discovering the techniques that did and didn't work and ZDoom just used all that hard work without as much as a mention of SoM before I kicked up a stink.

It's not like ZDoom has an entire page on linked portals and then tells people the feature originated in EE. All there are's a fleeting mention in Line_SetPortal and a logo for EE in the xlat section. Sector_SetPortal doesn't even mention EE, instead just having the xlat section alone.

 

2 hours ago, Dark Pulse said:

you can't really claim that it's "based on the structure and algorithms," because for that to be true, you need to be able to point at specific parts of the code, that aren't the only way to do a given result

I pointed at specific parts of code. You're asking me to prove a negative here. Asking me to spend just as long as SoM did on portals just to prove that there are other ways to implement portals in order to prove you wrong is highly unfair and you should be aware of that.

 

ZDoom from the early days has taken code, and apparently as recently as 2016 is no exception. Fiercely predatory competition may not have always been its primary tactic to stay on top, but it certainly ended up being a large part of it thanks to how it was developed.

ZDoom doesn't stand on the shoulders of giants, but instead on the corpses of other source ports.

[wesleyjohnson]

I will have to agree with the original post (Quasar) and others in that parts of the implementation portals was poached, before Eternity community even had a chance to get benefits from it.

If there now arises a difference in the final implementation, it is likely that the ZDoom community will claim that their larger fan base has more importance, and that Eternity Engine should change to be compatible with them.   There are other supporters of ZDoom and its derivatives that are not very subtle in promoting that everyone should just use ZDoom, and any good idea has already been rolled into ZDoom, so why should anyone bother with the other ports.   There is no end to the irritation this can produce in the general Doom community, the details of that I will leave to each individual reader.

 

Also, a mention in a bulk file is more of a legal defense than much else, as it is rather irrelevant for any other purpose.

The place in the code that was derived from examining Eternity code should mention that right at that place in the code.

This may be useful to whom-ever should be maintaining that code next, but is doubly important to any one else who may be considering "borrowing" from that code for their project.

 

It is possible to generate very similar code due to necessity, but this code seems to incorporate ideas and method that originated with Eternity Engine.

Even creating code based on examination of some other port often will "borrow" ideas that should be attributed in the derived code, especially if it is extensive or a major feature.

 

In this, I do not take into any account any changes that have happened during this discussion.  I am considering the original post and what should have been from the very start.

 

 

 

 

Edited August 23, 2019 by wesleyjohnson