New file extensions

[Simbax]

Currently, CBOT, Scene and SatCom files are kept in .txt files.

Advantages:

• Less intimidating for non-tech savvy users.
  
• Simpler programming in the engine?
  

Disadvantages:

• No reliable way to automatically detect the files in plugins for various text editors.
  
• Without looking at the contents, the files can be identified only by filename and/or name of the folder they're in. This makes searching and scripting a little harder.
  

The idea of changing the file extensions to something more meaningful existed for a too long time. We should finally decide and make it happen (or not).

No poll this time. At least yet. The subject matter is too complicated for a simple poll. I want everyone interested to answer the following questions:

Question no. 1. Do you want new file extensions? Whatever we choose as the new file extensions, changing them will bring problems with backwards compatibility. It may also be hard to change the engine at all. The changed names may cause problems with existing forks and branches. And there may be some more problems along the way. If you don't want any change, say why, it may be simply because you feel that it is ok like it is right now.

Question no. 2. If yes, what should the extensions be? It's a subjective matter really, it depends if we want to keep the extensions short or if we care more about their readability or if we care more about their consistency or if we care more about no conflicts with popular extensions and so on. So, let's see some propositions which appeared yesterday during a little Slack discussion:

1. Readable but long:
   • .cbot
     
   • .satcom
     
   • .scene (might cause conflicts)
     
2. Short, but less readable, might cause conflicts:
   • .cbot, .cbt?
     
   • .stc, .sat, .scm, .sam, .sac, .com, ...?
     
   • .scn
     
3. Again, short, but less readable, but less conflicts:
   • .cbot
     
   • .cbtm
     
   • .cbts
     
4. More suggestions?
   

No more questions I can think of.

[tomangelo]

1. I'm for new file extensions as long as it's possible to keep backward compatibility with .txt files. File structure won't change much (if at all), so only difference is file extension, which only make difference on Windows OS. It would be bigger issue if we would want to change internal file structure.
2. I think long extensions will be best. Easier to remember than shorter extensions ("Was it .sac like SAtCom, or .sat like SATcom, or .sam like SAtcoM, or [...]?"). It shouldn't be a problem for current OSs. It also makes it conflict-proof (.cbot and .satcom aren't used, .scene isn't really popular, used by few 3D editors).

[RaptorParkowsky]

4. More suggestions. This way is more consistent imho.

• .cbot
  
• .cbsm
  
• .cbsc
  

I'm against keeping backward compatibility with previous GOLD versions, and especially with original Colobot game. The game must evolve as much as it's possible before the beta stage. Maintaining backward compatibility would slow down development of some key aspects of the game. And that would cause unnecessary complexicity of the engine.

[tomangelo]

There are some custom scripts and userlevels that doesn't support these extensions yet, also making all these files suddenly "unable" to open in game or in Windows Notepad would be very confusing for some players. At least it would require some information in-game that you need to rename your files. Or make game to automatically rename them?

Code:

if(file.extension == ".txt")
{
    file.convertTo(new_ext);
}

[krzys_h]

I don't think this change is really needed. The fact that everything is immediately openable as simple text files is a part of what makes this game so eaisly moddable, and that's partially what initially got me interested in digging into it deeper. If your main goal is to detect file type automatically, why not just an optional header at the top, like what shell scripts on Linux usually use? It's slightly harder to implement everywhere but makes backward compatibility easier, keeps opening them easy, and most editors should be able to understand these for language detection.
offtop: Would anyone be interested in finished external CBot interpreter? If we made the headers compatible with Linux shebangs, you could launch them with

Code:

chmod +x somescript.txt # or any other extension
./somescript.txt

(although there is probably no practical reason you'd ever want to do this)

[radioactivity]

I have to ask just in case, Cbot will be able to save files in .scene, .scn, .cbts or .whatever, just as it can do now in .txt? I assume it can, because it's just file extension, just want to be sure though. Otherwise I'm indifferent, though backwards compatibility would be really nice

[Simbax]

If your main goal is to detect file type automatically, why not just an optional header at the top, like what shell scripts on Linux usually use?

Shell scripts still have a file extension and it's not like there are different highlighters for different shells, are there? The first line is for the shell to recognize which program to use when running them like ./script.txt, not for editors.

No, it's impossible in almost every editor to implement "first line detection" simply because in most editors file extension is worth more points than first line (or there isn't even such a setting at all). Once it's .txt, the language's set to "Plain text", it doesn't even look at the first line at this point. In fact, the only editor in which the first line detection works somehow is in Sublime Text IIRC. The related issues in VS Code and Atom are still open and I doubt they will be closed soon simply because it's hard to find an implementation of language detection that would cover all edge cases and this one is probably the rarest one.

keeps opening them easy

If by "opening them easy" you mean that every time I open a .txt file I have to set the correct syntax by hand which is annoying, slowing down and distracting, then yeah.

Would anyone be interested in finished external CBot interpreter?

If that'd be useful in implementing some error detection, intellisense etc. in extensions, then I'd be interested in that.

---

Everyone seems to have a different opinion about the subject, I'm afraid we won't reach an agreement any time soon :/

[krzys_h]

Shell scripts still have a file extension

Actually, they often come with no extension at all. You probably don't even realize how often programs you run on Linux are actually shell scripts. Just by randomly looking at some files in /usr/bin I found at least pip, lsb_release and ssh-copy-id.

it's not like there are different highlighters for different shells, are there?

Shebangs are not only for shells but also for all kinds of other interpreted languages like Python, Perl, PHP etc.

The first line is for the shell to recognize which program to use when running them like ./script.txt, not for editors.

I know for a fact thay both vim and IntelliJ IDEs set the syntax highlighting correctly based on a shebang, I never tried it on anything else. Jenkins' docs even recommend adding a shebang to Jenkinsfile just for the sake of syntax highlighting in editors.

[Simbax]

I know that, but they all still have their file extensions. What is more, I already said that file extension is worth more points than first line. So if a file already has an extension, an extension matching other language, like .txt, then it doesn't bother with first line. First lines detection work when a file has no extension, duh, that's not the problem.

Well, if vim and IntelliJ IDEs do that it's good for them. In both, Atom and VS Code, I'm pretty sure it's almost impossible (it'd be maybe doable with some scripting now that I think about it, but that'd be a dirty workaround).

Honestly, all I want is to make lives easier. We could keep even C++ source code files in .txt files, but we are not for obvious reasons. And to me, these reasons apply as well in the case of CBOT and other files, so why .txt? Different file extensions exist for a reason.

[tomaszkax86]

For binary files, file name extensions are not necessary because they often have headers with magic numbers that identify them easily.
Most often the case with images, audio and video files, executables and so many others. But with text files there's no easy way to tell right away what the format and meaning are, so the extension can tell you exactly what a given text file is meant to be. .txt are simple text, .ini files are Windows configuration files, .inf are installer files, and every computer language has its own set of extensions to identify source code. This is why it would be better, in my opinion, if Colobot used special extensions for at least some files.

I think we can at least agree that CBot source code could use .cbot extension. The language definitely deserves some recognition and by reserving unofficially this file name extension we can give it some.

Once we get to fixing this mess with model formats, we could decide if we want to introduce new file name extension for new formats or not. I checked that .cbm and .cmod are already used for some files, but .cbmod and .cbmf are available.

Scene and SatCom files could also use their own extensions to clarify what they mean. We could just use .scene and .satcom since they only really have a meaning within Colobot so it wouldn't cause real problems. We could also use 4-letter extensions and they could start with .cb, like .cbsf for scene files and .cbsc for SatCom files. Both are currently not in use.