Planet size contest ;)

Ahh, the old days.

I remember games that only needed 33MHz to run and a full system install of less than a single Megabyte... When SoundBlaster audio cards were considered THE thing to have if you really wanted to enjoy a game.

16MB of RAM baby! That was where it was AT, yo!

I want to make a suggestion according to my point in my last post:
"But maybe i´m with you to have a more "plateau"-stil with "ramps" to get on, than constantly "wave-like" mountainareas..."

We know those clefts all over the planet. why not make use of them to generate areas of different highs. From the sides there can be light increasing or decreasing "ramps" to get on:
(please make NO comment to my paint skills )



Thx for helping with the upload

well we won't since we can't see the picture... so I'll go ahead and criticise your tech skills instead. boooo! booo! ^=^

Attach it to the post. There's an upload attachment area below as you're composing your message

There are a lot of tractable solutions to these purely technical issues. For a start, ballistic solutions are a lot simpler than you think. They are generally the kind of easily solved quadratic equation that modern computers can handle by the millions. What's more it isn't Every single Unit, it's every unit which is currently firing and having it's shots hit the ground halfway through their arc. There are further optimisations along the lines of limiting the local solution space, sharing workable solutions across nearby units, and only running solution checks once every so-often. As someone whose job is based on accurately simulating the physics of particles, I can assure you that there are alot of different approximations and optimisations that can be used to simplify these kind of calculations. I don't know whether uber is in a position to integrate these into the PA code, but they have already discussed automating many aspects of unit behaviour, and i would be very surprised if this wasn't possible.

Furthermore, As raevn has correctly pointed out, even adding stringent limitations still wouldn't be a problem. It doesn't have to be perfect, only better than doing nothing.

And to answer your final question, yes, I absolutely think that these would be CPU cycles well spent if it brings the concept of terrain value and high ground into the game, whilst avoiding needless micro.

And if those CPU cycles were needed for Patched Conics to allow for greater orbital fidelity in both Orbital Unit movement and Celestial Bodies?

Or if they were needed to allow a greater number of units with more nuanced pathfinding over long distances?

Not to mention the time needed to code it. Simply posting feature requests doesn't give Uber more time or more money magically from the æther.

---

Honestly I'm still burnt over how realistic the terrain is now... compared to how stylized and cool it looked in the Pre-Vis.

...

I really miss those swirls

schulti love the idea, the canyons are created by bolean substract or add:

these are the canyons:

as a result the only possible way i see to do this is to have a terrain deformation on each side:

+1. Well said.

Wow Nanolathe, are you as fun at parties as you are on the forums? You really will grasp at any straw to kill an idea you disagree with. You should really pick your battles...

I'm less fun at parties.

yes, the canyons are subtracted. but i´m looking for a way to give each side of the canyons a own highrange then it had before substracting.
Could be possible to tell the planetgenerator ?!?

Of course i dont mean that the highrange on each side is then set until another canyon comes the way. the so created plateau could only use a specific area.

wouldn't that be a nightmare to code?

not to metion the mesh I showed you is flat but it undergoes a transformation to match the curve of the planet.

Just make a model and import it in.

That's still a planned feature, last I heard.

You mean you still get invited?

People insane enough to keep inviting you over and over almost deserve what they get!

That reads back a little meaner than I meant it to be. I'm not being mean, honest.

I'm fun if you're into reading the truth with a bit of snark thrown in.

If you don't like that then I'll assume you've already blocked posts that you clearly don't want to read.
I'm certainly not above doing so.

As if I'd want to miss out on your contributions!

:lol: :lol:

Every feature must be evaluated against what it brings to the game versus the processing power to run it, and the developer time cost to implement it. Otherwise, you might as well say "why should we have colour? by reducing colour memory address space we could probably squeeze yet more units out of it".

You provide a good example of this by mentioning patched conics. Patched conics, N-body dynamics, Runge-Kutta, or a variety of other orbital simulation techniques are a prime example of high computer cost for low gameplay improvement. It is entirely possible to create orbital models which are far simpler than these expensive techniques, without sacrificing game mechanics at all. Literally, it is possible to create a simplified newtonian model with various approximations, which would look and play identically to a more advanced simulation running on a much more powerful computer. Unless you decided to watch the simulations run side by side for a few hundred (subjective) years and see numerical instabilities flare up. The reason why astrophysicists use these models is because they care if the simulation is viable over millennia, where we only care about a couple or more hours.

Elevation advantage is not a radical concept. I feel it adds alot to the game. The Computational cost to make units fire a little more cleverly is low. If Uber is familiar with some of these kind of optimisations then the developmental penalty is really not that massive. It is worth the time and effort.

I realise that you would have to take this on faith that I know what I'm talking about, but adding this level of smartness to the units is a lot less computationally expensive than you think. If you're not willing to do that, fair enough. But I would recommend having a look at the maths of it yourself. If you know a coding language, try makinging a quick knock up of how you would find an optimum location to fire given, a variable contour plot. If you don't know an appropriate language, you can even do most of the maths in excel (if you must). You'll find that 90% of your time is implementing the bits that PA already has (contoured landscape, basic firing solution concept). Adding a bit of smartness isn't trivial, but it isn't that hard compared to a lot of the stuff that Uber is already doing, and has already done.

Then I'm still left stuck with the question;

Why has it not already been done? If it is as simple as you claim, then why is it not standard for every game that used real simulated projectiles?

That's a real honest question by the way. I'll be happy to take what you say on faith if you can explain to me why it's not already been done.

I think the last one is not ugly and all of those have easy solutions to. and the problem would be diminished by having the factories be smaller as I asked for in my Scale Megathread. but overall I think the best way to go is flattening terrain. and I'll show you examples later of how good that looked in supcom if you want.

But there is not a doubt for me that SmallCpu's planet is gorgeous and is exactly what I want to play on for the release.