That is strange. When I copy above code into a text doxument and remove the semicolon, it opens as a correct plist. Maybe you have some kind of hidden character on that line?HAL wrote:I have deleted the last semicolon, which has got rid of one error message, but it still has a problem with the = sign.
Scripters cove
Moderators: winston, another_commander
- Eric Walch
- Slightly Grand Rear Admiral
- Posts: 5536
- Joined: Sat Jun 16, 2007 3:48 pm
- Location: Netherlands
Re: Scripters cove
UPS-Courier & DeepSpacePirates & others at the box and some older versions
Re: Scripters cove
That remotely reminds me of this. (maybe?)Eric Walch wrote:That is strange. When I copy above code into a text doxument and remove the semicolon, it opens as a correct plist. Maybe you have some kind of hidden character on that line?HAL wrote:I have deleted the last semicolon, which has got rid of one error message, but it still has a problem with the = sign.
忍 knowing that enough is enough, you'll always have enough.
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Re: Scripters cove
Right. I have tried using vim to remove the BOM, and now I get this in the log:
Oolite 1.77/AddOns/gilgalad_0_0_1.oxp/Config/shipyard.plist as a property list.
Unexpected character { at line 1
Here's the code again (I messed around with the spacing, and put it back, which might have done something as well)
Oolite 1.77/AddOns/gilgalad_0_0_1.oxp/Config/shipyard.plist as a property list.
Unexpected character { at line 1
Here's the code again (I messed around with the spacing, and put it back, which might have done something as well)
Code: Select all
{
"gilgalad21213-player" =
{
chance = 1;
"optional_equipment" =
(
"EQ_ECM",
"EQ_FUEL_SCOOPS",
"EQ_ESCAPE_POD",
"EQ_ENERGY_BOMB",
"EQ_ENERGY_UNIT",
"EQ_NAVAL_ENERGY_UNIT",
"EQ_DOCK_COMP",
"EQ_WEAPON_PULSE_LASER",
"EQ_WEAPON_BEAM_LASER",
"EQ_WEAPON_MINING_LASER",
"EQ_WEAPON_MILITARY_LASER",
"EQ_FUEL_INJECTION",
"EQ_SCANNER_SHOW_MISSILE_TARGET",
"EQ_MULTI_TARGET",
"EQ_GAL_DRIVE",
"EQ_SHIELD_BOOSTER"
"EQ_NAVAL_SHIELD_BOOSTER"
);
price = 650;
"standard_equipment" =
{
extras =
(
"EQ_HEAT_SHIELD"
);
"forward_weapon_type" = "EQ_WEAPON_PULSE_LASER";
missiles = 1;
};
techlevel = 1;
"weapon_facings" = 1;
};
}
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: Scripters cove
There's still no comma behind
That's all.
You're already using indentation, which is good, because it makes things easier to see. Therefore, the lines
really stand out like a sore thumb (the last one has a different indentation, although its content should not be different in any way from the preceding lines). What's the reason for this? Ah! There's a comma missing in the line before that. Obvious copy&paste mistake. I guess you copied the last item into a list which originally closed with the second-to-last item.
Over time your eyes will be more trained to see something like this.
So, it should be
Code: Select all
"EQ_SHIELD_BOOSTER"
You're already using indentation, which is good, because it makes things easier to see. Therefore, the lines
Code: Select all
…
"EQ_GAL_DRIVE",
"EQ_SHIELD_BOOSTER"
"EQ_NAVAL_SHIELD_BOOSTER"
);
Over time your eyes will be more trained to see something like this.
So, it should be
Code: Select all
…
"EQ_GAL_DRIVE",
"EQ_SHIELD_BOOSTER",
"EQ_NAVAL_SHIELD_BOOSTER"
);
new wiki page for often recurring scripting tasks
Hi all,
I've started a wiki page for "often recurring scripting tasks".
You can find it here: [wiki]Scripting Tasks[/wiki].
Hope you all will add valuable content to it!
I already added one task: "(HowTo) drain energy while equipment is being used (simulate energy usage)". Feedback (as always) most welcome!
P.S.: I also thought about adding a page for "scripting caveats"... for adding candidates like this one. What do you think about that?
EDIT: Hey, since when do I have an ELITE status on the BB?? Cool.
I've started a wiki page for "often recurring scripting tasks".
You can find it here: [wiki]Scripting Tasks[/wiki].
Hope you all will add valuable content to it!
I already added one task: "(HowTo) drain energy while equipment is being used (simulate energy usage)". Feedback (as always) most welcome!
P.S.: I also thought about adding a page for "scripting caveats"... for adding candidates like this one. What do you think about that?
EDIT: Hey, since when do I have an ELITE status on the BB?? Cool.
忍 knowing that enough is enough, you'll always have enough.
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
- Cody
- Sharp Shooter Spam Assassin
- Posts: 16081
- Joined: Sat Jul 04, 2009 9:31 pm
- Location: The Lizard's Claw
- Contact:
Re: new wiki page for often recurring scripting tasks
Since your 256th post!GGShinobi wrote:Hey, since when do I have an ELITE status on the BB??
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
And any survivors, their debts I will certainly pay. There's always a way!
Re: new wiki page for often recurring scripting tasks
How funny that I didn't notice that back then... since I did notice the 256!!!!El Viejo wrote:Since your 256th post!GGShinobi wrote:Hey, since when do I have an ELITE status on the BB??
忍 knowing that enough is enough, you'll always have enough.
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: new wiki page for often recurring scripting tasks
If it makes you happy, that's probably fine.GGShinobi wrote:I've started a wiki page for "often recurring scripting tasks".
Generally, however, it doesn't strike me as a good idea to ever more scatter potentially useful information. It makes information harder to find, not easier.
For instance, there is already a resource for collecting "often recurring scripting tasks". It is this very thread we're currently posting in. It was started about three OXPer generations ago for exactly this reason:
In the meantime, even a whole OXP has been created (and is constantly being added to) to collect often recurring scripting tasks and perform them for you. That's what the whole idea behind Cabal Common Library is.Arexack_Heretic wrote:This thread will hopefully become a usefull resourse for scripting
offering interesting methods,
basic (modular) scripts,
and cooperative assistance by the cOomunity for scriptcoders just starting out or experienced ones with a difficult problem.
Also, the example that you describe over there on your page seems to be a rather trivial one; the very simple use of a timer to periodically reset a property. I'm wondering whether this really warrants a rather long-winding explanation, beyond what there's already in the timer documentation. How useful is this really for other people?
Re: new wiki page for often recurring scripting tasks
Thanks McLane for your feedback.
And to come back to your mentioning of this thread again: I really like the bb and how fast one gets very good answers, but I think it's not as well suited to collect information as the wiki is. To my understanding the bb is not intended to be a "reference book", but it's a tool to offer quick help if someone has a problem. The wiki, on the other hand, is a reference book, and in my opinion, valuable knowledge that can be extracted from the bb and other places should be collected there. Otherwise, people will have to answer the same questions over and over again.
But what are the opinions of others on this topic? Maybe I'm the only one having trouble finding something on the bb (I'm also not good at "googling")... I surely don't insist on using the wiki for this task.
I'm well aware of that, and I was really enthusiastic when I first discovered this thread. But at least I for my part often have problems to find something which might or might not be on one of the 66 pages of this thread. And using the search has the disadvantage that the used search expression has to match, since probably the post is not using the words "drain energy" but "reduce energy" or something else. Using only "energy" brings up way too many hits. On the other hand, using the wiki would have the advantage that all the info is on one page and I can relatively quickly read through the "content" at top to see if the page contains the task that I need, even if other words have been used.Commander McLane wrote:For instance, there is already a resource for collecting "often recurring scripting tasks". It is this very thread we're currently posting in. It was started about three OXPer generations ago for exactly this reason:Arexack_Heretic wrote:This thread will hopefully become a usefull resourse for scripting
offering interesting methods,
basic (modular) scripts,
and cooperative assistance by the cOomunity for scriptcoders just starting out or experienced ones with a difficult problem.
Hmm, I'm not sure what you are trying to say with that. As far as I see, the Cabal Common Library (CCL) has no "drain energy" functionality (yet). Do you suggest to add the functionality to it, then, rather than explaining it on the wiki? If so, the wiki would still have the advantage that everyone can edit / extend it first, so that one might collect different ways of doing something before choosing the "best" solution that is then added to the CCL.Commander McLane wrote:In the meantime, even a whole OXP has been created (and is constantly being added to) to collect often recurring scripting tasks and perform them for you. That's what the whole idea behind Cabal Common Library is.
My point was not to explain how to use a timer. My background was as follows: I've been investigating how one can have equipment use energy, and didn't find anything, neither on the wiki nor on the bb. So I peaked into an oxp of which I knew that it does exactly that (Ore Processor), and thought such an often recurring task should be documented, so that others can save some time. That's why I started the wiki page, and that's why I explain how to use a timer in order to simulate energy usage. And I hope that if there are other ways of doing this, people will add them to the wiki, so that everyone can choose the best solution for himself.Commander McLane wrote:Also, the example that you describe over there on your page seems to be a rather trivial one; the very simple use of a timer to periodically reset a property. I'm wondering whether this really warrants a rather long-winding explanation, beyond what there's already in the timer documentation. How useful is this really for other people?
And to come back to your mentioning of this thread again: I really like the bb and how fast one gets very good answers, but I think it's not as well suited to collect information as the wiki is. To my understanding the bb is not intended to be a "reference book", but it's a tool to offer quick help if someone has a problem. The wiki, on the other hand, is a reference book, and in my opinion, valuable knowledge that can be extracted from the bb and other places should be collected there. Otherwise, people will have to answer the same questions over and over again.
But what are the opinions of others on this topic? Maybe I'm the only one having trouble finding something on the bb (I'm also not good at "googling")... I surely don't insist on using the wiki for this task.
忍 knowing that enough is enough, you'll always have enough.
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Re: Scripters cove
I think it's not a bad idea to give some short examples for new users. A Wiki page is better prepared for quick navigation and lots of posted examples on the BB are outdated. I'd say keep the examples short and give additional infos if there are caveats (like unrooted Timers, the problem of deleting other OXPs entities, etc.).
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: new wiki page for often recurring scripting tasks
The information you were looking for is theGGShinobi wrote:GGShinobi wrote:My point was not to explain how to use a timer. My background was as follows: I've been investigating how one can have equipment use energy, and didn't find anything, neither on the wiki nor on the bb.
energy
property of your ship.You probably didn't find it in the documentation of PlayerShip.
So, the next step is to be aware that the player ship is really only a special case of a ship, and therefore look into the documentation of Ship. Because everything that is valid for any ship is valid for the player ship as well.
Energy isn't to be found in Ship either, though. That's because not only ship entities can have energy, but other entities as well. Thus you'll find it in the documentation of Entity. And there it says that it's a read/write property, representing an entity's energy.
So, that's the information you were looking for in the first place. It's already in the Wiki and doesn't need another Wiki page of its own. But admittedly, half of finding the information you need is to know where to look.
And within Oolite's hierarchy of things, then you only have to know that a ship is a special case of an entity, and the player ship is a special case of a ship. Therefore, all properties and methods for entities can be used for ships as well, and all properties and methods for ships can be used for the player ship as well. Thus, if you're looking for something and don't find it on the PlayerShip level, just think on which level it applies and search in the documentation of that level.
Re: new wiki page for often recurring scripting tasks
Though, you can think too hard about this, as so far Ships (and subtypes) are the only JS-accessible entities for which the energy value has any real meaning.Commander McLane wrote:That's because not only ship entities can have energy, but other entities as well.
A more recent alternative to using a Timer would be to use a Frame Callback (hastily fixes documentation). This lets you smoothly interpolate the energy use over time rather than taking it all at once in bursts. Which is better depends on what feels right for your item of equipment, of course.
Re: new wiki page for often recurring scripting tasks
Commander McLane wrote:The information you were looking for is theenergy
property of your ship.
You probably didn't find it in the documentation [...]
You are right, I've searched the docu for "player.ship" and "ship", and even "world script event handlers", "ship script event handlers" and "global"... should have looked at "entity", too...Commander McLane wrote:So, that's the information you were looking for in the first place. It's already in the Wiki and doesn't need another Wiki page of its own. But admittedly, half of finding the information you need is to know where to look.
I see, the best (and fastest) way would have been to simply ask my question in this thread. I only feared that if I ask questions before having tried to find the answer would get me lynched! And when I finally found the answer, thinking it was not in the wiki yet, I added it.Commander McLane wrote:And within Oolite's hierarchy of things, then you only have to know that a ship is a special case of an entity, and the player ship is a special case of a ship. Therefore, all properties and methods for entities can be used for ships as well, and all properties and methods for ships can be used for the player ship as well. Thus, if you're looking for something and don't find it on the PlayerShip level, just think on which level it applies and search in the documentation of that level.
So what shall we do with the wiki page, then? Do as Svengali suggests and transform it to a place where short examples for newbies are given, or should it be deleted?
忍 knowing that enough is enough, you'll always have enough.
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Question about Timers
I want my Subentity Repair System (ERS) to allow the player (and itself) to pause repairs (since they need energy). What happens if I simply stop the timer that counts down the seconds until the repairs are finished? Can I later resume them by simply starting the timer again? So for example lets say a repair would take 100 seconds. After 60 seconds the player pauses the repairs. Some time later, the player wants to resume the repairs. If I simply use "timer.stop()" and later "timer.start()", does the timer continue from the point where I stopped it, so that it fires when remaining repair time (40 seconds) have passed? If not, how could I implement that behaviour?
忍 knowing that enough is enough, you'll always have enough.
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
Running Oolite 1.77 on Ubuntu Linux 12.04 LTS
- Wildeblood
- ---- E L I T E ----
- Posts: 2453
- Joined: Sat Jun 11, 2011 6:07 am
- Location: Western Australia
- Contact:
Re: Question about Timers
No, timer.stop() doesn't actually stop the timer, just stops it calling the timed function. You'll need to reset timer.nextTime before re-starting it.GGShinobi wrote:I want my Subentity Repair System (ERS) to allow the player (and itself) to pause repairs (since they need energy). What happens if I simply stop the timer that counts down the seconds until the repairs are finished? Can I later resume them by simply starting the timer again? So for example lets say a repair would take 100 seconds. After 60 seconds the player pauses the repairs. Some time later, the player wants to resume the repairs. If I simply use "timer.stop()" and later "timer.start()", does the timer continue from the point where I stopped it, so that it fires when remaining repair time (40 seconds) have passed? If not, how could I implement that behaviour?
Something like this:-
Code: Select all
if (this.$myTimer)
{
this.$myTimer.stop();
this.$timeToRun = this.$myTimer.nextTime - clock.absoluteSeconds;
}
Code: Select all
if (this.$myTimer && this.$timeToRun)
{
this.$myTimer.nextTime = clock.absoluteSeconds + this.$timeToRun;
this.$myTimer.start();
delete this.$timeToRun;
}