@MrDoolittle I never called for it to be taken down -- quite the opposite, in fact. Perhaps work on your own reading comprehension before you call others out on it?
pro tip: I don't care.
Then why are you getting so worked up?
This is a building plane game not a debate club.
Who are you to define what this game is?
Now bugger off with the personal attacks
Show me where I made a personal attack.
just present your next argument so we can get this done with
I've already presented my one argument, you're the one jumping all over the place with wild misplaced accusations and zero understanding of what's being said.
@MrDoolittle @Awsomur No one's being mean here. You're asking for something quite contemptible -- to upvote someone's undeserving posts because you feel like it. If everyone started upvoting posts for any other reason than the quality of the post, the community would go to hell in short order.
Morpheus: What if I told you that you've been living in a dream world your whole life? That in SimplePlanes, while you believe that you are bound by "normal" rules of aerodynamics -- there are no rules. What if I told you that in SimplePlanes, you have the power to make anything fly.
Neo: Whoa. Why do my hands hurt?
Morpheus: You've never flown using a keyboard before.
Well, this is disappointing. I build a freaking hovering autocannon that fires Boom 50s at 300 rpm. I post a large warning not to crash it. And all the comments are about crashing it.
@Maxwell1 It's really very easy to control as long as you don't build up too much speed. To get the hang of it safely, rise up high enough and get away from land. Then practice moving around until the controls become familiar. Then proceed to blow stuff up...
@KSPFSXandSP Clearly there is erosion on the port side, so no. There are sometimes fluctuations in the hyperdrive field. The important thing is that it came through -- and still flies controllably.
@BACconcordepilot That would be funny, but the waveform that we see in audio applications is a subset of the audio information, showing amplitude but not frequency -- meaning that the audio signal cannot be reconstructed from a graph like that.
@FlyingThings My idea is that when these craft go through hyperspace, something... eats... at them. They go in pristine, but when they come out they look shredded. The only way to cross hyperspace safely is to make sure your ship has enough sacrificial metal to get you through.
@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 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 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 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.)
@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.
@MrDoolittle I never called for it to be taken down -- quite the opposite, in fact. Perhaps work on your own reading comprehension before you call others out on it?
Then why are you getting so worked up?
Who are you to define what this game is?
Show me where I made a personal attack.
I've already presented my one argument, you're the one jumping all over the place with wild misplaced accusations and zero understanding of what's being said.
Your move.
@MrDoolittle Yes, I can read what you're saying [sic]. You said:
I'm saying it's not. What @Awsomur is proposing is outright corruption, and strong reactions are entirely well-deserved.
Pro tip: Using "lololol" and ALL CAPS instantly destroys any credibility you might have had.
@MrDoolittle @Awsomur No one's being mean here. You're asking for something quite contemptible -- to upvote someone's undeserving posts because you feel like it. If everyone started upvoting posts for any other reason than the quality of the post, the community would go to hell in short order.
@DarthAbhinav No. How would engines acting against each other make something levitate? The engine(s) have to act against gravity to do that.
@DarthAbhinav no...
@DarthAbhinav hm....
Let's see if you can figure it out (others have).
@DarthAbhinav
@DarthAbhinav I don't care what the incompetent monkeys behind dictionary.com say, "flied" is not the past tense of "fly".
@Blue0Bull No, let's leave it up, there's no drama so far and this is an important point to make.
@DarthAbhinav Good to know. Let me know if you get around to using the autocannon.
PS it's "flew" not "flied".
@Pilotmario See also this.
Morpheus: What if I told you that you've been living in a dream world your whole life? That in SimplePlanes, while you believe that you are bound by "normal" rules of aerodynamics -- there are no rules. What if I told you that in SimplePlanes, you have the power to make anything fly.
Neo: Whoa. Why do my hands hurt?
Morpheus: You've never flown using a keyboard before.
Neo: I know XML!
Morpheus: Show me.
@Pilotmario
This is corruption, pure and simple.
@Treadmill103 Sunday? At SledDriver Industries, it's surreal time, most of the time.
Well, this is disappointing. I build a freaking hovering autocannon that fires Boom 50s at 300 rpm. I post a large warning not to crash it. And all the comments are about crashing it.
@KSPFSXandSP @XxMlgSwegxX @DarthAbhinav
@GermanWarMachine I guess I should have called this the "Can you fly this?" challenge.
@DarthAbhinav As the doctor said to the patient, "Well, don't do that, then."
@ForeverPie I originally built this as a 200-shot weapon, but it was too laggy.
"There's no kill like overkill" -- Clausewitz
Screenshots
@Maxwell1 It's really very easy to control as long as you don't build up too much speed. To get the hang of it safely, rise up high enough and get away from land. Then practice moving around until the controls become familiar. Then proceed to blow stuff up...
@Maxwell1 Hope you didn't give up after that. It's a lot of fun to use...
@ProKillaV12 Nope, no effort at all. That's why anyone can do it.
@Blue0Bull @weisofns @DarthAbhinav Thanks.
@Z3RO Thanks, I might try that.
@KSPFSXandSP Clearly there is erosion on the port side, so no. There are sometimes fluctuations in the hyperdrive field. The important thing is that it came through -- and still flies controllably.
Screenshots
@BACconcordepilot That would be funny, but the waveform that we see in audio applications is a subset of the audio information, showing amplitude but not frequency -- meaning that the audio signal cannot be reconstructed from a graph like that.
Thanks, @Ihavenorealideawhatiamdoing
@BACconcordepilot It does, doesn't it.
@Sarpanitu I can't stand the noise and low performance of props, so that's probably not going to happen.
Thanks, @HKAerodynamics
@OverlordAeronautics2 Thanks
@OverlordAeronautics2 Hey, I'm making high-quality, free content for the game. Why would you want me to stop?
@DarthAbhinav Some people say work hard, others say work smart. But when you do both together, the combination is unbeatable.
@FlyingThings Quite a few, as the degree of erosion and warping indicates.
@FlyingThings My idea is that when these craft go through hyperspace, something... eats... at them. They go in pristine, but when they come out they look shredded. The only way to cross hyperspace safely is to make sure your ship has enough sacrificial metal to get you through.
Thanks, @DarthAbhinav @DJ123
@GermanWarMachine It was just a joke, mein freund. And maybe it's time for an avatar... I'll think about it.
@GermanWarMachine It's not the size of the brake, it's the size of the gun that counts...
Very good build, especially for a newbie. That's one happy-looking dragon.
@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.
I thought it could do with a better muzzle brake.
@DarthAbhinav Thanks. Come for the cool builds, stay for the vocabulary improvement.
@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.
@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
@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.)
@FGW2014 Well, it does scintillate in the sun...
@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.
@GermanWarMachine But the cannonballs have cameras, so try firing one and see if it causes the fleet to render.