The Oolite Extended Project - Fork, no oxp

[Lestradae]

@Screet:

Can you compare the six or so java scripts that pmw57 published recently against those that were running so stable on your system?

Because apart from them, everything is as in your latest update of the Scripts folder you gave me.

@Commander McLane:

I think you are preaching to the converted here with your usually helpful explanations anyways, perhaps it might make sense to tone down the accusatory undertone ("how could you not know etc.") ... ?

Your input is very valuable, but it can be easy to overlook things and loose oneself amongst the mass of Oolite-specific data, for script noobs like myself and doing-this-as-a-job pros like pmw57 or Screet, either.

No use to get angry because it's complicated if you haven't scripted for Oolite for forever and a day, methinks

(By all means, don't let that stop you from commenting in the future I'm sure your infos have already been helpful, and still think your first explanation of the distinction between ship- and worldscripts belongs onto the wiki)

Cheers everyone

L

[pmw57]

Work is now beginning on updating the timer-based worldscripts for OSE.
updating OSE worldscript timer scripts

As there are many scripts in widely varying states of repair, jslint.com is going to be used to ensure that obvious issues are found and fixed. Even though such corrections are individually minor, they build together to ensure that the code is easy readable, and more importantly allows for wider-ranging updates to more easily be performed.

I'll be making such updates to some of the scripts as a suggestion for their authors. They're welcome to take advantage of the updates, or leave things as they stand.
The first of these updates is in Updating the OSE deep space pirates script

That's all from me until tomorrow night though, so have fun.

[Lestradae]

@pmw57, Screet & matthewfarmery, also Kaks, Thargoid, Eric ... and whoever is interested basically!

The debates about the scripts have given me some heavy food for thought, perhaps we can discuss these here. Please bear with me.

We (the "OSE team" ~ Screet, pmw57, matthewfarmery & myself) started out with the idea to check and perhaps alter the original java scripts merged into OSE. That for the following reasons:

a) To prevent timer-related crashes

b) Some of them had already started to migrate away from their originals ("ancestors"?), like the deep space pirates script and the scripts merged together into the Combat Computers

c) pmw57 has suggested "cleaning up" the java scripts according to industry standards and has started doing that - so has Screet

Now this creates some problems that have to be adressed methinks or problems will ensue - I think I can already see the beginnings of that: Never before have so many people worked on oxp scripts independently from each other. Now there's the original version, sometimes (rarely) my OSE version, then there's Screet's version and pmw57's versions!

A way has to be found to synchronise these efforts or:

a) I will not be able to update java scripts from their original oxps any more if they diverge too far

b) There will be an OSE version and an original version of scripts. That's beside the point. I want OSE to unite many oxps into a bundle for those who want that, I do not want to completely replace them!

c) The problems we are intending to solve in the OSE scripts are - where there actually are problems, and not "a winning team is changed", as T suggested - also problems of the original oxps. It might be a better strategy for all of us to involve the original oxp makers into evolving the scripts further instead of four parallel evolutions where every work is done triple or quadruple times. That's inefficient and it causes unnescessary frictions between people.

So these are my thoughts. My first conclusions from them so far are these:

I don't want the scripts in OSE to drift away so far from the original oxps. Reasons are said above. I want, for the scripts that have not been strongly altered so far (deep space pirates and the combat computer ones), a sort of discussion process that involves

a) the original oxp makers, as the problems we want to solve are also their problems (and the winning teams can be left as they are for future compatibility)

b) pmw57 & Screet (for you are delivering invaluable work to develop these oxps further)

