It is currently 28 Mar 2024, 18:25

WELCOME TO SIMUSCAPE!


Please Sign in or Register to enable all features, remove restrictions and gain additional access!
For information on how to bypass the CAPTCHA or to contact Team Simuscape, Continue Here!


Forum lockedPost a reply Page 3 of 4   [ 79 posts ]
Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: 06 Mar 2013, 12:40 
Lurker
Lurker
User avatar

Joined: 10 Jun 2012, 19:34
Posts: 48
@wallyweb - yes, I agree with your conclusion that the author cedes rights to Bananas. But that's not a destruction of copyright; it's building upon copyright.

Copyright is what makes it possible to grant those rights in the first place. It's quite conventional in distribution of digital materials that a license to distribute is granted, and that the author may then not be able to revoke that. There will be exceptions of course.

Anyway, playing weekend lawyers is boring, but I don't see this aspect of Bananas ToS changing.


Top
 Offline Profile  
 
PostPosted: 06 Mar 2013, 12:52 
Master Mentor
User avatar

Joined: 27 Feb 2012, 22:45
Posts: 1880
Location: Canada
andythenorth wrote:
Anyway, playing weekend lawyers is boring,
WHAT? But I was about to suggest a "Barristers and Solicitors" industry chain for FIRS. :(

:lol:

_________________
Visit SimuSchool - Tutorials, Questions and Answers
TTDPatch Nightlies Downloads are back
Thrive


Top
 Offline Profile  
 
PostPosted: 06 Mar 2013, 13:42 
Browser
Browser
User avatar

Joined: 04 Mar 2012, 10:10
Posts: 229
I absolutely agree, in the end the author has to be respected, IMO. It's just how copyright and ownership of your own works happens. There was a comment somewhere (either here or on tt-forums) where somebody mentioned that BaNaNaS is like any other hosting service, where you give them a license in perpetuity to distribute your works. This is not true at all. Even services whose intention is to distribute works forever, if you notify them that you no longer wish to have your works removed, they must remove it.


Top
 Offline Profile  
 
PostPosted: 06 Mar 2013, 14:09 
Well, yeah, you indeed cannot remove your content. But my question would then be why in the hell would you want your content to be removed, ever?

Because that version has a serious bug?
People should update.

Because you no longer "support" that version?
So what, nobody can demand anything from you.

Because you only want to have the latest, best, most awesome thing you worked on available?
Man up, I for example am not ashamed that NUTS 0.0.1 had a gigantic heap of bugs, looked horrible and what not. The best way to show your good things and make the old ones forgotten is to update with new and awesome stuff.

Or because your suddenly changed your mind and do not want to supply players with your content?

I mean, you already spent hundreds of hours on it, why would you want to destroy it? Or in this case, not share it if it is already shared?
Removing your content is just putting extra effort in absolutely nothing which is only contraproductive for no reason. If you "punish" the community by removing your content, what do you expect them to do? Move onto other content.

And above all: nobody can demand anything from you. You contributed with your thing, but you do not take any responsibility if the stuff is broken/bugged/whatever.


Top
  
 
PostPosted: 06 Mar 2013, 15:03 
Master Mentor
User avatar

Joined: 27 Feb 2012, 22:45
Posts: 1880
Location: Canada
V453000 wrote:
...
I do agree with much of what you said, but the simple fact of the matter is that without a contract (ToS or license) stating otherwise, an author can do whatever s/he wants without explanation.

_________________
Visit SimuSchool - Tutorials, Questions and Answers
TTDPatch Nightlies Downloads are back
Thrive


Top
 Offline Profile  
 
PostPosted: 06 Mar 2013, 18:26 
I get that, that is all great, but you can do that anyway. You do not have to care about the deletion at all in my opinion


Top
  
 
PostPosted: 06 Mar 2013, 18:41 
Browser
Browser
User avatar

Joined: 04 Mar 2012, 10:10
Posts: 229
V453000 wrote:
Well, yeah, you indeed cannot remove your content. But my question would then be why in the hell would you want your content to be removed, ever?
Just like I proposed to OzTrans earlier about why somebody would not have a particular NewGRF, I also propose to you - it doesn't matter why you want the content removed. There is no wrong or invalid reason to do so. The content exists where it does only because of the consent of the author and the host, and if one or the other wishes to no longer host it there, there should be absolutely no objection from the other party. If you cannot respect the property rights of somebody, then you risk hurting the system for all involved.


Top
 Offline Profile  
 
PostPosted: 06 Mar 2013, 18:45 
That makes some sense, but on the other hand since you do not pay anything for hosting it or arent obliged in any other way to do anything else, the Why still stands :s


Top
  
 
PostPosted: 06 Mar 2013, 18:56 
Browser
Browser
User avatar

Joined: 04 Mar 2012, 10:10
Posts: 229
V453000 wrote:
That makes some sense, but on the other hand since you do not pay anything for hosting it or arent obliged in any other way to do anything else, the Why still stands :s
And what does paying for it or not having to pay for it have anything to do with anything?

I give you a free hamburger. You eat half and decide you're full. That means I have a right to object to you not eating all of my hamburger on the basis that you didn't have to pay for it? :?:


Top
 Offline Profile  
 
PostPosted: 06 Mar 2013, 20:05 
Well I could find easily understandable that if you host your files on your website, it costs something. Putting your files on free service does not.
It is already there and you do not lose, have to do, or or have to pay absolutely anything,
and if it does not actively annoy you in any way, why stop making the files available.

By the way I am pretty sure anytime somebody would want their files to disappear, they could be just made invisible after a discussion with the devs. They would be available on demand, but absolutely not visible to anybody to download.


Top
  
 
PostPosted: 06 Mar 2013, 20:06 
Lurker
Lurker
User avatar

Joined: 10 Jun 2012, 19:34
Posts: 48
kamnet wrote:
If you cannot respect the property rights of somebody, then you risk hurting the system for all involved.
Eh? The property rights are respected by whatever the ToS are for a service. When accepting ToS, a contributor / user delegates or cedes or grants certain rights. The service then respects them. I don't get this point :o


Top
 Offline Profile  
 
PostPosted: 07 Mar 2013, 02:07 
Player
Player

Joined: 12 Mar 2012, 02:39
Posts: 469
One more scenario ...

It happens far too often, that a perfectly working GRF suddenly stops working because a new feature has been implemented in OpenTTD, i.e. OpenTTD developers have very little regard to backward compatibiliy. In such a case I want to remove the old GRF until I have fixed the issues and are able to provide a replacement.

If a GRF is faulty it must be removed from the supermarket shelf pronto.

There is of course a solution, but it would surely be met with another barrage of criticism. We only allow a GRF to operate with the most recent stable release of OpenTTD, currently that would be v1.2.3. Then, when v1.3.0 gets released officially, we test our wares against it and if found still working, we release an update of the GRF to operate with v1.3; or fix the issues first.


Top
 Offline Profile  
 
PostPosted: 07 Mar 2013, 03:55 
there is something like that but it is probably just reverse, aka if a newGRF uses specs which are only in newer OpenTTD, it will not show for download on older versions.

I cant think of a newGRF which would be broken due to technical reason and not work in latest OpenTTDs though... well maybe the TTD+ or how it was called? I am not what the cause there was however, might have been anything ... and as for example old train sets like DB set XL or US train set, or whatnot, still work then I guess the backward compatibility isnt that bad.

And mainly, why would it _have to_ be removed? If it does not work in latest versions, well too bad, the player will probably just get an error.


Top
  
 
PostPosted: 07 Mar 2013, 10:57 
Lurker
Lurker
User avatar

Joined: 10 Jun 2012, 19:34
Posts: 48
You can set min and max OpenTTD versions in bananas. I'm not 100% sure they do what you need, but it's worth exploring.

Interestingly you create yourself an extra maintenance burden that way, in that for each OpenTTD release, you have to go test your grfs, then update the max version on bananas if compatible. This will ensure great quality, and for a commercial product or a large team would be perfect. But is it what you want to do, working alone, on something you do for fun?

You could also rely on users reporting bugs with a new OpenTTD version, then set the max version appropriately if and when issues come up.

FWIW, I haven't experienced any of the problems you're trying to avoid (4 grfs, more than 1 million total downloads). Nor has pikka. But YMMV of course :)


