Project GenericVessel 140205, the SC3 open-source replacement

[Donamy]

Artlav,
You've seemed to have fixed the problem with the tip movement. I redid my EVAguy.ini the way it should be and it works with GV, not needing the workaround with SC3.

Could you acc more robotic joints ? SC3 only allows 8.

---------- Post added at 05:24 AM ---------- Previous post was at 03:40 AM ----------

Bug found.
When in robotic mode, while pressing Lshift + keypad (2,4,6,8) to operate the arm motion. The other animations set for those keys also operate. It needs to be either robotic or regular animations.

 

[Face]

Agreed, and add a note on the docs asking addon creators not to redistribute GV. That should be simple enough.

Such a note should then be formulated as suggestion, not restriction, or it would make the license void, just as stated in the license coming with the distribution:

(emphasis mine)

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version.

Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights.

and

4. You may not copy, modify,sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

However, if it is only a suggestion, it will not fulfill its purpose: avoid versioning hell. That's why I suggested to cure the disease instead of the symptom.

 

[Artlav]

I'm guessing that "location" should be "orientation", right?

Yep...

Could you acc more robotic joints ? SC3 only allows 8.

AFAIK there are no limits like that in GV.
Does it not work somehow?

AFAIK you can't restrict distribution on GPL'ed software. I'd instead suggest to add a version check feature, e.g. by offering (and checking) an optional compatibility key for developers to author into the vessel descriptions.

Restrict? No.
Ask nicely? Why not?

Not sure what a compatibility key would look like.
The problem is that add-on A with version 3 will overwrite previously installed add-on B's version 7.
B and other newer ones cease to work.
Version compatibility keys would prevent crashes and weird appearances (assuming the add-on makers typed them right, which is a big if), but won't solve the underlying problem.

Asking not to redistribute the binaries, on the other hand, should reduce the occurrences of the problem by a significant fraction, without any license voiding.

 

[Face]

Not sure what a compatibility key would look like.
The problem is that add-on A with version 3 will overwrite previously installed add-on B's version 7.
B and other newer ones cease to work.
Version compatibility keys would prevent crashes and weird appearances (assuming the add-on makers typed them right, which is a big if), but won't solve the underlying problem.

A compatibility key alone will indeed not fix the underlying problem. It is however a prerequisite to solutions. As you already stated, it can enforce integrity.

I think the most feasible solution is a side-by-side approach. Vinka's SC3 already took one, that's why they are named spacecraft2 and spacecraft3, after all. I'll take a similar approach for genericvessel, but not solely based on filename suffixes alone, as GPL'ed software tends to be more dynamic version-wise than closed code. If you are interested, I can outline it here.

Asking not to redistribute the binaries, on the other hand, should reduce the occurrences of the problem by a significant fraction, without any license voiding.

