Primary tabs

Comments by User

Wednesday, July 20, 2016 - 21:48

 it is technically doable but has the potential for significant performance impact and possible abuse.  The admins can already do this kind of bulk content update for a given user, but I would be quite reluctant to open up such broad powers to generial users. 

I also don't personally know the legal implications of you changing your attribution details for work which is already in use. It would be good to get some clarity on that. For instance, of you have previously released something as CC0, i don't think it is possible for your to later change that to something more restrictive.

Wednesday, July 20, 2016 - 09:14

@gsliepen How can you say "it doesn't work like that"?   The ogg version of a song is equivilant to the "object code" in the GPL licence, as it is the final compiled version without the actual "source code".  

Section 4 says "You may convey verbatim copies of the Program's source code as you receive it" 

And section 6 says "You may convey a covered work in object code form under the terms of sections 4"  

with the provisos of section 6c  "Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source" 

So if the artist agreed to provide the source on request then OGA would be conveying a verbatim copy of the object code with a verbatim copy of a written offer to provide the corresponding source.  

 
Wednesday, July 20, 2016 - 08:34

 

GPL v3 section 6b and 6c:

  • b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
  • c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.

 

It seems like keeping GPL is fine, as long as the artist explicitly agrees to offer a copy of the source for at least three years. At that point the artist would be meeting b) and OGA would be meeting c) 

  

 

Wednesday, July 20, 2016 - 05:55

I don't upload the component editing files for most of my art primarily because the size is often many orders of magnitude larger than the mixed down final form.  An ogg which is 3mb could easily be exported from a set of source files which is several gigabytes in size. Even that is not always the whole source, I might make 15 or 20 different iterations of an artwork prior to settling on a final form, I save each of those versions as a seperate project, and I can extract components from multiple versions to use in the final version.  At that point you're potentially looking at dozens of gigabytes of "source" files.

Hell, for most of the songs on here I have also made video clips, which also have multiple versions and massive source files.  If I were to upload all of that information, I would be seeding for months.  These editing component files are very unlikely to be used by a game dev, and would have a significant effect on the hosting cost of the site. There are a lot of downsides to uploading source files rather than the final mix.  

For all the discussion in this thread, I still don't see what the problem is with simply asking an artist for a different fomat if you need it. 

Wednesday, July 20, 2016 - 05:19

Joth, after a bit more work there is now a "Featured Art" section at the bottom of the Most Popular page 

 http://opengameart.org/popular 

 It shows 8 random pieces of art with over 30 favourites, a cut off which currently equates to about ~250 pieces of art.  The section is cached for between 1 to 30 minutes, at which time it is randomised again.  

It would be trivial to add this section to the front page, but I won't be touching the front page without permission.  

 

Wednesday, July 20, 2016 - 04:45

Hi Joth, 

I put together a page of the most popular content from all time.

http://opengameart.org/popular

It is essentially the same thing as a blank search filtered by favourites. 

I couldn't think of a quick way to make it display a random selection of only popular art.  

I didn't want to add an entire section to the front page without permission, particularly one which wasn't ever going to change.  However, I have made a slight change so that the "Popular this week" title on the home page is now linked to this "Most Popular" page, instead of the "Latest art" page.   

  Hopefully that goes some way towards your request.  

Sunday, July 17, 2016 - 20:33

What would we post to the main page? We certainly have the capability to do so, but I don't think anyone other than Bart has ever posted an update and there is not really anything warranting an announcement.   

I have done some further work on search and you may notice the default search results are significantly different, here is the change log:

  1. Changed the default sort criteria for search results, it used to primarily sort by post date, with an advanced option to sort by favourites or views.   It now defaults to sort by search score descending, with an advanced option to sort by favourites, views or post date.   (This means you can compare the new search vs old by changing the sort option)
  2. Altered the search index priorities slightly to increase the influence of keyword relevance over other factors like number of comments and how recently it was updated
  3. Experimented with adding an exposed date range filter, however it proved unsatisfactory so I have not implemented it. 
  4. Experimented with a custom combined field global search field, but this too proved unsatisfactory.    
  5.  Temporarily raised the minimum word index from 2 characters to 3, and lowered the number of items indexed per cron run from 100 to 50.  The idea here is that it is possible cron jobs are failing silently due to memory restrictions, so I am trying to make it as easy as possible for the index to  update.  These changes massively decreases the size of the index and the size of each cron operation, at the expense of providing worse results for terms like "16 bit".     (I suspect it won't actually help, since all items are showing in search results when you use the title filter, so i don't think the index itself is the problem. Still, it is worth trying as failed crons are a pretty common problem with larger sites which have been running for a long time. 
  6. Cleared the site caches, in case some searches were mistakenly being cached.  
  7. Noticed in the site error logs that solr search views are still being referenced by some views and generating warnings, however I haven't yet managed to track down the reference   

 Ultimately I believe the longer term solution is that the site needs to be brought down for maintenance, updates applied and a few database tables cleared before being brought back up. 

If anyone has feedback on these changes I'd love to hear it.  

Sunday, July 10, 2016 - 02:36

One more thing,  I just checked the access logs, and Bart logged in about a week ago, so he certainly isn't completely AWOL.  I also know that he is a very busy guy, so I wouldn't worry too much about it.  

Sunday, July 10, 2016 - 01:54

As I suspected, the re-index did not work. The index is a Solr Index, and the Solr instance is currently not working. This will require low level server access which is beyond mere site administration. 

@capbros  My understanding of the search situation is this: 

1. Main search used to use Solr search, this is a high quality search which searches across all fields and is highly configurable. 
2. Main search now uses Drupal core search terms, this searches for a specific term across all fields, but is not very configurable 
3. Title search isn't really searching, it is actually filtering all art titles by *any* of the terms entered.   

Saturday, July 9, 2016 - 05:19

Given the length of time this has been an issue, I have just unilaterally taken two actions on the search front. 

1. I have rebuilt the index (the big red button has been pressed). This can take quite some time, however I believe it may not solve the issue entirely. There is a deeper issue which requires low level server access to resolve.

2.  In the mean time I have added another search field to the advanced search page. The new "title" field uses a different search mechanism, so it will return results regardless of the state of the search index. The downside is that it only searches the art title, not all the fields on a piece of art.   

It seems to me that title limited search is more useful than time limited search, so if the re-index does not work, then we may have to consider replacing the main site search with the title search I just implemented. It would be great if people could try out the title search feature and let me know your feelings on using it instead of main site search, at least temporarily.  

Pages