Top
 Offline Profile  
 
PostPosted: 09 Mar 2013, 03:38 
Player
Player

Joined: 12 Mar 2012, 02:39
Posts: 469
andythenorth wrote:
You can set min and max OpenTTD versions in bananas. I'm not 100% sure they do what you need, but it's worth exploring.
Yes, I'm aware of that, although setting min == max will result in showing nothing at all. Indeed, I need more than that; I also need to restrict the GRF itself to min/max, which is possible. This code would then have to be adjusted from one stable release to the next.

Quote:
Interestingly you create yourself an extra maintenance burden that way, in that for each OpenTTD release, you have to go test your grfs, then update the max version on bananas if compatible. This will ensure great quality, and for a commercial product or a large team would be perfect. But is it what you want to do, working alone, on something you do for fun?
Maybe once or twice a year at best, there are not that many OpenTTD releases in any given year. Testing could be done by a select few (definitely not the masses], which would have access to an unrestricted pre-release. It would ensure great quality and that is what I aim for anyway. Doing the coding on my own is the only way to go as too many cooks spoil the broth.

Quote:
You could also rely on users reporting bugs with a new OpenTTD version, then set the max version appropriately if and when issues come up. ... I haven't experienced any of the problems you're trying to avoid (4 grfs, more than 1 million total downloads). ...
That is what worries me greatly ... there are GRFs with almost 300,000 downloads. I do not believe, that there are so many happy players that actually use these GRFs. The actual usage rate is much lower. I'm much happier with just 10 downloads and the GRFs actually being used to their full potential by players that appreciate our work and not having masses of downloaders that just click every possible box, download the stuff and forget about it. I don't really need any Online Content Download System as discerning players are very happy to come and see us, here at Simuscape, to get the quality wares we have on offer.

