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
https://steamcommunity.com/sharedfiles/filedetails/?id=2831096030
Go check it out!
I'm just trying to decide if it's worth the hassle to update the avionics on a bunch of my old designs?
hopefully they fix it soon. for now, the workaround is to just try and build it so the rotor axis point towards the centre of mass as much as possible.
as for the ship going up, could you publish the blueprint so i can see?
Confirmed, ship going up with only 2 thrusters and rotors too.
also the algorithm that decides how much each naceele should fire in which direction won't account for this. so if you have one nacelle that can fire in a certain direction, and another that can't, any thrust in that direction will be less than the full amount.
it's got *much* simpler setup, better algorithms, and i know it works the the latest version, this one is kina out of date. i just haven't bothered to put it on the workshop yet XD
2. there is a way to make it do this, but its not intended. and its really unstable, which is why i haven't tried to expand on that further.
also can you put 2 rotors on a thruster to have gimbaled thrusters?
about the linear equation:
multiplying it directly would actually work quite well, as long as you have some constant in there
eg:
`thrust *= cos_of_angle * some_constant;
if(thrust > max_thrust) { thrust = max_thrust; }`
the constant should probably be somewhere between 1 and 1.5
constant < 1: the thrust never gets to max
constant > 1: the thrust passes max some time before its exactly in line with desired vector
you might want to put some sort of log function or something, but that would not make much of a perceptible difference, and the script has to run every tick. so keeping it fast is desirable. mind, that hasn't stopped me from putting complex stuff in it thus far!
Its the same as 1wsx10's version but it will keep your thrusters from applying thrust in the wrong direction.
managed to figure out how to check the two angles. On large ships it works wonders! I mad another pull request if you want to take a look.
it lets you have multiple different copies of your code swapped out behind the scenes and keeps backups of everything, if you use it right. (it actually keeps a history of every single edit you make)
its a tool made for programmers, so its extremely advanced when it comes to everything you *can* learn, but like programming languages, you can get by knowing a few basic things.
github is a website made for the feature of git that allows you to have an online 'repository' which multiple people can download, work on, and submit changes.
@1wsx10 I'm not quitte sure how to make a pul request for vector thrust 2 in order to have the program control some of the gyros. Github is confusing to me.
To honest I dont remember. I think it had somthing to do with not having any idea what was wrong and it was easyer to just use the setFromVecOld, however after that I figured out how it worked and went back to using setFromVec insted. So the use of the word old was a mistake on my part.
P.S. im not accusing you of plagiarizing or anything, its just they seem very similar and im looking for scripts that do these kinds of things.
im thinking i should expose that as an option at the top of the file. last time i checked, both have their advantages and disadvantages. (namely, the old one uses a function with asymptotes which causes the rotors to jump when they cross it, and the new one tends to have a little drift when used with complex multigrid ships)
pretty sure I can't just see new branches you make, unless you pushed them. which means you need your own repo for that. the GitHub feature 'fork' makes a copy of someone elses repo that you have write permissions to so that you can work on it. then, if you want them to get your changes, you make a 'pull request'
limiting the thrust: should be fairly easy to do. not sure why i didnt do that, i just kinda had the attitude that the time it took to get to that position wouldn't make much of a difference. plus i only tested it on small ships. i guess it makes more of a difference in space. try this:
nacelle_thrust *= angle_between_actual&desired < 90degrees ? vector.dot(thruster_actual_direction, thruster_desired_direction), 0;
i dont remember what the variable names actually are, and i dont think i exposed thruster_actual_direction, so you would have to get that yourself... but thats fairly simple to get, just make sure its from the objects worldmatrix rather than localmatrix. also make sure its normalized.
You should be able to do that in the 'go' method of the nacelle class
the fix:
thanks, ill take a look in the morning.
Anyways love this script!
That sounds awesome, having the program control some of the gyros is something i was planning on doing actually. at the moment i have assignments and then exams, so i probably wont be able to do it now. but feel free to make a pull request for vector thrust 2 if you get it working.
First : when I start the script, thrusters automatically have the override to the maximum and push me to the sky. How can I change it ? Should they not adpat to the speed and weight ?
Second : Rotor only turns to brake the vessel, but never to go forward
if you like, you can try v2 here https://github.com/1wsx10/VectorThrust2
just know, its still WIP.
1. put %VectorTim in the name of the timer block and only put its actions as run the computer with default argument.
2. place the engines while the script is running.
2.5 use the %standby argument to turn the script off (there is no control module hotkey for it yet)
3. no need to do grouping or angles in the name, the script works that out automatically
4. i recommend using control module (see v1 instructions)
5. i recommend using the monitor functionality (see v1 instructions)
I use it in space for my main engines for travel and have a small set for manoeuvring :)
Also is there an argument you can run the programming block with to return rotors to a defined angle? I haven't tested the script with rotors engines that have armour on the rotor grid yet so I'm just checking as my rotor engine pods will probably be rather large In a build i'm planning.
@The Man Tank yes, that is exactly the problem. ill look into it for version 2
@adamsrealm it does, but not very well. the system is kind of inherintly bad for using in space. because it takes time for the rotors to move, the thrust isn't instantly applied in the correct direction like it is with standard thrusters. this is fine in gravity, because most of the time the rotors don't need to move much since they are almost always trying to counter gravity. in space to stop going backwards and go forwards, the rotors have to go all the way around.
dispite this, people still wanted it in space. so i made it work in space. but i hope you actually try it in gravity. its so much better.
Just to note, you can have multiple thrusters per rotor :)
Hope this helps