c) myself (because I don't want to OSE-ify the OSE scripts if I think about it. As already mentioned above, I want OSE to be a bundle and not a replacement!

I am leaning on the side to only implement changes to OSE scripts in the future if the original oxp makers can be convinced to make these changes too. The "why" and "what for" should be understandable from what I have said here.

If what I say should be done then it will need something I boldly state is not that evolved on this board (yet) except perhaps amongst the devs and two or three regular collaborators on oxps:

A constructive, critical discussion about how to do something complicated well together even if there are wildly diverging opinions to some aspects concerning the topic.

But I think, this board is capable to do that.

Awaiting your input, gentlemen

L

[matthewfarmery]

I think SVN is the key for this, there are plenty of material to understand how SVN works

http://svnbook.red-bean.com/en/1.5/index.html

there is a good manaul, you can create a trunk, then branches from the code,

http://svnbook.red-bean.com/en/1.5/svn. ... odels.html

the above link discuses locking files and folders, so that one file can be modified by one person at a time, this effectively stops person A uploading a file then person B upload the same file overwriting the file, (but the first file can be recovered as changes are remembered)

maybe if the full project is uploaded to the SVN, L only updates the core files, everyone else deals with the scripts and AI, if locks are introduced, it will stop people fromn stepping on each others toes, if an effective system can be reached, and SVN is used by many so a small project like this shouldn't pose a problem, while I will happy beta test it, as Im not a coder, but still part of the team, so I won't be changing any scripts,

branches can also be created, so that the code can be merged, that is what branches for there for, better then locking files, this means, that a 2 people can work on the same file, but in different branches, once they both have finished, the two files can be merged, this stops changes from being lost, Im new to SVN, so Im learning how to use it, but it will make the project a lot easier to manage, I do think the full project should be uploaded, there is enough space, L once he has a SVN client can still lock files and folders from being edited if he wants, while for the scripts and AI, branches can be made, then merged once the changes that people have made they feel its time to release the next version of OSE, if the original authors wish to come in, then they can either have access to the branches, so see how progress is being made, and maybe have a branche of their own, again the first link I have posted is a manual to using SVN, Im starting to read it, but I think it would help us greatly

while many scripts have moved away from their original code, SVN can track those changes, again people won't be stepping on each others toes if they all use their own brache of that code, then merge afterwards, have to experiment on that, but as I said SVN is used by many successfully so it can be used and works well

[Thargoid]

I've given this also some thought on the flight home (nothing much else to do for 80 minutes) and a few points came from the cogitation.

The main one is we seem to have the tail wagging the dog here. Unless I've been sorely mistaken for all these months, the fundamental idea of OSE was to draw together a number of OXPs (originally ships and such - hence its name - although that now seems to have gone out the window) into one common package.

From this we have the evolution of some elements into wholely new items (for example the OSE-Hired Guns and the Combat Computer) which are fine as they are distinct and separate entities from their originals. But now there is the proposal to start messing around with the individual OXPs themselves (or at least the scripts therein), without changing their functionality and basically to de-facto change the original OXP.

Whilst renaming the scripts will be helpful to know whether a problem is due to the new script or the original (as I see no way to guarantee that the changes will not induce problems either directly or indirectly, even with all the skills and talents in the world), in itself it will induce other problems. For example some of my OXPs interact with one another (Welcome Mat with Planetfall and RingRacer for example, and Planetfall with its add-ons. If things are messed around with then that linkage will be broken and the whole thing will fall apart. And of course if both OSE and Planetfall OXP (for example) are installed with the OSE version renamed, the script will essentially run twice distinctly and that will cause all sorts of chaos.

Also there is at least one example of a partially included OXP in OSE (that being Aquatics, there may well be more). Thus it is quite likely that for full functionality, at least for part of the time both OSE and the original may be installed. And here again there may well be all sorts of weird and wonderful interactions.

So basically I can see two ways out of this. There is either the hard way or the easy way, at least for my OXPs (I will let other authors deal with their own OXPs and interactions).

The hard way - All of the scripts which feature in my OXPs that are currently built into OSE are removed, along with anything which relies on them.

The easy way - "The OSE team" speak with the OXP author directly, and offer to assist with the improvement of the individual OXP(s). Then the original author updates their own scripts etc based on that input as they see fit, and then that version is built into OSE and we can basically continue as before.

By going the easy way everyone wins, but at least in my case I'm rapidly losing patience with all this, and the hard way whilst not preferrable is becoming more of an option.

Basically whilst I am quite happy for my work to be included in OSE, and for anyone else to take it and base something new from it, fundamentally I reserve the right to update, improve and oversee my own damn OXPs. Advice, assistance and input is most welcome, but people walking in and taking over, even with the best will in the world, is not.

[pmw57]

I am leaning on the side to only implement changes to OSE scripts in the future if the original oxp makers can be convinced to make these changes too. The "why" and "what for" should be understandable from what I have said here.

I fully agree with the direction that you want to take here. With the next full release of the Oolite game looming on the horizon, the aim to have all OXPs "ready for production" is too much. I'm too new to the group here, and am very likely to destroy any benefit that it might gain.

What I think is needed most is for me to stop what I have been doing so that we can take time to re-evaluate things. What is needed is for this group to triage the OXP scripts, to provide advice as to where my time would be best spent, so that working together with the original OXP creators we can come together in a grand and unified solution that benefits everyone involved.

So I will for the moment lay down my tools (step away from the vehicle!) so that decisions can be made.

[Thargoid]

Rather than lay aside your tools, I invite you to look at the scripting in my OXPs, and advise me where there are better commands that may be used, and possibly better methods of doing things.

I am not planning to change my coding style (I don't want to be a professional coder, I want code that new people can read, follow, understand and if they want re-use or reference), but I freely admit that I'm also an amateur and can always learn new things.

Then the OXPs can be updated, and as per the normal route of things, the "dog can wag its tail" and the OXP (scripting and all) can be included and everyone wins.

Either that or if you prefer a more solo task, there are plenty of legacy scripted OXPs that would hugely benefit from updating to Javascripting (with their author's permission of course).

[Screet]

Basically whilst I am quite happy for my work to be included in OSE, and for anyone else to take it and base something new from it, fundamentally I reserve the right to update, improve and oversee my own damn OXPs. Advice, assistance and input is most welcome, but people walking in and taking over, even with the best will in the world, is not.

As you write this...I've really got a question for some time now. Maybe you remember that some months ago I was trying to do something pretty much for myself, which included to have RMB Chaff and your AMS work together and automatically (now with Combat Computers as the explanation for the coordination). I'm currently at the point where I *really* like the changes and do wonder how others do feel about it, but I'm afraid how the original authors do see such a thing. I even could remove the RMB Chaff dependency easily, but with AMS the problem is that it's firing automatically, thus it's either to be incompatible to AMS or requiring to work together (in the AMS script or by coordination between the scripts). If you want to have a look at what I've done, I'd happily send you a PM with it. Question is, how do you feel about such an idea?

Aside from that, I'm far from some point I would like to reach: Some way that would give NPCs randomly (or per design) such equipment, as I don't like it if it's for the player only...and there I'm really not yet experienced enough to have an instant idea on how to do that.

Screet

[pmw57]

Rather than lay aside your tools, I invite you to look at the scripting in my OXPs, and advise me where there are better commands that may be used, and possibly better methods of doing things.

Thank you for your offer.

Either that or if you prefer a more solo task, there are plenty of legacy scripted OXPs that would hugely benefit from updating to Javascripting (with their author's permission of course).

This sounds like a more acceptable path to take. I will soon be heading off for about 10 hours or so, and look forward to seeing what advice about this there may be.

[Lestradae]

Basically, the constructive part of this debate gives me the following ideas/thoughts (this is just brainstorming as of yet) about the/my future procedure in creating OSE:

1) There are a few cases where something has been altered in OSE in relation to the original oxps it was merged from. For example ship prices, TLs, alternate ship versions have been/will be added, missile speeds/accuracies have been raised, the deep space pirates, player escorts and hardpirates scripts have been used plus been expanded upon, and the Combat Computers are intended to unite five different singular functionalities.

I think that is (and really should be) OK. These are things that have been altered to either widen existing possibilities or to take into account synergies or the changed environment in which they run. So I am firmly standing behind these changes.

2) In most cases except the abovementioned, OSE has been conceived simply as a bundling of oxps. So that someone who wants to play with as many oxps as possible has them all and also knows that in this bundle, incompatibility issues will have been ironed out already. OSE's scope has widened considerably as T said, but I am not sure how this is supposed to be a bad thing. Players who want more fine-tuning in their game won't play it. Players who want everything in one go will.

But this implies that any stuff for which 1) is not applicable should stay as close to the original oxp as possible imo. Add all the functionality but don't mess with it, could be the guideline. "Don't change a winning team." Also, if I update the bundle, it's much more easily doable if I can simply transfer the original-author-altered stuff into OSE, fin.

3) Often, bugs and errors have been found in the original oxps or the Oolite engine via OSE problems. Simply because they have a much bigger chance of occuring statistically in such a big package. And because OSE has inherited all bugs of all merged oxps.

In retrospect, it would have been better to contact the original oxp's authors about that instead of just fixing it in OSE and charging on. In the future, I will attempt this way. As Kaks said in another thread, in an ideal world I would inform oxp authors about problems or proposed changes and they would inform me if they update something. I at least will do as he suggested in the future. If that meets a complimentary reaction remains to be seen.

4) What I, sadly, also have to state is that I do not respond well to threats like "I pull out all my work if you don't do as I say ..." or even "You have to pull out my work ...".

