ProjectGenericVessel 140205, the SC3 open-source replacement

Face

Beta Tester
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)

It could, but that wouldn't actually solve the problem of having the "newer" version overwritten in first place. So the installation of a newly released addon that includes an "older" runtime would spoil the experience for previously installed addons that might use a "newer" runtime.

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.

Sure it isn't too much to ask, the problem here is just: what version should he install, and from where? Also: what is the metric used to define "older" and "newer"? Keep in mind that people might develop the system independent from each other. There is no single place that can be considered canonical. And even if there where, what prohibits an addon-dev to say: "hey, I just want that a little bit different here, without having to rewrite all that nifty features of the system in a custom DLL just to add my little code line", and going off to recompile it, and place it into the addon distribution?

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

You see, in this case I oppose the term "ignorant" for users or addon devs, because the license allows them to change the code and distribute the software under the terms of the GPL. Imagine the following use case:
1. An addon-dev decides that he wants to create an addon with a small little HUD display, something (for the sake of this argument) the currently "latest" version of the "official" genericvessel doesn't support.
2. He knows a bit of C++, but doesn't want to reinvent the wheel for all the other features genericvessel already offers.
3. So he sees the source code, reads the license, and understands that since it is GPL, he can modify and redistribute it accordingly.
4. Now he has a problem: where does he upload the new patch/version to? Will it be accepted there? How fast is it going to be in the new "latest" version on the central location?
5. For some reason, his patch is rejected from the "official" genericvessel project. What now? Frustrated, the addon-dev decides to distribute his addon (a cool work that certainly will have many fans) with the modified runtime.
6. In the meantime, a new "latest", "official" version comes out, many new features of it are used by the many new addons from OHM.
7. Some user has all those new addons, and also decides to install that shiny new work of our addon-dev.
8. Unfortunately, this end-user will also be frustrated, because he can't use the new addons (fully) while the addon-dev's runtime is installed. If he overwrites it again with the "latest" one, the addon-dev's work is not fully working anymore.

A solution to this is to tell the addon-dev to simply distribute his runtime as custom DLL, e.g. mygenericvessel.dll instead of genericvessel.dll. But this is just a side-by-side solution, then. Why not provide a system that supports this right from start?

Artlav

Aperiodic traveller
Beta Tester
- exhaust texture definitions are ignored (always displays default);
At the moment it's a known non-functional feature (along with particle streams and sound), as stated in the first post.

- attachment info on screen is confusing and doesn't update (reads something like Attachment:hatch:hatch regardless of being empty or not);
Being worked on, if you mean attachment control interface.

- attachment points are not shown on screen;
What should this look like?

As for the rest, let me point out that the version system is in contradiction with the goals of Generic Vessel.
...
No need to complicate what's simple!
What exactly are the problems here, besides what you stated earlier?

I am all for "One GenericVessel version to rule them all" approach, but that does seem to have some glaring theoretical problems associated with it.

Could you state your opinion on the problems outlined by Face?

What do you mean, "tweak it" ?
A failed joke about how the fixes seem to be asymptotic...

Why is that?
I use git all the time everywhere, and is well set for it.
Mercurial ends up being a third wheel that i have to wedge in.
Not a huge deal, just uncomfortable.

Face

Beta Tester
I use git all the time everywhere, and is well set for it.
Mercurial ends up being a third wheel that i have to wedge in.
Not a huge deal, just uncomfortable.

Ah, that's not really a problem, I can use hg-git to access git repos without too much hassle. Do you have your project on github, by any chance? That would certainly spare me the work of manually committing your patches into my hg repo.

C3PO

