Jump to content

ej89

Members
  • Posts

    22
  • Joined

  • Last visited

Everything posted by ej89

  1. Yeah, you may be right. I intend to try it (at some point) and find out. :-) In other news, I confirmed that the 6000 m/s approach at Duna is just as survivable with 3.75m heat shields as with the 1.25m. In this case the periapsis was higher (20,942 m), because the vehicle was more blunt (this time I tried my big bulky lander instead of the Mk1 pod), but I aimed for the same criterion as before, namely, that the Trajectories mod showed this as the absolute highest periapsis which would get me below escape velocity (into a highly elliptical orbit). My understanding is that, by doing this, I am aiming for the same maximum dynamic pressure ("Max Q", as they say in the real-world launch webcasts), which I understand to be the real limiting factor on what the heat shield can handle. See above screenshot for the proof. :-D (Note especially the 107d mission elapsed time demonstrating the fast transfer! That's for real - it started counting from low Kerbin orbit, where I debug-teleported the vessel from the launch pad. This simulates the real mission, since I'll construct it in LKO using EL.) The screenshot doesn't show all the heat shields since I jettisoned the outer ones before landing to make way for the legs. There was a 3.75m shield below each of the four outboard engines. (There's a fifth shield on the center part of the craft which is still there in the picture.) (P.S.: anyone know how to attach a picture on this forum? I've been uploading them to Imgur but I know I've seen people use attachments before...can't find the button though.) (P.P.S.: Hmm, I think I'm using the "Embed Imgur album" button wrong. I only get a link to the album, saying "Album qVZ33ta will appear when post is submitted". It still looks like that after submitting the post. Is it looking right for other people?)
  2. For those curious to know how this turned out: I finally got around to testing it, and it worked! For this test, I used a very simple craft optimized for safe reentry: a Mk1 command pod with a heat shield on the bottom and a parachute on top. (This way, I know that if I don't survive, it's because it simply isn't survivable, not because of a poor craft design.) I found that aerocapture at 6128 m/s, with a 18km periapsis, is "just barely" survivable. The heat shield temperature maxed out at somewhere between 98-99% of its capacity (i.e., the "red temperature bar" was at 98-99%, per KER's precise readout). This was the highest periapsis that the Trajectories mod said would achieve capture (in retrograde orientation, of course). It seems that Trajectories's estimate was a little pessimistic: it initially showed me getting into a highly elliptical, "almost escaping" orbit, but after the full aerobraking pass I ended up with a ~700km apoapsis. However, it was still very close: even a 19 km Pe was still too high to get captured. I suspect somewhere around 18.5 km is the limit. My experimentation would indicate that the true maximum periapsis would give me only marginally gentler heating: at 19 km, the heat shield's temperature bar stabilized at 97.98%. At 20 km, it stabilized at 96.7%. Clearly, we are indeed at the very edge of the heat shield's performance margins. Perhaps most importantly, the usefulness of the "4600 m/s rule of thumb" I had theorized is confirmed: 6000 m/s is about 4600 m/s higher than Duna's escape velocity. just as 8000 m/s is about 4600 m/s higher than Kerbin's escape velocity (and that is the highest reported aerocapture speed people have reported surviving there). Thus, when planning my delta-v, I should be able to safely pack about 4600 m/s less than what the Launch Window Planner says I need for the full trip with no aerobraking. Of course, the numbers may turn out differently with a different craft using a bigger heat shield, but since I would guess that the various stock heat shields are well-balanced with respect to each other, I'm guessing this rule of thumb will still hold for the bigger shields. (That's next on my list of tests to run... :-))
  3. Unfortunately not. I don't have HyperEdit installed (perhaps I should?) and couldn't figure out how to set myself on an escape-velocity flyby with the Alt-F12 tool. For the first experiment I ran, I put it in LKO with Alt-F12 (since I'm planning to build it there with EL in the real career game), and flew it the whole way to Duna, since I wanted to dry-run the whole mission. Since the reentry proved to be the difficult part, I've been rolling out new versions of the craft on the launch pad and manually editing a quicksave to switch its place with the one already on the Duna escape trajectory. It's clumsy and there's probably a better way to do it, but it works. :-) Can anyone with more save-file-editing experience confirm if the game stores any "sensitive" information (e.g. about my computer, etc.) in savefiles? If not, then I can post the savefile here if anyone wants to play around with it. Interesting. Sounds like a cool idea - will have to try that! What kind of maneuvers do I need to do to get that Ike encounter, in such a way that it happens after skimming Duna's atmosphere? Is it a matter of timing, to ensure Ike is in the right place when I fly by Duna? How far out from Duna do I need to be to have the ability to make such maneuvers without costing an exorbitant amount of delta-v?
  4. Have heard of these before, very interesting ideas. I'm having a hard time understanding how a cycler can save delta-v, though. Don't the "taxi" vehicles that shuttle people and cargo between Mars/Earth and the cycler have to burn just as much delta-v to rendezvous with the cycler as they would to put themselves into (and then out of, on the other end) its exact orbit? Is the idea simply that you can save fuel by only putting the big, heavy, well-equipped cycler into its orbit once for good, and do the "taxi" flights with smaller and more efficient (but only comfortable/equipped for short durations) craft? I guess that would make it an indirect solution to the problem of how to get faster transfers efficiently: you're still spending the same delta-v to do an aggressive transfer, but it involves a lot less fuel since it's done by smaller craft.
  5. Ah, you see, that is the challenge... ;-) What I'm really hoping to learn with all this is just how hard I can push those suboptimal transfer windows to Duna. I'm planning to set up a base there, and am thinking about installing both the Tourism Plus and Bases and Stations mods, which will add lots of contracts for getting people to and from said base. Knowing in the back of my mind that I can do a really, really fast transfer between Kerbin and Duna if the need arises, without waiting for optimal planetary alignment, will simplify logistics planning a lot, especially if one of those "Emergency Medical Evacuation" scenarios comes up for one of my base personnel... :-)
  6. Good to know, thanks! Since Kerbin's escape velocity is 3431 m/s, that means that an 8 km/s aerocapture there needs to shed about 4600 m/s. As @A_name noted, a typical Hohmann transfer to Duna will have you aerobraking at ~5 km/s, which means you need to bleed off about 3700 m/s (escape velocity being 1372 m/s). Taking the 8 km/s Kerbin aerocapture as an upper limit, that would suggest I can probably, with sufficient heat shielding, survive a Duna aerocapture in which I go in at roughly 6 km/s - and no more. (That is, such a trajectory would involve bleeding off about the same amount of speed as in the "upper limit" Kerbin example.) Now I want to test this... :-D
  7. No, not yet...thought about it though. I presume by "layered" you mean stacking them so when they blow up due to overheating, the next heat shield in the stack is exposed? :-) (I imagine that would lead to a rather "wobbly" flight as the shields burn up slightly asymmetrically...probably not so much as to be a problem though.) Does this approach actually tend to work out favorably in terms of mass, compared to spending the mass of the extra heat shields on more rocket fuel for "normal" braking? (As it turns out, I'm planning to build the craft for the actual mission using Extraplanetary Launchpads in Kerbin orbit, so I only need to optimize for mass, not cost. RocketParts cost the same amount per kg no matter what you build with them...)
  8. OK, I tried a few more experiments: 1. Used lots of 3.75m ablative heat shields instead of the one inflatable. (The design consists of a center "core" and four outboard tank/engine pods attached via girders; so for this, I put a 3.75m heat shield on each of the five sections.) This actually seemed promising...for about 10 seconds. :-) It lasted that much longer than the one with the inflatable, which was pretty good considering the inflatable burned up within 5 seconds of passing through the 50km atmosphere line. 2. Instead of the big awkward lander I'd designed, a simple craft consisting of a Mk1 command pod with a parachute on top and a 1.25m ablative heat shield on the bottom. This did about as well as test #1. 3. Same as #2, but with the 2.5m heat shield. Seemed to be about the same; it might have lasted a little longer but I'm not sure. In any case, the result was the same (boom). 4. Same as #3, but with 3.75m heat shield. Didn't seem to improve over #3. 5. Repeats of #4 and #2, but with the periapsis bumped up as far as I could take it and still get captured (according to the Trajectories mod's prediction for a retrograde reentry). With the 3.75m heat shield, I was able to get Pe up to about 23-24 km (versus the 13-16 km in the previous tests); it seemed to last a few seconds longer but still ultimately went boom. The 1.25m heat shield version had the opposite effect: I had to go with a lower Pe to ensure aerocapture, because there's less blunt surface slamming into the atmosphere to slow me down. This, of course, exploded about instantly. What I observed through all the tests is that the heat shields actually did a great job insulating the rest of the craft from heat - there were no temperature bars except for the heat shields themselves (at least until they blew up :-)). The "only" real problem was that they were simply absorbing heat much faster than they were rejecting it. I noticed that the "Thermal" tab on KER's Flight Engineer shows "Convection Flux" and "Radiative Flux" readouts - for the best of these tests, the radiative flux (which I'm guessing is how fast the spacecraft is rejecting heat, since it was negative) was only half the magnitude of the convection flux (this was positive, guessing it's the rate at which I'm being cooked by the superheated plasma in front of me). If these numbers mean what I think they mean, then the problem is clear: these heat shields simply don't reject heat fast enough to offset the heat that's being pumped into them. Regardless of how small or lightweight the craft is, it just isn't enough. As you noted, the same speed was survivable at Kerbin, but higher (relatively speaking) in the atmosphere. If I could pass through Duna's atmosphere less steeply, I could probably survive there too. However, I would then not get enough aerobraking to slow me down from escape velocity. I think this is the real difference between the Kerbin-free-return and Duna-aerocapture situations: for Duna aerocapture, it's critical to get rid of all that excess velocity right away, because you've only got one shot at it. Whereas for just lowering an orbit, it's acceptable (assuming life support considerations don't prevent this :-)) to be patient and make multiple, gentler aerobraking passes. Indeed, even if you set the Kerbin periapsis low enough to come all the way down on a single pass, that one pass gives you a lot more time in the atmosphere to slowly shed velocity, since your trajectory is far less eccentric (i.e., you "hug" the planet more closely), and is becoming rapidly less so as you lose velocity. Perhaps even a Kerbin aerocapture (coming in from escape velocity) would be easier to pull off than Duna's, at the same velocity, since the gravity well is deeper and thus escape velocity is lower, i.e. you don't need to shed as much velocity on that one pass (and thus can use a higher periapsis). Kerbin's escape velocity (3431.03 m/s) is a lot higher than Duna's (1372.41 m/s). Oh well...guess I'll just have to use fuel to brake. Or do a less ludicrously fast transfer. :-) Maybe I'll try an aggressive aerocapture on the return trip to Kerbin! (Or save it for Jool or Eve - they're a lot easier to get captured by.)
  9. Yeah, my experimentation showed that I could survive at no more than 2600 m/s at a periapsis no lower than around ~18-19 km. That was before heat shielding, though, on a large, unaerodynamic vessel with a lot of surface area. Based on your experience, it sounds like I might be able to make it with a little higher speed if I add heat shielding, but I'll probably be limited by the fact that this vessel is frankly huge and ungainly. It was really designed to operate in vacuum and in Duna's thin atmosphere (at speeds where the dynamic pressure is proportionately low). Ah, that explains it then. I was wondering if I was missing something like that. I figured "surely Realism Overhaul makes everything harder, so the stock heatshields can't be worse", but now I remember that stock KSP also nerfs engine performance considerably for the same reason, so it makes sense it'd do the same with heatshields. Also, Scott Manley was using the (RO equivalent of) a Mk1 command pod and small heatshield, a much smaller craft (and with an ablative shield), which is more in line with Cpt Kerbalkrunch's experience... I hadn't realized that the ablative heat shields had that kind of advantage over the inflatable one. It makes sense (from what I understand of how they work in real life), I just didn't expect KSP to model them as being fundamentally different from each other. Is KSP actually accounting for the way real ablative heat shields form a protective "barrier" of gas released as the heatshield burns, or does it do some more simplistic approximation? How much does the size of the ship matter? Is it an issue of mass? (Mine has over 20 tonnes dry.) I confess I don't fully understand the relationship between vehicle mass, surface area, drag, and heat.
  10. Hi, Using the oft-recommended KSP Launch Window Planner (http://alexmoon.github.io/ksp/), I'm attempting to set up a mission that will take a very aggressive (totally non-Hohmann) transfer to Duna. The idea is to shave time off the transfer (and depart a good ~80-100 days before the planets are "ideally" aligned) by spending a lot more delta-v than would be "optimal". I'm about to unlock the ISRU converter and build out a Mun mining base with Extraplanetary Launchpads, so my thinking is "fuel is cheaper than time". (I don't want to time-warp through the long coast because I've got lots of contracts and station stuff to keep me busy in the meantime back in the Kerbin system.) I've built a ship with about 5300 m/s of delta-v, and have been doing dry runs of the mission in a sandbox save. Figuring I could use aerocapture to avoid the most expensive part of the trip (the braking burn at Duna periapsis to get into orbit), I put almost all of the delta-v (5000 m/s) into the ejection burn from Kerbin and used the rest to fine-tune my approach, getting a ~13km Duna periapsis on the flyby, which I've read should be enough to aerocapture. However, my best-laid plans were shattered when I actually hit the atmosphere and my entire ship burned up almost instantly. :-) In retrospect this shouldn't have been a surprise, since the navball told me my orbital speed was well over 8000 m/s when I hit the atmosphere. (Yeah, this was probably a terrible idea.) So I tweaked the design and practiced a few more aerocaptures. I found that if I use the engines to brake down to an orbital speed of 2600 m/s when I hit the atmosphere, my design can survive (even without any heatshields). But that needed a lot of delta-v, and the rocket was getting ridiculously huge; I wanted to do better. So I slapped one of the big 10m (stock) inflatable heatshields on the bottom of my lander and tried again. However, it still burned up almost instantly. It's like the heatshield wasn't even there. :-( (In fairness, some non-critical bits of the lander were clipping through the bottom of the heatshield, but if that were the only problem, I'd expect everything behind the heatshield to survive.) What am I missing here? I was sure the heatshield would solve the problem, because I've seen a Scott Manley video where he was playing RSS and aerobraked at 10 km/s on Earth coming back from a lunar free-return; surely 8 km/s at Duna should be easier??? Thanks. :-)
  11. Ah, looks like Planetary Base Structures doesn't do this, then - it doesn't have a seat_tasks.cfg in its root mod directory. If I were to manually add such a file in Planetary Base Structures' directory (following the examples you mentioned), would that be enough to get it working, or would the mod need to do more to "cooperate" with KerbalStats?
  12. Good to know, thanks. KSP.log confirms that KerbalStats is indeed being loaded. I'm a little concerned because the KerbalExt nodes for my engineers don't show anything that seems to indicate workshop experience; I only see generic "Passenger", "Pilot", etc. experience. For instance, here is the KERBAL node for one of my engineers who's been hard at work in a workshop on the Mun for some time: Perhaps I should've taken the wording in the EL manual more literally, that "currently only EL's blue workshop" counts workshop experience. My engineers are working not in the blue workshop, but in Planetary Base Structures' K&K Workshop. I (perhaps incorrectly) assumed/hoped that since it was a purpose-built part designed to integrate with EL, it was "as complete as" the blue workshop... If this is the case, then it will be a moot point soon as these engineers are in the process of building themselves a bigger and better base containing an EL blue workshop. :-) Or does the experience not get recorded until I level up the Kerbals using a science lab (or by returning them home), as with stock XP?
  13. OK, so I partially figured out the answer to my question...but now I have a new one. :-) It turns out that I did indeed previously install KerbalStats from CKAN (along with ExtraplanetaryLaunchpads, which is still installed and working just fine), back when 1.3.0 was the current KSP version and I was running that. But it appears that since 1.3.1 came out, KerbalStats no longer appears in CKAN. The existing install, however, is still present in my GameData folder. My new question: is there any in-game UI to actually tell whether KerbalStats is installed and working in conjunction with EL? I could have sworn that right-clicking on a manned EL workshop showed the experience numbers for each of the crew inside, back in 1.3.0...but I don't see that any more. Now I'm wondering whether it was ever there (and stopped working with 1.3.1) or if I'm just remembering wrong. :-) Alternatively, is there somewhere I can look in a raw file (the .sfs savegame file, perhaps?) to confirm that my engineers are indeed racking up experience from spending time in the workshop? Some of them have pretty bad stats (stupidity + courage) and are hard to get work out of...some accumulated experience would really help them out.
  14. So you're saying that with ContractConfigurator, there will always be contracts available (no matter how many I have active) but there's a limit on how many I can have ongoing? (I see in the forum thread for CC that there's an overall limit, plus limits for each prestige level.) What does this limit max out at for the fully-upgraded mission control? I noticed in Contracts.cfg that letting a contract "pass by" (even without actively declining it, or even looking at it) will de-weight that contract so the game gives you ones like it less often in the future. Is this still the case in CC's new system if I'm maxed out on ongoing contracts and can't accept ones that are offered?
  15. Ah, that's what I was wondering, thanks! The Contracts.cfg file was an interesting read...very informative about the kinds of contracts I can/should expect now and in the future (and what conditions I need to have met to be offered some of them). Now that I know the magic keyword to search for, it wasn't too hard to find reports of others wondering the same thing: https://www.reddit.com/r/KerbalSpaceProgram/comments/37x63q/psa_if_youre_finding_the_10ish_active_contracts/. I was beginning to wonder if it was "just me"! :-) Would certainly be nice if this was configurable in the game GUI (like many other career mode difficulty options), if anyone from Squad is reading this. :-) Do you (or anyone here) know what relationship the AverageAvailableContracts value has to the number of contracts that that the game actually "maxes out" at? Clearly, it's not a one-to-one correspondence, because the default value is 10, yet it's maxing out at 14-15 active contracts for me (and others in the Reddit post report 13). Regarding Contract Configurator, it looks like a "dependency" type mod mainly intended to be used by other mods that add contracts. Does it actually provide any player-side functionality in and of itself? The mods built on it look pretty cool though, I might try some of them. Oh, and should I ever be expecting to get tourist contracts for more than six passengers at once in the stock game? Kind of wondering because I just built a Mun lander for up to 15 of them at once (in anticipation of future growth)... Edit: OK, one more question...I noticed in Contracts.cfg that under Station type contracts, it says: ContextualChance = 75 // The maximum chance for a station expansion request ContextualAssets = 2 // The amount of stations required around the planet to reach that chance Does this mean that I will get "expand this existing station" contract offers if and only if I already have at least two stations orbiting the body in question? And how does the game determine what constitutes a "station" for this purpose? Does it just look at how I've categorized the vessel in the Tracking Station (ship, lander, probe, station, etc.)?
  16. Hi, I'm playing a career mode game, and upgraded the Mission Control building to Level 3 (maximum) a long time ago. The game says this upgrade should allow "unlimited number of active contracts". Although the upgrade did indeed remove the hard limit on the number of contracts, I found that the game simply didn't offer me any more contracts once I had 14 active. Whenever I'd complete a contract, I'd be offered a new one, one-for-one, but no more than that. One day when I completed a story contract, the game offered me two in its place, which expanded the "rotation" to 15, but a few contracts later, for no apparent reason, I completed one and was not offered a new one, reducing it back to 14. The other day I completed a non-storyline contract and was offered two in its place, so it's now back up to 15. Does anyone know what's going on here? Is this "intended" behavior by the game? An arbitrary technical limitation perhaps (e.g. due to the contracts being stored in a fixed-size array in the game code)? I would really like to be able to have more than 15 active contracts. Right now, more than half of the effective "slots" are tied up with long-term missions that I can't (or don't want to) start yet - e.g. I need to unlock the requisite tech tree nodes to complete ore contracts, and I don't want to skip any of the storyline contracts (thus I can't escape Kerbin until I've finished exploring Minmus, since that would skip that contract). This leaves only a few slots for active turnover of contracts, which makes it difficult to e.g. get enough tourists on the books to fill up a big, efficient craft to take them to the Mun. Is there any way to "fix" this? Perhaps a setting, or a mod? It seems weird for the "size of the market" to be effectively capped like this; one would expect the market to increase as I demonstrate the ability to perform more ambitious missions more efficiently. Thanks!
  17. Is KerbalStats available on CKAN? I don't see it there in the list of available mods, but since @taniwha's other mods are there (I want to use KS with ExtraplanetaryLaunchpads) I'm wondering if I'm just not looking in the right place. I see that the title of this thread currently says "[1.3]", not "[1.3.1]" - could CKAN simply not be showing the mod because my KSP install is 1.3.1 and the mod doesn't declare compatibility with it? Thanks!
  18. Yeah...I "knew" that (and generally keep that in mind when designing my vessels) but forgot to check the CoM for the re-entry module on this particular craft. It was based on a craft which worked "just fine" for suborbital tourist flights (where the re-entry is easy), and I got lulled into a false sense of security after its first flight (which was piloted by Jebediah) made it back "easy" because of his Level 1 SAS abilities. :-) So naturally, the next thing I did was send up another one with tourists in all three seats...which is when I discovered the problem because the OKTO probe can't hold retrograde. It was immediately clear why this was happening, but it was too late for these tourists because I'd previously done a quicksave and lost the opportunity to revert the launch. I've since redesigned the ship to separate into two separate modules before re-entry (1 Mk1 pod + 1 two-man Crew Cabin), each of which have their CoM correctly balanced. An overkill solution to be sure (with more careful design I could do it in one module, as you did) but it's worked very well. And it can go to the Mun because of the extra delta-v of the engine I added to deorbit the upper craft. :-)
  19. Haha, wow...what is going on there? Which parts are part of which vessels and how did you manage to get them to "connect" (or at least be sufficiently entangled to push the non-engined craft)? Also - I'm assuming the game doesn't count that as "docked", i.e. you can't transfer crew that way (just give the one ship a delta-v boost)?
  20. Thanks! As it turns out, I already found that video myself while trying to figure this out before posting my question. :-) I was confused why it wasn't working, since I was doing everything just like in the video...but @Tex_NL's answer cleared that up (it was working just fine, I just shouldn't have been expecting it to transfer SAS skills).
  21. Thank you! That answers my question perfectly. Guess I'll need to try a different approach for this rescue mission then...probably something involving the Advanced Grabbing Unit ("The Klaw"). It's a ways out in the tech tree so it'll take a while to get, but fortunately I have plenty of time before my tourists' contract runs out. :-) Speaking of which: does anyone know if "docking" with the Klaw allows you to transfer Kerbals between different cabins on the now-combined vessel? The wiki says that it's possible to transfer fuel and electricity, but doesn't say anything about crew. Being able to do this would make the rescue a lot easier since I could shuffle a tourist off and a pilot on (without needing to EVA a tourist, which is of course impossible). If this isn't possible, then I guess I'd need to de-orbit with the Klaw attached, which seems "very Kerbal" (and potentially very difficult). :-)
  22. Hi, I've got a vessel stuck in low Kerbin orbit which desperately needs a Level 1 or better pilot to re-enter safely. The re-entry module was badly designed and it wants to tip over the wrong way (heat shield up, Mk1 command pod down) in the atmosphere; I've tried (many times) and failed to re-enter it manually without hitting the ground too hard. However, when I fly the same craft with Jebediah Kerman (who's currently at Level 1) on board, he can keep it stable all the way down with the "hold retrograde" SAS option. :-) The stranded vessel has three tourists on board, so all it has is an OKTO probe's SAS, which doesn't support "hold retrograde". The usual rescue options are precluded because 1) it doesn't have a docking port, 2) tourists can't EVA, and 3) there are no empty seats for me to EVA a pilot into. So I had an idea "what if I could use Remote Pilot Assist to transfer a Level 1 pilot's skills to it". I'm having some trouble getting this to work, though. As a preliminary test, I built a simple craft which has a Mk1-2 (3 man) command pod, two HG-5 (relay) antennas, a stack of batteries on top, and a token engine (not enough to get it off the ground) so that I can "launch" the thing and get the MET clock going without actually moving it anywhere. I then attempted to use it to control an unmanned probe (OKTO-based) which I already have up in keosynchronous orbit with visibility of the launch pad. However, it's not working. Even with two level 1 pilots on board the ground craft, both craft's antennas extended (they are both equipped with HG-5's), the orbiting probe still has only the OKTO's basic SAS (stability assist only) and the status bar at the top of the screen indicates it's being controlled from KSC, not the remote craft. In map view on the ground control pod, when I set it to "vessel links" it shows a faint green line from the ground control pod to the orbiting probe, so they do have a line-of-sight link. But still...the piloting skills are not being transferred. Am I missing something? Some requirement that's not met one one or other of the craft? Some button I need to press to activate the Remote Pilot Assist? Or does Remote Pilot Assist only kick in when the "normal" DSN link to KSC is occluded/too weak? Or does it not like the fact that the control craft is landed on Kerbin? (Should that even matter, since I did "launch" the thing and the mission clock is counting up like it should?) Thanks...any ideas are appreciated. :-)
×
×
  • Create New...