Ok all: no hard feelings here.
Please just allow me to expand a bit more and write some extra notes about the topic of external addon requisites and also
about why I wrote the first post.
External addon requisites are kind of something that some of us have inevitably to face unless:
- having the required time and / or skills to implement all what we would wish to in a specific addon release
- or unless focusing a given addon in a very specific topic vs free time
- or unless including and even integrating other people's work - with proper permission, from original docs or contact -
inside the addons, etc
(if I'm not incorrect, even some of the well known francophone addons do have or at least had requisites of one kind or another).
In this (AresI SC) and other cases, but focusing mostly in what relates with some of my work, giving that francisdrake has
already several very nice CEV implementations ready to fly, it is a lot easier for me to just make francisdrake's CEV-Orion
addon to be an external addon requisite than to wait extra time and spend extra effort to implement my own CEV or LSAM or
other spacecraft (for which, by the way, made several alternative designs that keep in the 3D archives / Orbiter development
folders but which are still a long way to go before some of those designs have a chance to become minimally operational - for
some release goals - inside Orbiter).
As a side note, this concern about external addon requisites is also why have personally decided (many, many *months* ago) to
start making my own launch pads, spacecraft, EVA suits, launchers, stations, etc – as can be seen in several of my flickr
space or LivePics previews.
This way, one day - but unfortunately(?) for some(?), in a not so immediate future - when much later versions of the older
NASA VSE SC addon (and other simcosmos' addons) are released at Orbit Hangar Mods, I will still probably continue to make
integrations with external addons but those integrations will then all become something really *optional* to my core
package(s) (as long as Vinka is kind enough to continue supporting the cool generic dlls and / or I start coding c++).
Meanwhile it is a lot easier for me to share
clearly identified as
*development* versions of such always
ongoing work... That is also why decided to start including the
dev designation or else calling
version zero dot
something - like in NASA DIRECT SDLV
v0.1 - in some of my most recent works) and then... Then just point users to
extra download requisites.
However, if all addon makers start doing like this - creating all their dreams stuff at their own rhythm, the way they wish
and / or can do in a given timeframe and, among several other reasons, with one of the goals being to avoid to make external
addons requisites
of any kind - then we will eventually all end up with several implementations of similar designs
(which isn't necessarily bad, unless for some eventual 'duplication' of work...) and those addons will take even longer to
appear...
Please note that I'm not minimally concerned at all about taking too long to release any addon: I really do these
implementations, within my knowledge and free time constraints, mostly for my self-pleasure and / or for the 3D models to be
used in 'applications' other than Orbiter. Have lots of things more or less working here but that aren't public, at least not
in well known addon repositories, because of documentation, files not yet being quite operational yet by their own, etc (just
to give a few of the traditional examples).
I mean, the current options are:
- to either fully wait until something is more completed – for given release goals - and to not have any extra requisite (not
something that all of us can accomplish, due to several reasons / goals)
- to release something that can be considered 'operational' - again, for given release goals - but that still might require
(or not) external requisites for specific scenarios / occasions
- to release some kind of 'development versions' and clearly note such nature / requisites
- to not share anything at all (because there might not exist such thing as perfect public releases)
---------------------------
Final Thoughts
---------------------------
Other than that – and this is what I'm trying to express from the start – all orbinauts (myself included!) could please try
to look first at the nature of what they are downloading (by looking at addon descriptions and, at very least, to
introduction / installation notes), that is all what I'm saying...
If really wanting to avoid CTDs - assuming the addon was well packaged - the best strategy is to at least do read such
documentation notes and, if not wanting to spend some time learning what the documentation contains and searching for
eventual addon requisites, simply do not continue any further and do not install the files! (by the way... zip. files
contents - such as the documentation - can be viewed without having to really extract / install any file from the zip package!).
If then deciding to install something, and then having problems, sure, of course that everybody is free to ask for help
wherever and to whom he / she wishes but, in my very humble opinion, I think that a very, very good option – which does not
need to be exclusive to asking others for help - would be to try to contact / alert the author of the addon in question (whom
might just probably be one of the best options to provide a quicker help to solve a 'problem' related with his own addon...)
and / or another very good option is to at least have a look at the provided documents and eventual related links.
Fellow orbinauts, my first post here was more caused by the indirect comments that if something does not apparently seems to
work then the immediate step should be to just and simply trash that work into the garbage container (almost without any kind
of consideration for such work!) and also caused by the suggestion that the files in question and related work might not have
been properly released...
That is why I continue to ask everybody to please take just a few seconds of your time to first look at the *nature* of the
files that are downloaded (is it a development zip?, is it a patch?, is it a full stable release?, does it have requisites?,
etc) and then to try to at least have a quick look at provided documentation and also to try to contact the author in case of
difficulties else...
... I mean: why should I - or anybody - bother about doing things such as:
- to package the files in their own custom sub-folder structure and / or use naming conventions,
- to write a list of the zip contents,
- to test the files in a clean Orbiter install (+requisites)
- to provide a specific addon designation,
- to write a description and provide a screenshot in the download entry,
- to have some care when doing the pdf layout and documentation contents,
- to write scenarios descriptions, etc
- to provide contact info
And to do all that in the first place, if people do not pay attention to any of it!?
Excusez moi (une fois plus) pour le long texte et pour écrire en anglais ici.
Encore, aucune mauvais sentiment ici, d'aucune sorte, j'exprime seulement mon point de vue.
Ok, temps de passer à autres choses
Merci et bon fin de semaine,
António
Search
Login
Register