I wonder why Squad doesn't want to give us a dV and TWR readout

[nathan1]

Part of the complication isn't just calculating the values but making sure that the information is displayed in a way that's understood by new players. Specifically vacuum dv vs atmospheric dv is a complication I haven't seen mentioned yet in this thread. If a new player is told their rocket has 3400m/s dv because their rocket has 3400m/s vacuum dv, but they fail to make orbit around Kerbin then they might conclude something's wrong with the game (especially if they're not the kind of player who frequents forums or downloads mods).

Including a dv readout in stock is an entirely different beast from including it in a mod: you know someone who downloads a mod is the kind of player who will look outside the game for more info to at least some extent (because they downloaded the mod in the first place), but some players who play stock wouldn't even think to look on a forum or download a mod if something isn't working. Mod-downloading forum-goers are not hurt by having to download a dv-readout mod, but a half-hearted dv implementation in stock could be misleading and confusing to new players.

Note that I am not arguing that Squad shouldn't add a dv readout. I'm only pointing out yet another complexity that Squad will have to take into consideration for implementing it. I agree that it should get added at some point, but I have no problem with Squad prioritizing other things.

[OrbitalBuzzsaw]

On March 31, 2016 at 0:32 PM, Hcube said:

I don't understand how we can have a ∆v readout for manoeuver nodes and kspedia explaining what it is, and yet we can't know how much delta V our ship has. It makes literally no sense to me

 

EDIT : i'm talking about a gameplay point of view. Not about technical doability of a ∆v-meter. Gameplay wise, i think that this situation is just like having the pricetag but being unable to look how much money you've got in your wallet

Yes, agreed. Stock KER!

[Nich]

Am I the only one who thinks KSP is one of the best educational games to have come around in the last 10 years?  It is supposed to be difficult just to get to orbit, making it to the mun takes all kinds of understanding of basic concepts, landing on other planets takes lots of math the students get to learn.  Teach a man to fish.....

 

First off Thrust is required to determine the equivalent ISP.

Also your pseudo code is laughably terrible.  You have no for each loops, no tests for decouplers or fuel lines, you never figure out the mass of available fuel which is a challenge in its self.  For example I have a 5 engine lifter.  1 main sail and 4 skippers.  2 skippers are set at 95% thrust and 2 skippers are at 80%.  Each engine has 20t of fuel and tanks above it.  In addition the 95% skippers feed the 80% skippers and the 80% skippers feed the main sail.  Finally you also have 2 , 20t fuel tanks feeding the main sail.

This is very complicated and I honesty don't even know where KSP would have the main sail pull fuel from as it has 2 options rather then the normal straight line.  And remember the code had to do this without any prior knowledge of the craft.

 

Also have the same code calculate the DV of a lander can with an FLT-200, fuel cell array, a .625m zenon tank and an ION engine. 

Edited April 3, 2016 by Nich

[Padishar]

6 minutes ago, Nich said:

Also have the same code calculate the DV of a lander can with an FLT-200, fuel cell array and an ION engine. 

0 m/s, you forgot the Xenon...

(And no, neither KER or MJ would try to do this, they don't run fuel cells during the simulation, they just assume you have all the EC you need).

[Nich]

Ha ha thanks lol

I was actually a little surprised it "looks" like KER does my ugly asparagus correctly however I don't feel like testing it or doing the math by hand.  I also forgot to test if fuel flow works based on staging or purely on distance from the tank (furthest first).  Sadly my ION did not reduce the ISP to account for LFO in the array but to be honest I never expected that as it gets indeterminate once you add solar panels and have 2 electricity sources.  In this case your ISP would change based on the throttle distance to the sun and angle of the solar panels.

 

Edited April 3, 2016 by Nich

[John JACK]

34 minutes ago, nathan1 said:

If a new player is told their rocket has 3400m/s dv because their rocket has 3400m/s vacuum dv, but they fail to make orbit around Kerbin then they might conclude something's wrong with the game

But a new player is not told that they need exactly 3400 dV to make orbit. That value or dV map is not stock, and should never be stock. But even new player should be able to figure that (for example) 3000 m/s of vacuum dV get rocket to edge of atmosphere, 3500 suborbital, 4000 is orbit with good piloting and 4500 allow for most errors.

4 minutes ago, Nich said:

It is supposed to be difficult just to get to orbit, making it to the mun takes all kinds of understanding of basic concepts, landing on other planets takes lots of math the students get to learn.

Nope. It's supposed to be fun.
Good game is easy for beginners and progressively more harder to offer challenges for seasoned players. And any game should not take a lot of math just to make simplest things work. Math and studying theory should help make late game — not possible at all, but more efficient.
It's arcade vs simulation holywar all again, and you tell that a cartoonish game without n-body physics should be harder that real life.

13 minutes ago, Nich said:

Also your pseudo code is laughably terrible.

That was not pseudo code, that was a general description of what draft for a simpified base for a pseudo flowchart for that code should be like. I'm not a programmer, I do not work for Squad or even do not code for money or for fun. Thought I do understand logic and sequences. And I do have a slide rule.

As for your lifter, it's not complicated at all. Fuel ducts just pump fuel in direction of arrow at very high speed, until one tank if empty or other is full. At first fuel only from 95% skippers will be used for all engines. First 2x20 t used — check mass, praise Tsiolkovski, drop stage. Second fuel from 80% skippers tanks goes to three remaining engines. At last, you have just single stage of Mainsail with full tank. You have dV values for all stages, just add them for total amount.
Right, late or early staging will lower real effective amount of dV. But here comes trial-and-error™. Determining right safety margins and factor of ignorance is left to player, a game just do numbers.
And code DOES has prior knowledge of craft. All parts, their hierarchy, tweakables, routing and staging already are right there in code.

15 minutes ago, Nich said:

In this case your ISP would change based on the throttle distance to the sun and angle of the solar panels.

Well, there is no general order to forbid being Kerbal.

[Nich]

42 minutes ago, John JACK said:

 

As for your lifter, it's not complicated at all. Fuel ducts just pump fuel in direction of arrow at very high speed, until one tank if empty or other is full. At first fuel only from 95% skippers will be used for all engines. First 2x20 t used — check mass, praise Tsiolkovski, drop stage. Second fuel from 80% skippers tanks goes to three remaining engines. At last, you have just single stage of Mainsail with full tank. You have dV values for all stages, just add them for total amount.
Right, late or early staging will lower real effective amount of dV. But here comes trial-and-error™. Determining right safety margins and factor of ignorance is left to player, a game just do numbers.
And code DOES has prior knowledge of craft. All parts, their hierarchy, tweakables, routing and staging already are right there in code.

Well if fuel lines transfer fuel then wouldn't the main sail pull fuel from both the external tanks and 95% skippers at the same time?  This means that the amount of fuel used from the extra tank would be dependent on the 1/2 the fuel flow of the of the mail sail, the fuel flow of the 80% skipper and the 95% skipper and the amount of fuel in the 20t tank.  so your rocket equation calculation would be 9.81*equivalent isp(calculated from another function)*ln(ratio of 20t+mass from external tank used).  However I required knowledge of the stage to write that equation so unless I programed it ahead of time to account for that corner case my code would not be able to calculate the dv of that stage.  In addition the Equivalent ISP function would require arguments passed to it for engine 1, 2, 3, 4, and 5 isp and thrust.  Luckily in most programming languages you can pass array with a (nearly) unlimited number of entries and the equivalent ISP calculation is just a sum of ratios.  However if you had to do something different depending on the number of engines you would then have to overload the function and write each case by hand.  If there are infinite possibilities you would have to write infinite overloads to cover them all.

 

At least you stated your not a programer so I understand your ignorance but what you are doing high level conceptual thinking which is very easy for humans but extremely challenging for computer programs.  This is why AI is so challenging.  They can only do what they have been told to do.

 

I will put it another way.  Curing cancer is easy all you have to do is remove the cancer cells.  So why has the medical community spend billions of dollars with some of the brightest people on earth and they still have not been able to cure it?  Because it is not easy....

Edited April 3, 2016 by Nich

[John JACK]

4 minutes ago, Nich said:

Well if fuel lines transfer fuel then wouldn't the main sail pull fuel from both the external tanks and 95% skippers at the same time?

Right, that asparagus is slightly more complex. But you can still count fuel flows from all tanks, divide it by fuel consumptions of relevant engines, and get a time to first checkpoint, when some tank goes dry, and that gives a "craft dry mass" for that step and "craft wet mass" for next. I suppose, fuel flow in ducts is fixed, and one engine will drain fuel from two ducted tanks symmetrically. There is fuel flow logic, it works in game, and developers surely can apply it to calculations.

There is a finite number of parts, so no infinite possibilities here. Just some common cases, some uncommon cases, and other cases that better should be left unmentioned. No need for AI here, just a flowchart to handle possible cases. As far as I know, that's everyday work for programmers, not something esoterical.

14 minutes ago, Nich said:

Curing cancer is easy all you have to do is remove the cancer cells.

Your argument is invalid. Living body is [adjective] complex up to atomic level, very poorly documented and somewhere even unobservable at all. It's not infinite, but close to it. A game is at contrary a finite, legible, structured (or I hope so)  code that you can just take and read. Even not too huge, compared to operating systems, graphics processors and whatever, and without decades of legacy. Getting some numbers from that code and processing them is possible even for outside addons, and is surely possible and easier for authors. ONLY problem here is not to actually plan and write a code, but to pretty please convince Squad to find some time to do it.
And telling that coding a dV readout is impossible is just illogical. It is already done even not once. If you fear that stock dV readout will somehow spoil your fun challenge, surely there will be an option or a mod to hide it.

[Snark]

16 hours ago, John JACK said:

There is a finite number of parts, so no infinite possibilities here. Just some common cases, some uncommon cases, and other cases that better should be left unmentioned. No need for AI here, just a flowchart to handle possible cases. As far as I know, that's everyday work for programmers, not something esoterical.

Well, maybe not esoteric... but it's really freaking hard.  As has been observed on this thread before, the Lego-like freedom of KSP means that there are a really insane number of possible combinations and permutations to try to deal with.  If you're not a programmer, and/or if you've never written a mod for KSP, then you really have no idea just how hard it is.  I mean this in the nicest possible way-- it's one of those things that's just a whole lot harder than it looks on the surface.  Really.

I have a bit of an inkling of this, since I wrote BetterBurnTime, which does a lot of this sort of calculation.  I've been a professional software engineer for a very long time, and even I was astonished at just how complicated it was to do something as simple as "calculate how long this burn will take."  A project that I anticipated as being quick and simple turned out to be many hundreds of lines of code.  And that's for a simple implementation-- for example, BetterBurnTime doesn't even try to do anything with fuel flow or staging.

But if you don't want to take my word for it, then don't listen to me-- I suggest you listen to @sarbian instead.  This is someone who has to solve this problem for real, not just chip away at the edges of it, like I do.  If you don't recognize his name, perhaps you'll recognize the name of a little mod that he's responsible for.  It's called MechJeb.  Perhaps you've heard of it. 

If you'll just scroll up this thread a little ways, you'll find some nice posts from sarbian explaining just why this is a lot harder than you seem to think it is, though he expresses it better than I do.

TL;DR:  if sarbian tells you that it's really really hard to do, you'll save yourself a lot of bother if you just take his word for it.  And if you don't want to believe him, then I suggest going off and writing a MechJeb yourself to get a feel for how hard this is, and then come back and we'll have that discussion. 

[tater]

It's funny that people who actually code, and actually code for KSP are telling others that dv is non-trivial... and people who have no idea what they are talking about then tell them it's somehow easy.

Kind of boggles the mind, or maybe I'm just simple-minded.

Is one of the problems spaceplanes? You can certainly calculate the propulsive dv, but what about any lift components? What assumptions do such calculations make regarding ingested air used as propellant, and how that changes with density (altitude) and speed?

[regex]

11 minutes ago, tater said:

It's funny that people who actually code, and actually code for KSP are telling others that dv is non-trivial... and people who have no idea what they are talking about then tell them it's somehow easy.

What really gets me is that the people who think it is easy or that we NEED IT NAO simply ignore the words of the people who have done it before in favor of "but my way is so much simpler!"  I mean, you'd think those people who've gone before would have prefered the simplest solution, no?  Makes programming so much easier.

Quote

Is one of the problems spaceplanes? You can certainly calculate the propulsive dv, but what about any lift components? What assumptions do such calculations make regarding ingested air used as propellant, and how that changes with density (altitude) and speed?

The problem is KSP, it's in how many ways you can combine the parts (E: and how the parts are stored?), really has nothing to do with (relatively) easily solved maths.  

Edited April 4, 2016 by regex

[Snark]

14 minutes ago, tater said:

It's funny that people who actually code, and actually code for KSP are telling others that dv is non-trivial... and people who have no idea what they are talking about then tell them it's somehow easy.

I confess that I occasionally have similar thoughts myself, but I find it hard to blame those folks.  The fact is, software is one of those things that's a lot harder than it looks.  It's very difficult for someone who hasn't actually done it to appreciate just how hard it is, so I find it understandable that people who've never done it can make that kind of mistake.

And not only is coding a lot harder than it looks... writing commercial production software is a lot harder than just writing code for fun as an amateur, in ways that also aren't obvious until you've done it.  So there are plenty of eager coders out there who have learned a programming language, and written some, and think they know how hard this is, and then they'll say "why don't you just add feature X".  And it's actually a lot harder than even they realize, simply because of the difference between production software and artisanal code.

For example, my mod BetterBurnTime works great (if I do say so myself), and I love using it myself, and I've gotten some nice feedback from users that a lot of people really get a lot of value out of it.  But it's not stock, and shouldn't be stock, because it's not production code.  I get away with a lot in BetterBurnTime precisely because it's a mod, which I couldn't get away with in stock.  I won't go into details here because it would be multi-paragraph rant.

But the moral of the story is... not only is it hard, it's hard to understand why it's hard.  So when I see someone saying "why don't you just do X?" without having any idea how hard X is, I'm inclined to cut them a bit of slack. 

 

14 minutes ago, tater said:

Is one of the problems spaceplanes? You can certainly calculate the propulsive dv, but what about any lift components? What assumptions do such calculations make regarding ingested air used as propellant, and how that changes with density (altitude) and speed?

That's a whole other ball of wax.

My post just above, in which I rant about how hard this is... is true even if there were no atmosphere anywhere in KSP at all and all engines have fixed Isp that will never change.

That is, it's incredibly hard even in a very oversimplified ideal case.

Throw spaceplanes, variable Isp, lift/drag, etc. into the mix and you change it from something that is merely very very astonishingly surprisingly hard into something that's... well... I hesitate to say "impossible" because that's a pretty strong word, but anyway, a whole lot harder than what I've already said. 

[Kerbart]

16 minutes ago, tater said:

It's funny that people who actually code, and actually code for KSP are telling others that dv is non-trivial... and people who have no idea what they are talking about then tell them it's somehow easy.

Kind of boggles the mind, or maybe I'm just simple-minded.

Is one of the problems spaceplanes? You can certainly calculate the propulsive dv, but what about any lift components? What assumptions do such calculations make regarding ingested air used as propellant, and how that changes with density (altitude) and speed?

The problem is that, for a mod, and especially for squad if it's stock, you'll have to get it right “all the time.” For 95% of the cases it's easy. Then there's a remaining 4% that's hard and then there's this one percent that makes you go “shut the front door!”

Calculate the dV manually for a asparagus-staged stack with some additional boosters thrown in  at launch.  Angle the boosters at 15% for no reason. Actually, have one of them point upside down. Why would you do that? I don't know, but I do know that the guy who does it will complain that his dV readings are wrong. And that is why the dV calculation is hard.

Edit: Snarked by @Snark!

Edited April 4, 2016 by Kerbart

[tater]

Yeah, an earlier post of mine said much the same about crazy crafts people make. I've never made anything in KSP that doesn't look pretty much like a RL rocket, so I have some issues even imagining some of the nutty craft I have seen here.

Suffice it to say that if a few of the people that have posted in this thread say it's hard---I believe them.

[John FX]

Personally I have no doubt it is hard. Off the top of my head I`d imagine it would involve making a whole craft part and staging tree (recalculating all the fuel flow rules on the fly which may not be exactly the same as they are reported to be in certain cases in the documentation) again and again just to add up the resulting output numbers for the rocket equation. Anything less would mean you miss a fuel flow route or staging event. In real time. With no errors.

On the flip side it would only need doing once unless fuel flow rules change and Squad have access to the internal code that deals with fuel flow etc so that would help a bit. Not enough to stop it being hard though.

What I have doubt on is whether a few tweets from max still mean anything now he has left and the feature keeps getting put back to later updates.

[cantab]

There are in any case situations where it's impossible for a delta-V calculator to give a correct result unless the player also inputs a complete flight plan. Most obviously, Apollo-style missions.

[Empress Neptune]

I think the best solution might be to give us a method of calculation and then explain what the method is and when it won't work.

Even a dV reading that works only 80% of the time would be helpful. If it is clear when you're entering one of the 20% cases where it won't work, there shouldn't be much of a problem. I think not having any way to even estimate craft performance is a bigger issue than getting a 100% reliable dV reading.

[Markush100]

I think its because the majority of people that play kerbal space program just want to mess around, and crash rockets. If you want to actually get into the advanced planning you would install KER. Its not like its hard to do that anyway.

[John FX]

20 minutes ago, cantab said:

There are in any case situations where it's impossible for a delta-V calculator to give a correct result unless the player also inputs a complete flight plan. Most obviously, Apollo-style missions.

Yeah, I have to build each part by itself (CM,LM) and look at the Dv then assemble the top and put it on the lifter as a single unit and figure lifter Dv.

As you say, without telling KSP that this part stages then connects to this part with docking it`s impossible.

[NecroBones]

 

Obviously dV calculations can get hairy very quickly, when you start taking into account staging, docking ports (including stages that can undock and re-dock later, such as landers), fuel flow, and so on.

 

As I've said in other threads before, I personally would be happy if stock just provided a "current dV" display, to go along with the dV requirement displayed for maneuvers. That is, just a simple dV calculation based on currently active engines, and the fuel available to them currently. Ignore stages, fuel that's unreachable due to those stages, inactive engines, and so on. I don't think the player would require much time to get used to the idea that the number is not a total, but rather just what the current configuration can do, and will change when they stage, or eject their drop-tanks, etc. In fact, I think that would be rather educational.

 

Some complexity still creeps in, in a few ways of course. Engines may not all be facing the same way, for instance, and cosine losses might need to be taken into account, which is doable by summing the thrust vectors and comparing the resulting magnitude to the sum of the thrusts. Also, due to fuel lines (or radial placement, etc), some engines may have access to more fuel than others, which means breaking down the relative potential burn times for engines and calculating dV in several batches to be summed afterward.

 

I would be OK with such a simple display, and still have the option to use mods such as KER or MJ if I want more detail. (but yes, I too would love a fully developed feature here too, it's just that a "current configuration" display is technically much simpler, and fits with Squad's more minimalistic approach). In any case, I think it's a bit of a crime to leave out dV entirely, when we're talking about spacecraft. But maybe that's just me.

 

 

[NathanKell]

To be clear, just because it's hard doesn't mean we're not going to work on it. I don't believe our prior statement of "it's coming" has ever been rescinded, and I certainly would like to see it in (and therefore would probably get drafted ). Also, Jim's planning to rework resource flow for the next update (per dev notes) and that really goes hand in hand--indeed, that those things are so tied together, and tied to the burn indicator, is the main reason I didn't try to fix the burn indicator for 1.1, it'd be wasted effort.

 

Now, on the "harder than it looks" front, let me give a quick example on why it's not merely hard, but also a question of design assumptions rather than just "getting it right." Let's consider hot-staging.

Here's a simple staging stack

interstage Decoupler

upper Engine

lower Engine

 

This stack involves firing the upper stage's engine shortly before decoupling. Now, it's interesting to note that MJ and KER handle this case differently. KER says "OK, we'll stage and then burn the lowest stage until it flames out, then stage and burn the next stage until it flames out, then do all that one more time." This results in its sim thinking the upper stage engine burns all its propellant with the lower stage still attached. Mechjeb, by contrast, will always stage if the next stage will not make things worse, so it will assume that decoupler is staged immediately following upper engine ignition.

Now, in the case of hotstaging in RO, MechJeb's assumption is correct. However, in other cases where one has a staging setup like this, its assumptions may well prove incorrect. See the issue? :]

[pandaman]

I'm not sure how feasible or acceptable this idea would be for stock, or if it's even realistically possible, but...

Assuming a stock Dv calculator that can work to a similar accuracy as KER and MJ is possible (which I guess is probably not an unreasonable assumption) then how about it flagging warnings if it's too complex to be accurate, but it gives a 'best estimate' which may not be accurate, but closer (and better) than nothing at all?

Crude Example, to illustrate the concept...

Top stage.  Payload with single fuel tank and one LV909.

          calculate Dv and display it next to the staging icon in green.

Lifter portion.  Two stacked tanks with Mainsail and four SRBs on radial decouplers, all staged to be fired together on launch.

          Calculate Dv, display it next to staging icon in red with warning triangle, clicking the triangle opens a dialogue box that says something like 'This value may be inaccurate'.  If possible it could go into a simple explanation as to why, like - 'Separating SRBs late will reduce available Dv', or 'Complex fuel flow makes calculation unreliable'.  This would then give the player a sensible estimate, but also point out that it not 100% reliable.  

 

Any 'burn time remaining' info could be stated as 'estimated remaining burn time at full throttle' which still gives a fair idea and (presumably) helps avoid calculation errors.

[John JACK]

5 hours ago, tater said:

You can certainly calculate the propulsive dv, but what about any lift components?

Does dV make any sense for spaceplanes at all? In space(!) there is no drag or lift so spend dV add directly to your current velocity vector. In atmosphere at some point all engine impulse goes to offset drag and velocity remains constant. Or you can change velocity vector without spending dV at all. I think, it will by right either give unreachable but mathematically correct value, like KER, or replace dV for atmo engines with just maximum burn time and let players trial-and-error™ their planes themselves.

5 hours ago, Kerbart said:

Angle the boosters at 15% for no reason. Actually, have one of them point upside down. Why would you do that? I don't know, but I do know that the guy who does it will complain that his dV readings are wrong.

If the guy can calculate dV of asparagus with boosters manually — and puts a booster upside down just to complain about wrong readings, that guy is a troll. Best way to treat trolls and excessely kerbal rockets is to just ignore them. Trial-and-error again — if your rocket does not fly straight,  you do not need a dV value for it.
dV readout must not account for flight plans, manual control or just poor piloting. It's a convenient tool to save rocket builder many minutes of slide rule shuffling and back of the envelope scribbling, not less, not more. It shows maximum design performance in ideal conditions. You surely can get less dV from a design, but you never will get more.
Understanding dV calculation limitations and inaccuracies is a challenge by itself — in a late game for experienced players. But to newbies it will be indispensable tool to tell if they will actually go to space today without minutes of errors and ragequit to library for studying rocket science demand a refund. Coding dV calculator may be hard, but a dV readout will may game easier where it need to be easier and more fun and a even better game.

5 hours ago, regex said:

What really gets me is that the people who think it is easy or that we NEED IT NAO simply ignore the words of the people who have done it before in favor of "but my way is so much simpler!"

The simple way was suggested as a, surprise, simple way. If a simple way is not enough for a production game — that's okay. Right way is better than simple way and doing anything possible right is a right way by itself. But one cannot help but wonder, how many lines of code could be written instead of lines again and again telling how exactly hard it must be. Coding dV readout for KSP is harder than curing cancer, going to Moon, or coding a KSP.

2 hours ago, NathanKell said:

To be clear, just because it's hard doesn't mean we're not going to work on it.

That's the best! We know that you can do it and we hope that you will do it. Just little whine to remind that we are waiting. Also a whine sometimes gets really cool answers like resource flow reworking plans or maybe even provides some unheard of suggestions.

[regex]

4 minutes ago, John JACK said:

But one cannot help but wonder, how many lines of code could be written instead of lines again and again telling how exactly hard it must be.

No devs are wasting any more lines writing to tell you how tough the feature is than needed, they're all working on polishing up the major codebase update they've recently done.

Rest assured that your continued whining has impacted development time very little.

[Kerbart]

8 minutes ago, John JACK said:

If the guy can calculate dV of asparagus with boosters manually — and puts a booster upside down just to complain about wrong readings, that guy is a troll. Best way to treat trolls and excessely kerbal rockets is to just ignore them. Trial-and-error again — if your rocket does not fly straight,  you do not need a dV value for it.

I'm not a troll. I happened to have a very large booster that was using a Flea as a sepratron (this way it would deorbit itself after staging in orbit).  And no, I was not complaining about it. But if you've been hanging around the forums here long enough (or for the past three weeks) you know that people will complain about anything and make a big deal about it. The point though, is that players can come up with designs that, when writing code for a dV calculation, you probably do not think of. That has nothing to do with trolling.

The question (thank you for completely ripping my text out of context, by the way) was "why is it so hard? It doesn't seem hard to me" and I used this as an illustration to show that yes, it is hard, because there's all these kind of silly cases that you cannot possibly make up when writing the code to cover those scenarios.