Combining efforts on proper mod management framework / tools / platform

[keks]

@keks: good plan, lot's of ambition, but be careful, too much ambition at the beginning may lead to messy development (want to go everywhere at once like a rover with 4 wheels, each one on a side of a square ). Maybe a simple tool to start: create base directory tree + dummy files according to some parameter like debian packaging tool, then step up the game with dependencies management (not an easy part) and so on.

I'm currently earning my money by developing applications and maintaining infrastructure, so I know how important extensive planning is. That's why I started a discussion here instead of blindly jumping into a project

Beware of evil statistics gatherer and crash reporter, some noisy people don't like this (see the great controversy thread).

This would of couse be opt-in for both, the end-user as well as the mod developer. You would need to actively enable it yourself. Sane defaults and so on...

For plug-in author, a checker may be useful: check if a version is provided inside the dll info + eventually check against some fields, like mod version and warn if there is mismatch. I guess "auto" recompilation with a chosen KSP version may be a great tool too.

I think I don't exactly understand this one. Could you please further explain the use-case here?

EDIT:

Oh, I think I got your point. Did you mean validating the assembly information against the contents of the meta-file? If so, of course that would be quite easy to do. For the auto-recompilation I am not so sure about. That would heavily depend on how the developers workspace is set up. Something we cannot and certainly do not want to influence in any way. But as already mentionend, building a IDE-plugin would absolutely possible (once we got the core structure up and running), providing such functionality.

/EDIT

As a part creator only, I don't need so much, I even don't upload like crazy. But I have doubt about auto uploading, as it will need one module per website, and worth, check those websites (especially the commercial one like most of spaces providers) regularly for updates they don't talk about (quite like JDownloader tool which have tons of plug-in for almost each single one online storage website).

Well, I think we don't necessarily need fully automated upload for all sites. I think a tool preparing as much as possible for you (update a text template for your post and properly pack up the mod itself) would be good enough for most modders. At least that would be something to start with, that can easily be implemented. You as modder would then only need to copy&paste into your forum thread / website and upload the prepared archive file.

Edited August 2, 2014 by keks

[TeddyDD]

keks I have some questions for you because I'm not sure I understand what you mean.

1. Want to create a single central repository, or rather something modeled on Linux PPA?

2. Are you want to keep mods (zip files) in the same repo as metadata files? Or mayby want to keep the yaml files inside the archive with the mod?

Or rather a repository of metadata not contain zip files, which would be taken from outside?

Anyway in my opinion, the first thing to determine is the same look and feel of files that store metadata.

[keks]

1. Want to create a single central repository, or rather something modeled on Linux PPA?

As a Debian user I learned to love their package management system and policies. I'd like to create something similar to that, where there is a controlling instance assuring the quality of the packages (or mods in our case) in terms of respecting defined standards. Like supplying a proper license, documentation, meta-information, etc... End-Users could ultimately add different repositories to their managing application, but that would be something to think about later. In the first step I'd like to follow a centralized approach, to ensure everything works as expected and to define said standards in a proper way. Once we accomplished to get the system working properly, we of course could enable other people to easily create and maintain repositories as well.

I'd also love to work hand-in-hand together with KerbalStuff. We could provide all the information, and KerbalStuff could build upon that data and provide a great web-frontend for managing, indexing and manual downloading of the mods. But of course, that's totally in the hands of the KerbalStuff guys to decide if they would like to cooperate in such a way.

2. Are you want to keep mods (zip files) in the same repo as metadata files? Or mayby want to keep the yaml files inside the archive with the mod?

Or rather a repository of metadata not contain zip files, which would be taken from outside?

Ultimately it would be nice to host both, the meta-information as well as the actual mod itself. That includes the source as well as proper pre-built binary releases. But as you might know that will not be possible for many mods, as long as they do not provide a proper license allowing us to do so. That's why I intend to support these mods through so-called meta-packages which would simply point at the original location of the mod, so the client-application can easily download it from there. The meta-information would in this case still be hosted by us and maintained by some volunteer maintainer.