V453000 wrote:
there is something like that but it is probably just reverse, aka if a newGRF uses specs which are only in newer OpenTTD, it will not show for download on older versions.
This is no longer a real issue. In the past I skipped parts of the code, if it were to have been used in older versions of the game; or simply restricted the GRF itself to be activated in older versions.

Quote:
... I can't think of a newGRF which would be broken due to technical reason and not work in latest OpenTTDs though...
An example ... it is common for North American Rail to have trains multi-headed with engines facing in the one or the other direction, in particular freight trains. This was prevented suddenly by the game (v1.1 introduced bit 3 in property 27 [Vehicle can be flipped around in the depot]). I received many complaints about that issue. The introduction of that feature made CanRail fail the high quality test we aim at. CanRail already dealt with flipping of vehicles long before that feature was introduced and it took me some time to fix it. Some may disagree, but CanRail was broken as far as I was concerned and no longer fit for human consumption.

Quote:
... old train sets like DB set XL or US train set, or whatnot, still work ...
Nowadays, we create far more sophisticated GRFs compared to those very early ones. I code at the edge of technical possibilites and make use of any feature (including undocumented ones) available. This can then cause issues, if features are changed suddenly without notice and without being backward compatible. The above example could have been implemented the other way around and thus backward compatible. The comments from Open Devs read ... "We don't care anymore if it breaks existing GRFs, we implement things how we see fit".

Quote:
... why would it <have to> be removed? If it does not work in latest versions, well too bad, the player will probably just get an error.
... and our reputation will suffer badly, especially if masses of players can no longer use our wares in a way they were intended. The more experienced and long time players are familiar with the ups and downs of game development, but the masses must be able to have a product that works any time and any where.

Once a product is up on the Online Content Downloader it is for the masses. The download counts prove that; e.g. eGRVTS with 280,000+ downloads vs CanRail with about 250 downloads. I'm much happier with the latter count any time, because it is much closer to reality ... who needs 'BaNaNaS', I don't, I can do without it any time and 'real' players are quite happy how things with 'all things Canadian' are today ...


Top
 Offline Profile  
 
PostPosted: 10 Mar 2013, 07:05 
Lurker
Lurker
User avatar

Joined: 13 Feb 2013, 06:47
Posts: 2
OzTrans wrote:
there are not that many OpenTTD releases in any given year.


On average, about one a day...

Quote:
I code at the edge of technical possibilites and make use of any feature (including undocumented ones) available. This can then cause issues. [...] The comments from Open Devs read ... "We don't care anymore if it breaks existing GRFs, we implement things how we see fit".


An "undocumented feature" is not a feature. Rely on unspecified behaviour not changing at your peril. ;) As far as the depot flipping bit goes, I think in hindsight it has made things much easier for both authors and players, and was the best solution, even if it did require updating (or, in the case of NARS2, not giving a toss about) the few NewGRFs which had tried to address the problem in other ways.


Top
 Offline Profile  
 
PostPosted: 11 Mar 2013, 00:13 
Player
Player

Joined: 12 Mar 2012, 02:39
Posts: 469
PinkOboe wrote:
OzTrans wrote:
there are not that many OpenTTD releases in any given year.
On average, about one a day...
I'm talking about stable releases, i.e. v1.2.3, then probably on April 1, v1.3 will be the next one.