I doubt that. Discipline-based workflows hardly ever work. With suggestions alone, you don't have any tools to ensure that popular places like OH are not riddled with genericvessel addons that include the runtime DLLs. More than suggesting you can't do without voiding the license, therefore the "cathedral" approach is IMHO failing here (as opposed to e.g. DanSteph's OS/UMmu/UCGO).

 

[4throck]

Why would I redistribute the GV .dll?
Nobody distributes GIMP along with textures, so the same applies here.

One thing is developing further versions of GV, another is using it to create add-ons.
No need to complicate what's simple!

If GV is backward compatible then there are no version problems. You only need to have the latest version from OH.

 

[Face]

Why would I redistribute the GV .dll?
Nobody distributes GIMP along with textures, so the same applies here.

One thing is developing further versions of GV, another is using it to create add-ons.

If GV is backward compatible then there are no version problems. You only need to have the latest version from OH.

One reason for users to redistribute genericvessel is because they did so before with spacecraft3. Another one is because they want to ensure easy installation, aka unzip and JustWorks(TM).

Your GIMP analogy falls apart, because a texture is an artifact you CREATE with GIMP, but an INI addon is not what you create with genericvessel. Instead your INI addon USES genericvessel.

Your last sentence has two fallacies in it:
1. "If GV is backward compatible": who ensures that? genericvessel is open sourced, there is no authority over it.
2. "You only need to have the latest version from OH": what exactly is a latest version, and why is OH the one place to get it? Those question can only be answered by "because somebody says so". In this case it is Artlav, but what if somebody else takes the code and develops it even further, possibly forks it - just as Artlav did for himself - and decides that his version is now the latest one on a different download place?

You might be inclined to say "this will never happen, we will just force the heretic to put down his copy", or "then it will be no official genericvessel". But there is no right you have to say this in a GPL project. If an addon-developer creates something based on an arbitrary genericvessel runtime and distributes the binaries with it, you can't complain that he is doing so, because the license given is allowing him to do this.

TBH, I think that the prospect of a practical restriction - due to community pressure - of runtime distribution could well kill genericvessel's potential as a feasible custom DLL alternative. It is better to think about solving the issue once than to start pointing fingers if hits the fan.

 

[Artlav]

I think the most feasible solution is a side-by-side approach.

I don't get it.
Distribute a dozen dlls, like SC1, 2 ,3 did?

With suggestions alone, you don't have any tools to ensure that popular places like OH are not riddled with genericvessel addons that include the runtime DLLs.

But i can put a first point into a troubleshooting guide:
If it does not work, download the latest genericvessel from the base repository.

Also, why would anyone actually distribute it with the add-ons?
SC3 tradition?

 

[Face]

I don't get it.
Distribute a dozen dlls, like SC1, 2 ,3 did?

Not distributing it that way, but instead allow for more than one version to be addressed.

But i can put a first point into a troubleshooting guide:
If it does not work, download the latest genericvessel from the base repository.

What is the base repository? What if it changes over time?

Also, why would anyone actually distribute it with the add-ons?
SC3 tradition?

As already written, because it will make it easy for the end-user to install (given that genericvessel actually supports it, of course). I know that this is not simple for the developer, but it should be simple for the end-user.

With cathedral approaches, it is complicated for the end-user, because he is the one having to worry about what he has to install to get the add-on work like it should. He is also the one to be hit by potential mistakes of the developer regarding version incompatibility, e.g. some feature suddenly ceases to work in the new version for vessel A, but you can't go back, because vessel B needs the new version to even work. I'm more a fan of "easy for the end-user, hard for the developer" instead of "easy for the developer, hard for the end-user".

Side-by-side approaches deal with that, because every addon could - in theory - bring along its very own version of the runtime. Whether or not this worst case will eventually happen in practice is not relevant, nevertheless the system should be able to handle it. Chances are quite high that the amount of parallel versions will be lower than 10, given a proper compatibility strategy.

 

[Artlav]

Side-by-side approaches deal with that

Please define "Side-by-side approaches".
So far i haven't heard any specifics of a solution other than a dozen dlls and cfg files, one per version.

For it to be easy for the user, there should be one modules/genericvessel.dll and one config/spacecraft/genericvessel.cfg, neither of which is afraid of being overwritten.

Versioning...
A version tag in the ini file.
modules/genericvessel.dll is a dumb wrapper, that looks for this tag, interprets it, and passes on to another dll.
If there is no tag - load SC3 version/latest version.

The actual dlls are version-named, and stored in a separate directory (for convenience). Developers distribute add-ons with whatever version dll they want, as well as never-changing wrappers.

Should work.
Also, makes a perfect dll hell, Microsoft-style.

 

[Ripley]

If GV used a distribution system like Orbiter Beta (TortoiseSVN for example) everyone would always have the latest version. This would be great!

Face is probably suggesting something like this, but I admit I have some problems understanding his posts 100%.
He obviously knows versioning systems in and out, and this deep knowledge "makes" him naturally use a high-level technical language, sometimes a bit too high for me...

:tiphat:

 

[Face]

Please define "Side-by-side approaches".
So far i haven't heard any specifics of a solution other than a dozen dlls and cfg files, one per version.

For it to be easy for the user, there should be one modules/genericvessel.dll and one config/spacecraft/genericvessel.cfg, neither of which is afraid of being overwritten.

Versioning...
A version tag in the ini file.
modules/genericvessel.dll is a dumb wrapper, that looks for this tag, interprets it, and passes on to another dll.
If there is no tag - load SC3 version/latest version.

The actual dlls are version-named, and stored in a separate directory (for convenience). Developers distribute add-ons with whatever version dll they want, as well as never-changing wrappers.

Should work.

This is exactly what I had in mind with side-by-side. That's why I'm not boring you with complicated explanations: you always understand the technical terms, anyway.

Also, makes a perfect dll hell, Microsoft-style.

And here we disagree. It is actually the approach Microsoft took to deal with DLL hell, and IMHO it works well, whereas the cathedral approach did not work for them, although they where in the perfect position to enforce it.

Anyway, I'm going to implement this feature in my version. Since the two approaches don't really exclude each other, genericvessel users can always choose if they want to include the runtime in their addon distribution for a turn-key end-user experience, or instead want the end-user to deal with it on his own. No loss either way.

If GV used a distribution system like Orbiter Beta (TortoiseSVN for example) everyone would always have the latest version. This would be great!

Actually that would be the cathedral approach I was talking about, as in "go to the cathedral and pray for an update". This works for Orbiter because nobody is working on it besides Martin alone. This works also for e.g. DanSteph, because he does not open up the source to OS/UMmu/UCGO, and so naturally can dictate what and when something goes out and is considered "latest".

That's all fine and dandy, until a bus hits one of the cathedral masters (which hopefully never, ever happens in the case of Martin, DanSteph or Artlav!). Or until one of them decides that his time is better spent on other things in life.

Then you are suddenly again locked-in to a system nobody can extend/update anymore.

Now fortunately things don't look that bleak in this case, mind you! Having genericvessel GPL'ed almost guarantees that people at least don't have to rewrite everything from scratch again. Still the distribution decisions we take now will influence the situation/eco-system at that imaginable point in the future where again maintainers have to be switched.

He obviously knows versioning systems in and out, and this deep knowledge "makes" him naturally use a high-level technical language, sometimes a bit too high for me...

I'm sorry for the technical language, but I deal with similar issues at work every freakin' day, so naturally I speak up if decisions are made - especially on forks of a project I started - that IMHO take the wrong turn. Most of that language was addressed to Artlav, because I assume that he understands it, based on the level of insight he presented in the past. And as you can see from his answer, the assumption was not too far away from the reality.

 

[Donamy]

Yep...

AFAIK there are no limits like that in GV.
Does it not work somehow?

GV seems to allow joints 0-9, joints 10,11 are ignored.

 

[Artlav]

Version 140205 is out:
http://spaceway.1gb.ru/files/genericvessel-140205.zip (269Kb)

Changes:
-Fixed animations firing while working arm
-Fixed arm joints limit

---------- Post added at 21:35 ---------- Previous post was at 21:29 ----------

And here we disagree. It is actually the approach Microsoft took to deal with DLL hell, and IMHO it works well

Well, WinSXS is still the largest thing in the Windows directory, which ticks me off.

Anyway, I'm going to implement this feature in my version.

Ok. A pity you don't use Git.

How exactly are you going to do it?
Offloading the vessel already loaded by Orbiter to a class in another DLL might be tricky, now that i think about it.

Xves and genericvessel dlls can be updated independent of each other (or be missing at all).

Authors might not put the right version or any version at all.

A fork might alter the whole appearance of both DLLs, yet should still be compatible with the core.

Etc.

 

[Donamy]

Arm joint limit fixed.

When joint animation is running, pressing spacebar to get out of robotics mode, stops tip from moving. Pressing spacebar again, the tip snaps to position.

 

[C3PO]

Versioning...
A version tag in the ini file.
modules/genericvessel.dll is a dumb wrapper, that looks for this tag, interprets it, and passes on to another dll.
If there is no tag - load SC3 version/latest version.

The actual dlls are version-named, and stored in a separate directory (for convenience). Developers distribute add-ons with whatever version dll they want, as well as never-changing wrappers.

Should work.
Also, makes a perfect dll hell, Microsoft-style.

Couldn't the wrapper just warn the user if the GV version is older than the version specified in the ini file? (Or if it's missing)

