Scripting requests
Moderators: winston, another_commander
Re: Scripting requests
Currently it's possible to useSpecialCargo that will take up the whole cargo space for special cargo. I would instead like to be able to use some of the cargo space with special cargo leaving the rest for the player to be used as they wish. It could be something like addSpecialCargo("Evil juice, shaken not stirred", 2, this.name) and removeSpecialCargo(this.name). Possible?
Re: Scripting requests
In 1.81, probably the easiest way to do this is:
- define equipment items which are hidden, undamageable and (possibly) multi-installable ... and also happen to take up 1, 2, 4, 8, ... TC of cargo space.
- to add special cargo, add the appropriate combination of items (multi-installable means you don't have to consider other uses if you plan to do more than one) and then do
- define equipment items which are hidden, undamageable and (possibly) multi-installable ... and also happen to take up 1, 2, 4, 8, ... TC of cargo space.
- to add special cargo, add the appropriate combination of items (multi-installable means you don't have to consider other uses if you plan to do more than one) and then do
mission.setInstructions(["Special Cargo:","2 TC Evil Juice shaken not stirred"]);
useSpecialCargo
is I think there solely to make the core Nova mission work and like many of the other special features for that mission probably doesn't work particularly well when used elsewhere.Re: Scripting requests
Why of course . Thanks.cim wrote:In 1.81, probably the easiest way to do this is:
- define equipment items which are hidden, undamageable and (possibly) multi-installable ... and also happen to take up 1, 2, 4, 8, ... TC of cargo space.
- to add special cargo, add the appropriate combination of items (multi-installable means you don't have to consider other uses if you plan to do more than one) and then domission.setInstructions(["Special Cargo:","2 TC Evil Juice shaken not stirred"]);
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4841
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Scripting requests
In the oolite-populator.js file, there are a number of instances of something like this:
My apologies if this is an obvious line of code, but I'm not sure what the "|=" is doing. My research says it's doign a bitwise OR with a mask, but I'm afraid I can't interpret it! If
Code: Select all
eg[i].bounty |= 3+Math.floor(Math.random()*12);
eg[i].bounty
is zero, what would be the expected result?Re: Scripting requests
0 OR x = xphkb wrote:If eg.bounty is zero, what would be the expected result?
Bitwise OR has the useful property that if 'x OR y = z' then 'z OR x = z' and 'z OR y = z' so you can combine bounties for different offences using OR, without potentially getting massive bounties if something decides to repeatedly apply a 2 credit bounty in a loop.
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4841
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Scripting requests
With the runScreen function, when specifying an ship model as the background with no rotation, is it possible to view the ship in a view other that from the top? If possible, I'd like to set the view to from the front, a little elevated and to the left, if that makes sense.
Re: Scripting requests
Setphkb wrote:With the runScreen function, when specifying an ship model as the background with no rotation, is it possible to view the ship in a view other that from the top? If possible, I'd like to set the view to from the front, a little elevated and to the left, if that makes sense.
mission.displayModel.orientation
- Norby
- ---- E L I T E ----
- Posts: 2577
- Joined: Mon May 20, 2013 9:53 pm
- Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
- Contact:
Re: Scripting requests
[wiki]Gallery[/wiki] OXP contain good examples, as you can see in screenshots the player can zoom and rotate ships via custom position and orientation updates.phkb wrote:With the runScreen function, when specifying an ship model as the background with no rotation, is it possible to view the ship in a view other that from the top?
-
- Competent
- Posts: 58
- Joined: Mon Mar 02, 2015 2:08 pm
- Location: drifting in remLock mask near Vezadi Station
Re: Scripting requests
Could we please have a method for Ship entities (which works on NPCs, player ships, and subentities of player or NPC vessels) which tells the ship (or subentity) to simply fire one shot from its current, or a specified, laser as long as it has such a weapon and the weapon is not recharging or overheated? I can see a few uses for this:
1) The 'laser strafing mine' concept suggested by Huntress, which unless I've interpreted it wrongly calls for lasers to fire indiscriminately in all directions.
2) An easier way to make player ships with multiple forward (or aft, or side) lasers, which fire simultaneously in the same manner as NPCs'. I know this will be controversial, so I will set out a few reasons for allowing this below.
3) Detailed control of ships in combat using scriptedAI, for instance to make a mission ship fire a warning shot across the player's bow (the present scriptedAttackAI simply shoots if the target is in its sights).
4) The ability to make the player's lasers malfunction in a way which produces uncontrollable firing, or to have a 'co-pilot' opportunistically fire the aft gun if a target wanders into its sights while you're looking forward (or vice versa), or anything similar.
Reasons for allowing player ships to have multiple front lasers in this manner:
1) There would be other applications for the required scripting functionality (see above).
2) The present restrictions on player-ship armament pre-date Oolite 1.77, which gave NPC lasers equal firepower, and Oolite 1.81 which reduced standard per-second damage rates for both player and NPCs and allowed the definition of new laser types. I think these changes give room for multi-laser player ships to exist in a more balanced fashion.
3) If I remember rightly, the backstory justification for not allowing players to fly MFL ships was that they're illegal for civilian use. However, the ability to define new starting scenarios and create missions around them means that the player may not always be a civilian--and some players have little respect for the Galactic Cooperative's laws anyway.
4) It is currently easier to make self-firing secondary lasers which can fit on any ship (Primeable Lasers OXP) and self-aiming laser turrets than manually-operated equivalents. Barring that OXP's attempt to make itself more balanced by restricting its equipment to Deadly-rated commanders, I find this a bit odd given that game balance is the reason for not allowing multiple front lasers in the first place.
5) I have already produced a workaround which allows something approaching this functionality, but it has some serious bugs and even if these are fixed it will be more complex, less efficient and less versatile than the method I'm asking for. Essentially, you can have MFL player ship OXPs this way with some other OXP-ing possibilities, or you can have them an inferior way, but some day they will exist.
6) I am asking for one scripting method which would make it easier for OXPs to add MFL player ships, not full core-game support for such vessels. Issues such as upgrading the subentity lasers would be left entirely to the OXP.
7) It would be each player's individual choice to fly such a ship if desired, just as it is now their choice to install NPC ships with multiple front lasers or indeed any other type of uber-ship OXP. If unbalanced gameplay results, that's their problem.
1) The 'laser strafing mine' concept suggested by Huntress, which unless I've interpreted it wrongly calls for lasers to fire indiscriminately in all directions.
2) An easier way to make player ships with multiple forward (or aft, or side) lasers, which fire simultaneously in the same manner as NPCs'. I know this will be controversial, so I will set out a few reasons for allowing this below.
3) Detailed control of ships in combat using scriptedAI, for instance to make a mission ship fire a warning shot across the player's bow (the present scriptedAttackAI simply shoots if the target is in its sights).
4) The ability to make the player's lasers malfunction in a way which produces uncontrollable firing, or to have a 'co-pilot' opportunistically fire the aft gun if a target wanders into its sights while you're looking forward (or vice versa), or anything similar.
Reasons for allowing player ships to have multiple front lasers in this manner:
1) There would be other applications for the required scripting functionality (see above).
2) The present restrictions on player-ship armament pre-date Oolite 1.77, which gave NPC lasers equal firepower, and Oolite 1.81 which reduced standard per-second damage rates for both player and NPCs and allowed the definition of new laser types. I think these changes give room for multi-laser player ships to exist in a more balanced fashion.
3) If I remember rightly, the backstory justification for not allowing players to fly MFL ships was that they're illegal for civilian use. However, the ability to define new starting scenarios and create missions around them means that the player may not always be a civilian--and some players have little respect for the Galactic Cooperative's laws anyway.
4) It is currently easier to make self-firing secondary lasers which can fit on any ship (Primeable Lasers OXP) and self-aiming laser turrets than manually-operated equivalents. Barring that OXP's attempt to make itself more balanced by restricting its equipment to Deadly-rated commanders, I find this a bit odd given that game balance is the reason for not allowing multiple front lasers in the first place.
5) I have already produced a workaround which allows something approaching this functionality, but it has some serious bugs and even if these are fixed it will be more complex, less efficient and less versatile than the method I'm asking for. Essentially, you can have MFL player ship OXPs this way with some other OXP-ing possibilities, or you can have them an inferior way, but some day they will exist.
6) I am asking for one scripting method which would make it easier for OXPs to add MFL player ships, not full core-game support for such vessels. Issues such as upgrading the subentity lasers would be left entirely to the OXP.
7) It would be each player's individual choice to fly such a ship if desired, just as it is now their choice to install NPC ships with multiple front lasers or indeed any other type of uber-ship OXP. If unbalanced gameplay results, that's their problem.
Re: Scripting requests
The "fire" option in the scripted attack AI probably should have an unconditional fire option (I'd probably have added one sooner if there was previous evidence that anyone wanted to use it at all). That can be added easily enough after 1.82, and should allow cases 1 and 3.
A method to fire a player's currently selected laser (or any on an NPC main entity) should be straightforward enough; I suspect there would be issues with firing a non-selected player laser, especially if the player was also firing the selected laser in the same frame, but they might be manageable. That probably covers case 4 well enough.
Firing of subentity lasers more generally is trickier - the code that allows it at the moment for NPC forward fire brings in all sorts of extra complexity that I have no inclination to extend to player ships and/or other fire directions in its current form. What I would prefer to do with that - for both players and NPCs - is to optionally allow "weapon_position_X" to be an array, and keep all the weapons bound to the main entity. The current subentity option would need to be kept for compatibility with existing OXPs, of course.
A method to fire a player's currently selected laser (or any on an NPC main entity) should be straightforward enough; I suspect there would be issues with firing a non-selected player laser, especially if the player was also firing the selected laser in the same frame, but they might be manageable. That probably covers case 4 well enough.
Firing of subentity lasers more generally is trickier - the code that allows it at the moment for NPC forward fire brings in all sorts of extra complexity that I have no inclination to extend to player ships and/or other fire directions in its current form. What I would prefer to do with that - for both players and NPCs - is to optionally allow "weapon_position_X" to be an array, and keep all the weapons bound to the main entity. The current subentity option would need to be kept for compatibility with existing OXPs, of course.
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4841
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Scripting requests
Is it possible to give a specific quantity of a specific commodity to a NPC ship? For instance, can I give 3 tons of food, 4 tons of computers, that sort of thing?
Re: Scripting requests
In 1.82, yes. Assuming it's currently empty, thenphkb wrote:Is it possible to give a specific quantity of a specific commodity to a NPC ship? For instance, can I give 3 tons of food, 4 tons of computers, that sort of thing?
ship.adjustCargo("food", 3); ship.adjustCargo("computers",4);
. If it had cargo on board already you might need to do something like ship.adjustCargo("food", 3); ship.adjustCargo("computers",-6); ship.adjustCargo("machinery",-10);
- phkb
- Impressively Grand Sub-Admiral
- Posts: 4841
- Joined: Tue Jan 21, 2014 10:37 pm
- Location: Writing more OXPs, because the world needs more OXPs.
Re: Scripting requests
I have this code:Now, I get this:
Code: Select all
var shipdata = Ship.shipDataForKey(my_shipkey);
shipdata
has a condition_script set for it. I want to run the "allowSpawnShip" function to check whether it's OK to create a ship with this key. But how to I execute the function? When I try this:
Code: Select all
var include = shipdata.condition_script.allowSpawnShip(my_shipkey);
Code: Select all
01:58:40.475 [script.javaScript.exception.notFunction]: ***** JavaScript exception (StationDockControl 0.3.0): TypeError: shipdata.condition_script.allowSpawnShip is not a function
01:58:40.476 [script.javaScript.exception.notFunction]: ../AddOns/StationDockControl.oxp/Scripts/stationdockcontrol.js, line 391.