As in the example repo I put up and linked earlier (https://github.com/ksprepo/) I'd like to keep it all together where possible, but split it into three branches:

* upstream: the original modders branch, where we keep track of the unmodified original content. So it would basically be a mirror. That would also allow us to easily send patches / pull-requests upstream to the modders.

* develop: the branch maintainers actively contribute to, like creating meta-information, merging updates from upstream, applying hotfixes, etc...

* master: the actual 'release' branch keeping track of versions we release.

Both develop and upstream will almost always be exact copies of upstream, except the additional meta-data as well as (eventually) additional documentation and changes in directory-structure (if necessary).

Anyway in my opinion, the first thing to determine is the same look and feel of files that store metadata.

That truly is something to specify early, but first we need to find out what data we actually need and how it should be organized. The examples I mentioned earlier are really just a first draft to give you an idea of what I am talking about. The meta-files will have to follow a exactly specified scheme later. Else the repo as well as the client-application can't work with them

Some things we need are:

* title

* author (may be multiple)

* version

* original source (forums / curse / etc - may be multiple)

* mandatory dependencies

* optional dependencies

* license and copyright (may be multiple)

* checksum

* download url (for meta-packages)

* file-map (where things go)

any most likely some more.

Edited August 2, 2014 by keks

[TeddyDD]

Ok, thanks, that's something

I do not really like the keeping mods together with metadata (there are many websites to keep mods) but I also see the advantages. In my view, the ideal solution would be if the metadata could be completely independent and to contain all the information needed to install mod by any program following this standard.

This is my design of such a meta file. I worked on it in April and since then I have a lot of other ideas. There's a mess, unfortunately. Also its python file but you can guess how it works.

http://pastebin.com/NWc5WjRV

Of course, many fields from this file would probably be completely unnecessary like extends

The main difference in our ideas is each metadata file would have name like MODNAMEvVERSION.some_funny_extension

Then you would need a way to get a list of packages from the repository. Then the program will fetch the file with metadata. In this file would be link to download mod itself.

Edited August 2, 2014 by TeddyDD

[neamerjell]

Might I suggest Nexus Mod Manager. It works beautifully for Skyrim...

[TheAlmightyOS]

Might I suggest Nexus Mod Manager. It works beautifully for Skyrim...

Oh how I wish it were so simple

I use nexus for Fallout 3, Fallout NV, Morrowind, Oblivion, Skyrim, The Witcher 2, DragonAge.... and it would work great with KSP to. But it would split this community even further.

This community needs LESS options, not more. THAT is the reason we need things like a mod repo in the first place.

[Justin Kerbice]

@keks: you get it for plug-in auto compilation. I think it may be easier than we may believe initially as modders just have to provide a build script, so it can call the compiler, put all source files together and build a super nice library ready to package.

For fields, instead of mandatory/optional dep, I believe Debian's style is better:

depend: the mod CAN'T work with it (ex: hotrockets/smokescreen, HR can't work without SC, I guess or some other which use MM)

recommend: the mod can work but with less feature mostly (ex: Extraplanetary launchpads: Kethane is not hardly needed, but without it, mining is off)

suggest: the mod can do even more incredible things with the dep (... not sure such an example exists) or just the suggested mod(s) improve users experience (I guess more example can be found with RSS, Lifesupport, etc mods + RF/MFT) or simply a new mod with heat-shields suggest Deadly-Reentry as without it it'll be just visual.

+ KSP version can be a substitute for distribution version, ie instead of stable, testing and unstable, we can have 0.23, 0.23.5 and 0.24

so people keep the choice of moving from one KSP version to another as smooth as possible (maybe similar to what they have with Steam), with the ability to find and auto update mods to another version.

ex: 0.23.5, mod A,B & C

A v1.0 dep on B 1.2

C v 2.5 suggest D 1.3

upgrading to 0.24.2 =>

check A... v1.1 exists, support 0.24.2 ok

check B... v1.2, no update, A is on hold

and so on.

Finally the modding tool may include a checker, so it will verify a mod to be sure all requirement are there (a readme, not empty ! , a license, an install instruction, a GameData folder, ...) and display warning like "no readme included" or even more better: "mismatch between dir name aaAA and part using aAAA" (as KSP is case sensitive)

[keks]

@keks: you get it for plug-in auto compilation. I think it may be easier than we may believe initially as modders just have to provide a build script, so it can call the compiler, put all source files together and build a super nice library ready to package.

These build scripts would have to be standardized and may not fit every developers environment. I'd prefer to not have to have the mods compiled by the maintainer, rather than just redistributing the binary release created by the original author. Forcing the developers to make use of unified build scripts is not better than forcing them to use a special directory layout.

For fields, instead of mandatory/optional dep, I believe Debian's style is better:

depend: the mod CAN'T work with it (ex: hotrockets/smokescreen, HR can't work without SC, I guess or some other which use MM)