Donator
I'm sorry I misunderstood the scope of this project. I assumed that in genericvessel.dll at least the dll would be generic. I guess I'm too used to SC3 and believed that there would be a place like orbithangar where I can get the "latest" version.
My thought was to add a GV[version#].cfg so it wouldn't be overwritten by an older version. Then the wrapper would warn the user that he needs to pop by orbithangar for the latest official version.

'Ignorant' was meant literally and not derogatory. If the developer doesn't know he shouldn't overwrite the 'official' dll, I'm betting he doesn't adhere to a version structure. Although I'm totally C++ illiterate I'm guessing it wouldn't be difficult to change the name (class?) of the dll that gets called by the scn file.

Face

Beta Tester
I'm sorry I misunderstood the scope of this project. I assumed that in genericvessel.dll at least the dll would be generic. I guess I'm too used to SC3 and believed that there would be a place like orbithangar where I can get the "latest" version.
My thought was to add a GV[version#].cfg so it wouldn't be overwritten by an older version. Then the wrapper would warn the user that he needs to pop by orbithangar for the latest official version.

I don't think you have to be sorry here, you understood the scope quite right IMHO. The genericvessel.dll should still be generic in the sense of generating a vessel on a decription INI file. There will still be a release on OHM where you normally go to.

This whole version chitchat is about how to ensure that the add-on devs AND the end-user don't have to care about version suffixes at all. No warning, no crashes, just working addons. So as add-on dev, you follow a simple rule-set:
1. Download a genericvessel version from wherever you want. Preferred location: e.g. Artlav's OHM releases. Modify the source if you want, create your own version of the genericvessel-binaries if you want, but preferred action is: just use what you've got with the release.
3. Author the releases' (or your own) version tag (hash, text, number, whatever it is in the end) into the addon INI(s) or configs.
4. Put all necessary files into a ZIP, and include the /Modules/genericvessel.dll as well as e.g. /Modules/genericvessel/<versiontag>/*.dll .
5. Distribute it.

The terms "preferred location" and "preferred action" here is not to make it work, but simply to minimize parallel versions. The system works by design, not by convention, so to say. To minimize work for addon-devs, we could also offer tools that do the whole packaging automatically, e.g. by extending a given ZIP-archive with appropriate runtime-files and perhaps even checking for proper version tags in the INIs.

The end-user will simply download the addon, unzip it, and play. No fiddling with extra downloads, no search for the proper location, no version troubles. It would also be possible to offer "expert" tools to inspect the SxS cache and perhaps shrink it based on compatibility information, but that is just convenience upon the basic system.

All the while the developers working on genericvessel itself don't have to wrap their heads too much around version troubles that might ensue. Sure it won't totally free them of this chores (compatibility should still be sane, the underlying SxS system must remain unchanged), but at least the essential feature sets are more or less free to tinker with.

'Ignorant' was meant literally and not derogatory. If the developer doesn't know he shouldn't overwrite the 'official' dll, I'm betting he doesn't adhere to a version structure. Although I'm totally C++ illiterate I'm guessing it wouldn't be difficult to change the name (class?) of the dll that gets called by the scn file.

Of course, if everybody in the chain "behaves" in terms of keeping the discipline up to make the version system work, everything is fine. But why push that burden downstream, if we can fix it up here in the runtime already?

So to summarize: my whole point is to free addon-devs and end-users from dealing with runtime-versions at all.

Artlav

Aperiodic traveller
Beta Tester
I've been thinking about it, and it seems that the proposed solution to the versioning problem is being severely over-engineered.

Sure, it's GPL, so anyone can make whatever with it.
But, let's look at other GPL and open-source add-ons.
Which of them have "i like to add this-and that tiny feature" forks?
I don't really know any off the top of my head.

What is the point of SC3, and by extension, GV?
To provide a common, easy, repeatable framework for making add-ons for non-programming-savy people.

Developers don't have to worry about distribution and compatibility issues - they just make add-ons.
Users should not have to worry about a hundred GV versions from each add-on, then just download GV (Like OrbiterSound, UMMU, D3D9Client - lots of precedents), and all the GV add-ons simply work.

By it's intention, by it's design it should be one thing, not a mess of versions and flavours.

If someone want to add a special little feature to the code, then he knows C++, so he can use the converter option - convert the INI definition into C++ code, and compile and distribute that, instead of GV vessel. Remember the origins of GV - it can turn INI straight into a DLL.

If someone want to make a fork with something new and good, then it's their problem to make the thing interesting and useful. That never happened before in this community, AFAIK.
I.e. if a fork is on a scale of D3D9Client forking into D3D11Client, then it's a whole new thing, that people would want to use separately.

If i get a one-way ticket to the Moon one day, then the code is still there and is open, so anyone can embrace the project and keep it alive.

It seems to me that making GV into a full blown and elegant SxS is a lot of mess and trouble to cover some possible cases with probability less than 1%.

Face

Beta Tester
Developers don't have to worry about distribution and compatibility issues - they just make add-ons.
Users should not have to worry about a hundred GV versions from each add-on, then just download GV (Like OrbiterSound, UMMU, D3D9Client - lots of precedents), and all the GV add-ons simply work.

By it's intention, by it's design it should be one thing, not a mess of versions and flavours.

I've already addressed the cathedral approach before, so I will not repeat it. Let's just say I disagree with the notion that add-ons will simply work with it, and that I think precisely this approach will lead to a mess of versions and flavours.

I see that we have so many differences in the vision of the project that it is pointless to try to combine them even in the slightest way (just as you already wrote in the opening post). Nevertheless, I am thankful for your contribution of the code, and I wish you good luck with this fork.

Donamy

Donator
Beta Tester
If GV turns out to replace SC3 and surpass it, all the better. IMHO

C3PO

Donator
So to summarize: my whole point is to free addon-devs and end-users from dealing with runtime-versions at all.

I get your point. I'm just worried it could lead to trouble down the line. I just don't like the method where you include the current dll with the addon. I've seen it go wrong too many times with vessels using Vinka's dlls.

B: Someone discovers a bug in an older version. How do you fix that? You can't be sure all the devs that used that version will update their addons.

C: Compability. Who's going to check that a GV version works alongside other versions (generic or "home made") in the same scenario? Orbiter has 4 "current" versions in circulation right now. In-line client; D3D9; D3D11; Orbiter Beta. A bunch of different GV versions are not going to make life easier.

You can't prevent people distributing the dll, but you can make it easy to fix. The wrapper checks if:
GV dll is present.
GV dll is older than the Version parameter in the ini file.
GV dll older than the GV[version].cfg.
If any of those tests fail, the user gets a pop-up telling him to go fetch the latest GV dll. The addon should only contain the genericvessel wrapper.

One way to help devs make the addon compatible is to make a SDK.zip with all the required folders with the wrapper and GV[version].cfg in the correct place. The dev extracts the zip, adds the ini; msh; textures; sounds in the appropriate folders, and zips it up again. You can put a deleteme.txt in all the "empty" folders to make sure they are extracted.

Artlav

Aperiodic traveller
Beta Tester
I see that we have so many differences in the vision of the project that it is pointless to try to combine them even in the slightest way (just as you already wrote in the opening post).
Which makes it a perfect test case for the versioning system you proposed.

The approaches are not so mutually exclusive - if you get your system working, then mine becomes one of the said forks/versions within it.

And we get a double win.

Face

Beta Tester
I get your point. I'm just worried it could lead to trouble down the line. I just don't like the method where you include the current dll with the addon. I've seen it go wrong too many times with vessels using Vinka's dlls.

Yeah. That's the case because of previous systems never taking the SxS approach, but always the cathedral one.

B: Someone discovers a bug in an older version. How do you fix that? You can't be sure all the devs that used that version will update their addons.

C: Compability. Who's going to check that a GV version works alongside other versions (generic or "home made") in the same scenario? Orbiter has 4 "current" versions in circulation right now. In-line client; D3D9; D3D11; Orbiter Beta. A bunch of different GV versions are not going to make life easier.

All these scenarios are problems in the cathedral approach, not in the SxS. That's why I've suggested it first place. There is no "bunch of different GV versions", there will just be a bunch of addons using their appropriate GV version the way they were developed to.

You can't prevent people distributing the dll, but you can make it easy to fix. The wrapper checks if:
GV dll is present.
GV dll is older than the Version parameter in the ini file.
GV dll older than the GV[version].cfg.
If any of those tests fail, the user gets a pop-up telling him to go fetch the latest GV dll. The addon should only contain the genericvessel wrapper.

"Older", "latest", "go fetch". These are the problems here. What is "older"? What is the metric of versions in a GPL project? What is the "latest" one? Where go to fetch them? As long as these question are not answered unambiguously, you will have troubles.

One way to help devs make the addon compatible is to make a SDK.zip with all the required folders with the wrapper and GV[version].cfg in the correct place. The dev extracts the zip, adds the ini; msh; textures; sounds in the appropriate folders, and zips it up again. You can put a deleteme.txt in all the "empty" folders to make sure they are extracted.

The point is: you don't have to make it compatible. It simply uses genericvessel in version XYZ. Period.

But I've already realized that perhaps all this might be clear to me, but difficult to sell by words alone to the audience here. It is a change of paradigmas, after all.

Especially seeing how people get upset simply because I point out mistakes in their suggestions-presented-as-facts and resorting to all kinds of indirect personal attacks instead of using arguments to show their points, I get the feeling that it is pointless to pursuit this further without an example to demonstrate the behavior.

---------- Post added at 00:20 ---------- Previous post was at 00:15 ----------

Which makes it a perfect test case for the versioning system you proposed.

The approaches are not so mutually exclusive - if you get your system working, then mine becomes one of the said forks/versions within it.

And we get a double win.

It is a test case for sure, but only for the self-healing aspect of it. Far from "perfect". But you are right, it will be a double win. And if it works out, adapting it shouldn't be too complicated.

Last edited:

C3PO

Donator
Hmmm...... I got the feeling I'm missing something.

As you were.

Donamy

Donator
Beta Tester
Related to my last post.

When you launch a scenario that has the Arm animation already running. The tip isn't moving. When you press spacebar, it snaps into position.

Artlav

Aperiodic traveller
Beta Tester
When you launch a scenario that has the Arm animation already running. The tip isn't moving. When you press spacebar, it snaps into position.
You do realize that the whole "it keeps running if i let go of shift first" thing is exploiting a bug in SC3, that i have to recreate in a bug-free environment verbatim, just like WINE have to recreate every single Windows bug to make the programs that exploit them run properly, instead of declaring them broken due to their authors ignoring one of the main rules of programming - never to exploit bugs?

Just checking.

jedidia

shoemaker without legs
one of the main rules of programming - never to exploit bugs?

I never heard of anyone sticking to that rule... :shifty:

Last edited:

Donamy

Donator
Beta Tester
You do realize that the whole "it keeps running if i let go of shift first" thing is exploiting a bug in SC3, that i have to recreate in a bug-free environment verbatim, just like WINE have to recreate every single Windows bug to make the programs that exploit them run properly, instead of declaring them broken due to their authors ignoring one of the main rules of programming - never to exploit bugs?

Just checking.

I did not realize, that it was a bug, because it is a great feature !!:thumbup:

---------- Post added at 02:38 AM ---------- Previous post was at 02:30 AM ----------

Is there a way to program it, so that it is a feature and not a bug ? I wouldn't mind redoing the .ini in that case.

Artlav

Aperiodic traveller
Beta Tester
I never heard of anyone sticking to that rule... :shifty:
Well, the difference between ideal and real is small ideally, but really is large.

Is there a way to program it, so that it is a feature and not a bug ? I wouldn't mind redoing the .ini in that case.
It's an artefact from handling the keys in a non-consistent manner, nothing in INI is relevant to it.

The key release event in DLL was handled inside the check for shift being pressed.
Thus, when you release shift first, it never gets to the key release handler when you release the key.

Normally, there shouldn't be enough keys to save at the same time as something is moving on an arm, but thanks to that bug it is now possible.

What happens when you save with moving arm is a direct result of whatever the way saving is handled in SC3.
Essentially, it's an interference pattern between a bug and the rest of the code.

I have to simulate that behaviour somehow - either detect the animation being run on start, or make the tip move with the animation all the time, or stop the arm-related animations on load, or something else.

Since my code is quite likely different from SC3, i can't just make the same error and get the same bug behaviour pattern, so i had to code it directly, as a feature.

Which is a large set of tiny, undocumented micro-features.
So, the problems appear to never quite end, even though i keep fixing them.
That's the sort of thing that happen when you try to turn a bug into a feature.

Donamy

Donator
Beta Tester
So I assume, more moving attachments isn't going to happen. j/k

I appreciate the effort.

Artlav

Aperiodic traveller
Beta Tester
"launch a scenario that has the Arm animation already running" is very much a bug.
There should be no way to save a scenario with arm moving, but to ensure this i need to fix the "it keeps running if i let go of shift first" bug, which is kind of a feature now.

So, it will be fixed one way or another.
Are there any other tip movement/arm bugs?

Donamy

Donator
Beta Tester
This what the scenario has for the moving tip at launch.

Code:
jasonpad:Spacecraft\Spacecraft3
STATUS Landed Earth
POS -80.5280120 28.4586630
AFCMODE 7
NAVFREQ 0 0
RCS 1
CTRL_SURFACE 1
CONFIGURATION 1
END