The plane appeared in the OVA The Cockpit.

Hi I was wondering if you could help me with some gauges in the cockpit of my plane

@AndrewGarrison Feel free to take up my offer, any time.

That's a nice way of looking at it, but the only time I'd want a game world leaking into real life is if I made a few million dollars in-game. :) Plus, it's not I who gets frustrated -- I rarely crash my builds -- it's other users.

@SledDriver wow, thanks for the offer to help with the website! We may take you up on that! Thanks for the suggestions on the website. Lots of great feedback. When the bomb explosions crash the game, I know that can be frustrating, but part of me thinks it really just demonstrates how powerful the explosion was :D

Can you make the F4N Phantom VF 161 Navy USS Midway livery

I heard a small dog ran off with the only blueprints and was never seen again. @Stellarlabs

Kidding..... maybe....

@WalrusAircraft I'm guessing they don't have the design which makes it harder.

@Stellarlabs - It takes time to restore aircraft. I've been on board the USS Lexington 3 times in the last five years and have seen one guy working full time on restoring an F4. Just an example of how much effort it takes, restoration work on the Enola Gay began in 1984 and involved a total of some 300,000 staff hours.

Sounds less like "awaiting restoration" and more like "never to be bothered with"

@AndrewGarrison Another idea I had that would be very easy to implement is different fuzes for the bombs -- timed fuzes, proximity fuzes, naval mine fuzes.

Also, it would be great if when an airplane carrying a number of bombs crashes, only one of the bombs goes off. At present, a number of bombs going off together crashes the game.

@AndrewGarrison I posted this on another thread, but wanted you to see it, and discuss it with you somewhere too many people won't see it.

