Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
@an egg what error do you get?
https://steamcommunity.com/sharedfiles/filedetails/?id=583272553
popped into this altitude one, was wondering if it is possible to repurpose this one (or a new one) to do a type of "comparison check" I.E have 4 sensors one each corner of a vehicle, upon activation it reads whichever is the highest (altitude) and the others activate until they equal it? (by initiating a piston / hinge etc) aka self leveling? don't know if this is even feasible or how hard to achieve, just an idea. anyhow thanks again for a great mod and lots of fantastic scrips :D
I was also trying to get it to trigger multiple times by putting something like 400;TimerBlock1; 200;TimerBlock2; 75;TimerBlock4; in the argument but with no luck. I’m guessing I need to use multiple program blocks for this?
On a side note I haven’t used a lot of SE scripts, it was a little unclear that I needed to put this in the argument and hit run.
You make a lot of great scripts, they are greatly appreciated. So thank you Isy. =)
altitude;timername
So if you want the script to toggle the timer "Timer Block Dampeners" at 100 meters, run the script with:
100;Timer Block Dampeners
The script is only executed until the condition is met and will be on standby after that.. You can however restart the script with the executed timer and another condition again..
- Changed: Adjusted the LCD screens to the newest API changes.
because the remote control is not being detected after it is spawned and this is problematic when respawning the warhead with a projector system. Any advice to fix this issue?
Version 1.1.0:
- Added: the script now detects remote controls as well. There has been added an option to define the wanted cockpit or remote control in the settings. By default, the first found cockpit or remote control is used.
- Added: the script can now run programmable blocks as well. If you only set the PB name, it will be executed with a blank argument. To specify an argument, add it as the third parameter, e.g.: '100;Programmable Block;pause' - this will execute the PB named 'Programmable Block' at a 100 meters with the action 'pause'.
- Added: trigger by speed. The script can now trigger timer blocks or programmable blocks at a certain speed. The syntax is: 'speed + "ms";blockname', e.g.: '50ms;Timer Block 2' - this will trigger 'Timer Block 2' at 50m/s.
- Changed: the current speed is now shown on the LCD and PB info. Some texts were rearranged, too.
- Internal: the used reference block (cockpit or remote control) is now shown in the PB's custom data.
My use is for drone leaving planet.
I use altitude and speed.
If drone speed is > 9800 do stop the engine
if drone speed is < 9000 start the engine.
This use less fuel.
I combine that with altitude to only start a part of the engine.
altitude < 5000 do start all engine
altitude between 5000 and 15000 start 75% of the engines
altitude between 15000 and 25000 start 50% of the engines
altitude > 25000 start 25% of the engines.
And ofc altitude > 42000 disable thrust override, start all directionnal engine, and start autopilot.
With this I use really less fuel and I don't have issue with the autopilot speed bug.
@Sich: Trigger at a certain speed? What use case do you have in mind?
@Jedd: Thanks ;-)
Im not putting a cockpit on my 2x2 bomb
You could setup two timers, each in a different state between on and off.
You would need a third timer to trigger both and flip their states. It is also more error prone, since the states of the timers can be reversed, and lead to the wrong timer being triggered.
If you have multiple heights you start increasing the amount of timers needed by a significant bit, because each height needs to have its own extra timers to flip states between them, and can quickly become quite complicated. Having the capability to set a timer for when you ascend a height and descend a height allows you to not have to deal with on/off states of timers.