As discussed in "New version for Debian Jessie release?" I hereby open the discussion for ads on cars.
The original car textures of Trigger Rally contain non-free trademarks. This gives the cars a realistic look and feel, but could cause legal problems. Therefore qubodub created new textures without such brands. Unfortunately this way his well designed textures look less realistic.
Liviu proposed to use free software projects as brands. Of course we want to check this with the projects we want to promote, before we go for it, but let's collect some suggestions first!
Based on what I use for creating new maps I want to point to:
After we have decided on what projects we want to use I can offer to adapt qubodub's car textures.
I'm not sure if we should use more than one project per car. This way we probably could do a more exiting design fitting to each project...
Iwan Gabovitch (qubodup)
My 2 cents:
I would find it disturbing to have real software logos in ads because:
1. Even in open source software, logo rights are sometimes complicated. For example: Blender.
2. It makes no sense for software, especially open source software, to pay for being featured on racing cars.
I would rather suggest having fake advertisement. The textures made by me contain a lot of software package and command names but their design has no relation to their actual visual branding (if they have any at all). In the end it would have been just an insider joke for those who know what the commands/apps are. Might be funny, might ruin immersion (see my second point above).
We could look at http://www.wrc.com/en/wrc/teams/page/18-94---.html and let the brands inspire us to create fake brands that are advertised on TR's cars. I would prefer non-parody brands or only very subtle parody. I consider TR a simple but serious/realistic-themed (even if the physics are silly) simulation game.
Keeping or replacing with other software names is fine too but I would then prefer pretending that they are names of brands of oil companies and energy drinks by not connecting them to the actual software packages visually.
"I would rather suggest having fake advertisement."
I strongly disagree. But as I said before, I won't fight over this and if no middle-ground consensus can be found, we may as well revert r88 and proceed to a release from there.
From my point of view there ist no harm in using real software product logos (without demanding any compensation for that) if the project leaders are happy with it. (And we should be able to check that.) I see this as a good opportunity to give those projects an additional stage - if they are not embaressed to be present in our ancient zombie-like project.
I suggested projects which helped making Trigger Rally possible since this seems logical to me. I guess Jasmine could name very important additional projects related to programing like gcc.
The Blender logo might be complicated, but since Blender is in the official Debian repositories, it can't be as bad as the Firefox logo for example.
My only real concern is proprietary stuff I would not want to promote and which could cause legal problems.
In order of my preference:
But even for the option I would like least I wouldn't endanger a new release by vetoing it.
"From my point of view there ist no harm in using real software product logos (without demanding any compensation for that) if the project leaders are happy with it. (And we should be able to check that.)"
Personally I don't feel we need to ask anyone for permission. As long as the artwork is GPL'ed or similar, we're good to go. But feel free to do so once/if we come up with a suitable list of projects.
I think asking would benefit good relations and possibly get us allies.
Sure, but I wouldn't make it a prerequisite for either including the artwork (as long as it's free, as in beer) or performing a release.
Ok, if we decide to go for real projects, I will do my best to get any feedback from the project teams. But first we should clear how we will make the decision. Is there any established procedure in Trigger Rally for such decisions yet?
"Is there any established procedure in Trigger Rally for such decisions yet?"
Nah. It's as ad hoc as it gets. Let's come up with a list of projects, and see if there are reservations to any individual candidates.
I already posted a list in my first entry. You're welcome to add items to it. Should we make a deadline for collecting proposals?
On the other hand I have the impression you and qubodub are reaching some kind of agreement on the fake brand discussion. I don't know what you both prefer, but I posted my preference list on the question what kind of (real or fake) brands i would like to have in the game already.
"Should we make a deadline for collecting proposals?"
I'd rather not. Let us naturally get to a point where we have a list of includeable projects and proceed from there.
So here's my list of proposals:
OpenAL (although it would seem that lately it's become proprietary)
OpenGL (although there may be issues with legalese)
Some of those are integral components of Trigger, while others are software that I use when working on Trigger. One outlier is LyX; it has nothing to do with Trigger, but it's an excellent project and I'd love to see it on our cars.
From our two lists one overlap is Geany and gedit. We may choose one of those two (even though I must admit I always found Geany superior to gedit), or we may keep both of them and put each on separate cars. A bit of competition can't hurt!
I wouldn't go for the proprietary or legally complicated options. Otherwise your suggestions are fine for me as well.
If we do not stick to what we explicitly use for creating Trigger Rally we might end up with too many unrelated options without any clear guiding possibility on what to choose. If we go for needed software we can prefer projects more important for creating the game. Additionally I think it's a great way to promote just the tools we used. This way it's actually kind of a showcase...
Agreed. Let's start with a list of projects that are (even tenuously) related to developing Trigger, and later we can see if we want/need to include less relevant projects. Personally I don't think it's necessarily a bad thing to have irrelevant projects, but let's leave this for another day.
For the projects that we've highlighted, could you compile a list of (1) project license, (2) link to logo, (3) logo and name legal status (trademark, etc.)? Then we could proceed to modifying the textures..
I don't think this is a very good way of using our limited ressources. I think we should first find out what we want to use. I'm not keen on doing a lot of research for nothing. I would even avoid doing this work and just ask the responsible people if they would be fine with us using their logos and names in the game. They should know if this is ok for them.
Only as the last step I would actually adapt the textures since this would be a waste of time as well if the project people don't like the idea of being present in our game. (I know you don't feel it would be necessary to get confirmation from them. Legally you might be right, but I still think it's the much nicer way to talk to people who have a stake in this beforehand.)
Since we have only three cars we need to decide if we place more than one ad on each. Racing cars seem to have different spots for different ads normally. We could do three different types of projects: programming, graphics and environment/used general purpose tools. Either on each car a different type or on each car a representation of all three types...
This seems to be our list so far:
How do we narrow it down?
Should we just go for projects absolutely necessary for Trigger Rally? Shall we just pick projects you could not avoid if you want to play or create the game because it depens on it?
I think the list is good. The cars are big and we will need to have sufficient projects to fill all the space up. If we realize that we have too many candidates, we'll simply avoid including some of them (those most remote from Trigger itself).
For following projects I couldn't even find any artwork to represent it:
For all the others I could find svg files - at least from the logos. Most of the time without any name written on it.
For emelFM2 (GPL):
But I'm sure I can find an SVG if I looked attentively. Would that help?
I can't find any icon related to Jam (unsurprisingly), nor for PhysFS. We could always ask them on their ML, though.
"Most of the time without any name written on it."
I think that's fine. We want to use the icon next to the project name in our textures.
Ok, I finally did find an svg for emelFM2. But since on the main web page an other image is used to represent the project I'm not sure if the folder icon you linked, is the best choice for our purpose.
I have asked someone from PhysFS if they have a logo and if they would be fine with being on our car textures.
In the last weeks I had a lot to do and no chance to follow up on the textures. I actually don't mind any version as long as we can get it done in time for Debian - if it's not to late already.
As I mentioned previously, doing a release with the old textures/ads/names is a breeze and can be done very quickly, assuming there is anything resembling agreement. Doing a release with the experimental textures/ads/names currently by default in SVN is a no-go for me. Coming up with new textures/ads/names takes time and will depend on our involvement. Sofar we didn't move very much on the names front, and with the current rates I don't think we can have anything by the end of the year.
If we revert to the stable textures/ads/names (the only sane thing to do IMO, until we agree to agree on any changes), then we can do a release swiftly. This however shall not guarantee acceptance in Debian, and will depend on (1) us making their freeze deadline and (2) the Debian maintainer moving swiftly.
For me the only concern is getting a new release done. This could shed some light on the project and signals it is not dead yet - maybe we can even attract a new programmer ...
So right now we would just need Ivans ok since he is the only person left who did mention an opinion on this.
Iwan Gabovitch (qubodup)
Sorry for being so slow to respond.
I believe that whoever is able to create a win/debian release should do
whatever keeps him or her motivated to contribute. I'm with Onsemeliot that
a new release is most important.
Sorry, I won't be able to help by (re-)adding non-free content.
If the decision maker sees an option that uses free content only, I'd be
glad to work on that tomorrow and the day after.
OK, it's settled then: a new release it is. Over the weekend I will look into tweaking the defaults to point to the stable textures. We will also need to add the remaining of Onsmeliot's tracks. After the release we can resume the discussion on new textures/ads/names.
@Onsmeliot: Could you please check SVN and come up with a list of tracks that you made but have NOT yet been included?
Sorry to read about the fact that your principles get hurt right now. I share your perspective about keeping everything as free as possible, but I guess I'm less consistent than you in this case. I hope you will be available in the future when we find a solution with free textures and names.
Sorry, I didn't get into how to work with the SVN yet. Can't you just overwrite everything with the most recent versions? The following links contain everything I contributed so far. (If you want to reduce the amount of work I suggest you just use the three zip files with the collected works in each category:
Without the new sprites many maps wouldn't work properly. Please ensure to add them correctly as well! (6 sky textures and 6 plant variations)
Shortcut: All events in one zip for direct implementation into the "events" folder (not as plugins).
Shortcut: All maps in one zip for direct implementation into the "maps" folder (not as plugins).
Great, thanks for the links. I'll check myself what's already in.
Iwan Gabovitch (qubodup)
@Onsemeliot No worries, I'm more sorry about me allowing my principles to hinder the project. I'll be available for tasks working towards TR being free and other tasks after.
I think most of your maps and events are in svn. I guess you're still having troubles running the svn version rather than an old release. I'd suggest uninstalling everything and then only getting svn.
https://sourceforge.net/p/trigger-rally/code/HEAD/tree/data/events/ to see what's in svn
If Liviu and Stefan (Debian packaging) are not up to work instantly I fear we are to late for the next Debian release. This is very sad since we just lost to much time arguing about things we didn't need to solve right now ...
The problem might be the ten days deadline before being accepted.
In the maps.zip I find several tracks that seem to have been updated since last included in SVN: ancient country dry highland jumpy stoned. Do I update these on SVN with the versions from the ZIP file?
I also see changes in 'alps' event. Do I update that, too?
And for the textures, there seems to have been an update in 'grass.png'. In too?
Yes please, in doubt use all the files from the new zip archives I posted most recently in this discussion!
Quick question: For Dry in the ZIP file the f.png has been removed. Intentional?
Yes, because it's not needed. Thank you for your careful work.
Hi again, Liviu.
You where quite buzy. Is the SVN - from your point of view - in a state where Stefan could start making a Debian package already?
If this is the case we urgently should inform him or other people who could help us with this. I think you are on the developers list as well. Please do reply to the discussion there as soon as you think you're done!
Maybe we can manage to get ready in time still.
No, not yet. But I'm working towards it. I hope to have the release ready today. But in the meantime, please do contact Stefan to make sure he knows that a release is being prepared.
Stefan told me he won't have time to do it. He sent the request as well to the Debain games developer list, but at least I didn't see any reaction from there.
Please try to finish this update as fast as possible! I asked several people involved into Debian if they could help out but it's possible they won't be able to do it either.
Today unfortunately is the last day our new release could be added to the testing tree because on 5th of November is the freeze for Jessie and they will only consider packages which where in testing for at least 10 days.
I guess we will have at least a minor change in the version number. What do you think: 0.6.1?
I'm pretty sure that I can prepare the Debian packaging bump myself. But I don't have commit rights, so if you can find a Debian maintainer willing to take the patch that I would provide...
Does the introduction of *.obj textures introduce a new dependency on Trigger?
OK, 0.6.1 has now been released. The source archives are available from the Downloads section of SF. Please test them and report back if you hit any issues. The textures default to the historic .ase, but the .obj textures are also available and can be easily enabled by the user (see Readme).
I will not be providing Debian packaging today. So hopefully Stefan is available to perform the release. Packaging-wise the changes are minor: change program icon and bump the version number. For an experienced packager, it's roughly 10min job.
Wow Liviu. That was really fast. Thank you so much. I hope I can find someone to do the last bit in time.
Only the download link on top of the Files page still offers 0.6.0 as the most recent version and I couldn't find any place where I could change that so far.
Ivan or Liviu, do you know how to chance this link as well? Other wise this could be misleading.
I will try to contact further people now in order to find someone for Debain packaging ...
Yeah, I left it intentional until the source archives get tested by us and there is some feedback that all is OK. I did the release rather quickly, so didn't take the time to test everything. Once we're happy, we'll change that link, too.
I just downloaded the new version and couldn't find any errors so far. Since I didn't install it but compiled it directly from source I can't tell if this would work with installing it as flawlessly, but from what I can tell it's perfect. :)
Thank you so much, Liviu, for your fast and concentrated work.
Tobi from the Debian games team has added our new release. If nothing went wrong and if we didn't overlook important errors, Trigger Rally 0.6.1 can be in Debian Jessie. :)
Puh, that was close. It still can go wrong, but we managed to get past this crucial step.
Sounds excellent. Let me know if he hits any issues with the released archives.
From what I see, 0.6.1 is now in Sid.
Did you try to install it to check that all is OK?
No, I didn't from the Debain version yet. Just the one from Sourceforge.
I hope I didn't get this wrong, but now when I think of it I'm not so sure any more if it was enough to get our new version into sid. I fear it would have been necessary to be in testing for at least 10 days. And now it's just in sid, but not in testing ...
Best to ask Stefan or Tobi. I for one have a feeling that pre-stable freeze the testing distro disappears and is taken over by Sid. But I may be wrong..
However, if you have access to Debian please do test the unstable 0.6.1 there, to make sure that if anything gets into Debian stable, it actually is so.