P.U.R.E. 0.55

[Guessmyname]

Yeah, it's roughly to scale, like everything else is. I wanted it to be a big, bad mecha, and it works pretty well.

I'm not complaining

[1v0ry_k1ng]

that looks totally awesome!

[Warlord Zsinj]

It kind of annoys me that no matter how much you blacken out the underneath a glowmap, the glow still seems to combine with the light source and desaturate all colour into pure white. In reality when you have a glint off the surrounding metal, the light would appear a lot dimmer then it would under other conditions (because of the relative light saturation / bloom)

(in reference to this: http://www.wolfegames.com/TA_Section/teaser176.jpg

You can see what I mean further when you compare the lights on the lit/shadow side here: http://img249.imageshack.us/img249/6756 ... 034kw3.jpg )

[Argh]

Yeah, but there's no really easy way to control for that. I guess that glowing areas could be clamped to their glow values, and not allowed to vary with lighting, but that'd screw with subtler lighting effects, where we want them to get washed out under direct lighting conditions, among other problems.

Maybe a clamp above an R value of 200 or so might be the way to go?

[Warlord Zsinj]

It could work... but how likely is it to get implemented?

[Argh]

I don't think it'd be terribly hard, to add that to the fragment shader used for reflectivity, although changes might also need to be made on the basic shader. Contact Kloot about this, he's been doing some shader work, and I have a feeling this should be fairly simple, since it's already getting the gray values of the color channels. It'd be nice, if stuff never reached fullbright levels if glowing. Personally, while I think it's mildly annoying, it's not the end of the world- most of the time the effect isn't terribly noticeable, at typical zoom levels- it's a pretty screenshot issue, imo, not a killer graphically.

[Warlord Zsinj]

This is true, it's just a pet peeve of mine, it bothers me when I see my carefully made glowmap get washed out during sun glints - which is typically the angle you want to take shots of, because they look the best at those angles.

[Argh]

I would like to announce that I've coded a new gameplay feature for P.U.R.E.- artillery may now use velocity controls. So it finally acts like real artillery- you can use different "powder loads" to change the parameters of your big guns, making them more useful for different jobs. I dunno whether this is a useful feature yet, but I suspect that the answer is "yes, very".

I'm still waiting on issues with Widgets to get resolved, then I have to make some UI tweaks before the next Beta will be released, so everybody has at least 3-4 days. Meanwhile, I'm going to see whether I can finish the new Assault Shell...

[AF]

I suspect it might be too much control. Remember there are entire games around artillery and choosing the right angle and fire-power out there and they're seldom perfect shots the first time.

Although the code would be veyr useful for any worms style game.

[Argh]

Oh, I don't give people that much control, it's not quite that fancy. I don't see the point in that, tbh, Spring's aiming code handles the main tasks of aiming, etc. already.

All I've done is give each artillery-type gun a low, standard, and high velocity setting, with corresponding changes to the weapon's parameters. Nothing too complex, and probably something most users will set only situationally, for arty duels, sniping resources, and for dealing with assaults. Expanding that to make artillery systems with very fixed ranges based on the "powder" involved would be incredibly trivial, though.

[Argh]

I got the Lua working, the weapon controls work, but it turns out that Cannon type weapons refuse to obey their range, other than BurnBlow. No matter what, they're governed purely by their velocity. Looking at the code:

Code: Select all

gravity = weaponDef->myGravity==0 ? mapInfo->map.gravity : -(weaponDef->myGravity);

It appears that myGravity settings lower than the map's are ignored in favor of the map. This should be changed, imo, so that we can use low-velocity projectiles with a lower myGravity constant, and ignore the map's settings. I don't want some mapper interfering with my game design arbitrarily

[KDR_11k]

You misread that code. If myGravity is 0 it uses the map gravity, otherwise the tag. Look at THIS, plasma artillery uses very low gravity to fly pretty much straight.

I would like to announce that I've coded a new gameplay feature for P.U.R.E.- artillery may now use velocity controls. So it finally acts like real artillery- you can use different "powder loads" to change the parameters of your big guns, making them more useful for different jobs. I dunno whether this is a useful feature yet, but I suspect that the answer is "yes, very".

Shouldn't MRSI be a single-click ability instead of needing micro to pull off?

[Argh]

You misread that code. If myGravity is 0 it uses the map gravity, otherwise the tag. Look at THIS, plasma artillery uses very low gravity to fly pretty much straight.

Hmm. I tried to set it to 0.05, down from 0.1, which is the standard setting I'm using for my Cannons, and range didn't double. What else might be interfering? Lemme test with another weapon, the first thing I picked was the Artillery Shell, which has GroundBounce enabled. Can't think of anything else that's unusual about it, but meh, the rest of this code works- if I can get what I wanted, which is higher velocity and greater accuracy, but lower range, and lower velocity but greater range (I have the inverse right now, which is annoying) it'd be nice. I'll experiment a bit, see what went wrong.

Also, instead of the current target check, would it maybe be possible to calculate the highest possible point the shell can reach, then check a ray from there to the target? Since that works out to 45 degrees both ways, surely that's not difficult to add, and it'd allow all cannons to operate correctly insofar as targeting is concerned.

[EDIT]Instead of the above, the smarter way to go is to change the state, so it skips the ray-test entirely, like mortars do. Duh. I'm reeeally tired.[/EDIT]

And yes, it's a single-click ability, you just change modes. Sorry if that wasn't clear- micro's very minor, I didn't see the point in making it a pain in the butt to use. The other problem that's come up is that weapons seem to "jam" if they could fire farther away, but can no longer engage the target, due to range changes... I'll look into that, make sure they re-engage closer targets.

[EDIT]Just tested it, and range is purely based on velocity, for Cannons, and it seemed to totally ignore my changes to MyGravity entirely. Higher velocity == higher range. You can't really make it use a lower range than velocity gives it, basically, which is what I wanted. I suppose I could just jam it and call an identical-looking EMG, for the plasma weapons, but that seems lame to me. Cannons need to obey their max range- if potential range > max range, they should obey that, imo. Between that and using a different method of ray-testing for hits, it'd make a world of difference in their behaviors.[/EDIT]

[imbaczek]

range for cannons is a very tricky thing to do in an rts if you don't want a piece of arty on a small hill to have 100% map coverage. cannon range is decided in this piece of code (Cannon.cpp):

Code: Select all

61 	 // initialize range factor
62 	rangeFactor = 1;
63 	rangeFactor = (float)range/GetRange2D(0);
64 	// do not extend range if the modder specified speed too low
65 	// for the projectile to reach specified range
66 	if (rangeFactor > 1.f || rangeFactor <= 0.f)
67 	rangeFactor = 1.f;
68 	// some magical (but working) equations
69 	// useful properties: if rangeFactor == 1, heightBoostFactor == 1
70 	// TODO find something better?
71 	if (heightBoostFactor < 0.f)
72 	  heightBoostFactor = (2.f - rangeFactor)/sqrt(rangeFactor);

Code: Select all

266 	float CCannon::GetRange2D(float yDiff) const
267 	{
268 	  const float factor = 0.7071067f; // sin pi/4 == cos pi/4
269 	  const float smoothHeight = 100.f; // completely arbitrary
270 	  const float speed2d = projectileSpeed*factor; // speed in one direction in max-range case
271 	  const float speed2dSq = speed2d*speed2d;
272 	
273 	  if (yDiff < -smoothHeight)
274 	    yDiff *= heightBoostFactor;
275 	  else if (yDiff < 0.f)
276 	    // smooth a bit
277 	    // f(0) == 1, f(smoothHeight) == heightBoostFactor
278 	    yDiff *= 1.f + (heightBoostFactor-1.f) * (-yDiff)/smoothHeight;
279 	
280 	  float root1 = speed2dSq + 2*gravity*yDiff;
281 	  if(root1 < 0.f){
282 	    return 0.f;
283 	  } else {
284 	    return rangeFactor*(speed2dSq + speed2d*sqrt(root1))/(-gravity);
285 	  }
286 	}

heightBoostFactor is exposed in the weapondefs - you can set it manually to something higher than 0, which will stop its magical calculation; experiment with it. if you want your cannons to shoot realistically, you'll need to calculate range by hand so rangeFactor will come out to 1.

[Argh]

Code: Select all

heightBoostFactor is exposed in the weapondefs

Yeah, but I can't manipulate it on a per-Unit basis via COB, and Lua doesn't have a way to do manipulation of defs on a per-Unit basis (at least, last time I looked into this).

I guess I could set it to some really low value, like 0.01. Then the magic would stop happening, and it'd be safe and wouldn't break stuff, at the relatively minor cost of not working physically correctly on hills. Meh, I couldn't care less, to be honest, when what I want to do is going to make it pretty much irrelevant anyhow. I'll try that, and see how it goes.

<tests>

Nope, didn't work. I don't think it's getting past this line:

yDiff < -smoothHeight

I'll try 0.99, just to be sure, but I don't think that will work, either.

Nope, that doesn't work. It does screw up the CAI's response, though, because it suddenly had trouble figuring out whether it needed to move forward or not.

[KDR_11k]

I'm not talking about the ability to change speeds as needing micro, I'm talking about Multiple Round Simultaneous Impact which is a technique used by modern artillery that involves firing several rounds at different velocities so that they all reach the target at roughly the same time and give the enemy less time to react to the strike. Your approach would allow MRSI but require the player to manually time the shots.

[Argh]

Sorry, I pretty much skipped the MRSI bit. Was a little tired at that point.

That's not anything like what I'm doing though, I'm trying to emulate using different powder loads to change the ballistic behavior of artillery- for example, lowering the powder load and firing higher, to get over hills.

I suppose that you could use this as the basis for MRSI simulation with large numbers of artillery, etc., sure.

MRSI is all of that, plus doing it with multiple units- the math would get quite crunchy, I suspect. You'd have to send each one the solution generated for the first one in the chain, then each one would have to generate its own solution for velocity, based on distance (thankfully, unlike IRL, we don't have to take air density into account). Not too bad, other than whatever code was used to identify other members of the chain. I suppose it doesn't even really have to run over one frame, either, since it will take multiple frames for everything to engage.

