NathanKell changed the topic of #RO to: Welcome to the discussion channel for the Realism Overhaul (meta)mod for KSP! Realism Overhaul Main Thread https://goo.gl/wH7Dzb ! RO Spreadsheet http://goo.gl/Oem3g0 ! Code of Conduct http://goo.gl/wOSv2M ! | [15:01] <soundnfury> Straight Eight Stronk (and) RP-0/1 is basically "Space Agency Spreadsheet Simulator" with a rocket-flying minigame
<Pap>
ProjectThoth: I did a lot of research on it back for the science rework
<ProjectThoth>
Pap: What's the biggest problem with the shape?
awang has joined #RO
probus_ has joined #RO
Sarbian has quit [Ping timeout: 207 seconds]
Probus has quit [Ping timeout: 383 seconds]
technicalfool has joined #RO
<Pap>
ProjectThoth: nothing that I came across. It was designed in a capsule shape
<ProjectThoth>
Pap: That's about what I figured. I know there's been efforts to bring the geometry back for manned flights. Just didn't know what was or wasn't a show-stopper.
<Pap>
It was essentially shaped like a nose cone. With a fat bottom
<ProjectThoth>
I'm surprised it hasn't seen a revived interest in light of the current focus on reuse.
<ProjectThoth>
Like, the Kistler K-1 had a flat (spherical segment) heat shield on the nose. I wouldn't imagine that to be relatively drag-free.
<ProjectThoth>
Er, relatively un-draggy.
<ProjectThoth>
AERODYNAMIC
<ProjectThoth>
That's the damn word.
Wetmelon has joined #RO
egg is now known as egg|zzz|egg
probus_ has quit [Read error: Connection reset by peer]
<awang>
\o
<Qboid>
awang: soundnfury left a message for you in #RO [20.02.2018 22:48:34]: "My opinion is that the Tree should be generated from a Python script, so all the 'structured data' that creates it is in the form of Python objects. Kinda like what I've been doing lately with EK, really ;)"
<Pap>
o/
<awang>
soundnfury: Took a look at EK. Think a toml file might look a little less intimidating to newcomers :P
<awang>
But yeah, basically a return to the old yaml tree, in a way?
<awang>
Pap: Does your spreadsheet do anything the old yaml + scripts didn't?
<Pap>
Yes, it is organized. The old Yaml scripts were a mess when you were looking for anything to fix and edit. The nice thing about the spreadsheet is the organization. I can see all parts that unlock in a specific node, or I can see all engines only, or I can see all Apollo parts. I can make changes to them that the old way did not allow.
<Pap>
Why is this way bad?
<Rokker>
Bornholio: Adm. Jim Ellis has been put on the National Space Council
<Rokker>
former stratcom head
Probus has joined #RO
<Rokker>
Probus: ex head of stratcom has been put on the Natl Space Council
<Rokker>
Adm. Jim Ellis
qwertyy__ has joined #RO
qwertyy_ has quit [Ping timeout: 207 seconds]
ferram4 has quit [Read error: Connection reset by peer]
ferram4 has joined #RO
SpecimenSpiff has joined #RO
SpecimenSpiff has quit [Quit: Web client closed]
SirKeplan has quit [Ping timeout: 186 seconds]
stratochief has quit [Remote host closed the connection]
SirKeplan has joined #RO
blowfish has joined #RO
probus_ has joined #RO
Probus has quit [Ping timeout: 207 seconds]
Mike` has quit [Ping timeout: 207 seconds]
Mike` has joined #RO
qwertyy_ has joined #RO
qwertyy__ has quit [Read error: Connection reset by peer]
<ProjectThoth>
Bornholio: I think I have a problem.
<ProjectThoth>
I'm super tempted to buy a box of Mitsubishi 9850s and combine them with Blackwing ferrules.
aradapil_ has quit [Remote host closed the connection]
aradapilot has joined #RO
leudaimon has joined #RO
<Maxsimal>
I don't really understand all the objections or desire to change Pap's spreadsheet. Could someone summarize?
<leudaimon>
I guess the main issue is it not being amenable to integration with github and version tracking in general
<leudaimon>
the final result is, ofc, but still the proccess of generating the cfg is not
ProjectThoth has quit [Quit: +++out of cheese error+++]
<leudaimon>
but the process of translating everything that spreadsheet does into another language should be a pain in the arse
<Maxsimal>
yeah. Seems easier if you could just host a csv on github that your sheet could read, but that might be even more of a PITA if the sheet currently uses a ton of formulas
<leudaimon>
I thought about it too... one intermediary option would be to have the csv with the part info on github, and have the googlesheet import only this sheet and make all the hard work, and output the cfg
<leudaimon>
but I'm not sure google sheets formulas can import a remote file
<leudaimon>
I changed into a csv only the parts sheet
<leudaimon>
the part with actual formulas is still in the google docs
<leudaimon>
I don't think it makes sense to put the formulas in github. That would be better writing the thing the spreadsheet is doing into a python or perl script, but I have no idea how to do that, and I'm happy the more editable part is in github and can be PRed
<Maxsimal>
That's cool. Actually, if you're going to get someone to write script to do the formulas, sheets is already built to do javascript plugins, might be better to start there.
<leudaimon>
oh well.. if someone is willing to try that, I would encourage, but I'm kind of happy with things this way. Let's see Pap's opinion on this, and then I'll make the PR to add the csv in the repository
<Pap>
Leudaimon so if a change is made on the sheet, it automatically updates to the Github?
<leudaimon>
no, the other way round... you change the csv on github, and it automatically updates on the sheet
<Maxsimal>
Or you could add something to export the csv
<leudaimon>
so people can edit the csv locally and make a normal PR, and then the sheet (and the TREE sheet) is updated
<leudaimon>
if it were possible to automate the generation of the cfg file, with no need of copy/pasting it would be mostly done in my opinion
awang has joined #RO
<Pap>
Leudaimon so I can download the CSV and edit it locally on Excel and then push it like a normal PR?
<leudaimon>
exactly ;)
<leudaimon>
you can try that with the files I linked above
<Maxsimal>
Shouldn't everyone have to test it doesn't break Pap's google sheet?
<Maxsimal>
Their changes, I mean
<leudaimon>
what do you mean Maxsimal?
<Pap>
The sheet can't ever really be broken. Google has some very good version control, would just have to revert.
<leudaimon>
and the way this is implemented the sheet can be protected
<leudaimon>
no one ever edits the sheet
<leudaimon>
my only issue is that the TREE sheet -> cfg file thing is a bit messy imo... having to filter and then copy/paste and get rid of the "" is quite prone to error
<awang>
I'm inclined to go with soundnfury's suggestion of turning these into some kind of programmatic entities
<awang>
Skip the spreadsheet altogether
<awang>
Functions are hopefully easier to read/edit than Excel/Google Sheets formulae
<leudaimon>
that would be good... I like the part source being a csv just because it's easier to batch edit the parts, but these two things are not mutually exclusive, it's possible to have a script turning a csv into the cfg
<awang>
The programmer in me objects strongly to the idea of csvs
<awang>
Too easy to break
<leudaimon>
haha, ok... I'm very used to csvs because of my academic background
<awang>
I don't have too much experience with CSVs, so you probably know something that I don't
<awang>
I just got to mess around with them in lab since the TAs wanted to demonstrate how easy they are to break
<Pap>
Awang there is no better option to batch edit parts. Unless someone converts it is a database. That would be best.
<awang>
And I deal with them occasionally at my job, although those are much more straightforward since they're simple tables
<awang>
Pap: When would you want to batch edit parts?
<leudaimon>
well, they are an easy way of turning a spreadsheet into a plain text format, and as Pap put it, unless these things are in a database, having a spreadsheet friendly format has lots of advantages
<awang>
Depends on what functionality the spreadsheet provides, I guess
<awang>
Databases would be nice for querying/editing parts, but doesn't play too well with version control
<awang>
Unless we serialize the database to text format and have scripts read it in first
<awang>
idk if that's considered good or bad
<awang>
Pap: What kinds of things does the spreadsheet do?
<awang>
Mostly query operations, like "find stuff with this and stick those fields into this template for a cfg file"?
<leudaimon>
I think what he means by batch editing is for when adding/changing parts, not what the spreadsheet does to create the cfg
<awang>
Right, I understand that
<awang>
I'm more wondering what kinds of operations the formulae in the spreadsheet carry out
<awang>
Try to get an idea of how they would map to non-spreadsheet stuff
<leudaimon>
yeah, this part of the spreadsheet is witchcraft for me, and I'm quite amazed he managed to do all that in a google sheets instead of some programming language
<awang>
Spreadsheet has a pretty bad bus factor, too
<awang>
Not that I'm expecting that to be a problem, but still
<awang>
Maybe that's just because we don't have enough Excel gurus around
<awang>
Or if there are a lot, I'm not aware of them
<leudaimon>
haha, I had to google bus factor... yeah, I haven't used excel for more than data input in years
<Pap>
Excel is the only place on here that I am the most knowledgeable. The rest of you are programming gurus, I have my Excel. :)
<Pap>
Awang for example, the new tech tree has 4 times as many parts accurately placed compared to RP-0. I was able to achieve this by creating a lookup based on the year. So I mapped the part to be in the Orbital Rocketry family and in the year 1960. There is a formula that looks up that information and returns the proper technology
Dazzyp has quit [Remote host closed the connection]
Daz has joined #RO
<awang>
Pap: Hmmm... That part at least sounds like it can be done programmatically
qwertyy__ has joined #RO
<awang>
idk what a database query would look like
<awang>
Well
<awang>
You're already doing that programmatically
<awang>
Hmmm
qwertyy_ has quit [Ping timeout: 182 seconds]
<leudaimon>
other advantage I see in having a sheet-friendly format is for people that just want to add support for some mod, it's much more straightforward to include, no?
<awang>
Depends
<awang>
Arguably if we pick the right text format it can be converted to both a sheet and database
<awang>
Whichever ends up being more convenient, as long as the text format is treated as canonical
<leudaimon>
sure... csv is just the simplest option for that, but I have no special prefference for it
<awang>
Does Excel have any way to deal with commas inside CSV values?
<awang>
Pretty sure at least some descriptions would contain commas
<leudaimon>
afaik text fields are separated also by " "
<awang>
Hm
<awang>
So as long as no descriptions contain commas, we're good
<awang>
Unless Excel has an escape sequence?
<awang>
s/commas/quotes
<Qboid>
awang meant to say: So as long as no descriptions contain quotes, we're good
<awang>
Do any descriptions contain literal newlines? Or just the \n sequence?
<leudaimon>
no issue, whatever is inside the quotes should be treated literally
<awang>
Hm
<awang>
Other than other quote characters, I assume
<awang>
Interesting
<awang>
Pap: Is there one sheet in that spreadsheet that holds "canonical" values?
<awang>
The PARTS sheet?
<awang>
All other sheets derive from that?
<Pap>
Correct
<awang>
That's good
<leudaimon>
that's why I think putting the parts sheet in github solves half the issue
<awang>
Could probably autogenerate the PART NOT SUPPORTED BY RP-0 OR RO part too
<awang>
And missing entryCost field
<awang>
Pap: Are some of the descriptions copy/pasted from the stock ones?
<Pap>
awang: All of the descriptions were pulled in from the MM cache files that are created when KSP is loaded with Mods
<Pap>
It took a LONG time to build it
<awang>
Ah
<Pap>
PART NOT SUPPORTED BY RP-O and RO are already auto-generated as well
<awang>
Right, because MM does that
<awang>
Didn't realize you imported the parts
<Pap>
No, MM does not do that
<Pap>
the spreadsheet does that
<Pap>
Columns G and H are marked as Boolean columns and are True / False
<leudaimon>
haha, I was just changing the file name for something more straightforward
<leudaimon>
should be working now
<leudaimon>
Pap ^
<Pap>
yep, it's back :)
<leudaimon>
can I PR it? then you just change the parts sheet by =IMPORTDATA("URL") in the first cell, with the URL it will have in the RP-0 repo
Senshi has joined #RO
<Mike`>
i don't know what spawned the discussion, but i noticed two things:
<Mike`>
1) stuff like prices and identicalparts are duplicated between identical parts and thus can get/were/are out of sync
<Mike`>
(eg different models of the same engine have different prices/aren't recognized as identiccal even though they should be)
<Mike`>
2) Nathan and random guys like me commit changes just to github/do PRs for autogenerated files and don't update the sheet
<Mike`>
thus the sheet and the repository get out of sync
<leudaimon>
for 2), that's the point of adding the csv... now the autogenerated file should be generated only upon release, just like it was before... and all changes commited to the csv
<Mike`>
well, i guess to really solve 2) we need a build pipeline. the files should be generated after every commit/change, so you can actually test the changes you made and make sure it works
<leudaimon>
yeah, that's the next step we were discussing... some documentation on how to fill the csv with new/chaged parts is necessary anyway though
<leudaimon>
and you can still create your own cfg from the google sheet
<Mike`>
yes, but people don't do that it seems (i haven't done it either, yet)
<Maxsimal>
Well, as long as the people who can approve PR's all know how to do this, they can make sure the cfg's get built each time they approve a PR with that CSV. They really shouldn't have been approving PR's that only touched cfg's and not the sheet.
<Mike`>
i would also like to hear nathan's opinion about it, what he would prefer to work with - but in any case, as pap's done the most work with all this, his opinion is probably the most valuable. :)
<Pap>
Well, it all depends on the future of RP-0...
<Pap>
If there are going to be any major changes, or any large scale additions of parts from mods, then it needs to be done with a spreadsheet
<taniwha>
Pap: it will be doused in refined kerosene ;)
<Pap>
There is no other way to make sure the parts are accurately edited and are consistent with other parts of a similar nature
<Pap>
lol taniwha
<Pap>
I placed every single part in the new tech tree of RP-1 and the only reason I was able to do that is using a sheet that let me make large changes quickly
<Pap>
RP-0 has VERY few parts actually placed in the tech tree and I think the old system is a big part of the reason why
<taniwha>
I just spent the last hour or so balancing formulas for hematite + rp-1 + lox -> iron + CO2 + water
<taniwha>
(assuming C12H16 for RP-1, and 8.5:1 (mol) for O2:RP-1)
<leudaimon>
Pap, what about the inconsistencies that are appearing for engine/rcs/proc avionics configs in the tree vs. RF GUI? is there any way to fix that? I don't really get what is going on...
<Mike`>
Pap: yeah, makes sense i guess. Do you have an opinion on separating parts and part variations? eg have one table/sheet where you only have one entry per part, lets say engine F-1. and then you have a different table/sheet with actual part variations/models, eg SSTU F-1, Bluedog F-1, which all link to the base table. that wayx, the base table sets all attributes like price, year etc, and the variations/models
<Mike`>
table/sheet can just adjust those if necessary, eg if you have a model representing two engines
<Mike`>
that way you can generate "identicalparts" automatically and also make sure every model has the same price/year/other common attributes as all the other identical parts
<Maxsimal>
Pap: In some ways, using a CSV might help you more - I (personally at least) find excel to still be more useable than google sheets, so you could use whatever editor you wanted to. FWIW. I agree with Mike` that it's you that is the key stakeholder here
<Pap>
Maxsimal I completely agree! I did the vast majority of the work in Excel. Only moved it to Google to allow NK access.
<Pap>
Mike`: that would be useful, it just requires someone to do that work. At the time, it was easier for me to just filter and copy and paste.
<Mike`>
yep, i see
<Pap>
The formulas I wrote for excel were MUCH less complex. Then I rewrote them thinking Google Sheets was best for sharing since NK didn't have Excel.
<leudaimon>
I guess for the cfg writing it's better to have it in a google sheets, so that anyone has access to it and it's getting the csv in real time
<leudaimon>
excel would make it too dependent on SO and stuff
<leudaimon>
OS*
qwertyy_ has joined #RO
<Maxsimal>
Have you tried open office calc? That's also still better than sheets, as far as useability, and I believe it's sufficiently cross platform to have everyone covered.
<awang>
Wonder if making a mother-of-everything something for both RO/RP-0 would be a good idea
<awang>
Autogenerage cfgs for both
<awang>
That way, no duplication of info in either repo
<leudaimon>
awang that would make building a database totally worth it
<awang>
Problem would be that people would open up the repo and be incredibly confused as to why there are no cfgs in sight :P
<awang>
Maybe steal time on someone's Jenkins instance to spit out a build every commit?
<Maxsimal>
Yeah, it's linux/mac/windows. There's an android port but I wouldn't trust it :P
<leudaimon>
Maxsimal I guess the problem with that is that it wouldn't be version controlled, right?
qwertyy__ has quit [Ping timeout: 207 seconds]
<Maxsimal>
leudaimon No you'd still be reading from a CSV that we keep in the repo. OpenOffice will read csv's just fine
<Maxsimal>
And I'm fairly certain, unless Pap did some crazy stuff, that any formulas he wrote for sheets/excel will port to OpenOffice - it may do so automatically even, openoffice can read most excel sheets.
<leudaimon>
yeah yeah, but all the magic the current google spreadsheet does, it should be in hosted somewhere... and having it as a .ods file that people have locally could induce lots of error propagation
<Maxsimal>
True. Why not just put the ODS file on github too? It can handle binaries surely? CSV is diff-able, so that's better.
<Mike`>
leudaimon: the data should probably be easily editable (with as little effort as possible), so that probably rules out a database? that's why i initially proposed something like yaml files.
<Mike`>
if you mean an RDBMS with "database"
<leudaimon>
well, ease in editing is the whole point of having the csv file... it makes both manual and batch editing easy
<leudaimon>
it's not so easily readable as plain text, but any spreadsheet application can open it
<Mike`>
yeah. I don't have any installed though. :)
<Maxsimal>
Well it's up on google sheets so unless you don't have a browser installed, you still have no excuse :P
<Mike`>
so i think it would be cool if it's editable in a good old plain text editor. True, csv somewhat applies to this aswell.
<leudaimon>
man, anything can open csv
<Mike`>
but it's lees cool to edit a huge csv ina texteditor i guess. :)
<Maxsimal>
More cool than editting a DB in a text editor :P
<Mike`>
i do see the need for csv/sheets for large edits and rebalances though, true.
awang has quit [Ping timeout: 207 seconds]
schnobs has joined #RO
<leudaimon>
Pap your sheet is protected, so I couldn't test putting the csv import there
<Pap>
leudaimon: Yeah, I protected all the formulas once NK and I gave others access
<leudaimon>
sure... I was just curious if it would work
<leudaimon>
and having the csv makes it possible to have the whole thing protected
awang has joined #RO
mkalte has joined #RO
Hypergolic_Skunk has joined #RO
leudaimon has quit [Ping timeout: 186 seconds]
leudaimon has joined #RO
<Probus>
Sure do love that new Decoupler Shroud mod. Very nice.
<schnobs>
Could I have a procedural cargo bay please? kthxbye
<Probus>
How about stackable SRB segments.
<schnobs>
Yeah, talking bout which, I seem to lack procSRBs.
<schnobs>
But it's the cargobay which I'd really need. That, and a conical cockpit of, say, ten crew.
<schnobs>
Not suitable for a cockpit, for obvious reasons.
<Probus>
That looks really cool
<schnobs>
Pretty huge, though.
<Probus>
That looks like Werner VonBraun's space plane.
<schnobs>
I just tried to assemble something along these lines that can fit a double Atlas, in RP-0.
<Probus>
MRS has some good cargo bays.
leudaimon has quit [Read error: Connection reset by peer]
<schnobs>
MRS?
<Pap>
schnobs: DId you burst through the RP-1 early game limitations now?
<Pap>
Modular Rocket Systems
leudaimon has joined #RO
<schnobs>
Pap: nah, the pic was from a very, very custom install I made a few months ago.
<Probus>
MRS has a lot of cool parts schnobs
<schnobs>
Pap: Still, I'd like to get back to it, in a proper RP-0.
<schnobs>
In principle, it should be possible to skip capsules and do the spaceplanes->station->planets thing.
<schnobs>
One definitely needs some lunar science to unlock it, but otherwise it should work out.
<awang>
How awkward is it to edit CSVs with a plain text editor once you start getting tons of columns?
<awang>
Reason I was thinking about TOML or something like that was because that's much more readable than a CSV
<awang>
Although you have to repeat the key names, which is probably problematic
<schnobs>
awang: with tabs, bearable. Not cool, but bearable.
<awang>
Database would be nice if we can serialize it to a format that is also easy to edit by hand
<schnobs>
Pap: that's also teh reason I asked about getting new parts into RP-0
<awang>
schnobs: And tabs are probably not going to be in any KSP stuff. Interesting idea
<Mike`>
awang: we could use something like toml if we add a csv im/exporter :D
Maxsimal has quit [Quit: Web client closed]
<awang>
Mike`: We should probably just stick with one thing
<awang>
I'm leaning towards something table-ish, to avoid repeating keys/etc.
<awang>
TSV instead of CSV would probably be easier
<awang>
No need to worry about quotes/escaping
<awang>
Hopefully
<awang>
Only annoyance is that editing it in anything other than a spreadsheet program will be annoying
<Mike`>
indeed
<awang>
Especially plain text editors
<awang>
Wonder if Notepad even supports files that big
<Mike`>
that's the advantage something like toml offers, no? the question is how feasible csv im/export is. I assume 90+% of changes would be small and thus a plain text editor the tool of choice, for example, fixing typos or missing tags
<Mike`>
i guess you only really need excel-alikes when doing larger scale changes like rebalancing etc
<awang>
What I'm somewhat concerned about with TOML is that the key values have to be repeated over and over
<awang>
Whereas in a table they only have to be specified once
<awang>
This is one of thsoe cases where repetition may be useful
<awang>
CSV im/export is probably pretty easy
<awang>
Corporate world will probably lynch the Office team if they broke CSV imports
<Mike`>
i mean we'd need ex/import the toml/yaml to csv
<awang>
Or just keep everything in CSV/TSV in the first place
<Pap>
Why the attempt to remove all spreadsheet editing?
<awang>
Pap: It's not?
<awang>
Or at least that's not my intention
<awang>
idk about others
<awang>
I'm just wondering what the best version controllable format is
<awang>
And how that could/would ultimately be edited/read
<awang>
And what formats would make editing/reading easier/harder
<Mike`>
well, i probably would prefer a non sheet format like yaml/toml for small fixes, no need to use the (slow) google docs, no need to use something big like excel. Then again, there might be small open source sheet progs out there so those might be an option aswell, true
<awang>
Wonder if you can write a git hook that enforces that either the csv/tsv and yaml/toml change in a commit, but not both
<awang>
And automatically update the other when committing
<awang>
That would be a nice compromise
<Mike`>
hehe, i thought about the same
<awang>
Advantages of both, and don't have to worry about synchronization problems
<awang>
Trying to edit both in the same commit? Stop. Small commits!
<awang>
Probably should write something that performs a sanity check on the data, too, to ensure that they're in sync
<Pap>
Mike`: I think the issue is that the file is so huge as well
<Mike`>
true
leudaimon is now known as leudaimon|away
<awang>
Pap: How many MB is the spreadsheet?
<Pap>
The sheer amount of parts that are part of the RP-0 suite is massive
<awang>
Or csv
<Pap>
I actually do not know
<awang>
Just the parts sheet is 1.2MB
<awang>
Not too bad
<awang>
Full spreadsheet is 2.7MB
<awang>
Not bad at all
<schnobs>
So. Erm. If I may bring up spaceplanery again?
<schnobs>
Currently unlocked the first nodes where it seems possible at all. First problem, beast becomes nose-heavy.
<schnobs>
Nearly all the dry massis in the cockpit and crew container; I find nothing reasonable to put in the rear.
<schnobs>
Does someone have pictures of workable things?
wb99999999 has joined #RO
schnobs has quit [Ping timeout: 182 seconds]
Hypergolic_Skunk has quit [Quit: Connection closed for inactivity]
probus_ has joined #RO
Probus has quit [Ping timeout: 383 seconds]
Senshi has quit [Quit: Leaving.]
leudaimon|away is now known as leudaimon
stratochief has joined #RO
leudaimon is now known as leudaimon|ZzZz
probus_ is now known as Probus
<Probus>
Gotta love Oklahoma... Everything is ice. Roads, trees, cars
<Mike`>
awang, which rd 0105 (model) are you using?
<awang>
Mike`: Like what part pack?
<Mike`>
yea
<awang>
Uh
<awang>
Looks like RealEngines
<awang>
Based on the .craft file
<awang>
Yeah, looks like it
<Mike`>
hm
<Mike`>
i use realengines too, yet it looks like that engines gimbaling is kind of broken here
<awang>
Hmmm
<Mike`>
the stock/ro rd0105 gimbals fine however
<awang>
Pretty sure gimbal sort of works for me
<awang>
It's ridiculously weak though
<awang>
Hm
<awang>
Looks like I should have a bunch of other RD-0105s
<awang>
Don't remember if I've seen them
<Mike`>
well
<awang>
Tantares, RealEngines, stock, RaiderNick
<awang>
Pretty sure I have all those installed
<Mike`>
i do have ridiculously weak control, but i don't see the engine moving at all
<awang>
Is that normal?
<Mike`>
maybe its also ridiculously tiny movement
<Mike`>
anyway
<awang>
I wasn't sure if the weak control was due to a small gimbal or low thrust
<awang>
Config says 6 degrees
<awang>
Which is a pretty decent amount
<Mike`>
something is wrong i guess, because the rd0105 is supposed to have 6° of gimbal according to the config=?
<awang>
I think
<Mike`>
yes
<Raidernick>
awang it has low thrust and 6 degrees on a thrust that small will give almost no control
<Raidernick>
just how it is
<Mike`>
the stock/ro control/gimbaling is *much* stronger
<awang>
Well
<Mike`>
Raidernick, no, thr stock model has *much* more control
<awang>
My .craft file says gimbalLock = False and gimbalActive = False
<Raidernick>
do the configs have the same thrust and gimbals?
<awang>
Does it default to off, maybe?
<Mike`>
Raidernick, yes
<Mike`>
same thrust, 6° gimbal
<Mike`>
though the realengines mod has vernier thrusters
<Mike`>
maybe the gimbal is applied to the verniers or something
<Raidernick>
do the non stock ones use more than one gimbal transform?
<Raidernick>
yes that's it
<Raidernick>
it has multiple transforms
<Raidernick>
when that happens the game doesn't always handle it well
<Mike`>
hm :|
<Raidernick>
it's usually best to separate every part of an engine with a transform rather than conbime them otherwise you end up with weird control issues
<Raidernick>
combine*
<Mike`>
with separate you mean separate ksp part?
<Raidernick>
yes
<Mike`>
okay
<Raidernick>
what i usually do is slice off any engine bells that have separate gimbals
<Raidernick>
and you'd reattach them to the parent part in the editor
<Raidernick>
solves that issue
<Mike`>
yeah
<Raidernick>
some mod makers just combine everything to one part which is ok for stock but breaks in Ro often
<Mike`>
hm..well, i hope we can fix it somehow in the config, should take a look (or check if it actually works in stock)
<Mike`>
question is also how the real rd0105 worked with the verniers and gimbaling etc
<awang>
Raidernick: So should the @MODULE[ModuleGimbal] be @MODULE[ModuleGimbal],* in the global config?
<awang>
Or something like that?
<awang>
Or Mike's question
<awang>
So should the verniers have a different gimbal range/direction/etc. than the main bell
<awang>
I'd guess verniers would be roll only, main engine for pitch/yaw?
<Mike`>
lamont, awang, btw, i used a different rocket (2 stage, lower twr/quite a bit longer time to orbit) and PEG nailed my 97°inc 420x700km orbit with it fine.
<awang>
Is there that fine-grained control of gimbals available?
<awang>
Mike`: That's why you ran into the RD-0105 issues? :P
<Raidernick>
just so i'm not stupid here, that engine was used on the vostok/luna upper stage right
<Raidernick>
so i'm not confusing it with something else
<Mike`>
yep, new one uses rd0105 :S
<Raidernick>
ok yeah those verniers didn't actually move at all
<awang>
Raidernick: The description says so. I don't know for sure
<Mike`>
yeah i think so - are non moving verniers actually useful?
<Raidernick>
they used turbine exhaust ported only when it needed to move
<Mike`>
ah okay
<Raidernick>
so normally they'd be off
<Raidernick>
then if you needed to adjust your heading that side would fire for x seconds
<Mike`>
interesting
<Raidernick>
they don't actually move
<Raidernick>
but in ksp that's impossible to do
<awang>
Mike`: Yeah, I ended up having to lob my rocket way higher since there wasn't enough control to deal with the aerodynamic forces with the trajectory I was using with the X-248
<Raidernick>
basically it's like RCS
<awang>
Oh jeez
<Raidernick>
or how rcs works in KSP
<awang>
Wait, so what took care of roll?
<awang>
Regular RCS?
<Raidernick>
that stage couldn't control the roll
<awang>
Oh
<Raidernick>
as far as i know the block l stage used it's fuel for roll control
<Raidernick>
it had roll jets on the skirt
<Raidernick>
block L*
<Raidernick>
when the vostok was used i have no fricking clue what they used
<Raidernick>
lol
<Raidernick>
the vostok jets would've been hidden inside the block e stage
<Mike`>
Raidernick, and i assume the main engine didn't have any gimbaling at all then? hmm...
<Raidernick>
no it didn't gimbal
<Mike`>
i see, so the model is correct
<Raidernick>
actually hold on
<Raidernick>
ok yeah no the block E did have roll jets
<Raidernick>
it was the same exhaust the attiude jets used
<Raidernick>
and they are right on the sides of the attiude nozzles
<Raidernick>
there is probably some valve in there to switch the roll on and close the attiude off
<awang>
Huh
<awang>
Interesting design
<awang>
So the RO config is wrong?
<awang>
Or maybe we should limit the @MODULE[ModuleGimbal] to just the side transforms
<awang>
(assuming they exist)
<awang>
Raidernick: I just realized, how would block E control both pitch and yaw?
<awang>
Fix one, use the roll to turn 90 degrees, fix the other?
<Raidernick>
awang as far as i know the thrusters were always running
<awang>
Since there are only 2 verniers
<Raidernick>
and if it needed to turn, it would shut one off
<Raidernick>
or vary the thrust
<Raidernick>
also there are supposed to be 4
<awang>
Right, but that gives you either yaw or pitch control, right?
<awang>
Oh
<Raidernick>
at least on the block e there are 4
<awang>
Ninja'd
<awang>
So the RealEngines model is wrong
<awang>
...Unless RealEngines just doesn't include the model
<awang>
Well, looks like the RD-0105 isn't quite as good as I thought it should be :(
<Mike`>
hm...so... as that rd0105 isn't the real one anyway, i might try another one... can you recommend one, awang, tantares or rn? :D
<awang>
Something to keep in mind for my next playthrough, if I ever get to that
<awang>
Mike`: idk, I don't even remember seeing other ones
<awang>
idk if they load for me
<awang>
I'll check
<awang>
But RaiderNick makes a good case for his
<awang>
Namely that the separate gimbals should be a bit more faithful to the original
<awang>
Or at least that's how I interpret it
<Raidernick>
don't use mine
<Mike`>
:D
<Raidernick>
it's only useful for historical reenactments
<Raidernick>
useless for "lego" play types
<Mike`>
ah okay :s
<Mike`>
ah well, i might have to give that stage rcs control...or reconsider my design :s
<awang>
Raidernick: Useless how?
qwertyy_ has quit [Ping timeout: 207 seconds]
<wb99999999>
his part packs have their own system
<wb99999999>
many parts are only functional when attached to specific part in the same pack
<wb99999999>
many are made for the sole purpose of recreating historical craft
<awang>
But if they work when put together, isn't that fine?
<awang>
Or at least the way I'm thinking of it
<awang>
engine + verniers attached to engine = standalone engine?
<awang>
Or are there specific tanks/etc. that they only work with?
<awang>
Mike`: That 316s isp is just too tempting to ignore :(
<awang>
I got RCS on my stage anyways, to deal with deorbiting
<awang>
Since apparently my computer gets even slower with Principia once I get more than a few things orbiting
<awang>
Can't wait for orbital decay to become a thing
<soundnfury>
<Pap> There is no other way [than a spreadsheet] to make sure the parts are accurately edited and are consistent with other parts of a similar nature <-- this is absolutely not true.
<awang>
So I can leave the stage for a few days and not bother with the weight/part count of RCS
<soundnfury>
any kind of "master" format would do, it does not need to be a spreadsheet.