Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.
More details in this thread.
Scripting requests
Moderators: winston, another_commander
- Cody
- Sharp Shooter Spam Assassin
- Posts: 16078
- Joined: Sat Jul 04, 2009 9:31 pm
- Location: The Lizard's Claw
- Contact:
Re: Scripting requests
It was only a flippant response, is all... ignore.
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!
- Capt. Murphy
- Commodore
- Posts: 1127
- Joined: Fri Feb 25, 2011 8:46 am
- Location: UK South Coast.
Re: Scripting requests
Hi,
Requesting
Thanks.
Requesting
station.hasShipyard : Boolean (read/write) (read only for mainStations)
to give the result of shipdata key has_shipyard
.Thanks.
![[EliteWiki]](/images/elitewikismall.png)
External JavaScript resources - W3Schools & Mozilla Developer Network
Win 7 64bit, Intel Core i5 with HD3000 (driver rev. 8.15.10.2696 - March 2012), Oolite 1.76.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: Scripting requests
I think read only should be fine for all stations.Capt. Murphy wrote:Hi,
Requestingstation.hasShipyard : Boolean (read/write) (read only for mainStations)
to give the result of shipdata keyhas_shipyard
.
All stations in my OXPs either deliberately have a shipyard, or they deliberately don't. I see no reason why this should be changed after the fact.
-
- Quite Grand Sub-Admiral
- Posts: 6579
- Joined: Wed Feb 28, 2007 7:54 am
Re: Scripting requests
I think I agree with McLane on this one.
hasShipyard
added as read-only property to the OOJSStation class on r4980.- Capt. Murphy
- Commodore
- Posts: 1127
- Joined: Fri Feb 25, 2011 8:46 am
- Location: UK South Coast.
Re: Scripting requests
Thanks,
The reason for read/write is because it can be a fuzzy boolean in shipdata.plist, and I was after a way of ensuring that if an OXP station in a particular system had a shipyard on a visit to that system/station, on a return visit the OXP station would still have a shipyard. I can work around it though if you really think it's a bad idea to make it read/write.
The reason for read/write is because it can be a fuzzy boolean in shipdata.plist, and I was after a way of ensuring that if an OXP station in a particular system had a shipyard on a visit to that system/station, on a return visit the OXP station would still have a shipyard. I can work around it though if you really think it's a bad idea to make it read/write.
![[EliteWiki]](/images/elitewikismall.png)
External JavaScript resources - W3Schools & Mozilla Developer Network
Win 7 64bit, Intel Core i5 with HD3000 (driver rev. 8.15.10.2696 - March 2012), Oolite 1.76.1
Re: Scripting requests
Maybe a mission/campaign forces you to use a certain ship? You can't exactly sell it if there's no shipyard. ![Laughing :lol:](./images/smilies/icon_lol.gif)
![Laughing :lol:](./images/smilies/icon_lol.gif)
Re: Scripting requests
Easier there would be to use guiScreenChanged and mission.runScreen to cancel the shipyard screen.Switeck wrote:Maybe a mission/campaign forces you to use a certain ship? You can't exactly sell it if there's no shipyard.
- 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: Scripting requests
That's a reason I can understand. Consistency is a worthwhile goal. It would be interesting to know, though, how many OXP stations are actually making use of a fuzzy boolean in the first place.Capt. Murphy wrote:The reason for read/write is because it can be a fuzzy boolean in shipdata.plist, and I was after a way of ensuring that if an OXP station in a particular system had a shipyard on a visit to that system/station, on a return visit the OXP station would still have a shipyard. I can work around it though if you really think it's a bad idea to make it read/write.
I have to admit that I wasn't aware of the possibility of fuzzy booleans for
has_shipyard
when I responded rather instinctively. I had in mind that a certain station either would or wouldn't have a shipyard for good reasons. At the same time I am wary of a new generation of OXP-creators and a tendency to use every provided scripting ability for quick-and-dirty cheat OXPs under the flag of "if it can be done, it cannot be wrong". A development which—for me, at least—tends to make Oolite less and less attractive. Thus I'm not overly keen on making everything writeable.Re: Scripting requests
Heh .-) I'd think it's a bug in the offering OXP then .-)Switeck wrote:Maybe a mission/campaign forces you to use a certain ship? You can't exactly sell it if there's no shipyard. :lol:
If a station is designed to have no shipyard it shouldn't be possible to force it via script to have one, so I'm with CMcL.
Re: Scripting requests
Ah, I was looking for removal of the offending shipyard...not ADDING one where there shouldn't be.
cim's suggestion of: "Easier there would be to use guiScreenChanged and mission.runScreen to cancel the shipyard screen."
...works just as well, which is very similar to what is done in Galactic_Misjump_0.3.zip to prevent the player from seeing the Short range chart.
However making a readable variable (to scripts) as to whether a station HAS a shipyard seems handy. Hardly a potential exploit that way.
cim's suggestion of: "Easier there would be to use guiScreenChanged and mission.runScreen to cancel the shipyard screen."
...works just as well, which is very similar to what is done in Galactic_Misjump_0.3.zip to prevent the player from seeing the Short range chart.
However making a readable variable (to scripts) as to whether a station HAS a shipyard seems handy. Hardly a potential exploit that way.
Re: Scripting requests
This should be working as of the current nightly build (r5016). Let me know if you have any problems with it.Wildeblood wrote:Can we have the player ship cross-hairs dictionary/file changeable, the same way the HUD file is, please? Currently, to alter the cross-hairs on the fly, one has to embed the cross-hairs dictionary in a HUD file and switch the whole HUD file. It's easily done, but can cause a rapid proliferation of HUD files.
Crosshair definitions go in a file in Config with the same format as the built-in
crosshairs.plist
and an arbitrary (should-be-unique) name.To apply a crosshair definition file to a HUD:
- give the HUD a "
crosshair_file
" parameter with the filename.- set
player.ship.crosshairs
to the filename by scriptHUD plists can have both "
crosshair_file
" and "crosshairs
" keys: if so, the "crosshair_file
" key takes precedence.If you change
player.ship.hud
, then player.ship.crosshairs
will be reset to the new HUD's default.If the HUD default crosshair is in place and not generated through "
crosshair_file
", then player.ship.crosshairs
will be null. Setting player.ship.crosshairs
to be null will revert the HUD to its default crosshairs (however they were specified).- Wildeblood
- ---- E L I T E ----
- Posts: 2325
- Joined: Sat Jun 11, 2011 6:07 am
- Location: Western Australia
Re: Scripting requests
Thanks cim.
I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?
I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?
-
- Quite Grand Sub-Admiral
- Posts: 6579
- Joined: Wed Feb 28, 2007 7:54 am
Re: Scripting requests
It is normal. In order to have the watermark text as it appears on the nightlies, you must compile usingWildeblood wrote:I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?
make release-snapshot
Re: Scripting requests
That will only appear if SNAPSHOT_BUILD was set as a build option. The "release-snapshot" build target (and equivalents for deps and debian package) set it, the others don't.Wildeblood wrote:I just compiled r5016 from source and it doesn't have the version number display in the top-right of the screen, is that to be expected?
- CommonSenseOTB
- ---- E L I T E ----
- Posts: 1397
- Joined: Wed May 04, 2011 10:42 am
- Location: Saskatchewan, Canada
Re: Scripting requests
cim wrote:This should be working as of the current nightly build (r5016). Let me know if you have any problems with it.Wildeblood wrote:Can we have the player ship cross-hairs dictionary/file changeable, the same way the HUD file is, please? Currently, to alter the cross-hairs on the fly, one has to embed the cross-hairs dictionary in a HUD file and switch the whole HUD file. It's easily done, but can cause a rapid proliferation of HUD files.
Crosshair definitions go in a file in Config with the same format as the built-incrosshairs.plist
and an arbitrary (should-be-unique) name.
To apply a crosshair definition file to a HUD:
- give the HUD a "crosshair_file
" parameter with the filename.
- setplayer.ship.crosshairs
to the filename by script
HUD plists can have both "crosshair_file
" and "crosshairs
" keys: if so, the "crosshair_file
" key takes precedence.
If you changeplayer.ship.hud
, thenplayer.ship.crosshairs
will be reset to the new HUD's default.
If the HUD default crosshair is in place and not generated through "crosshair_file
", thenplayer.ship.crosshairs
will be null. Settingplayer.ship.crosshairs
to be null will revert the HUD to its default crosshairs (however they were specified).
![Very Happy :D](./images/smilies/icon_biggrin.gif)
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
CommonSense 'Outside-the-Box' Design Studios Ltd.
WIKI+OXPs
CommonSense 'Outside-the-Box' Design Studios Ltd.
WIKI+OXPs