random thought: Make Spring depend on unitsync?

[Tobi]

I was playing with this idea a bit a while ago; didn't do anything with it and basically discarded it as too big a change. But yesterday I wanted to add support for mod valid maps in the engine. Because all this code lives in unitsync and depends on other unitsync code, currently I'd have to move about a quarter of all unitsync code to the engine just to support this. So I decided to post the following idea here after all, for discussion.

The idea is to give unitsync a more prominent role, and to actually move all the code related specifically to the virtual file system, (part of) map loading, mod loading, etc. into unitsync. The engine could then depend on unitsync and use the exact same API to get it's data as lobbies.

This would inherently result in less code paths, better testing of unitsync, clearer (and strict!) boundary between game code and auxiliary / utility code (less coupling). This could even motivate some one to write decent (automated) (unit) tests for unitsync (Also this would save some binary size and compile time, because now due to unitsync a lot of engine files are compiled twice: zip, 7z, lua, VFS, ..., but of course this is a minor point.)

On the other hand it would introduce some extra complexity in build process, some extra thing that can go wrong, extra wrapper code in engine. (Though implementing CFileHandler in terms of unitsync functions would be trivial and covers a major part of the interface between VFS and rest of engine, so I don't think this wrapper code is a really big problem)

Opinions?

Maybe I'll take a better look at all the problems that may arise later today

[Argh]

I don't pretend to understand all of the implications of this, but I would support unitsync --> engine tie-ins, especially if that meant finally losing the Registry requirements and moving to something that got written to the core directory (no more complaints from players about a game installer wrecking their Settings, etc., and installing multiple Springs with multiple settings would be less messy).

And I would certainly support map limitations, as that would facilitate better support of wild new game types and maybe encourage people to make more true map formats (like that minimalist thing I was talking about a month ago).

[Tobi]

I don't pretend to understand all of the implications of this, but I would support unitsync --> engine tie-ins, especially if that meant finally losing the Registry requirements and moving to something that got written to the core directory (no more complaints from players about a game installer wrecking their Settings, etc., and installing multiple Springs with multiple settings would be less messy).

And I would certainly support map limitations, as that would facilitate better support of wild new game types and maybe encourage people to make more true map formats (like that minimalist thing I was talking about a month ago).

Well, I don't intend to also change functionality at the same time. Refactoring and changing functionality at the same time usually results in bugs (that are harder to find then when doing the refactoring and functional changes in - at least - separate commits.)

This idea is purely about engine internals, pretty much everything would stay the same for end user. (Though some features could be easier to implement...)

[Auswaschbar]

The idea is to give unitsync a more prominent role, and to actually move all the code related specifically to the virtual file system, (part of) map loading, mod loading, etc. into unitsync. The engine could then depend on unitsync and use the exact same API to get it's data as lobbies.

From what I know, unitsync is actually a wrapper for the VFS ( and others) calls, why then use it as a second wrapper? Wouldn't it be better to "librarize" those parts (filesystem e.g.)?

This would inherently result in less code paths, better testing of unitsync, clearer (and strict!) boundary between game code and auxiliary / utility code (less coupling). This could even motivate some one to write decent (automated) (unit) tests for unitsync (Also this would save some binary size and compile time, because now due to unitsync a lot of engine files are compiled twice: zip, 7z, lua, VFS, ..., but of course this is a minor point.)

lua, zip and 7zip are compiled only once in cmake (they are static libraries). They could be made shared libs in with 5 lines of changes.

[Argh]

This idea is purely about engine internals, pretty much everything would stay the same for end user.

IOW, I shouldn't have an opinion yet

NP, was just thinking that if one of the implications was that we could move Spring away from the Registry, it'd make builds for Linux and Windows functionally identical, other than a couple of DLLs (OpenAL vs. DSound, etc.), and that would be a big step in the right direction, imo.

[Tobi]

The idea is to give unitsync a more prominent role, and to actually move all the code related specifically to the virtual file system, (part of) map loading, mod loading, etc. into unitsync. The engine could then depend on unitsync and use the exact same API to get it's data as lobbies.

From what I know, unitsync is actually a wrapper for the VFS ( and others) calls, why then use it as a second wrapper? Wouldn't it be better to "librarize" those parts (filesystem e.g.)?

For the VFS, yes. It also contains quite some custom code though, in particular I need the GetModValidMap stuff in in Spring , so it's definitely more then a wrapper only. Maybe most sane solution would be to just start ensuring it actually is a wrapper for the stuff that's useful in the engine too, by moving the actual code that does stuff to Spring itself.

But indeed librarizing those parts could be a good (first?) step too. Care should be taken though on how to handle stuff that's shared between those libraries again, e.g. logOutput.

This would inherently result in less code paths, better testing of unitsync, clearer (and strict!) boundary between game code and auxiliary / utility code (less coupling). This could even motivate some one to write decent (automated) (unit) tests for unitsync (Also this would save some binary size and compile time, because now due to unitsync a lot of engine files are compiled twice: zip, 7z, lua, VFS, ..., but of course this is a minor point.)

lua, zip and 7zip are compiled only once in cmake (they are static libraries). They could be made shared libs in with 5 lines of changes.

Well that was a minor advantage anyway, and still it saves duplicate compilation of VFS etc. What about the other points?

[Auswaschbar]

For the VFS, yes. It also contains quite some custom code though, in particular I need the GetModValidMap stuff in in Spring , so it's definitely more then a wrapper only. Maybe most sane solution would be to just start ensuring it actually is a wrapper for the stuff that's useful in the engine too, by moving the actual code that does stuff to Spring itself.

+1. Actually I'd say that having everything in unitsync would be more mess than it is now. I am almost sure that the engine itself needs more and other information from maps and mods than the lobbies, adding all of those functions to unitsync will not only make it extremely large, but also hard to use because it contains every function the engine needs.

Well that was a minor advantage anyway, and still it saves duplicate compilation of VFS etc. What about the other points?

Just wanted to say that it doesn't have to be more complex in the build system this way. What other points?

Maybe off-topic, but a general question about ModValidMaps:
As far as I understand, making a map for such a mod would be like:

• make the map
• hack the mod so I can test it with the mod
• if it works, ask the mod-maker to add this map to the list
• mod-maker releases a new version of this mod which can be played with this map

Am I getting it wrong or it is this intended?

[dizekat]

Sounds good to me. Would ensure that lobbies get access to functionality same as spring engine. Its already the case that if spring needs something related to vfs/maps/mods, lobby needs that too.

[hoijui]

+1 for: librarizing the things.

i again want to stress using an other name then unitsync, if a big change is done to it anyway. (i remember i was confused for quite some time in the beginning about unitsync, what it is used for)

[lurker]

On the topic of changing this relationship, it would be nice if Spring loaded its settings through unitsync rather than using whatever it was compiled with.

[Tobi]

They both use same config source so why would that exactly be better?

[lurker]

Because it's very easy to have a situation where they don't use the same source but nothing else is wrong.

[Tobi]

Hmm right.

I suppose that would be an implicit advantage of the reduced number of code paths: engine is really guaranteed to use same settings and same data directories etc. as unitsync..