I am completely open to constructive (!!) criticism or suggestions of any kind. I am completely capable of saying sorry if someone is made unhappy by something I do, and I am completely OK with getting to a solution together. But one thing has to be crystal clear:

This here is a creative commons project. There are grown-up people here working on a game. No one has to "command" anyone else somehow, including me and that goes into both directions. The maximum of command is the word "Please" here, for anyone.

That said, suggesting "If you don't do as I say I'll try to destroy your work of over 1000 work hours and two years" to me is insane. Just don't do it. Talk to me, anything can be ironed out. But I won't get into the kindergarten spirit we already had in the past. I just can't do the Shanti thing alone

So, this is the current state of my thoughts regarding the matter of OSE. Comments welcome.

L

[Kaks]

Hmmm,

Some issues - like outright bugs - can be sorted very quickly to everyone's satisfaction. The other stuff, well, sometimes it's not so easy...

With OSE the ooniverse is a lot more dangerous than without, and if you make some ships tough enough to survive with OSE, they'd be way too strong without OSE. If you try to compromise between the two, you'd get a ship that's still too weak for OSE, and still too strong for vanilla Oolite. So it might not always be possible to have a single version of a specific oxp, and 2 versions might become necessary.

If something gets changed to fit better with OSE it doesn't seem like the end of the world - to me - as long as it is at least renamed, so we can make a distinction between stand alone & embedded.