Quote:
... As far as the depot flipping bit goes, I think in hindsight it has made things much easier for both authors and players, ...
Of course it has, but it has concerned many while they waited for the update(s).


Top
 Offline Profile  
 
PostPosted: 11 Mar 2013, 09:26 
Lurker
Lurker
User avatar

Joined: 10 Jun 2012, 19:34
Posts: 48
OzTrans wrote:
Of course it has, but it has concerned many while they waited for the update(s).

It's interesting to compare working methods.

If that had affected one of my grfs, I would have:
- switched to the last tag (because trunk is often not in a shippable state for my grfs...bad, but it's the way I work)
- fix whatever needed to be fixed
- tag a new version (probably it's a minor or trivial version)
- push the new version to bananas (anyone who updates online content will then get it)
- in the Bananas UI, mark the old version as not compatible with OpenTTD > some rev
- port the fix forward to trunk

How would you do it?


Top
 Offline Profile  
 
PostPosted: 12 Mar 2013, 09:55 
Player
Player

Joined: 12 Mar 2012, 02:39
Posts: 469
andythenorth wrote:
It's interesting to compare working methods. ...
I don't use any utilities/tools nor an online repository like you do ...

a) I start with a source (.SRC) file; this could be compared how some authors code in nml, but has nothing to do with it, or even looks anything like it.
b) Then, I compile the source, using a HLL program (my creation); as a result I get a file (.NFO) in pure NFO.
c) The NFO file runs through NFORenum (finding problems with my HLL program) followed by GRFCodec.
d) Once I'm happy with the result after having repeated a) through c) above numerous times, it goes through some testing (currently by wallyweb).
e) Then, the GRF will be released to the public and ALL files, including graphics, get archived. Just in case we need a back copy.

If there is a minor fault, like a misaligned sprite or a missing comma, I fix the NFO file directly, then continue with c) above. In this case, the GRF gets a sub version, or minor update (e.g. from v1.1 to v1.1a or v1.1.0.0 to v1.1.1.0 internally, with the fourth level having been introduced for the iGRF system, where the iGRF had an internal version of v1.1.0.0 and the 'real' one v1.1.0.1). Naturally, these minor fixes will have to be back ported to my source file, ready for the next release/update.

Now, if there is a new/updated feature introduced by OpenTTD that affects a publicly released GRF negatively, it will be fixed either as a minor update or major update. If I can just update the NFO directly it will be a minor update and can be released fairly quickly. But, in most cases it will require an update to be applied to my source first, which in turn may have a major addition/update pending and therefore cannot be released quickly. It has to run its full course from a) to e) above. Also, using the back copy for such things has become difficult to do lately, as my HLL program is under development too and could make changes to the GRF, that I don't want to happen to an already released and proven GRF.

This was the case with engine flipping, which did not see it fixed until July 2012 (CanRail v1.1). Another, major problem was the introduction of the 'engine pool'. The real fix for that will be in CanRail v1.2 which is due for release in the next few weeks, i.e. many months or even years after that event.

These updates take their time, because it is not just a little bit of tweaking here and there. It always involves doing it properly with external testing, updating the user guides and most importantly coming up with a good solution to maintain quality.

Quote:
... switched to the last tag (because trunk is often not in a shippable state for my grfs...bad, but it's the way I work)
You are not the only one. My GRFs are in a state of 'work in progress' most of the time; that is why I just cannot release a fix immediately, even if minor.


Top
 Offline Profile  
 
PostPosted: 25 Apr 2013, 07:28 
Lurker
Lurker
User avatar

Joined: 30 Jan 2013, 13:32
Posts: 4
I'd like to add to this discussion by presenting a 'real world' scenario. I'm running a multiplayer server with a reasonable user base (the server is never empty) which uses newgrfs. How would I go about using the newgrfs created here, on my server? If not for Bananas, do I have to make every individual user sign up, wait for approval, and download the newgrf here manually? As a server administrator, that usually means players won't bother will all that effort, and I might as well not use it. Is there any solution for this?


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Forum lockedPost a reply Page 3 of 4   [ 79 posts ]
Go to page Previous  1, 2, 3, 4  Next


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron


Status SimuscapeTerms of UseAbout Simuscape

Design by SAC © 2012-2015, Sweden • Powered by phpBB • Based on twilightBB by Daniel St. Jules