I'm not entirely sre if a whole physics engine is necessary: everything is "gridded", thus each square can only have two states: on fire, or not on fire. Figuring out how the fire spreads can be done just as well with somthing that makes all  burnable squares around a burning square catch fire after X turns.

Damnit! Beat to the punch by the 15 year-old yet again! Using the physics engine to determine things like the rate of spread of fire is overkill. It would make more sense if the world of Elemental were continuous and not grid-based, but it is grid-based and thus determining how things spread doesn't need to be that complex. To determine how fast fire could spread, they could just have some parameter for rate of spread (# of tiles/turn, modified by a little bit of randomness and by type of terrain - it should also be probabilistic imo). This would be just as effective as using the physics engine, but much easier to code, much easier to mod, and much less computationally expensive. 

Using the physics engine to determine things like the rate a fire spreads "can" be overkill. I believe it would be easier to make use of Havok in this particular situation rather than hardcoding it from scratch. Truefully, I doubt either would take very long but if you did the coding using Havok you could potentially do some really cool stuff that would take a lot more work to perform if you coded it from scratch. 

As for the grids within Elemental do we know exactly how they will be handled? I mean is the smallest grid the one the player interacts with on the cloth / tactical map or are there smaller grids within those grids that only the program interacts with? Are grids treated as open or closed systems when something like battles or magic spells take place? I personally had though each grid could be linked at the cloth map / tactical level then treated as a kind of open system filled with space. If this was / is the case the use of Havok for spell effects and other calculations makes perfect sense to me.  

I guess what I'm saying is if the cloth map / tactical map are the lowest levels of their respective systems you could go either way but I would still lean towards Havok. If there are smaller non-player interactable grids that make up the lowest levels or the grids can be linked and treated as abstract closed / open systems using Havok would be the best way to go in my opinion. 

I don't understand what you're saying. Could you explain what you mean regarding the grids in clearer words?

And, I don't think it's as simple as saying "let havok do it!" For one, as far as I know, havoc doesn't simulate fire (maybe I'm wrong?). Secondly, having a physics engine that determines things like the rate of spread of fires IMO is overkill, unless you try to make it actually realistic - in which case the simulation is going to bog down slower computers. Secondly, I'm not sure how a physics engine would be used to simulate something in turn-based time. Physics doesn't work that way - the only thing I can think of is to have each turn last a certain number of physics engine seconds, but that could cause huge problems (different processes taking place physically on totally different time scales, for example, among other more subtle issues).

Having a physics engine deal with dropping a mound of dirt from the sky and turning it into a hill, spreading fire, and all those things over the map seems like it'd both be overkill and would in some cases detract from the game. The mound of dirt in particular, as in the end it wouldn't look like a hill it would look like a mound of dirt. Having physics tied into spells and such on the tactical map would be very neat, though. I'd love to to see fireballs, lighting and explosions throwing units around.

 

What I was trying to convey is we don't know what the smallest unit of game-play for lack of a better word will be in Elemental and how it will function. It could work like your normal grid based game or it could be something we haven't seen before. I was saying if it works like a standard grid based game it wouldn't matter so much but if it is something more complex like grids within grids or joining multiple grid sections together to make an open / closed system I feel the argument for Havok becomes stronger. 

I have never worked with the Havok SDK or Havok in general save for interactions with games. So I'm not in a position to state anything with absolute authority. I do know a bit about game physics though. When we are talking about physics as applied in a video game we are really talking about nothing more than calculations. Using fire again as the example what calculations would you really need for software to simulate it spreading? You would need to know the source, initial fuel, potential fuel in the vicinity, and wind direction. Nothing more is required unless you wanted to get really complex.

Havok to my understand excels at performing parallel calculations which is a big part of physics. I believe what sets physics calculations apart from other calculations is the potential for variation. For example if you shoot a missile at a wall in most video games the wall either falls down the same way every time or is unaffected by the missile. With a physics engine running you can have individual calculations on each piece of debris created by the missile causing them to move realistically through the air. Each piece affected by the missile however would still share a lot of the same code with variations here and there.