I might have a solution for possible clashes between renamed and stand alone oxps... what I was thinking of, was for Hotrods.oxp to simply detect the presence of the ose world script and behave accordingly: either display a simple 'OSE detected, please remove one oxp to remove incompatibility' or something more elaborate, depending on exactly what clash possibilities we're talking about... That should be a flexible enough solution, but I don't really know if it sounds reasonable enough to everybody concerned.


Lestradae, I don't think Thargoid actually mentioned - or even implied - you throwing away the 1000+ man hours you put in RS / OSE. As far as creative commons licences are concerned, yes, we all have been given the right to reuse stuff & change what we don't like. Myself I'm quite happy to try and respect other people's wishes too. Granted you feel protective about your work, but you'll have to agree that other people feel equally as protective about theirs.

[Thargoid]

Correct, I'm not looking to throw OSE out at all. All I want to do is ensure that things are in their correct place and order, that OSE is in effect a collection of OXPs, and the functionality and scripting of the OXPs within OSE is the same as would be achieved had all the individual OXPs been installed (give or take bug-fixes, which should be replicated both ways). It's a collection and meta-OXP, not the fabled and feared "one OXP to rule them all..."

PMW57 and I have had some private discussions concerning all this, and I must say I am entirely happy with the outcome of those and the attitude taken. For me how it should be is that the first part of improving a script should be working with the author and then updating the original OXP. Then and only then should anything be replicated into OSE, ideally after the original OXP update is released as a separate entity.

And as for things like the "AMS with auto-chaff dispenser", Combat Computers and OSE-hired guns, I have absolutely no problem with any of them, as each is distinct from the original, and is not trying to "over-write" it (for want of a better way of putting it). But changing the scripting within OSE but still keeping everything else the same is doing so, and even with the best of intentions it cannot be guaranteed that a new script will work the same as the old one, and it will make version control and updating a nightmare.

