Yes, there have always been much parallel programming going on, as well as parallel sites for almost the same thing, sites which load data from SWGCraft and just re-package it, and so forth. Is that bad thing?Monty Burns wrote:However if there is one thing I would like to see in all of the 3rd Party Utilities being produced and discussed on this site is some level of interoperability as it seems that we have 4-5 people doing some nice work but all acting independently of each other.
Parallel work and similar applications is not in itself a bad thing, users do not always think or use applications the same way or for the same purpose, and some are more familiar with one kind of applications than the another.
The only and the one thing I really would hate is yet another SWGCraft wannabe!!!
However, I very much dislike sites which lure people away from here.
The reason for my emotions is really, really simple:
There are not enough players who submit resource data to always keep the galaxies up-to-date. Too many players are lazy and greedy and they do not submit any resource data whatsoever! The result is that the momentum of submitters is not very strong. With several competing resource data sites the only possible result will be that none of the sites is even remotely close to decent, and the causal user will not know where to go. A casual user will not not even look like the donkey between the hay stacks because there would be no stacks but just some scattered straws.
IMHO any other crafting web site would just draw attention away from SWGCraft. Such a site would greedily suck resource data from here but not give anything back, nothing whatsoever. Yes, sites must have some link to SWGCraft, but realistically, how many users do follow that tiny link and really begin to submit some resource data to this site every now and then? What do you think? Not many if any, so any other crafting site effectively shadows this site, gravitates possible submitters away from this site and makes new-comers ignorant of this site's existence.
I am sure that none of the developers of such sites cunningly want to defeat and strangle SWGCraft. Probably they have the very best intention and just want to help fellow crafters. However, in the end of the day any such site bites the hand that feeds them.
Hence, rather than launching yet another web site, plan and develop something that can be run at SWGCraft's server. I am sure that Slyvampy and Sobuno do not mind being handed a chunk of code* to scrutinize and incorporate. They have advertised for other developers in the past, why not respond to that request and help making this site even the better? I know first-hand that nobody has yet provided any of them any code for review*.
In general there are two kinds of applications:
Spreadsheet based that run inside Excel but hardly at any free competitor.
Standalone applications, such as SWGAide which does not require Excel or such.
Three years ago when I begun with what grew into SWGAide, the only reason I did not go the Excel-route was that I sincerely wanted something that could interact with SWGCraft. I wanted something that could upload resource data to SWGCraft, both single resources and from ISDroid reports. At that time and yet today I consider web forms way too awkward and cumbersome, hence in themselves a limiting factor which I think causes so few players to submit resource data. I really did want to help people to help SWGCraft, and I still do.
Excel cannot easily interact with SWGCraft but it downloads stuff. Thence, Excel will not be of much help for SWGCraft, it will not suggest and help players to actually return something to SWGCraft as a contribution for the data they download. IMHO this is the big drawback with any Excel spreadsheet and the only reason I decided to go another path. Hopefully players realize the connection anyway and manually submit data.
On the other hand, developing SWGAide from ground up takes the longer time. The first seed was planted by a number of players and myself in early September 2005. It dropped stone dead with NGE when kind of all crafting just died off for quite some time. However, even if SWGAide was version 2.5 there would still be people who felt more comfortable with another kind of application. I realize and understand that, and I really have no feelings about that fact. Such is life, people choose this over that because of color, design, old habits, and whatever reason.
It is not an easy thing to have applications even from the same vendor to share data internally. Microsoft struggled that path for years and it took them ages to get Office to its current shape, literally bazillions of man-years. What we can do is to add import/export features but everything will still be based on "save a file in application X and load that file in application Y"; it will never be any better than that.
Both SWGAide and Excel is built in such a way that it is easy to plug in another tabbed panel or sheet. Once programming of the the new panel/sheet is done, in Excel it is effortlessly added, in SWGAide it takes a day at most.
However, anybody can gather and compile any kind of useful in-game data, such as the file resourcetree.XML which contains static data about all resource classes. If in-game data was compiled in a way which is easily read and parsed by a computer it is a breeze for the developers here at SWGCraft to quickly add it to the database, and it can be loaded into any kind of application, SWGAide, Excel, or whatever. But also data at any form is better than no data at all.
What do I want to say with this? Is this a gripe? No, it is not. I just want to convey a few things:
- do not to compete with SWGCraft about visitors, that will only decrease the number of resource submitters
- implement import/export features which can share files between applications, and document how it is done
- any player can help; provide missing in-game data in any kind, form or fashion
Opinions here are purely my own and are not part of this site's generous policies.
* Footnote: Code is written in several fashion but here I rather mean "pseudo code". To be able to produce ready-to-run code a developer must know a lot of details whereof some may be very internal or secret. Pesudo code rather describes in detail how the logic for a feature or some functionality wotks; it is then rapidly transformed to real code by a developer who has access to the details.