Guswut

Sorry about that, I restored from a backup that was out of date and I didn't notice that it had wiped out the KSP directory. I've also gone ahead and uploaded the patch to SpaceDock as it doesn't look like it'll be integrated into the main version anytime soon (and I don't want to take over guardianship of this mod nor fork a copy (but if anyone else wants to use my code for either of those, feel free of course!)). I'll update my older posts to reflect the SpaceDock link as well. Huge thanks to @AloE for shooting me a PM to bring this to my attention!

I can confirm I'm getting the same issue, and when I get a chance to get KSP loaded I'll grab a copy of the error message. Edit (2016-08-20--12-46-01): The error is as follows: [EXC 12:42:42.963] FileNotFoundException: Could not load file or assembly 'DistantObject, Version=1.5.4.21166, Culture=neutral, PublicKeyToken=null' or one of its dependencies. It doesn't happen when CactEye is not installed. ~~~ Besides that, what else is required to add new planetary bodies besides the ScienceDefs.CFG file? Specifically, I've created an RSS and RSSExpanded set of science definitions that use the same structure as the standard science definitions with names changes and the description grabbed from the RSS/RSSExpanded body files. What else am I missing, as I'm surely missing some part somewhere but I didn't see anything else referencing OPM (which I assumed was a relatively simple way to find the compatibility patches required to get it to work with a modified solar system). Thanks! Edit Log: Edit 2016-08-20--12-47-02: Added exact error message from log spam.

I'm getting a strange bug which is causing my re-entering unmanned ship to stop de-accelerating at a seemingly random point (I'm using RSS, so orbital velocity is around 8000m/s at the edge of the atmosphere which is at 140km; on a normal re-enter it hits at around 6500m/s, but I've cheated to stop and drop down and then it hit around 3500m/s, and when I've cheated and floated down at around 200m/s it happened around 10,000m from the ground). My KER window disappears, all of my resources go to "0/0", I cannot control anything (I'm using RemoteTech, so this would be normal but without it the same thing happens). The ship continues to stay at the same speed (no more drag, gravity doesn't appear to affect it, etc) until it either smashes into the ground on the current vector or it flies off into interstellar space. When this happens, my debug console overflows with the following: [EXC 18:59:05.554] ArgumentOutOfRangeException: Argument is out of range. Parameter name: index System.Collections.Generic.List`1[PartThermalData].get_Item (Int32 index) FlightIntegrator.UpdateOcclusionConvection () FlightIntegrator.UpdateOcclusion (Boolean all) ModularFI.ModularFlightIntegrator.UpdateOcclusion (Boolean all) FlightIntegrator.Update () A full copy of my latest log can be found here: http://guswut.com/KSP/KSP.log.2016-08-19--19-58-13.zip It's around 40MB uncompressed. Now, the reason that I'm posting here instead of the ModularFlightIntegrator mod is that when I remove Orbital Decay the issue goes away completely. I'm using version 1.5.0 which I just checked and is out of date as of today. Also I didn't have the ORBIT_DRIFT_COMPENSATION setting set to False. After changing that setting and upgrading to the latest version, the issue persists without any change from what I can see. A screenshot of what things look like is here: http://imgur.com/a/z3No5 I've got way too many mods, so there may be another conflict at fault going on here besides ModularFlightIntegrator and OrbitalDecay, but this is a start after all. So is there something obvious that I'm missing (besides the changing of that setting and making sure I'm on the latest version), or should I start testing a stripped down build to make sure it's ModularFlightIntergrator (and FAR which is why I've got it installed, maybe also DeadlyReentry if I recall). Thank you! Post script (2016-08-19--23-44-58): And after another round of testing, it may in fact not be related to Orbital Decay. I'll sleep on it and try it again in the morning to see if I can narrow it down. Sorry, and thanks! Post script (2016-08-20--14-12-05): Yeah, Orbital Decay isn't the issue. Sorry about that, and back to the drawing board for me. Thanks! Edit (2016-08-19--23-44-58): Added post script. Edit (2016-08-20--14-12-05): Added update to my last update.

I can confirm that I no longer am getting the errors I was getting previous (see below) which appear to have been similar/identical to the other errors people had. [LOG 07:48:33.795] [ModuleManager] Applying node SMURFF/SMURFF/@PART[*]:HAS[@RESOURCE[Ore],~SMURFFExclude[*rue]]:FOR[zzz_SMURFF] to ProceduralParts/Parts/Tanks/TankOre/proceduralTankOre [LOG 07:48:33.797] [ModuleManager] Cannot find key maxAmount in RESOURCE [LOG 07:48:33.798] [ModuleManager] Error - Cannot parse variable search when replacing (%) key resourcemass = #$RESOURCE[Ore]/maxAmount$ [LOG 07:48:33.818] [ModuleManager] Cannot find key resourcemass in PART [LOG 07:48:33.820] [ModuleManager] Error - Cannot parse variable search when editing key mass = #$resourcemass$ [LOG 07:48:33.836] [ModuleManager] Cannot find key resourcemass in PART [LOG 07:48:33.837] [ModuleManager] Error - Cannot parse variable search when editing key reservedmass = #$resourcemass$ Thanks!

Understood. I went ahead and re-ran the data on those moons, as well as Triton. I updated the orbital data, and tried to make a pull request for the updates. I've never used github before so I doubt I did it correctly. If I did in fact screw it up, I can toss up the files here, or I can try again if I know what went wrong. Thanks!

@NathanKell, are the orbital colors for the following bodies left unset (all values at 1.0) by design, or are they not configured by design (body name (parent body for reference))?: Moon (Earth) Dione (Saturn) Enceladus (Saturn) Iapetus (Saturn) Mimas (Saturn) Rhea (Saturn) Tethys (Saturn) Triton (Neptune) In the case of the Moon, I assume this is the case as the values appeared to be identical to the other bodies, but in the case of the latter I assume they were just not configured by whomever set up these bodies. I've put together some orbital colors using an estimation of the planets via a screenshot half in the light. I'm not entirely sure how to use GitHub and set up a pull request, so before I go through and figure that out I'd like to see if these changes would be wanted. Also, does RSS have a DOE (Distant Object Enhancement) file for compatibility? There was one in the RSS-Expansion mod, but I cannot find one in the RealSolarSystem folder. Thanks!

Alrighty, hopefully the last update until @ImkSushi comes back. The fourth version of this unofficial patch has orbital line colors and DOE (Distant Object Enhancement) colors for all objects (not just solar satellites). Enjoy! SpaceDock: https://spacedock.info/mod/1276/Real Solar System Expanded - Unofficial Patch v2016-08-06--18-59-37 Direct link (just in case): http://guswut.com/KSP/RSSExpansion_UnofficialPatch_2016-08-06--18-59-37.zip Also, check out this post if you need further versions, more rambling, etc:

What I did was change the value of the "color" variable under the "orbit" module in each file. As an example: @Kopernicus:AFTER[RealSolarSystem] { Body { name = Ida flightGlobalsIndex = 31 Template { name = Eeloo } Orbit { // Target body name: Ida (589) // Center body name: Sun (10) // Center-site name: BODY CENTER referenceBody = Sun semiMajorAxis = 427904743543.44635 eccentricity = 0.046474075527804304 inclination = 24.39428219340693 meanAnomalyAtEpochD = 129.3100272836345 longitudeOfAscendingNode = 358.4223635049695 argumentOfPeriapsis = 75.014701982506807 color = 1.0, 1.0, 1.0, 1.0 } [...TRUNCATED!...] That's Ida's CFG file, with the default color of the orbit. The colors are in (what I'm likely erroneously calling) unidigit decimal format, meaning that "1.0" is equivalent to "255" in standard decimal color format, of "FF" in standard hexadecimal color format. It also uses a fourth unit to deal with alpha, but when I tried messing around with that I didn't have much like (I likely forgot to clear a cache or something though). The Ida that I'm using (and is now included in download link number three here: http://forum.kerbalspaceprogram.com/index.php?/topic/139492-112-real-solar-system-expanded-0140/&do=findComment&comment=2698947) is as follows: @Kopernicus:AFTER[RealSolarSystem] { Body { name = Ida flightGlobalsIndex = 31 Template { name = Eeloo } Orbit { // Target body name: Ida (589) // Center body name: Sun (10) // Center-site name: BODY CENTER referenceBody = Sun semiMajorAxis = 427904743543.44635 eccentricity = 0.046474075527804304 inclination = 24.39428219340693 meanAnomalyAtEpochD = 129.3100272836345 longitudeOfAscendingNode = 358.4223635049695 argumentOfPeriapsis = 75.014701982506807 color = 0.396078, 0.396078, 0.396078, 1.0 } [...TRUNCATED!...] I got the values by taking screenshots of all of the solar-orbiting bodies (you'll notice that none of the satellites are done. I, too, just noticed that, D'OH!) and took a rough sampling of their colors and then converted the hexadecimal color into unidigit decimal. I've included my changed version in the above post, so if you want to use something that is (mostly) completed (and will be finished shortly now that I recall those satellites!) I'd say give it a whirl.

Did you remove the "000-RSSPatches.cfg" file, or rename it to something like "000-RSSPatches.cfg.DISABLED"? That'd be my guess as to what is happening as that file introduces a bunch of inclination changes to the stock-RSS planets. The real tip-off is that your camera appears to be working as if you were using the stock game, instead of tilted to the side from the inclination modifications. This is what it should look like without that file (please disregard the coloring of the orbits of the bodies, as I messed with that for my own personal usage): This is a roughly side-on view (notice the camera is innately tilted, because of the inclination change for the whole solar system because Earth is a wee bit tipsy as it were): Please double check that you've disabled or deleted the "000-RSSPatches.cfg" file (the simplest thing to do is to remove the entire contents of the "RSSExpansion" folder and replace it with my upload (which is going to run out shortly, bother!)).

No offense taken at all! Tell me if you see anything that looks out of place as far as the orbits go. Thanks!

RSSExpansion Unofficial Patch v2016-08-06--18-59-37 can be found at SpaceDock: https://spacedock.info/mod/1276/Real Solar System Expanded - Unofficial Patch v2016-08-06--18-59-37 The rest of the below post will be kept for posterity's sake, in case someone really wants one of the in-between versions, or if SpaceDock ever dies the way whatever the name of that one site that used to be the go-to KSP mod site but ended up dying is called. Thanks! (See lower in the post for details on a second download with adds all of the bodies except for "Z1-Dactyl" and "Z1-Vanth", although I'm not entirely sure about the Pluto system). Alright, I've tossed together the following updated .CFG files: 001-Vesta.cfg 002-Juno.cfg 003-Ceres.cfg 004-Pallas.cfg 005-Ida.cfg 006-67P.cfg 007-Lutetia.cfg 008-Orcus.cfg 009-Makemake.cfg 010-Chariklo.cfg 011-Halley.cfg 012 - Sedna.cfg And I've renamed "012 - Sedna.cfg" to "012-Sedna.cfg" to keep with file convention. The changes reflect what I hope is an accurate input on the orbital characteristics based upon the data from the RSS mod. This removes the changes made in "000-RSSPatches.cfg" (and the entire file) to get the solar system angled properly again to simulate the tilt of Earth. Additionally, the "000-RSSPatches.cfg" file contained a patch for the existing body Iapetus, so I've split this out into a subfolder "RSSPatches" and added a "603-Iapetus.cfg" file in their for handling this change. The change is a vertex height map from what I can see. I have not patched (and they're not included as such) any bodies that orbit a body that isn't the Sun. I'm working on figuring out how to make JPL Horizons give me accurate data from that, and will toss those up as soon as I get them. Download #2 now includes all bodies except for "Z1-Dactyl" and "Z1-Vanth", although for some reason I'm getting an inclination around 90° for most of the moons which seems incorrect to me. From what I can see, this may just be how it is, but I'm not entirely sure: If anyone can comment on if this is accurate, please do! Here's a picture if that helps: http://imgur.com/nKYYMQy http://guswut.com/KSP/ for all versions, license, usage, and actually that's already on this page. Download #1 (just solar orbiting bodies): http://guswut.com/KSP/RSSExpansion_UnofficialPatch_2016-07-30--14-53-47.zip Download #2 (all bodies except for "Z1-Dactyl" and "Z1-Vanth" (I still cannot find them in JPL Horizons)): http://guswut.com/KSP/RSSExpansion_UnofficialPatch_2016-07-31--14-47-10.zip Download #3 (now all solar orbiting bodies (I did this before I did the satellites, but they'll be done shortly) have an orbit color which I made via a half-in-the-sun screenshot of each body, and then a bit of estimating what'll look alright in map view, as well as an updated DOE (Distant Object Enhancement) color based upon the orbital color): http://guswut.com/KSP/RSSExpansion_UnofficialPatch_2016-08-06--10-33-21.zip Download #4 (now ALL bodies have an orbit color which I made via a half-in-the-sun screenshot of each body, and then a bit of estimating what'll look alright in map view, as well as an updated DOE (Distant Object Enhancement) color based upon the orbital color): http://guswut.com/KSP/RSSExpansion_UnofficialPatch_2016-08-06--18-59-37.zip Usage: Replace the RSSExpansion folder in your GameData with the contents of that ZIP file. Make SURE that you've removed the "000-RSSPatches.cfg" or you'll end up with strange inclinations! License: Credits: imkSushi for doing something pozine for making the mod in the first place NathanKell for Real Solar System ThomasP for Kopernicus (sorry about the axial tilt discussion) Sigma88 for SigmaBinary the ksp devs for KSP anyone who downloaded the mod for supporting the mod This hot patch, that will be gone in a week, is licensed by the Creative Commons Attribution 4.0 International - http://creativecommons.org/licenses/by/4.0/ I have made changes to the original work provided by the above authors. Enjoy, and hopefully I'll figure out the satellite mechanics soon! Edit (2016-07-31--11-08-01): "the the", really now? This is what I get for sleeping on this post! Edit (2016-07-31--14-36-34): Added additional bodies (everything except for "Z1-Dactyl" and "Z1-Vanth"), may have made the Pluto system off somehow (not sure how), added Download#2 to the download location. Edit (2016-08-06--10-29-06): Moving downloads to my personal domain so the downloads don't disappear in a few days. Edit (2016-08-06--10-37-48): Added third download for orbit-color-changed files as well, in case people want 'em too. Edit (2016-08-06--10-46-02): Updating third link to make evident of my failures as a person that remembers to color within the lines. Edit (2016-08-06--19-03-44): Adding fourth download link now that coloring within the lines is a completed skill. Also, I forgot that I updated the DOE (Distant Object Enhancement) values in both download three and four, so those are noted as updated. Edit (2017-03-25--08-02-02): After the web server that my personal site sits on took a flying SRB-assisted launch at a rolling ROUND-8 toroidal fuel tank, which is to say I forgot about it and Bad Things™ happened, I restored an older backup that didn't have the KSP directory. I've since re-created the directory, reuploaded the files, and I've also added a SpaceDock upload because it's much more likely to not have an issue compared to my page. The above links have been modified to put SpaceDock as the primary and my site as the secondary/backup.

Yeah, I ended up noticing that I wasn't using the solar system barycenter right around the end when I was doing some manual checks against the data. If I can get the correct date/time, I'll re-run all of the solar satellites (the only I've got working thus far, d'oh!) using 500@0... 500@10 I just checked and the RSS readme lists the following: Which I'd assume means "January 1st, 1950" (2433282.4235) is the correct time to go with. I'll toss together some new values under that assumption, at least for the items I'm able to get correct. And I'll likely hit my head against the problem over the weekend to try and get the other bodies resolved if possible, as I'm surely just misunderstanding the data and application of it in this case. Thanks! EDIT (2016-07-28--20-19-19): Found it! And by "it", I mean "the correct/exact date": This was at the top of the "Kerbal Space Program\GameData\RealSolarSystem\RSSKopernicusSettings.cfg" file. Which is where it should be, and where I should have looked first! Now onwards to glorious additional orbital bodies! EDIT (2016-07-30--12-13-21): If I had only decided to read the next paragraph, I'd have seen this: Which gives us a date of 2433282.4235 which is the Julian Day Number for CE 1949 December 31 22:09:50.4 UT. And in testing and finding that my numbers are rather off with Jupiter I dug into Jupiter.cfg and found this (which I certainly have read before, but entirely didn't consider as an important data point, most likely because my ears are separated by wax alone): Using 500@10 as the center body, and the correct date, I'm getting a semi major axis delta of -5.10849000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001258, which I'm not sure how to correct so I'll run with that. I should have new configs for the sun orbiting bodies shortly.

It took me a bit to figure out exactly how to get the frame set up properly (I hope!). For anyone that might need to know how to do the same sometime in the future (to note, I'm only mostly kinda sure that this is correct, so hopefully someone that knows what the values should be can confirm the accuracy of this): Go to http://ssd.jpl.nasa.gov/horizons.cgi Change the "Ephemeris Type" field to "Orbital Elements" Change the "Target Body" field to which ever body you want) Depending on the body, you may need to select one of a few from a list, or you may need to find the correct designation for the body. The "Center" field defaults to "Sun (body center)", which should work (unless we're using "Solar System Barycenter (SSB)" for RSS, in which case I'll have to go back and update these values (to note, we are not using the barycenter, so stick with the body center)). Change "Time Span" to use "switch to discrete-times form", and then enter a time stamp of "2433282.4235" This is the value designated in RealSolarSystem's "RSSKopernicusSettings.cfg" file. Change the "Table Settings" to "output units" in "km & km/s", "reference plane" to "Earth mean equator and equinox of reference epoch", and "reference system" to "FK4/B1950.0". "CSV format" can also be helpful if you're automating the process as it puts each data point on a single line. Use "$$SOE" and "$$EOE" as your delimiters. The reference system is designated in the RealSolarSystem config "RSSKopernicusSettings.cfg". You can change "Display/Output" to "plain text" if you want to use an HTTP GET to grab the data. It's cleaner than the default "formatted HTML" in that manner, but you may want to stick with the default if you want to be able to more easily see the naked data. Click "Generate Ephemeris", and you'll be brought to a page with the data. Look for "$$SOE" and "$$EOE" (ctrl-f/cmd-f is your friend) to find your data. Below the table is a key giving you details on which item is which. If you click the "show "batch-file" data" link below the "Generate Ephemeris" button, you'll get an output something like this: !$$SOF COMMAND= '243;' CENTER= '500@10' MAKE_EPHEM= 'YES' TABLE_TYPE= 'ELEMENTS' TLIST='2433282.4235' OUT_UNITS= 'KM-S' REF_PLANE= 'FRAME' REF_SYSTEM= 'B1950' TP_TYPE= 'ABSOLUTE' ELEM_LABELS= 'YES' CSV_FORMAT= 'YES' OBJ_DATA= 'YES' !$$EOF This can be formatted into a batch command by removing the "!$$SOF" and "!SSEOF" lines, putting an ampersand ("&") at the end of each line, removing all of the newlines (line breaks, put everything onto a single line instead of a bunch of lines), and finally add "http://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&" to the front of the line. You'll end up with a link like this: http://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&COMMAND= '243;'&CENTER= '500@10'&MAKE_EPHEM= 'YES'&TABLE_TYPE= 'ELEMENTS'&TLIST='2433282.4235'&OUT_UNITS= 'KM-S'&REF_PLANE= 'FRAME'&REF_SYSTEM= 'B1950'&TP_TYPE= 'ABSOLUTE'&ELEM_LABELS= 'YES'&CSV_FORMAT= 'YES'&OBJ_DATA= 'YES' Any irregular characters will get converted to the proper HTML characters (at least during my test in Chrome on Windows, your mileage may vary), which should get you a link like this:http://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&COMMAND=%20%27243;%27&CENTER=%20%27500@10%27&MAKE_EPHEM=%20%27YES%27&TABLE_TYPE=%20%27ELEMENTS%27&TLIST=%272433282.4235%27&OUT_UNITS=%20%27KM-S%27&REF_PLANE=%20%27FRAME%27&REF_SYSTEM=%20%27B1950%27&TP_TYPE=%20%27ABSOLUTE%27&ELEM_LABELS=%20%27YES%27&CSV_FORMAT=%20%27YES%27&OBJ_DATA=%20%27YES%27 There is also a Telnet interface if you want to go that route. More details on how to connect can be found here: http://ssd.jpl.nasa.gov/?horizons Also, make sure to not hammer the server as per any batch jobs. Delay your requests to one a second at the most, and run it in sequence (do one request at a time). Now, for part two of my post: Asking for assistance. Specifically, I was able to get the bodies that are orbiting the Sun all good to go (as far as I can tell. The orbits appear to be at roughly the inclinations they should be versus the Sun, and they seemed to be in the right general locations as well), but I couldn't get any satellites to work. I've tried all three reference frames with no luck (everything is on an escape trajectory, off to find a solar system where the person running it knows orbital mechanics better than I do). If you have the time, could you confirm which setting/settings I've got wrong above to deal with satellites? Assuming, of course, that any of the above is correct (ugh!). On my first attempt I got passable-ish orbits (they appears to be at the right inclination, right distance, etc) by adding the value for Earth's inclination to their inclination. But as you said it should be a copy-paste from the JPL Horizons page, so I'm surely doing something wrong there. Edit: For satellites, all that is required is to change "Center" to the correct center body for the orbital system, which should be "500@", the number of the planet (or dwarf planet in the case of Pluto, which is still considered "9"), and then "99". For example: "500@599" would be Jupiter's center, to be used with any moons of Jupiter. You can find this in RealSolarSystem configs for any moons, which is where I found it after I went to double check my (more or less) correct numbers. Also, I couldn't get the JPL Horizons system to talk to me about satellites of satellites (Z1-Dactyl (Ida) and Z1-Vanth (Orcus)). I am I just missing something obvious? (Still a problem) Oh, and the file "000-RSSPatches.cfg", besides changing the inclinations, also had a vertex height map for Iapetus. I've ported that out of that file (which should be tossed out, or at least disabled via a rename to add .DISABLED to the end of the filename) and put it into a file called "603-Iapetus.cfg" in a folder called "RSSPatches". If anyone wants to give them a quick test, I've tossed them together on wetransfer.com (the link will only be live for a week, but before it goes down we'll hopefully have resolved the outstanding issues and I'll put it someone that won't get deleted in a week): https://we.tl/4G6r32wgn3 If you're looking for the download for this unofficial patch, check out my second to next post a few posts down, or click here: I assume that I need to add a license (better safe than sorry, right?), so here goes: Credits: imkSushi for doing something pozine for making the mod in the first place NathanKell for Real Solar System ThomasP for Kopernicus (sorry about the axial tilt discussion) Sigma88 for SigmaBinary the ksp devs for KSP anyone who downloaded the mod for supporting the mod This hot patch that will be gone in a week is licensed by the Creative Commons Attribution 4.0 International - http://creativecommons.org/licenses/by/4.0/ I have made changes to the original work provided by the above authors. Thanks! Edit#1.0: I've updated my instructions regarding the time stamp and time form to use to get accurate positions, and I've updated the reference system to make sure we're using the same system (by default JPL Horizons had me using "ICRF/J2000.0", or I somehow ended up on that value so directly making sure to state which we're using is not a bad idea). I'll make a new post with a new offload of the planetary bodies that I've got working (not on an escape trajectory with a core-inspection-level "flyby" on a gas giant/etc) with the updated accurate starting time and reference system. Edit#1.1: Forgot the links and code for the batch jobs. Those have been updated. Edit#2.0: Typo in second link Edit#2.1: No, all the links, ugh! Edit#3.0: Incorrect time used, per the "RSSKopernicusSettings.cfg" comment: This is why you should read things completely before running off and doing things. Edit4.0: Satellite JPL Horizons instructions added to post. Edit5.0: Removing (now expired) download link with a link to the post that contains non-expiring download links.

What would the process be to get the correct inclinations for the heliocentric and non-heliocentric bodies (assuming they aren't correct)? For example, would it just be "Get JPL object database inclination, and add/subtract Earth's inclination from that value"? If so, I wouldn't mind compiling a quick community hotfix until ImkSushi is able to come back and address this. The majority of the work would be bothersome data-entry, and I can automate that relatively easily. I messed around with the inclinations of Vesta, but adding and subtracting Earth's inclination didn't seem to get it to an orbital inclination of 7° (per 7.14040615716409 from the JPL small-body database), so I'm surely doing something wrong. Jupiter's moons (500-Metis, 501-Adrastea, and 502-Amalthea) appeared to be resolved (they appeared to be within the few degrees of inclination per their JPL entries) by adding Earth's inclination, so I'd like to know what the heck is going on to cause this to happen as I don't know why Earth's inclination is involved with Jupiter's moons. I've disabled the "000-RSSPatches.cfg" file so Earth is properly tilted. Thanks for any help you can provide!