However, personally... I think it'd be overkill, unless you were dealing with a massive scale. At P.U.R.E.'s scale, it'd be just a piece of techno-frippery.

The remaining problems are that:

1. They don't seem to be obey gravitational forces as specified. They should always use MyGravity, and should never use the map's value, if not zero, but this doesn't seem to work, when tested- only values that were higher than the map's worked correctly. Since I don't want to be forced to use realistic velocities for my shells (i.e., 3000 or so) I need to be able to play with gravity, and make it low enough that I can use very, very low velocities. It doesn't seem to work, when tested.

2. Cannon weapons do not obey their stated max range. They obey their velocity and the gravity constant. They don't even apply burnblow at the stated max range. If max range < whatever magic range it comes up with, then that is used. Kind've a problem, if I want to allow for high-velocity, flat-trajectory shooting, but only at shorter ranges (like IRL).

So, for now, I use higher velocity, lower accuracy, and the inverse. It works reliably, but it's not what I wanted, as it doesn't emulate reality very well, imo. I want to see artillery in Spring that can actually reach 45 degree angles of aim, which never seems to happen, except with high trajectory stuff.

[FLOZi]

I want to see artillery in Spring that can actually reach 45 degree angles of aim, which never seems to happen

Easy...

ye olde python script

Code: Select all

