If warp engine in use, then.... (or alternatively, if current speed is high, then...)
I'm really enamored of the idea of making a mission map with wormhole gates, ala Babylon 5, where there's fixed points generated on the map that teleport you from place to place and you can't use your warp drive. The mission would then have a plot reason why you don't use your ship's normal FTL technologies to warp or jump. I tried doing this with a timer that constantly re-damages the warp engines but that has too many other side effects, like the DamCon crews being stuck from the very start of the mission because they begin in the warp engine room and can't get out of the room that constantly re-damages itself.
But that isn't even the way I really want to implement it. It was just an idea I was trying because people mentioned getting it to work in this forum.
What I *really* want to do is this: I want to allow the warp drive to work BUT at an extreme energy cost so that crews won't want to use it (i.e. make it cost 500 units just to go warp for a few seconds). This fits the backstory idea I have in mind better than doing it by damaging the engines anyway.
Can anyone think of a property test I could do that would achieve this? I could either check for "if warp drive is on" or I could check for "If ship is going faster than S then it must be going faster than impulse" or I could check for "If the ship has traveled farther than distance D from the last position it was at one second ago, then it must be going faster than impulse". But so far I don't think I see any properties in the documentation that would let me access the information to do this. The "check the position every second, see if it moved really far" seems to me to be the best bet, but I don't think I can just make up my own homebrew variables in which to store the ship's previous position.
But that isn't even the way I really want to implement it. It was just an idea I was trying because people mentioned getting it to work in this forum.
What I *really* want to do is this: I want to allow the warp drive to work BUT at an extreme energy cost so that crews won't want to use it (i.e. make it cost 500 units just to go warp for a few seconds). This fits the backstory idea I have in mind better than doing it by damaging the engines anyway.
Can anyone think of a property test I could do that would achieve this? I could either check for "if warp drive is on" or I could check for "If ship is going faster than S then it must be going faster than impulse" or I could check for "If the ship has traveled farther than distance D from the last position it was at one second ago, then it must be going faster than impulse". But so far I don't think I see any properties in the documentation that would let me access the information to do this. The "check the position every second, see if it moved really far" seems to me to be the best bet, but I don't think I can just make up my own homebrew variables in which to store the ship's previous position.
page
1
5 replies
Replying to my own message here. I have a workaround that is "good enough". The workaround is this:
Since warp engines cause the impulse throttle to max out to 100%, I simply check if the throttle setting (which I can read) is >= 1.0, as a sort of proxy for checking whether or not the warp throttle (which I cannot read) is > 0.
The only problem is that I have to write in some explanation why the helmsman can't quite set the throttle at 100% and has to try to put it to 99%.
Since warp engines cause the impulse throttle to max out to 100%, I simply check if the throttle setting (which I can read) is >= 1.0, as a sort of proxy for checking whether or not the warp throttle (which I cannot read) is > 0.
The only problem is that I have to write in some explanation why the helmsman can't quite set the throttle at 100% and has to try to put it to 99%.
"warpState" has been added to the player variables you can get/set. This change will be available in the next release.
Creator of Artemis
Yay! That's a big deal!
Thom, I suggest you consider making "warp state" a speedometer that gives the true speed combining Helm setting and Engineering power allocation. It would also be useful to the players (and more Trek like) if that speedometer showed up on the Helm console. The current bar on the Helm console only shows what the Helmsperson has selected, it doesn't tell the Helmsperson how fast the ship is moving.
The setting selected by Helm doesn't tell my script how much time it will take the players to get from point A to point B. Knowing that time is important to story exposition. Also, if my script has an action triggered by Warp 4 the players can cheat by having Helm select Warp 4 while Engineering cuts power to the Warp drive.
Thom, I suggest you consider making "warp state" a speedometer that gives the true speed combining Helm setting and Engineering power allocation. It would also be useful to the players (and more Trek like) if that speedometer showed up on the Helm console. The current bar on the Helm console only shows what the Helmsperson has selected, it doesn't tell the Helmsperson how fast the ship is moving.
The setting selected by Helm doesn't tell my script how much time it will take the players to get from point A to point B. Knowing that time is important to story exposition. Also, if my script has an action triggered by Warp 4 the players can cheat by having Helm select Warp 4 while Engineering cuts power to the Warp drive.
"Damn the torpedoes! Four bells, Captain Drayton!"
(Likely actual words of Admiral David Farragut, USN, at the battle of Mobile Bay. Four bells was the signal for the engine room to make full steam ahead).
(Likely actual words of Admiral David Farragut, USN, at the battle of Mobile Bay. Four bells was the signal for the engine room to make full steam ahead).
I suggest having two separate options:
- warpState should be used to set/get the warp state, like, if you want to have a mission where players can warp to other sector if they hit sector border at warp 4 (it doesnt matter if engineering tweaked the energy allocation, its just a simple way for players to tell the mission "We want to go to the other sector").
- currentSpeed should be used to get (maybe set too?) the current speed at which object is moving. This could be used for purposes Mike mentioned - to know how soon they will arrive at their destination, or maybe to give players hints, like a tutorial mission that notifies the crew when they're using warp 4 instead of using warp 2 with 300% energy allocation, etc.
- warpState should be used to set/get the warp state, like, if you want to have a mission where players can warp to other sector if they hit sector border at warp 4 (it doesnt matter if engineering tweaked the energy allocation, its just a simple way for players to tell the mission "We want to go to the other sector").
- currentSpeed should be used to get (maybe set too?) the current speed at which object is moving. This could be used for purposes Mike mentioned - to know how soon they will arrive at their destination, or maybe to give players hints, like a tutorial mission that notifies the crew when they're using warp 4 instead of using warp 2 with 300% energy allocation, etc.
I agree with Hissatsu. There are cases where actual speed is useful and there are cases where control setting is useful.
Thanks for adding WarpState. I'll be able to use it in my mission script when it becomes available, which not only makes more sense than what I'm doing, but also greatly simplifies the exposition text the players receive in the form of Comm text and audio transmissions. Right now having to explain the thing with the 100% throttle is cumbersome to word precisely and quickly.
Thanks for adding WarpState. I'll be able to use it in my mission script when it becomes available, which not only makes more sense than what I'm doing, but also greatly simplifies the exposition text the players receive in the form of Comm text and audio transmissions. Right now having to explain the thing with the 100% throttle is cumbersome to word precisely and quickly.
Login below to reply:
