https://svn.orxonox.net/media

[1337]

I'm running p2p and I'm trying to do another checkout (network branch), but that takes time.

Too much, to be honest.
I've heard 'rumours' about creating an svn repository for our media files.
And I think now could be a time to reorganise that since it doesn't seem to be a lot of work.

My suggestion in short:
- create an svn called media (not Media please)
- put all the created and collected media files from the Media folder in it
- put all the audio and level files in it
- destination: bin/media for the release and for those having more than just one or two branches checked out, the media repo could simply be put one level down so that it is required only once.

As far as I know you can check out an svn repo inside another one, because this would be a condition.

And since it is eastern and I don't feel like working for my studies, I would do that job once it has been agreed. My problem: I don't think I have got the rights to create a new svn and even if I did, I wouldn't know how

[BadElvis]

This is a very good idea, I think it is also important that we use this opportunity to rename all the media file in a sensible way. There are lots of files where no one knows what they mean, for example "MyShip.mesh" or something like that.

There should be a consistent patter for the names of models, texture, materials, particles and all that. Furthermore the old unused models should be removed.

[1337]

And here the advantages of svn come in handy.

[beni]

This has been done some time ago...

Also in my branch it is possible to set the path of the media directory via command line and configfile...

see http://svn.orxonox.net/data/Media/ ...

[1337]

wow, very nice. Has anyone ever posted that?

I'm just checking it out.

And I think I'm gonna need your branch, Beni

[beni]

I haven't uploaded the newest version yet, but alright, I will send out a dev mail when this is done.

I did this that afternoon you complained about the size of the media in each branch (1 week ago).

[1337]

Yes I remember

And I'm grateful that my wishes are heard

But you sound like you would like to update the branch? I would have time tomorrow and on sunday to update things to meet my suggestion.
You say who does it.

[beni]

So, I updated as far as possible after I discussed some changes with x3n. Unfortunately, not everything was possible yet, but that's not too bad. It works as far as I hoped it would.

Changeset r911 and r924 withhold all the changes you have to make in Orxonox.cc/.h and GraphicsEngine.cc/.h. It's not really much and there are also some unnecessary changes, but nothing too serious.

With those changes the data-repository can be specified. Be aware that if you use a relative path the location of the executable is significant and not where you start. The execute command would be something like this:

Code: Select all

me@mypc:orxonox$ ./run --data ../../../media/

This tells Orxonox where to search for the resource.cfg file (!!!!) so be sure there is one in the media directory and the paths in that file are correct relative to the location of the file.
This is however a temporary configuration. To make in permanent you should change the entry "dataPath" in the orxonox.ini file which should be there after first execution with the new code. Also be sure not to make an error with the paths as the program takes the path and checks for the resource.cfg from the location of the executable.

If you still got any problems, don't be afraid to ask bluntly.

[1337]

wow, that's really great!

I've just applied your changes to the network branch and it works fine! New branch size: 1.20MB!!!

Also, I'm going to explode the data repo by adding the audio files, since these are really nasty to upload every time you want to check out a branch.

And there's this idea of creating an Interface "Configurable" so that classes like GrahpicsEngine don't have to be a BaseObject. Another possibility could be to split the orxonox.ini in the Class hierarchy part (Ships, weapons, etc.) and the orxonox engine part (dataPath, debuglevel, etc.).
Hmm, I think I'll have to ask x3n, master of ConfigValues.

Oh, almost forgot: Applying your changes to Orxonox.cc wasn't that easy because the network guys restructured their init() and start() routines. And since I've discarded none of your changes, you could update your branch to meet ours. Although, I've committed a crime: I've deleted the commented regions in Orxonox.cc (like defineResources etc.), but svn should not let us down there.

[nicolasc]

That is some improvement... was about time!

and that way you really see how much code there is, and not those big but needed beautiful media file...

cheers
nico

[x3n]

And there's this idea of creating an Interface "Configurable" so that classes like GrahpicsEngine don't have to be a BaseObject. Another possibility could be to split the orxonox.ini in the Class hierarchy part (Ships, weapons, etc.) and the orxonox engine part (dataPath, debuglevel, etc.).
Hmm, I think I'll have to ask x3n, master of ConfigValues.

just inherit directly from OrxonoxClass and you join the party. look at the DebugLevel class if you need an example (src/orxonox/core/DebugLevel.h). don't forget to use RegisterRootObject instead of RegisterObject, but that's everything you need to know.

[1337]

Didn't actually look, where you implemented the ConfigValues (not that I checked for that info three days ago, should've known).

Then I'll ask Beni whether there's a special reason for inheriting from BaseObject.

Oh, @x3n: You forgot the virtual
Could be that one wants to make it tickable as well...

[x3n]

Oh, @x3n: You forgot the virtual
Could be that one wants to make it tickable as well...

There's no need for "virtual" if you don't want to inherit from an interface.

[beni]

I was thinking about it. But since I did not know the exact background of the implementation, I wanted to be on the save side.
I just implemented the config values by book, so there is really not much magic behind it.
In this case inheriting from OrxonoxClass would be better, since the GraphicsEngine does not need to be a BaseObject. So no: no special reason.

[1337]

Ok, never mind then.