As pointed out by Cmdr. Adler in this post in the German forums there are conflicts between CR and OC files. Especially since OC is not meant to replace CR it would be good if they would not get into conflict with each other. So should we change the file extensions of OC files to *.c5?, and what are possible side effects of doing so? I think C4Update does not support renaming files, so we could not provide an update package (though on Windows we can't anyway since the fix to the previous problem requires an updated engine already). Anything else?
I would agree. Since the version is also 5.x, the files should be named after that aswell. The other arguments you mentioned sound also valid.
It should probably be changed to ".oc?", so we don't clash with CX files.
The file format didn't change, though, so using a different extension would be weird. I'd rather make sure that the "Open With" functionality works.
Is that even possible? How do we know whether to apply a given update to OC or CR? We could guess from the filename but that does not sound very sane to me. Plus things start to break again when CR re-acquires the .c4u registration (does it?).
The user would have to choose, obviously. That's what the "open with" functionality is there for: Having multiple applications associated with one file type. Probably requires that OC uses different registry paths but the same file extension. And a different file name for the .desktop file on Linux.
Actually I would prefer it if we kept the mechanism automatic. I think that's also more convenient to players.
What about changing the version numbers in the c4group header? (offset 28 and 32)
How about changing the extension of script files while at it? Less conflicts with C source files :)
Yeah, let's change it to .cs for "Clonk-script". :-P
Anyways, I would like to see this change.
Anyways, I would like to see this change.
could be good, I just got an error of the opensuse build service because it thinks the .c files are development files. I could easily walkarround that but it shows what such conflicting endings can cause.
>openclonk.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/share/openclonk/planet/Objects.c4d/Items.c4d/Resources.c4d/Ice.c4d/Script.c
>A development file (usually source code) is located in a non-devel package. If you want to include source code in your package, be sure to create a development package.
>(none): E: badness 12800 exceeds threshold 1000, aborting.
Of course we also need new icons if we do this (at least for the ones that have "c4" on them, such as c4d, c4f, c4g, c4m etc.). There are contained in src/res. Anyone? :)
i guess thats not the problem. we have enough people who can do this, we should rather decide on an file extension name first, or do we stick to *.c5x now?
I don't mind actually. *.c5? was just the first thing that came to my mind, but I am also OK with any other.
Regarding that replacing C4Groups with Zips is on the (imaginary) todo-list:
*.zip
Scen*.zip
Folder*.zip
changing the magic header should be enough or? So it could keep a extension that is related to clonk...
Like the .jar File for Java which is a Zip file only with a different suffix...
So keep that in mind before moving to a .zip extension... it is basically not necessary to rename...
Like the .jar File for Java which is a Zip file only with a different suffix...
So keep that in mind before moving to a .zip extension... it is basically not necessary to rename...
Well, .zip would have the advantage that the users could use their regular tools for packing their modifications/scenarios. If changing the magical bytes than that wouldn't be possible. Using the same bytes but an different extension would be possible. However.
Huh? Most packers probably refuse files without a correct header, so that wouldn't work.
Thats what I explained in the irc in advanced...
So here the summary again...
A normal zip file with a suffix like *.ocd or *.ocs.
The current state is that it is a zip file with a changed header...
So all we need is a zip compatible header and this is completly independent of the name, the suffix, the extension...
I hope that makes the things clear..
So here the summary again...
A normal zip file with a suffix like *.ocd or *.ocs.
The current state is that it is a zip file with a changed header...
So all we need is a zip compatible header and this is completly independent of the name, the suffix, the extension...
I hope that makes the things clear..
>The current state is that it is a zip file with a changed header...
AFAIK C4* is GZIP.
To me it seems like *.oc? is slightly preferred over *.c5?, so I'd suggest to use that. If nobody objects I'll try to do the necessary changes in the upcoming week.
i agree. since i already made a few icons with the OC-label on them, i will make the rest of them too. while opened the .ico-files, i noticed, that i can turn through 6 pages, with the same icon in different sizes, with anti aliasing and without. what are the meaning of those?
also, i will use the Silver/Red color scheme, since it was the same with .c4? files, only with silver/blue, if no one objects.
also, i will use the Silver/Red color scheme, since it was the same with .c4? files, only with silver/blue, if no one objects.
>while opened the .ico-files, i noticed, that i can turn through 6 pages, with the same icon in different sizes, with anti aliasing and without. what are the meaning of those?
6 sizes where automatically the nearest will be choosen, with anti-aliasing are the 32 Bit versions, the icons which will be used on systems with 32 Bit colors, without are the 256 colors versions for those systems with less.
While you're editing the windows registry, you could install the registry keys necessary for extracting packed files with c4group with the installer. (And we could start shipping a install.sh that creates the connection on Linux...)
So I finally got around to finishing this. There might be some hidden side effects or bugs caused by this change so please file bugs and assign to me if you encounter any.
i made some icons.
Attachment: res.rar (121k)
Attachment: ObenGlonk_Icons.hg (666k)
I don't think we should rename player files. The only reason is consistency with the other file extensions, but consistency with 5.1 is more important, because it actually affects players: you can't continue playing with your player file in the other engine. So either we'd do a conversion at startup, removing the player file from the point of view of the 5.1 engine, harassing players who help us test the nightlies, or leaving stale files lying around, or we essentially throw away the player profile for normal players on update. So the engine should continue to work with unmodified old player files. (Brand new player files are a different story, but I don't like making the engine more complicated for aesthetics alone.)
What about this: Let's do a conversion at startup but keep the old .c4p file around until a few days before the 5.2 release at which point we switch to deleting .c4p files?
That's still a lot of effort for no particular gain. But thinking about that, switching the player files to a more efficient format would be helpful. So how about postponing the renaming until someone does the work of implementing a better format?
Not creating an entire c4group for every crewmember. At least with c4group all those tiny files are packed together, with ZIP it would be even more inefficient.
A better format would have either one file containing all information for all crewmembers, or at least give every crewmember only a single file, not their own subdirectory.
A better format would have either one file containing all information for all crewmembers, or at least give every crewmember only a single file, not their own subdirectory.
Hello,
What is the reason to want a good compression of the packages? Nowadays people have generally big hard drives and good network connexion. If it is to save HD bandwidth, then you seem to say that player files are small, so it won't save much, will it?
/Forty (just some old clonk player who has just started playing with OC and would really like to be able to unpack C4 packs with his usual archive/compression tools)
What is the reason to want a good compression of the packages? Nowadays people have generally big hard drives and good network connexion. If it is to save HD bandwidth, then you seem to say that player files are small, so it won't save much, will it?
/Forty (just some old clonk player who has just started playing with OC and would really like to be able to unpack C4 packs with his usual archive/compression tools)
Hi there too, welcome to the OC forum,
Currently every player in an online round needs the playerfile of every other player. This might be good enough for beginners with small player files, but you always noticed it in CR when there where many players with big player files - consisting of all the crew members of all the different rounds, thus making the files bigger and bigger. Therefore it just would be better to optimize this as good as possible, minimizing traffic and in the end, nothing is wrong in saving space.
Also in Windows you can use C4Group as a context menu extension to pack and explode groups quickly. Alternatively you just could add c4group to your PATH somewhere, so it isn't so inconvenient.
Currently every player in an online round needs the playerfile of every other player. This might be good enough for beginners with small player files, but you always noticed it in CR when there where many players with big player files - consisting of all the crew members of all the different rounds, thus making the files bigger and bigger. Therefore it just would be better to optimize this as good as possible, minimizing traffic and in the end, nothing is wrong in saving space.
Also in Windows you can use C4Group as a context menu extension to pack and explode groups quickly. Alternatively you just could add c4group to your PATH somewhere, so it isn't so inconvenient.
The player files were just big because of the portraits stored in there. This "feature" has been (partly) eliminated already.
Personally, I don't see any reason why the packages are still packed in c4groups. Other than that it would require considerable implementation effort to remove this feature and perhaps temporarily pack them in zip for network transmission. And simply... no one did that yet. I think that's the best answer to forty.
Personally, I don't see any reason why the packages are still packed in c4groups. Other than that it would require considerable implementation effort to remove this feature and perhaps temporarily pack them in zip for network transmission. And simply... no one did that yet. I think that's the best answer to forty.
Ok I understand. What about tar.gz or tar.bz2 or even tar.lzma archiving then? Since the whole archive is compressed as one file it is possible to achieve much better compression. Of course, random access possibility would be lost.
The other solution to have only one file would work as well but a way to embed images in the text file must be found. Base64 encoding is generally used for that.
Does C4group works for Linux as well? I used to play clonk on Windows but I don't have any Windows any more.
/Forty
Edit : found the answer to my question :)
The other solution to have only one file would work as well but a way to embed images in the text file must be found. Base64 encoding is generally used for that.
Does C4group works for Linux as well? I used to play clonk on Windows but I don't have any Windows any more.
/Forty
Edit : found the answer to my question :)
The argument I was making is independant of the package format. C4Group transparently deals with unpacked and packed data the same way. At the moment, a player consists of a few files describing the player, and for every crewmember one subdirectory with one file in it. I want to replace that with a list of crewmembers stored in one text file, mostly because that's simpler. It would also use fewer c4group API calls, making an eventual transition easier. Both forms would end up as one physical file on disk with minimal size differences (though for network transfer every byte still counts due to slow uplinks).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill