Jump to content

swjr-swis

Members
  • Posts

    2,822
  • Joined

  • Last visited

Everything posted by swjr-swis

  1. @jimmymcgoochie already offered alternative suggestions, worth noting. to still answer your questions directly: Yes, engines attached to rotors will keep running when or after rotating. No, no fuel line is needed - as long as a part doesn't explicitly mention 'no fuel crossfeed', KSP considers all parts to include invisible internal fuel conducts. Fuel lines stretch pretty far, usually more than is practical. They also don't care about stuff being in the way.
  2. Hi there, welcome to the KSP forum. You're going to have to be a bit more specific, I'm afraid. KSP is notorious for having 1001 ways to generate phantom forces, intentional or not. An image is likely not going to be enough to diagnose this - it's hard to see if parts are placed/clipped/configured in just the kind of ways that might have this effect. Try uploading your craft file (kerbalx.com, dropbox, google drive, etc) and post the link to it here.
  3. Cautiously confirming this. A change in the image host interface seems to have been the cause for that one. It doesn't retroactively solve the missing thumbnails of pages uploaded during the error window, so for those pages please try to manually refresh the thumbnail image (in edit page mode, click the tiny thumbnail image at the top beside the title and reselect the desired image). Or if you had no image on the page as a workaround, you can try adding one now. Thanks everyone for your patience so far. Agreed!
  4. Not if you drain their ablator first. There's only one 'real' wing part lighter (basic fin) than a drained 0.625m heat shield, none of the control surfaces, and only the smallest of the prop and duct blades. Also makes it the cheapest and next-to-lightest separator/decoupler option, btw.
  5. It's connected with the current issue. At least the craft pages with a missing thumbnail work and the craft file is downloadable; other craft pages just don't work at all and show the 404 error page. No news to report on this yet.
  6. Barely. I think the regular drag force applies to the base of the blade or very near to it. At that point radial speed is minimal and so is the drag calculated for the blades = minimal torque required to get/keep them moving. Which is my point: The optimization is based on moving the drag point to get as close to zero blade drag as one dares so the readouts still show a minimal EC usage and the divide-by-near-zero flight range goes through the roof. But since it's a continuous sliding scale, a micron more and it's now in infini-land. Proof is in the pudding. I just exaggerated it to show the issue clearly, after you both stopped at the edge of it going into 'negative', while your previous series of entries show the range growing exponentially at the blades moving inwards.
  7. @camacju explained it ealier in this thread: On regular lifting surfaces, all force vectors (drag/lift) act on the same point. On prop blades, the point of action for lift/thrust was moved somewhere far outside the tip of the blade to artificially enhance the generated thrust and make props more playable. In a default placement it works as expected, but when offsetting the blades inward the drag point moves to the opposite side while the lift point, being way out there, still stays in the 'correct' side. Instead of the airflow causing a drag that slows the props rotation, it's now accelerating the rotation, ie. magic torque that doesn't require rotor EC usage. Offset it enough and it becomes enough to not need any EC at all anymore, as long as there's an initial bit of airflow started.
  8. @18Watt: did my last entry not meet the criteria?
  9. I hate to be the party pooper, but yes, I would call this an exploit, because yes, there is absolutely free energy being created. Proof, with a plane with a relatively poor cabin drag-optimization compared to the other two entrants. The only improvements it introduces are the better choice of wing part and a system to almost nullify the vibrations that kill SAS, allowing me to simply use SAS on ORB PRG to let the plane fly itself: Two rotors set at max size/power and max RPM, with two of the smallest duct fan blades each, liberally offset inward from their default to clearly show what's happening. Used all my EC simply getting up to speed and in the air. This was hands-off, ZERO management of blade deployment, rotor torque, or RPM limit - all I did was release the brakes. 25 mins later, the plane is still at (over!) max RPM and climbing, 79.5 m/s at almost 9 km altitude. I didn't feel it necessary to wait a day to see if it will circumnavigate because obviously it will. And being completely stable in flight, it doesn't even need watching. Just to make sure, this time I went and LOCKED the battery just after take off. Same result. Plane will keep going as if nothing's up and will obviously do so indefinitely. I have literally done nothing but close the fore bay, set SAS to ORB PRG, and released the brakes, zero prop/rotor management or even flying. Let me be clear: I am a strong proponent of Applied Engineering in KSP, and I have zero issue with putting this to good use. But let's call it what it is: what we're seeing in this exchange is really just 'infini-props'. We can pretend it's not, but it's really just about how far we dare offset the prop blades inwards, allowing an arbitrarily low EC usage to keep up torque, passing through literal zero, and then even becoming 'negative' since now the blades are basically creating their own torque (once the craft gains a bit of speed). Craft file for anyone wishing to peer review: https://www.dropbox.com/s/eit1qdj09wf412c/SWiS TinyProp 3.craft?dl=0
  10. Thank you but no. All I did was a refactor to make the craft comply with the stock part rule. If you're gonna put it on the leaderboard do it under @Poppa Wheelie's name, please. Maybe I'll make an entry of my own when I get time. Carry on.
  11. To make up for compromising your entry, I redid your craft to meet the stock parts rule (octo 2 core, battery, and reaction wheel, stacked on the bottom node of the engine and clipped up into the tank), and improved a bit on it with a different tank size and staging strategy. The resulting craft now gets to orbit with 3087 m/s left in the tank.
  12. Question: what is the part you used directly above the engine? Zooming in on some of the screenshots it looks like a very short shroud or fairing, and I imagine it's where you placed your probe core etc, but none of the stock (or DLC) ones are that short or flush with the tanks.
  13. Ok another entry, this time to (temporarily, I expect) take the top spot. The R100EC-2, making it 26.7 km away from the planted flag on the KSC Runway spawn point. This one was a test to see if maybe drag was more of an impact than weight. There's still one more thing I can do to make it better drag-wise, but posting this one since it got me a top entry already. On the KSC Runway with flag planted. Battery empty; spent more than half the time maneuvering slowly down slopes to keep free-wheel momentum. Then I literally ran myself into a corner where it was either roll back towards the flag, or climb a steep hill with no juice left to do so. So I just stepped on the brakes and measured here. Compared to my previous entry it *seems* like it pays to optimize for drag instead of weight. But the cave at is that the path one takes seems to be the even more important factor. I took a completely differnt path, trying to keep to low slopes, climbing at first and then trying to use the potential energy by following the slopes down in a generally away-from-the-flag direction. So I'm not sure this offers conclusive evidence of drag vs weight as much as it shows it really pays to watch where you're going. Suggestion: why not move the starting point for the challenge to the Dessert Runway? It may be possible to get longer runs from there, purely because on average it looks flatter for longer distances away from the span point. Just a thought.
  14. Perhaps something like this: Radial drogue chutes, 6 of them. They'll be plenty for Duna for a craft like this. 3x Ant and one Doughnut for fuel. All at the bottom to keep CoM low... not that it matters much in this case. The drogues lower drop rate to about 20 m/s. You can afford to wait until the last 100 m or so to use the Ants and bring that further down. Arrived at our Red Buddy. Time to transmit some sweet science (and with a TWR of 1.11+, you can hop to nearby biomes and get some more).
  15. RFP-F Flag Flat. One of the stock parts added since... 1.11 I think? In the utility section. It adds no drag or even collision; that way I can have all parts visually connected and still spread my wheel base.
  16. Is this a private party, or can my R100EC-1 rover enter too? Seats lying down to lower drag. I needed a Jr dock for correct control orientation, so I used cones and a 0.625 battery limited to 100 EC. Trying my luck with the DLC rover wheels. Using a flag to visually connect everything with zero extra drag. On the KSC runway, flag planted. Resource panels shows 100 EC (battery at half capacity). Ran almost out of juice just as a pretty steep hill got in my way of following the coastline - even the bit of climb killed the rest. I may have to retry a different path to get a bit further. 13.5 km as the crow flies.
  17. Thank you for reminding me of this one; I keep forgetting to do this again for every KSP instance. Undoing the frustrating editor offset limits, this, and lowering kerbal respawn to 5 mins (more than enough to pull themselves together after a crash. Back to work, I have craft to test!). Well, that and the ISAIDNOCAMERAWOBBLEDAMMIT! portrait setting (CAMERA_FX_INTERNAL = 0) that newer KSP versions no longer honour...
  18. @Thundrevv Test payload of exactly 50 t (inert), feel free to add to the OP for standard use by everyone: https://www.dropbox.com/s/ydxqmh6p4bpk01q/00000-50t.craft?dl=0 Also, a first entry to get things started, since no one else has submitted anything yet. I'm going for a pure stock entry, no mods or DLC at all. Intended to land all stages with parachutes on drone ships, since that's the best scoring option. Lifter is 2x side boosters, 1x core stage, 1x extender+cabin, with the core stage and side boosters being almost identical. Complies with all stated rules as of the moment of this posting: Central core is Size 2 (2.5m) Has three cores, same size. It is fully reusable, second and later stages included (with exception of the fairing and engine shrouds, but that's standard in such challenges, even if not explicitly stated). It's obviously not an SSTO, or it wouldn't comply with rule #2. It can be both remote-controlled and crewed. Recorded run is with crew, but all stages including the extender have a probe core and comms for full remote capability. No cheats (Kraken drive, Alt-f12 menu, KAL glitch etc.). Since it's pure stock, all recovery is done through savefile reloading, as permitted by OP. Note though that it is necessarily done in reverse order, due to the time-critical path to circularize the payload first. WIP context for the curious: So my entry then: the FRL3C50T-B, recorded on a minimum-score successful run, all parts recovered undamaged. This was just aiming to recover everything as the challenge requires, no drone ships yet. Scoring for 2x side boosters on water (2x 20p)+ 1x center booster on land (1x 80p) + 1x extender stage on land (1x 80p) and price of 121799 funds (payload cost excluded): by the original OP method: (2x20 + 1x80 + 1x80) + (121799 / 1000) / 2 = 160.8995 by my suggested alternative calculation: (2x20 + 1x80 + 1x80) * 1000 / 121799 = 1.642 Pictorial evidence of craft, flight, payload delivery, and individual recovery of all stages: P.S.: This design is 'no rights reserved, free to do as you please with it' as far as I'm concerned. If it gives any other entrants ideas for improved versions, you have my blessing to tinker away and enter your result as a competing entry. The craft file is linked here for anyone to try it. I just want to see a successful landing of all stages on drone ships, by anyone - fair play if you happen to succeed before I do, because I have limited free time and will take a while to get it.
  19. Looking at this more closely now: it favours building the most expensive lifter possible - building cheaply would just bring the average down. Alternative: points * 1000 / price. This would result in a score range between 0.5 - 5.00 or so, higher being better (high points and low price). This is assuming points scoring for 2x side boosters, 1x core, 1x extender as a maximum. @QF9E 's question about additional stages also getting points is very valid.
  20. This one I wondered too. It's the only way to make a full recovery including side boosters happen in a pure stock game, and how I was attempting to make an entry for this. Still not easy to make happen, but not entirely impossible anymore... IF loading a save point is allowed.
  21. He's doing this out of his own pocket and in his spare time next to a demanding full time job and other real life stuff, folks. Keep that in mind. As frustrating as it is, be assured that your reports have been seen, and the errors are being looked into. Unfortunately the current spell of instability is looking like a problem in the hosting platform itself. Moving the site to a different and more reliable hosting provider is currently being investigated, but it's not a quick easy thing to decide or do. A live database needs to be migrated, there's code compatibility to consider, money has to be spent, and certainly not least free time slots have to be found for the actual move. If it were a code fix it might've already been resolved, but this is a project by its own right. In the meantime, I'll keep fielding and answering the reports here as best I can.
  22. I do think previous airliner challenges suffered a bit from being subject to individual interpretation. I think there is sufficient room to use objective in-game parameters to judge operating efficiency. A few examples: There's three actual runways in the stock game (KSC, Island, Dessert). One can request evidence to be submitted of flights between those runways, 1) as proof of flight and landing capability, and 2) with starting/ending fuel numbers shown to calculate fuel efficiency. KSC-Island is bare minimum on flight range, while KSC-Dessert is a good validation for medium-range liners. Island runway is a good measure for short take off and landing (we are focusing on airliners here, not carrier-graded planes), offering sufficient contrast with the KSC runway length. A few other locations can serve for additional judgement/points on landing capability, and serve as examples of typical tourist routes. KSC-Temple and KSC-Baikerbanur come to mind. The geography of those locations add some extra difficulty to approach and landing compared to the runways. Long-range capability can be judged by successful flights from KSC to Poles, opposite side of Kerbin, and/or a full circumnavigation. Lat/Lon can be shown even in full stock games as proof. Cruise altitude can be divided in 'bands' to add different point values. Same with cruise speed, cost, passenger capacity. Fuel burn is a tricky one. From an operating perspective, I think I'd rather know total fuel usage after landing at destinations. Reason: a plane that can cruise very efficiently once at altitude might still burn off quite a bit on the climb to said altitude. Which could make such a plane very inefficient for short(er) routes. 'Maintenance' can be simplified to part count. Divide in bands for different point values. Use a few of these parameters to define a few separate categories. Range and passenger capacity come to mind as the most prominent separators. This will allow people to submit planes tuned to their best affinities and encourage more people to submit entries. I think using things like the above would allow people to pretty much judge their own entry already. The OP or judges would just need to confirm the given information and check on the entry being within the requested category parameters.
  23. Message received and passed on. One thing that would help investigating the cause is if we had the craft files that the site keeps crashing on. Since this can't be done through the site itself, use one of these alternatives: Dropbox: https://www.dropbox.com/request/WrDKybZC8DbCMnrmFlih e-mail mailto:[email protected] Thank you.
×
×
  • Create New...