[There's a problem with] the "airplanes" tab of the website. It links to the "hottest" airplanes, which is usually full of mediocre builds. It doesn't matter how much effort someone puts into a build, it will be off the "hottest" list in at most two days, and likely won't get any upvotes after the first 24 hours. This is discouraging for those who post high quality builds, and the incentive is to keep posting lots of low-quality ones. Why put days or weeks into something when it will only be seen for a day, or a week at most if it hits the front page? Quality posts should keep earning upvotes for weeks and months to reward hard work. Perhaps the default "airplanes" page should have a random selection of high-ranked posts, no matter how long ago they were posted. At present the only way to reach good builds that are older is to go to "Highest rated > all time," then keep clicking through the pages. Clicking past the first few pages is tiresome -- there's no way to go directly to an older page -- and most people will stop before page 10 or so, and probably never come back, because getting to page 11 means clicking through pages 1 - 10 again. I think this is a serious defect with the website and needs to be fixed.

Another problem is the presentation of the posts -- the thumbnails are just too small, the default background is too dark and has an ugly pedestal, and the page itself is glaring white, which means you have to squint hard to see some of the builds. The thumbnails need to be at least twice as large and presented better, and the background needs to be dark grey so that images stand out more. The screenshot mode should offer users a selection of backgrounds and lighting setups so that users can show off their builds in the best way possible. If larger images would put too much load on the server, the image format can be changed from PNG to JPG - the difference would be hardly noticeable, and there would be significant savings in page load time and bandwidth.

@AndrewGarrison If you need some help with styling the website, I'd be happy to do some pro bono work -- I'm a professional web designer/developer.

Thanks @SpiritusRaptor You have some neat builds I need to check out!

@SledDriver @WalrusAircraft Thanks for the suggestions guys. You both make incredible designs and I'm always interested to hear your suggestions. I can't promise we're going to implement them, but I did add this to our task board to consider for 1.8.

That's very interesting with the slow-downs in the designer related to intersecting parts. Thank you for letting us know about that.

@AndrewGarrison @SledDriver - Encapsulation of parts into a boundary box that allows colliders to be turned off is an intriguing idea. It is more work than simply exposing those properties in the XML, but would be an outstanding way to turn behavior on and off. Nice thinking "outside the box" Andrew.

@WalrusAircraft Yes, I think part size has to do with it as well, if not as much as intersecting parts.

@AndrewGarrison Designer lag (and by that I mean delays when loading/saving a build or switching to and back from sandbox mode, and UI freezes when alt-tabbing) seems to correlate with lots of intersecting parts. I.e. I may have a build with 500 fuselage blocks 100 units wide and 20 high, and that saves and loads fairly fast. Then I add a subassembly of maybe 20 parts inside it, and suddenly save/load times go up significantly.

So you're probably right that it has to do with physics colliders and visual meshes. XML attributes to disable both would most likely solve the problem (and improve sandbox performance, to boot).

I have to say, I'm floored by your taking the time to respond to individual posts so quickly and in detail. Tremendous responsiveness from you and all the other developers. Hats off to you gentlemen.

I've noticed in the past that a few parts scaled very large had a similar effect as multiple parts with no scaling. I run regular expressions on my XML to normalize disparate values like mass. An XML option to disable colliders might work as well. It is low cost for you I think. @AndrewGarrison @SledDriver

@SledDriver Is the designer lag consistent with the size of a build? Or does it seem a bit random? The designer doesn't batch part meshes to reduce rendering overhead like the terrain scene does, but that shouldn't be a problem on a powerful PC unless you have an enormous build.

The combining of physics objects like you mention would be a significant task. Maybe something like an XML option on parts to completely disable their physics colliders would be helpful. Maybe another one to disable their visual meshes. Then you could encapsulate a collection of parts in a single invisible fuselage piece, and turn off the colliders for all the pieces inside. I'm just thinking about this as I'm typing.

@WalrusAircraft Programmer minds think alike, hmm?

I've been plagued by lag in designer mode as well, and I have quite a powerful machine. I've also noticed that when in sandbox mode, I can alt-tab out of the game and back instantly, but in designer mode, if I have a large build open, there is a very noticeable delay when alt-tabbing - up to a few seconds where the UI is frozen. The same lag happens when switching from designer to sandbox mode, or vice versa.

I wonder what it's doing in designer mode that takes so long, and if it could be optimised. The lag happens even when the build hasn't changed at all, so I think it could be something like if(the view is refreshed) { recalculate volume, mass, drag, whatever}. I'm pretty sure it performs the calculations on the entire body, so perhaps it could be optimised by only recalculating bits that change, when they change.

As for complexity, I have a feeling it could be done without too much hassle. The graphics engine sees one version of the plane, the physics engine sees another, much simplified version. I'm sure there are off-the-shelf bounding-box algorithms that could be used. FPS games where hit detection and collision need to be precise have always used cylindrical/rectangular hitboxes for hit detection, so for a game like SimplePlanes it should be just fine. Plenty of mobile users complain about larger builds, so I have a feeling the ROI would work out. Just a guess, though.

@AndrewGarrison

@SledDriver - I asked that very same question a year ago, and was chatting about the idea again with someone who I won't mention a few days ago. I can't speak for Jundroo, but I'm not sure what the ROI is for the development work, considering how powerful mobile devices are getting. However, one could argue that it would allow much more creativity in the game since builds could be fantastically large. There are serious memory lags in design-time when builds get to big, so even if the run time is optimized, you will always see a delta between the two. I suspect optimization would need to occur in both to make it happen. I personally would love to see this happen but I wouldn't be surprised if it required game re-architecture.

@AndrewGarrison Hmm. Then I have another question: would it be possible to treat a bunch of parts as one part, to reduce the physics computation load? Meaning, if an airplane's fuselage (or any other part) is made up of dozens of blocks, could they be treated as one cylinder, as far as the physics engine is concerned? And if other parts are much smaller compared to the overall size of the aircraft (say, decorative panels/decals/details), then could they be excluded from physics calculations altogether? This would let builders create high part count builds without affecting performance too much.

It could work like this: the game engine analyses the overall shape of the airplane, and breaks it down into large, simple shapes that roughly match the shape of the airplane. So a build with 300 fuselage blocks for the fuselage and 200 blocks each for the wings becomes one cylinder for the fuselage, one cone for the pointed nose, and two flat blocks for the wings. To put it another way, the build looks highly detailed, but to the physics engine, it's a stubby pencil with wings. Still looks like a 1000-part build, flies like a 10-part one.

Actual wings would continue to be treated as they already are. Only fuselage blocks get the "averaged shape" treatment.

(I'm assuming that the physics calculations are responsible for a large part of the lag with high part count builds.)

@SledDriver Thank you for that diagram. That's really interesting. I had never heard of that before. In terms of implementation, there are really two separate things here. Ogives and seamless joints. The ogives would be quite hard to implement in SP, especially the frustum clipping. The seamless joints would be tricky to implement, but I think far easier than ogives.

All of this would be a lot easier in SimpleRockets 2, because I have completely rewritten the fuselage code in SR2 and it's much more flexible than SP.

@AndrewGarrison Certainly. These are examples of ogives - you take a cylinder of radius r1, then draw an arc starting at the edge of the cylinder with radius r2 until it meets the axis of the cylinder, then rotate the arc around the axis. Adjusting r2 gives you blunter or sharper tips. More info here. It would be very useful in making nose cones and tapered engine pods, fuel tanks, etc.

Wow, nicely done with this one!

@SledDriver I'm sorry, but I don't understand what you mean. Can you elaborate a little more? I think a diagram might be actually necessary! :)