IMHO it isn't too much to ask of a user to install GV the first time he uses a SC3/GV vessel. If an addon developer includes the GV dll that overwrites a newer version (a method I personally dislike), the user gets a warning next time a newer ini file is loaded.

Trying to 'protect' against ignorant users is difficult. 'Protecting' against ignorant addon devs is hopeless.

 

[Artlav]

When joint animation is running, pressing spacebar to get out of robotics mode, stops tip from moving. Pressing spacebar again, the tip snaps to position

Tweak it.
Tweak it some more.
And more.
And more.
And more.

 

[Donamy]

What do you mean, "tweak it" ?

 

[4throck]

Did a quick test of GV to see if it was good enough to start using it for development. Found two important issues:

- exhaust texture definitions are ignored (always displays default);
- attachment info on screen is confusing and doesn't update (reads something like Attachment:hatch:hatch regardless of being empty or not);
- attachment points are not shown on screen;

---------------------------------------------

As for the rest, let me point out that the version system is in contradiction with the goals of Generic Vessel. Otherwise GV would be sc4 and never replace sc3... So back to square one with every new Orbiter version.


Until I see what way this project is headed I'll suspend further testing.



It's not amusing to be bullied by people that confuse mere suggestions with facts and being right or wrong. I've seen this attitude appear on this thread and elsewhere on the forum.
Don't know what's the point of attacking an active addon developer, even if with a nice words like fallacies (even ancient greek was used on other occasions).

And all that on the grounds of knowing some "superior" programming language, having some professional experience, etc, etc, when in fact it demonstrates lack of knowledge of enthusiast hobby development...

The stress is always on not following the "proper" way to do things and never in finding out solutions that work at our amateur level. Again, it seems that some are professional Orbiters and others are mere amateurs.


I'm not in school or at work to be evaluated, and I care very little for totalitarianism, God complex and control freakiness.

 

[Face]

Ok. A pity you don't use Git.

Why is that?

How exactly are you going to do it?
Offloading the vessel already loaded by Orbiter to a class in another DLL might be tricky, now that i think about it.

It is tricky, but doable. This is best explained in source code, though, so stay tuned.

 

[Donamy]

I'm very excited about this. What difference does it make what it's called, as long as it works and is improved on. I see all 'win' here.