fout.writelines (str(int(math.ceil(math.sqrt(int(maxRange) * 140)))) + ";")

That 140 is the map gravity, 140 being fairly average for spring. Using that formula, the gun will animate to 45 degrees to fire at its max range. Basic high-school physics.

[Argh]

Yeah, but that's not the issue.

The issue's that projectiles aren't obeying the MyGravity parameter correctly, when tested, and won't use their stated ranges. I don't want to simply bump their velocity up- they already work correctly, in that sense, and you're right, the equation for messing with that is well-known, I actually found a calculator online using JavaScript, but meh, that's beside the point. What I want to do is keep them at a low velocity, but increase their range, so that their fundamental ballistic behavior is different.

Currently, Cannons don't allow for that, because of the MyGravity problem. Since they apparently obey only the map's gravity, velocity governs their range, period. I understand all of this was changed over a year ago, to deal with modders not giving their projectiles enough velocity to actually reach their targets- what I'm basically saying is that:

A. That's a modder's fault. Make 'em fix it. Having the engine hold their hands is just eliminating potentially-useful options, imo.

B. With both velocity and MyGravity as constants to use, it should be possible to achieve a wide range of behaviors. It isn't, because of the issues with MyGravity.

C. Cannons don't obey their range parameter, period. It's being overridden by the hand-holding code.

So, sure... I could run that python script's Lua equivalent during Create(), and arrive at a base velocity value that would work perfectly. However, I don't want to use a map's gravity. I want to use custom MyGravity parameters, to better-simulate various ballistic profiles (maybe shells drop faster than flaming balls of plasma, or vice versa).

And I don't want a mapper's settings screwing around with my gameplay any more than I can help it, to be perfectly honest. To even get around that issue, the logic of how and when MyGravity needs to change.

At any rate, what I've got now works, it's just not what I wanted. It's not going to work like I want until cannons behave a lot differently, and meh, given how much this could screw up everybody else's games, I'm just going to quit worrying about it, and do it this way for now.

[Argh]

Click to enlarge the shot above.

The revised Assault Shell. Model by Guessmyname, with minor modifications by me, paint by me.

I figure this is one people will either love or hate, its a really wild design. Personally, I think it's a lot cooler than the old one, and the shiny bits are really quite real-feeling when it's in motion- the "brass" took bloody forever, though, as it required a lot of airbrushing to get somewhere decent. So don't expect everything to be covered with brass any time soon

The polycount's fairly high, but meh, this is not a unit that typically gets built in giant bunches anyhow, so I'm not sweating it. Sorry, no WIP shots this time, I just sat down and did it, got it scripted etc., without really stopping to document it at all.