I'm perfectly happy and supportive for any of my scripting or other OXP work to be re-used by anyone towards a new application or usage (e.g. Wyvern's use of Repair Bots for the Neo-Caddy self-healing scripting - although being made aware of it is a nice touch ). Where I have issue is when we end up with de-facto updates to my OXPs that I have no involvement with nor any immediate desire for. If there are bugs identified that need fixing then fine, but all this is amateur work, and doesn't have to meet any standard or structure other than it works and doesn't break the game.

Oh, and as to "commanding" people to do anything, yes. You will notice when I spoke to you about the last resort option I used the word "ask". By creative commons you're fully entitled to do what you want, but building from something is different to changing the thing itself.

[Kaks]

Where I have issue is when we end up with de-facto updates to my OXPs that I have no involvement with nor any immediate desire for. If there are bugs identified that need fixing then fine, but all this is amateur work, and doesn't have to meet any standard or structure other than it works and doesn't break the game.

I've got the feeling it'd be very difficult for anyone on these boards to disagree with that!

About coding style - or lack of it - by all means, do let us know what you feel would look best / be more efficient / be easier to maintain, but ultimately an oxp needs to make sense to its author, so that it's as easy as possible for them to understand & update, even after a few months of not looking at a particular piece of code... as in many cases, friendly advice can be a lot more effective than just about anything else...

[matthewfarmery]

then the way I see it is

I would agree with Thargoid that it should be done in the easy way, the last thing OSE needs is getting scripts removed, especially if they are good ones, then for now, it might be a good idea if all the scripts had their own folders on SVN, at least for Thargoid scripts, so that he can change and modify them, if he want help from other authors on updating his scripts then so be it, but only he should update his scripts through SVN, once he is happy with the results, the scripts can be recompiled within the OSE package itself, that goes for other authors if they so so desire, so that solves that problem

I do think the main authors should be contacted or worked with on their scripts, if the author /s aren't known, then they can be modified by everyone until the original authors makes themselves known credit is giving to the author for the script and the script is handled by the author is they wish, otherwise, those that don't have known authors remain in the OSE main script folder /(or where they should belong in the whole pakage)

[Lestradae]

Only short; as my life outside the computer needs me too

I think we are nearing something better than a compromise here, more like an emerging consensus:

1) Most oxps merged into OSE should stay the way they are. That means they are still the same oxps, control over them is not taken away from their original creators in any form or way and it is easier for me to update them, as I can essentially copy & paste their fixes & updates into OSE.

2) It makes sense to add to the names of the scripts in OSE an "OSE-" tag. So that when bugfixing, devs, original oxp creators and myself immediately know which version we are talking about. <- not applicable

3) OSE does and will expand the original oxps. It can and should add to their original functionality in places, but should not replace their original functions. It might expand on the range of, say, Lampyris ships available, but the original Lampyris ship with its original stats etc. is still in there as it was. The new range is added, not a replacement.

4) Replacing things or fixing bugs should happen in accordance with the original oxp authors in the future, if that is possible and they are open to that. As things that should/could be upgraded and/or fixed affect OSE and it's constituent oxps alike.

5) We need to be polite about it towards each other and keep consciously aware of the fact that creating/adding something for/to the Ooniverse has an emotional meaning to all of us. Perhaps also apply the "breathe-to-ten-and-think before posting/PM'ing" approach. Shanti. "Please" should be the word of asking something from someone here, not bossing each other around or attempting to.

Another issue - brought up by Thargoid now multiple times, and he's up to something there - is the content OSE is supposed to have. It's called "Oolite Shipyards Extension" and has since far surpassed this description content- and topicwise.

I don't think that's a bad thing, but this is another topic for me about which I would like to think for a few days and then tell you my conclusions, what/where I want to go with this - and not debate that one right now.

If we can all agree with the five points outlined above as a workable consensus, a way forward with less toes-stepping and more cooperation and constructive criticism that helps all of us should be doable.

Oh, and I agree with 95% of what Thargoid had to say in the last posting (and also your PM ), so that feels much better to me than before

Shanti

L