Also, I believe a physics engine like Havok could easily be adapted to work with a turn based game. All you would have to do is break up the calculations into stages where each turn a fire could only spread so far or whatever. This would be even easier if the physics engine was able to complete all the calculations involved before any action had been taken. You would have to set some base values for per turn calculations I suppose but I kind of addressed this in my original post on this subject.

 As for the mound of dirt I think you’re confusing the physics engine with the graphics engine pigeonpigeon. The physics engine to my knowledge doesn’t control how something will look it only provides data on how things would act under certain circumstances with certain rules being applied. You could have the hill created look like whatever you want the physics engine would only really come into play when it hit the ground or something interacted with it. For example when it hit the ground the physics engine would provide data to be interpreted by the graphics engine on any pieces of the hill that should fall off, the amount it should sink into the ground, or the amount of dirt and debris kicked up, etc. It would still be up to the graphics engine to draw or not to draw all of these things even if the data was there to be used.

 You also need to remember that almost everything we have talked about so far is only 2nd order physics (eye candy) not much being discussed here is 1st order physics (affects game-play). I really don’t think making use of Havok or other physics engines is quite as complex as you seem to think. The whole point of licensing graphics engines and physics engines is so you don’t have to use time and resources building them yourself. Using Havok in as many places as applicable increases the amount of worth you got out of buying it. 

Edit: My quote function apparently no longer works otherwise I would have made this a bit easier to ready. 

 

I see no difference. Whether it's a regular grid, a grid-within-a-grid (which is essentially just a smaller grid!), or some small variation on a theme I think just having things like rate of spread of fire be determined by a spread factor modified by some randomness, terrain type and other enchantments will work as well as using physics but with much less overhead. Such a method will look more than good enough, function wonderfully and be very simple to calculate and display.

Game physics is just calculations, because physics itself is just calculations Even if havok is capble of dealing with fire, you are completely right that it would require the source, initial fuel, potential fuel in the vicinity, wind direction... It'd also have to know distance between fuel sources, factors that would put out fire, etc. For one, this would require every object or at least every terrain tile to have some sort of 'fuel' property, it would require them to put in Wind direction for every tile - having factors like these (and many many others if they want their spell system to be very general) would be insane (and having this many more parameters to track for each and every tile and possibly object would probably not be appreciated on computers with less memory). AND there's the whole part about, being tile-based, each discrete portion of land must either be on fire or not on fire, and it would evolve in large discrete intervals: using physics for this would be a crazy amount of overheard for no gain over a simpler system...

You could easily adapt a physics engine to work on a turn-based basis, but there isn't much of a point. You won't even notice the physics happening if it happens in turns. And even if SD could manage to solve the time-scale problem (which I suspect wouldn't be that easy to do), there's also the issue of the fact that discrete physical evolution using large time intervals can result in undesirable effects - important or expected effects but not ever occur simply because they happened somewhere inside those long intervals. A fire that spreads or burns fast enough could result in a tile being pristine one turn and burnt to the ground the next, without ever having been on fire, for example.

That is not completely true. If you want to drop a pile of dirt and have it dynamically turn into a hill, shaped and sized based on the amount of dirt and the elevation and shape of the land below it, then the dirt must be treated as lots of particles by the physics engine (otherwise it just wouldn't work right). After stressing your computer for a bit, the dirt would fall and make a convincing mound of particles. The graphics engine would then have to render all of this - but during the falling process it'd have to render the individual particles, but once they settle it'd have to somehow make them look incorporated into the terrain. You lose some graphical freedom for any animation that uses a physics engine, particularly if you want something to be fine particles one moment and a cohesive solid mass the next (the other way around isn't nearly so difficult, though).

That is not true. Having physics determine the spreading or burning rate of fire affects gameplay. Having physics determine how large a hill and what shape your magically dropped ball of dirt will become affects gameplay.

Using Havok in as many places as applicable increases the amount of worth you get out of it, but using it in places that you shouldn't just because it'll increase the worth you get out of it is downright silly. Game physics is a wonderful innovation and can be used to better gameplay and graphics to enormous extents in many situations, but there are still many situations where physics will not help, or will not help enough to make the extra computing power or memory requires worthwhile. The beauty of physics is in the exquisitely fine details. Physics is wonderful for smashing walls at 60 fps, where a non-physics method would look unnatural. However, if you smash that same wall at 2 or 3 fps, the differences between each discrete state are so large that you aren't gonna notice the difference. That is why things like turn-based fire spreading will gain nothing by having it use physics. Physics will allow a huge number of dirt particles falling from the sky to form a realistically shaped hill based on terrain factors (though it'd take some time to calculate if you include enough particles), but it would be supremely difficult for the graphical engine to render that information in a pleasing way (it could display the falling dirt well, and the final result well, but animating the transition would be hairy at best) - and I think a non-physics approximation would be more than sufficient anyway.