recommend: the mod can work but with less feature mostly (ex: Extraplanetary launchpads: Kethane is not hardly needed, but without it, mining is off)

suggest: the mod can do even more incredible things with the dep (... not sure such an example exists) or just the suggested mod(s) improve users experience (I guess more example can be found with RSS, Lifesupport, etc mods + RF/MFT) or simply a new mod with heat-shields suggest Deadly-Reentry as without it it'll be just visual.

Thats actually exactly what I proposed. There are mandatory dependencies (debian's "depends") and optional dependencies (debian's "recommended" / "suggests"). As "suggests" vs "recommend" would be based on subjective personal opinion of the maintainer, I'd like to not distinguish between them. Instead this field was meant to list optional mods that extend the functionality of this mod in any way. The popular "Toolbar" for example would be a candidate for "optional" as most mods do not depend on it, but make use of it when it is available.

+ KSP version can be a substitute for distribution version, ie instead of stable, testing and unstable, we can have 0.23, 0.23.5 and 0.24 so people keep the choice of moving from one KSP version to another as smooth as possible (maybe similar to what they have with Steam), with the ability to find and auto update mods to another version.

I don't think you will get may modders to keep up support for more than one target version. There's really no point of doing so (IMHO) as KSP is still in early beta. I do not aim to maintain the mods code, fix compatibility, offer support, etc. All I want to do is taking away the pain of updating mods by hand. If we decide to host via git, we'd simply tag a release with it's proper version string. The client-side application can then get a list of these versions (for example through GitHub's API) and download the versions meta-data.

Again, I do not want to maintain the mods, I watn to maintain meta data.

Finally the modding tool may include a checker, so it will verify a mod to be sure all requirement are there (a readme, not empty ! , a license, an install instruction, a GameData folder, ...) and display warning like "no readme included" or even more better: "mismatch between dir name aaAA and part using aAAA" (as KSP is case sensitive)

That's something we could do later. At the start I'd do this on service-side rather than client-side to be able to easily change standards once problems arise.

Oh how I wish it were so simple

I use nexus for Fallout 3, Fallout NV, Morrowind, Oblivion, Skyrim, The Witcher 2, DragonAge.... and it would work great with KSP to. But it would split this community even further.

This community needs LESS options, not more. THAT is the reason we need things like a mod repo in the first place.

My opinion. Additionally Nexus is just another commercial platform just like Curse is. I do not want o rely on a external company.

What I want is a open and free community of modders, maintainers and end-users working together, not because they want money, but because they like to do what they are doing.

When using a commercial platform, we would be bound to their decisions. Just like Squad decided to take down SpacePort and replaced it by stupid Curse.

Ok, thanks, that's something

I do not really like the keeping mods together with metadata (there are many websites to keep mods) but I also see the advantages. In my view, the ideal solution would be if the metadata could be completely independent and to contain all the information needed to install mod by any program following this standard.

This is my design of such a meta file. I worked on it in April and since then I have a lot of other ideas. There's a mess, unfortunately. Also its python file but you can guess how it works.

http://pastebin.com/NWc5WjRV

Of course, many fields from this file would probably be completely unnecessary like extends

The main difference in our ideas is each metadata file would have name like MODNAMEvVERSION.some_funny_extension

Then you would need a way to get a list of packages from the repository. Then the program will fetch the file with metadata. In this file would be link to download mod itself.

Actually there is no big difference in our ideas. As I said earlier we do not have to (and in some cases cannot) host the mod data itself. The meta-data can be distributed independently to the actual mod-data itself, as long as both versions match up. In my scenario this would be realized via download-url and checksum in the meta file. the meta-file itself would be distributed through GitHub and tagged with the mod version.

That way you can say "hey, give me the meta data of mod X version Y" and you will get a file pointing you to the actual download location for the mod data.

One problem with external hosting is that we cannot be sure the file will remain available over time. Many modders just replace their uploaded files with new versions, making the old version inaccessible. This would not be a problem when we host the mods ourselves.

Edited August 4, 2014 by sumghai
Consolidated consecutive replies by the same poster

[TeddyDD]

I understand, but metadata files in your sample repository would not be independent. It would be best to package file always contain a link to the files and every information even if it is stored together with the mod.

One problem with external hosting is that we cannot be sure the file will remain available over time. Many modders just replace their uploaded files with new versions, making the old version inaccessible. This would not be a problem when we host the mods ourselves.

That's a point. We can mirror only mods, which the license allows it. Unfortunately, there's nothing you can do about it. I have always believed that mods with restrictive licenses is a bad idea. It is a pity that Sqad allows it.

In any case, I am very glad that you created this thread. It's time to simplify process of installation and updating mods. I just spent about 40 minutes making sure that I have all mods up to date :>

We need to find a convenient way to brainstorm with moders and the authors of mod managers and design metadata file that will suit everyone. This is the basis of the entire system.

[keks]

I understand, but metadata files in your sample repository would not be independent. It would be best to package file always contain a link to the files and every information even if it is stored together with the mod.

The meta-file will always contain all information available. It does not matter if we host the mod or if it is an external mod. There's only one exception: the download url. We do not need this parameter for self-hosted mods, because they can (and should) be identified by their unique name.

[TheAlmightyOS]

My opinion. Additionally Nexus is just another commercial platform just like Curse is. I do not want o rely on a external company.

What I want is a open and free community of modders, maintainers and end-users working together, not because they want money, but because they like to do what they are doing.

When using a commercial platform, we would be bound to their decisions. Just like Squad decided to take down SpacePort and replaced it by stupid Curse.

Actually, unlike curse, Nexus was created by fans [citation included] to host their mods and turned into something bigger. It started much like Kerbal Stuff is starting with KSP right now. Curse, on the other hand, was a way to make money [citation included]. And as you can see, Nexus founder has no intention on going commercial.

Now, that's not to say that I think we should SWITCH to Nexus. That would be very bad this late in the game. Just clearing up some misinformation.

And back to what I was saying, Going from one mod host to another... that is the problem. This community is FRACTURED every which way. And right now almost every single modder out there uses THIS FORUM to showcase their work. A forum that, going from some people's sigs, had a catastrophic failure and lost data not too long ago.

keks, I will be very honest with you. I like your idea very much. It could work. Just like all the other ideas out there. There are faws, such as how to scale such project. KSP is a very modifiable program and the devs are making it easy for modders so I foresee thousands of mods during KSP's life-cycle. How can a few individuals maintain a repo of meta-data for so many mods? Those sorts of things need to be worked out.

I just deleted what was going to be a rant. I won't hijack your thread. Your working toward a solution so hats off. May the best fix win

[Justin Kerbice]

One problem with external hosting is that we cannot be sure the file will remain available over time. Many modders just replace their uploaded files with new versions, making the old version inaccessible. This would not be a problem when we host the mods ourselves.

Don't forget not a single mod license forbid private "hosting", you can always keep a particular version in a place you own, asking modder in such case when old version are still needed.

[keks]

Actually, unlike curse, Nexus was created by fans [citation included] to host their mods and turned into something bigger. It started much like Kerbal Stuff is starting with KSP right now. Curse, on the other hand, was a way to make money [citation included]. And as you can see, Nexus founder has no intention on going commercial.

Nexus has a subscription model. Without subscribing you will not get any decent download speed. An I remember not being able to download some mod without going 'pro' in the past. But that was long time ago, I cannot exactly remember which mod / nexus platform that was...

keks, I will be very honest with you. I like your idea very much. It could work. Just like all the other ideas out there. There are faws, such as how to scale such project. KSP is a very modifiable program and the devs are making it easy for modders so I foresee thousands of mods during KSP's life-cycle. How can a few individuals maintain a repo of meta-data for so many mods? Those sorts of things need to be worked out.

That's the point. We don't have to support thousands of mods. In the beginning we'd have to support a few dozen most common mods. Then we will get to a point where we either get enough support from the modders / independent maintainers, or we don't and the project is doomed to die. It's that simple. Support for a mod with no active maintainer will be dropped and so it will no longer be available (at least the most current version) via the repo. This in turn may make someone else take over maintainance of the mod, or not.

I really do not care which mods area available via the repo. With such a system it's really not that much work to maintain a few dozen mods as a single person. It's basically the same I do right now with a bunch of google docs sheets for my own KSP installation. Right now I have 107 mods on list of which 101 are installed. So one could say I currently actively maintain 101 mods as just a single person.

It's important to understand that as a maintainer there is really not much work to do for a single mod. Most mods will not change their directory structure that often over time, so all a maintainer would have to do from update to update is to upload the new version to the repo (or update the download url for non-licensed mods, respectively), replace the version string and maybe update dependencies. That's something that can almost always be done in less than five minutes.

I just deleted what was going to be a rant. I won't hijack your thread. Your working toward a solution so hats off. May the best fix win

I'd really like to read it ;-) I started this thread to discuss, to read what you guys think about this. To read about different attempts / alternate solutions

[keks]

Don't forget not a single mod license forbid private "hosting", you can always keep a particular version in a place you own, asking modder in such case when old version are still needed.

That's not correct. Depending on the license you may not be allowed to redistribute the mod in any way. That includes "hosting" the download archive. Not to mention unlicensed content.

[TheAlmightyOS]

Keks, I think I got an idea. Well, more like your idea but with some alterations. Do you have an example of that meta-file you want to use?

oh, sorry about not responding directly to responses. I think I might be on to something big.

You ever talk to the guy who maintains Version Checker?

BTW, want to see the train wreck from that rant: http://forum.kerbalspaceprogram.com/threads/89490

[keks]

Keks, I think I got an idea. Well, more like your idea but with some alterations. Do you have an example of that meta-file you want to use?

There is no format for such a file yet. That's why this is called planning stage, where we plan what we need an define our requirements

I linked an early draft version in a previous post (actually there's also a link to an example repo, which ofc. also is an early draft).

You ever talk to the guy who maintains Version Checker?

I took a look at that mod earlier, but that one is really just a basic update notifier based on a static link to a json/yaml-file. I also linked that mod in my initial post i think.

I want to create a full-blown mod repository with everything we need - that includes the modders and end-users. So far none of the solutions present do this in any acceptable way. Either they completely focus on one side, have a absolutely unmaintainable code base, do no work correctly or are simply "broken by design" (IMHO). Don't misunderstand me, I do not want to make those developers look bad, I actually learned quite a lot from their failures.

BTW, want to see the train wreck from that rant: http://forum.kerbalspaceprogram.com/threads/89490

Well, ofc. modders do not want to change theys way they work. That's just how developers (including me) are And that is the point why I am trying to create a opt-in solution with absolutely minimal effect on the developers themselves. If they don't like it, fine, just ignore it. Maybe someone else will pick up your mod and maintain it for you. You don't want us to distribute your mod? Fine, simply tell us to leave you alone and/or add this restriction to your license and you're done.

@the modders:

IMHO it's sad that so many people here fear any kind of change instead of saying "Ye, let's try that. Even if it does not work we may learn something on the way." This Project may have great potential, but I will not do it on my own. I do not want to build a mod management system for myself, I want to build it for this community, with the help of this community. I am open to any suggestions, so tell me what you would like to see. If you prefer talking, we could also organize a teamspeak/skype/ventrilo/google hangout/whatever meeting and talk. But again, I will not start coding anything until I get at least 3 developers to work with me.

[TeddyDD]

I will not start coding anything until I get at least 3 developers to work with me.

Do not count me as a developer but despite the fact that not all of your ideas I like I'm with you

http://forum.kerbalspaceprogram.com/threads/89490-A-Modding-Community-Divided <- It's getting hot :>

[TheAlmightyOS]

Do not count me as a developer but despite the fact that not all of your ideas I like I'm with you

http://forum.kerbalspaceprogram.com/threads/89490-A-Modding-Community-Divided <- It's getting hot :>

You're not the one in the fire getting roasted I need to learn when to STFU. EDIT: So now YOU threw yourself into the fire. Well, at least I will have a buddy in the burn unit

Keks, I think if we work together with the KVC crew we could add more to the .version file, aka metadata. The Mod author has to go to the site anyway to generate the file (opt-in), why not have them fill out two or three more fields of information then when they download a version file and the version DB is updated, our repo gets the medadata file OR we combine databases with the KVC guys. It's a thought at least

And what kinda code are we talking here?

Edited August 5, 2014 by TheAlmightyOS

[TeddyDD]

You're not the one in the fire getting roasted I need to learn when to STFU. EDIT: So now YOU threw yourself into the fire. Well, at least I will have a buddy in the burn unit

Nothing new here. Anyway I'll burn in hell

We considered the needs of developers (about a format of file etc.) Fortunately they do not have any

We just do our bit.

[keks]

Keks, I think if we work together with the KVC crew we could add more to the .version file, aka metadata. The Mod author has to go to the site anyway to generate the file (opt-in), why not have them fill out two or three more fields of information then when they download a version file and the version DB is updated, our repo gets the medadata file OR we combine databases with the KVC guys. It's a thought at least

It's not just the meta-data. We need to make sure we have all information available in a way that our versioning system can easily work with. Changing the existing .version files from this mod would break compatibility (maybe multiple times) and I don't think that's what they want. What I'd suggest is to build this repo as a standalone system, and once we got it working we open up for external developers to build upon it. So the KVC guys could make their mod work with the repo, and in turn also contribute back to us.

And what kinda code are we talking here?

What do you mean? We would need to create the full client-application doing (almost) all the logic. We're talking about at least a few thousand lines of code.

I'd suggest C#/Mono, as that's what KSP is build with, so there would not be any additional client-side dependencies.

In addition to that, we'd need to create the developer tools as mentioned earlier.

As for the problem with scalability you mentioned over in the other thread:

There really is no problem at all. The current plan is to make this a decentralized system. As I already said earlier there is no reason to only have ONE repository. With my proposed architecture you could have hundreds of repositores hosting different mods. Even each developer could have his own repo if he wants to. It really does not matter at all, how many repositories a client uses, as long as there are no conflicts between them.

That's exactly what "apt" does on Debian-based distros right now, efficiently handling more than 20k packages and their dependencies in like no time.

Edited August 5, 2014 by keks

[TeddyDD]

We should talk to these people:

http://forum.kerbalspaceprogram.com/threads/78861-Java-8-Win-Linux-Mac-Ultra-complete-Mod-Manager-v0-1-8-7alpha

http://forum.kerbalspaceprogram.com/threads/26031-Win-KSP-Mod-Admin-v1-3-11-%281-4-0-PR-12%29-Mod-install-with-a-few-clicks

http://forum.kerbalspaceprogram.com/threads/57284-All-OS-Java-MultiPlayer-Part-Manager-v3-4-2-March-2014-No-Support

http://forum.kerbalspaceprogram.com/threads/85865-Tinker-Time-Self-Updating-Curse-com-Mod-Manager-for-KSP

[TheAlmightyOS]

It's not just the meta-data. We need to make sure we have all information available in a way that our versioning system can easily work with. Changing the existing .version files from this mod would break compatibility (maybe multiple times) and I don't think that's what they want. What I'd suggest is to build this repo as a standalone system, and once we got it working we open up for external developers to build upon it. So the KVC guys could make their mod work with the repo, and in turn also contribute back to us.

What do you mean? We would need to create the full client-application doing (almost) all the logic. We're talking about at least a few thousand lines of code.

I'd suggest C#/Mono, as that's what KSP is build with, so there would not be any additional client-side dependencies.

In addition to that, we'd need to create the developer tools as mentioned earlier.

As for the problem with scalability you mentioned over in the other thread:

There really is no problem at all. The current plan is to make this a decentralized system. As I already said earlier there is no reason to only have ONE repository. With my proposed architecture you could have hundreds of repositores hosting different mods. Even each developer could have his own repo if he wants to. It really does not matter at all, how many repositories a client uses, as long as there are no conflicts between them.

That's exactly what "apt" does on Debian-based distros right now, efficiently handling more than 20k packages and their dependencies in like no time.

Keks, you got a good idea and for sticking up for me in that thread I know you are a good guy too, but I do not think this is the direction I am going to go in. While your plan most definitely would work with the right backing it is at best a band-aid for a system that is inherently flawed and, I should say, intentionally crippled by those who should be the leaders of this community. I wish you good luck on your project man. If you ever need a server to test it out on or some help debugging code or testing just throw me a PM and I will offer what I got. As for me, I am going to take a swing at the core issue

Edited August 6, 2014 by TheAlmightyOS

[keks]

As for me, I am going to take a swing at the core issue

And how would that look like? Do you plan to take over Squad and force developers to play by your rules?

[TheAlmightyOS]

And how would that look like? Do you plan to take over Squad and force developers to play by your rules?

Why does everyone.... Seriously, WHY? I compliment people. Be polite, friendly. I try to understand their side of things, I look for compromises but everyone and their dog thinks I am trying to get "my way" and just trample over everyone? I don't even have A way! I just know the system is broken.

Sheesh, what did I do in a past life? Take over a small nation?

[keks]

Why does everyone.... Seriously, WHY? I compliment people. Be polite, friendly. I try to understand their side of things, I look for compromises but everyone and their dog thinks I am trying to get "my way" and just trample over everyone? I don't even have A way! I just know the system is broken.

Sheesh, what did I do in a past life? Take over a small nation?

I did not mean to offend you in any way. I was just interested in how your solution may look like