Just out of curiosity how do you think the "physics calculations" for spreading fire or creating a hill / mountain would affect game-play? I can see what they represent affecting game-play but not the physics calculations themselves for this sort of game.

At any rate I guess we will just have to agree to disagree on this point because the vast majority of what we are discussing I feel would only require a decent amount of unique calculations. The physics calculations for fire spreading and hill / mountain creation would be almost identical except for a few key areas that would add the element of randomness. Your point of view would make a lot more sense to me if this was an FPS or RTS. Maybe I'm misunderstanding the conversation but I just don't see how hardcoding a system for this would reduce coding overhead by such a drastic amount when I believe you could simplify the physics calculations to achieve the same result in less time since the code already exists largely.

I would also say physics in real life is not calculations but attempting to understand the rules that govern this plane of existence.  

 

Edit: I found a video of Havok performing fire spreading calculations in action. Far Cry 2 uses the Havok physics engine and I seriously doubt Elemental's physics calaculations would be supremely more daunting then this. Also, the guy who posted this video doesn't have some crazy high end gaming rig. 

Well, with the fire example: there is no wind (because i don't think that sort of weather detail COULD be implimented), and everything is limited to binary squares (ON fire or NOT ON fire), so the physics engine would have to perform the necessary calculations, then "round down" the results to the ON or NOT ON state for each square. And the result would be exactly the same: after a short, quasi-random number of turns, each flammable square that borders the flaming square would catch on fire. But it would be faster and easier on the dino computers to just have the code say "after a short, quasi-random number of turns, each flammable square that borders the flaming square will catch on fire", than going to all that trouble.

Umm... If physics calculations are used to spread fire, then how fire spreads will be determined by physics calculations. And how fire spreads is definitely an aspect of gameplay, it is not just graphical eye candy. If you drop a pile of dirt from the sky to create a hill and have the physics engine calculate the resulting shape of the hill, that affects gameplay because the shape of your new hill is very much an aspect of gameplay. You just buried a region of land whose shape and area is determined by the physics engine. That's not a bad thing in its own right, the bad thing about it is you can't just turn off this feature for lower end systems because it would actually affect gameplay, not just graphics.

Whether the code between spreading fire and dropping dirt from the sky is similar (and I would be shocked, there are no similarities in the ways they 'spread') is irrelevant. Falling dirt wouldn't give a crap about how much fuel there is, only about the amount of falling dirt and the local topography. My point is that using raw physics for all of these things would require adding very many extra properties to every terrain tile and possible other objects, something that low-memory machines will not be happy with (and it would also reduce the map sizes other people would be able to play well on). Then there's the issue of animating a giant ball of dirt falling from the sky using physics - it would be a very intense calculation. For it to behave and look at all like dirt you would need an enormous number of particles, and simulating that many particle interactions is not an easy thing to do, even when using simplified physics simulations like those of Havok. I doubt most regular people's computers could run such a simulation in real-time.

Through calculations and equations. Physics as it is today is a giant mathematical model designed to approximate the phenomena of the universe. Every physical law you've ever read in sentence form, for example, has a corresponding mathematical equivalent.

Ok, so at least we know Havok is capable of doing fire. Nonetheless, I'll bet you anything that the guy who posted that video has a computer that falls well above Stardock's intended recommended system specs, let alone the minimum requirements. Secondly, having fire spread in an FPS makes sense - it's done over continuous terrain at a high temporal resolution. In Elemental it would be over discrete terrain at extraordinarily low temporal resolution. Physics would add nothing over a simpler system, besides run-time overhead and some extra programming.

Secondly, I'm not convinced that tying all magic into the physics engine will make modding magic as flexible as some of you think. To do spreading fire, you need all sorts of special properties, for example. What if I make an iceblast spell that covers a region in ice? If you want the physics engine to melt the ice then you're gonna need some sort of heat property, as well as how much heat will melt ice how fast... Or if you want to make a spell that causes ice to spread out from one area, sort of like how fire spreads - how would you do that using the physics engine? My point is, so many different spells would require so many different properties in order to work with a physics engine that you essentially have to do all the 'hard-coding' anyways. The only difference is instead of having direct control over specifying things like "rate of spread: 0.5 tiles per turn, random factor: 0.5 tiles per turn", you'd be stuck with fiddling with all sorts of properties until you get the result you want. And ultimately, the physics would go completely unnoticed in the majority of strategic map spells due to the turn-based nature of the game.

Setting fire to a forest does one of two things from my point of view it either destroys a resource or damages building / units inside if forests are passible terrain or if they are impassible it creates a new path to march troops or whatever. The physics calculations for this have no impact on game-play. The hill / mountain creation is similar it creates a natural obstruction to the player that either needs to be removed or gone around. The physics calculations have no impact on game-play. I hadn't assumed you would be able to drop the hill / mountain onto towns, create an earthquake, or something of that nature. 

You misunderstood my statement which is partly my fault I should have worded it as follows. "The respective calculations for fire propagation and hill / mountain creation would largely be the same with only a decent amount of unique calculations for each action." As for extra properties being added once again I feel you are making it more complex than necessary. You wouldn't need that many variables / properties for each tile. Using Havok that option would always be there if you wanted to do more advanced things in the future but just to get the basic functionality we are talking about it would not be required in any shape or form. 

As for the video I looked at the guy's specs we are the same in every area except his processor is better (I have an E6400) and I have 4 GB of memory. My gaming computer is considered by the vast majority of gamers to be average / below average. As I said before I disagree with your point of view on this subject and there really isn't much more to be said. If I find some more data relevant to this conversation i'll be sure to bring it up. 

Lastly, mathematics is "one" of the ways we use to understand the universe. I don't personally consider it the only or best way. 

Climber: I think you have overestimate the cpu cycle needed.   Physics calculation is needed only when the spell is cast, and btw turns where the multiple turn effect (e.g. fire-spread) is still in action.  And most likely, most spell/effect will only affect a few to a few dozen tiles.
Once the calculation is made, it changes the tile data (that affect future gameplay) and the graphics engine make a representation of it.

Climber: Then again if certain spell/effect requires so many particle interaction, game designer/mod maker should not make such spell/effect out of the concern of cpu requirement.  There are probably way more material physics that does not require so much calculation than those need it.
To me, the physics engine in EWOM is a library of material interaction.  If there is no need for a particular interaction, there is just no code that describes it in the library.  And since it is a library any physics code is designed to be reused.


Climber: I regard TBS’s tile system as a representation of continuous terrain.  I don’t see why such distinction is relevant to this discussion.


Climber: My point is you’ll need to program this kind of ice melting mechanism regardless there is a physics engine or not.   Designing that piece of code into the physics engine will promote code reuse for similar effect in future.   How many properties the programmer factors in the code is his decision. 

The distinction is: while tiles do REPRESENT continuous terrein, they are not, in fact, the same thing.  A tile exists in any number of "states": on fire, covered in grass, has unit Y on it, etc. These states can overlap, but there is little in-between: you can't have a "knight on bottom-right part, upper section is on fire, lower-right corner has a tree" state. Thaus, it is simpler to just do things the old fasioned way tile-by-tile.

Are you kidding me? If you use physics to determine where and how fast fire spreads, it affects game play. You can't argue that. If you have one method that uses physics and another, semi-random non-physics method - they will not always produce the same result and so the effects will be different: different tiles will be set on fire, thus resulting in a different game. Therefore, this is not just graphical. You cannot just turn off the pretty physics calculations and be done with it, because then you're playing a different game! The differences might be subtle but are still very much there. And depending on how multiplayer is implemented, it could cause drastic out of sync issues. Anything that only affects graphics is something you can turn off for better performance. Anything that actually results in things playing out different by definition affects gameplay.

Likewise, if you make a hill by dropping dirt and let the physics decide the shape of the hill, you will get very different results than if you don't use physics. Even if you couldn't drop the hill onto towns (but why not?), it would create an obstacle of varying shape. The physics method would create a differently-shaped obstacle than the non-physics method - each method creates a different obstacle and so the player sees and has to deal with something different. This means that it affects gameplay, because with physics on and off the result is different.

Mathematics is ultimately the only method used in physics. We think conceptually all the time but unless we can put those concepts into mathematical equations and formulas, it is not physics. Whether you think it's the best or only way is irrelevant, because that's what physics is. Any other method of understanding the universe falls under philosophy or faith/spirituality (or both). I'm not saying any one method is better than the other (although I do have strong beliefs on the matter) - I'm just saying what physics is.

 

Ultimately, it all boils down to what Scoutdog keeps saying. You don't really gain anything by using physics like you're proposing. It doesn't add anything in particular over the much simpler methods - partially because of the tile-based terrain and partially because of the turn-based nature of the game. All you get out of it is a much more complicated and confusing system to learn before you can mod your own, creative spells. I think you actually retain much more versatility by using a simple parameter-based system like what I've mentioned before in this thread. Even if there is no default parameter to cover a spell effect you're looking for, I'd imagine it would be much easier to program in a new one of those than to get the physics engine to perform a brand new trick.

I just don't see how you think it will affect game-play. If I have a 10 tile map 5 of which have forest on them and I set one forest tile on fire. Using physics based calculation the fire would spread to other tiles adjacent to the one that has been set on fire. The path fire takes is very predictable and linear in nature. It couldn't jump over a tile unless a programmer took the time to create such an effect. Even if you expanded this to 1000 forest tiles and set the center one on fire anyone could accurately predict how the fire would move through the forest. It would expand in a circular shape until it consumed the forest. For the purposes of a game if there are no advanced weather features you could even ignore wind direction.

You could make a system to simulate this effect not using physics which would produce largely the same results with irrelevant changes in process.  I don’t think the physics engine approach of choosing which tiles to set on fire based on a simply calculation vs. a randomized system would effect game play. The end result would be the same if both were set to have the same constraints. If a LV 1 fire ball spell has the constraint of only burning a maximum of 10 tiles the process for each system would be different but the result would be the same. Hence it would not affect game-play.

Hill / mountain creation would have the same result it would not matter if you used a physics calculation to create it or a static system. If LV1 hill creation could only create a hill that was one tile big once again the processes for each would be different with the end result being the same. The only difference is with a physics calculation system you would get unique looking hills while with the other you would only get a number of pre-designed hills. This would not affect game-play.

I think you’ve overlooked the idea of constraints on everything. As long as the constraints are the same for both systems it doesn’t matter how each does it as long as they do it within the constraints. The resulting systems would only impact game-play if they had different constraints which I never suggested.

On the subject of physics I concede mathematics is the only method used by some people. Personally when taking physics classes looking at an equation or the math behind something rarely helped me understand the nature of an event. I always needed to understand potential reasons why first then the math would fall into place. I also disagree with physics being completely limited to mathematics. 

That's the point: you could get the same result using conventional algorythms, except it would take MUCH less time to calculate.

Ok let me make myself perfectly clear. I will state the advantages as I see it for having a physics based system for such effects.

1. Negligible increase in calculation time if done properly.

2. The code is already there to be manipulated thus saving time.

3. Allows for potential expansion to more advanced effects in the future. 

4. You paid for it might as well use it.

5. I have Intel stock, Intel owns Havok, what is good for Havok is good for Intel, What is good for Intel is good for my portfolio. (joke??)

Agree / disagree / whatever I've enjoyed the conversation none the less. 

1. You are forgetting the large amount of dev time needed to impliment something like this: and tose guys don't work cheap!
2. The code is now the ONLY thing that can be manipulated. That means that tose of us (myself included) who don't have the skill to actually write physics code but know our way around a text-based datafile are stuck. And anyone who can mess with the physics like that would most likely be able to create new standard algorythms anyway.
3. True, but so does conventional coding (see above).
4. Huh? I don't quite understand what you mean?
5. Joke.

4. Huh? I don't quite understand what you mean?

I was making reference to the fact that Stardock had to purchase Havok's physic engine. Since they paid for it and it would be well suited to this situation in my opinion they might as well use it.  

Edit: @ Scoutdog I would replace the word fact in your post with potential. 

Except for the fact that it's not well suited for this situation.

It appears this is largely a misunderstanding of what we mean by "gameplay." What I mean is, unless you intend to make an extraordinarily simple method of propagation - like fire spreads 1 tile per turn, always - the physical simulation and the 'regular' methods would have slightly different results. Even with the same seed, one tile that burns in one method might not burn in the other, even if they achieve very similar end results. Two people playing duplicate games, doing exactly the same thing as each other but one using physics for these things and the other using the regular method could end up playing somewhat different games. Small differences propagate into much larger ones - it's why desyncing is such a problem: a small desync doesn't stay small, it hurtles out of control.

And regarding hill/mountain creation - your example only works if such spells are constrained to affect one tile. That would suck horrendously. And without such a constraint, the results of this particular spell would differ wildly depending on whether or not physics is used. Secondly, without a physics calculation system you are not constrainted to a number of pre-designed hills. Do you think the hills and mountains generated by the random map generator will all be predesigned? It doesn't look like it from the screenshots we've seen so far. The exact same algorithms could be used.

The means to the final result are as important as the result itself. If one method burns down a forest faster, or in a somewhat different order than the other, then game-play is effected, even if only subtly.

Just because you needed somebody to explain the equations and mathematics to you in a language you are more familiar and comfortable with does not mean those explanations are fundamental. Especially when you get to the higher levels of physics, most people find that they start looking at the equations to clarify people's spoken explanations more often than the other way around. Also consider that in very close to 100% of situations, the mathematics precedes the conceptual explanation (which is really just an interpretation of the math into another language). Please, don't have this argument with a physicist.

Regarding your later post, Scoutdog already covered it.

Suffice to say I disagree with just about everything you have said thus far piegeonpigeon in terms of both the game and physics. For the time being we will just have to leave it at that. I would also point out assuming I needed someone to explain the equations to me is a faulty assumption. 

Your words:

And where did you get this understanding from? Either someone explained it to you, or you discerned it from the mathematics. Trust me - if you can't put an idea into math, it ain't physics 99% of the time. There are very few exceptions - and most of them that I can think of off the top of my head are in fields like astrophysics. But even there, observations are ultimately turned into mathematics - it's just a rougher process that usually takes longer due to the nature of the beast. You can believe as ardently as you want that this isn't the case, but you'll be wrong.

Now, when it comes to the game, your opinions are at least as valid as mine And considering we've already pretty much gone in circles I think you're right that we should leave it at that - at least until we know more.

Allow me to explain this quickly. 

You can break physics and almost any science up into application and theory. 

I did not have problems with application. However, the numbers provided using application did not help me understand why something happened. Any one can mindlessly follow an equation and arrive at the right answer.

Theory is where the real heart of physics is in my opinion. If the logical theory behind the math doesn't make sense to you it doesn't matter if you can do the calculations or not. Once I understood the logic behind the theory the math would go from being meaningless to meaningful. 

I would also point out there are places in physics where the math falls apart or doesn't work. Such as with a singularity. 

Edit: In short I would think about the logic behind something until I figured out how that conclusion was reached then decide wether I agreed or disagreed with it. 

Um.. the 'logical theory' behind numerical calculations IS math. Yes, anybody can plug numbers into ∮E•dA = Q_enc/ε0. The logic behind that calculation, however, is in that equation I just wrote. Even if you've never seen this equation before, if you know what is represented by the variables an astute or experienced mind can figure out from the math itself that it means that the electric flux through a closed surface is proportional to the enclosed electric charge. Or, if I generalized the equation to ∭(∇•F)dV = ∯F•ndS and providing the meaning of the variables, one could deduce from the math alone that it means that the net flow out of a region is the sum of all sources minus the sum of all sinks. All of that information is encoded into the mathematics. Theory is where the real heart of physics is - but physics theory is mathematical in nearly every single case. The only aspect of physics that is not mathematized is observational physics, where the conclusions drawn are along the lines of "this is what happens when you do this" - but even there the goal of that observation is to figure out a mathematical model that explains that process.

Which is one of the reasons why we don't have a clue what the heck happens inside a singularity. Conceptualizations of what might occur inside a singularity are not really physics - they're conjectures made for the sake of curiosity without any real evidence or chance of validation. Until someone comes up with a mathematical framework that does not break down inside singularities or some other workaround (or, even better, a physical model that does not degenerate into a singularity in those circumstances!), physics will continue to be inapplicable to singularities.

The conclusions in physics are the equations themselves, and the logic behind them is the relevant data and preceding theories (equations!) used to derive them. The logic behind numerical calculations are simply the equations used to make said calculations.

 

Sorry for the off-topic...

I believe the core of this disagreement stems from the fact that you believe equations are meant to explain while I believe they are meant to predict. Either way if you wish to continue this discussion we should probably do it someplace else. 

Edit: In other words send me a PM if you want.