Shooting Range

[the pig]

Here is my shooting patch. The patch was made from the 2.8.0 RC4 source.

In a nutshell, uses the brake input to shoot death zones of various sizes (depending on the amount of brake reservoir used). Using the whole brake reservoir shoots a megashot in multiple directions.

Configurations for the shooting are:

Code: Select all

############################################################################################
#
# shooting range settings
#
############################################################################################

# The braking reservoir used for shooting goes from 1.0 (Full) to 0.0 (Empty)
# All of the shot thresholds are calculated from the amount of reservoir used
# To disable shooting, set SHOT_THRESH to 1.0

# SHOT_THRESH commented out as it is very annoying for 2.7.1 or older clients...
# Uncomment this to enable shooting
#SHOT_THRESH 0.0001         # Amount of brake reservoir that will make a shot, 1.0 to disable shooting
SHOT_DISCARD_TIME 0.2      # Time in seconds to hold off shooting between shots
SHOT_START_DIST 1.0        # Starting distance of a shot from the cycle
SHOT_VELOCITY_MULT 1.4     # Cycle velocity is multiplied by this to calculate shot velocity
SHOT_RADIUS_MIN 0.75       # Minimum radius for a shot (As if minimum reservoir was used)
SHOT_RADIUS_MAX 6.0        # Maximum radius for a shot (Full reservoir used)
SHOT_ROT_MIN 1.0           # Minimum rotation for a shot (As if minimum reservoir was used)
SHOT_ROT_MAX 7.0           # Maximum rotation for a shot (Full reservoir used)
SHOT_EXPLOSION 0           # 0 for no explosion, 1 for explosion centered at cycle, 2 for explosion centered on shot

MEGA_SHOT_THRESH 0.95      # Amount of brake reservoir that will make a megashot, shooting has to be enabled
MEGA_SHOT_MULT 0.5         # Radius and rotation calculated for a normal shot, then multipled by this for mega
MEGA_SHOT_DIR 3            # Number of directions to shoot around cycle, 0 to disable the shots (cycle explosion still works)
MEGA_SHOT_EXPLOSION 1      # 0 for no explosion, 1 for explosion centered at cycle, 2 for explosion centered on each shot, 3 for both

SHOT_KILL_SELF 1           # (0,1) if set to 1, your own shot kills you
SHOT_KILL_VANISH 1         # (0,1) if set to 1, shot vanishes after killing someone
DEATH_SHOT 1               # (0,1) if set to 1 and you were in the middle of a shot, releases it after you die

This is my first attempt at making a patch file, and it seems that I can't make TortoiseCVS ignore white space so there are some unnecessary changes recorded. Let me know if anyone gets the patch to apply.

the pig

[wrtlprnft]

I'm currently playing around with it, I definitely want this for my race server in some fashion.
For your whitespace problem: run make rebeautify and the whitespace at the beginning of lines will get "standarized".

[the pig]

As far as I can tell - the extra whitespace was in the CVS code, whereas my IDE (Codeblocks) was configured to delete it on save.

Great, let me know if you're able to get it to work. I'm interested in if the patch is OK or not.

[Luke-Jr]

As far as I can tell - the extra whitespace was in the CVS code, whereas my IDE (Codeblocks) was configured to delete it on save.

I suggest: diff -uBbr

[wrtlprnft]

Ok, I had some trouble since I wanted to apply it to the code in CVS HEAD, not rc4, and i basically ended up applying it by hand with copy & paste.
Currently compiling, If everything goes right my race server will support it really soon

If it works I'll make another patch and post it here.

[Luke-Jr]

No need, I converted his patch to a diff -uBbr format
... and one for HEAD, too

[Luke-Jr]

Now, having actually looked at the code...

In my opinion, it will need some changes before it is ready for mainline CVS inclusion. If someone wants to commit the current patch to a CVS branch (shootingrange?; should be based off HEAD, of course) and work toward this stage there, that'd be fine.

Obvious changes needed that I noticed:
- I don't see a way to disable shooting completely (?)
- There should be no changes (or few) to the death zone. There should be a gProjectile subclass of gZone (interfacing to OnFire, OnCollide, etc) and a gDeathShot (or similar) subclass of that.

[Lucifer]

Ok, in working this into CVS, I found two links to help whoever does it. One is to philippe's post containing the specification for zones, and the other is to z-man's post describing what he did to make fortress zones and why. Regardless of what we do with this, we need to stay in line with philippe's spec as much as possible, so if this has to be split out into its own classification of game objects to do that, then we probably should do that.

Zone specification:
http://forums.armagetronad.net/viewtopi ... 3881#33881

What z-man did when he made fortress zones:
http://forums.armagetronad.net/viewtopi ... 4707#34707

The other thing I wanted to bring up was backwards compatibility. Is it possible to make a game object that is completely new, but gives itself up as an older version of itself for older clients? I was thinking we might want a new base class for projectiles that's divorced from zones, but send the projectiles as zones to older clients.

A thought, anyway.

Also, I had intended to beat on it a bit myself and had emailed groundpig on it, but I guess that discussion is now moot since he threw his code out here for all to see.

[wrtlprnft]

Ok, I set up my server now, it's the multicolored race server.
You can't "shoot", you lay some kind of mines. There's a pretty high shot_treshold (well, actually it's tiny, but if you consider the cycle_brake_deplete of 1e-6...), so you have to speed up before you can shoot which makes shoots risky.

[the pig]

In my opinion, it will need some changes before it is ready for mainline CVS inclusion. If someone wants to commit the current patch to a CVS branch (shootingrange?; should be based off HEAD, of course) and work toward this stage there, that'd be fine.

Ah sorry, didn't mean to imply this was ready for a commit to HEAD, especially as it is so obviously incompatible with braking.
Quite a bit of hacking was done here so that this would work with current clients. I had gotten a ton of emails asking for a patch to be posted, so this was only intended to be used by the folks that wanted it *NOW*.

- I don't see a way to disable shooting completely (?)

Leaving SHOT_THRESH commented out or set to 1.0 or above should do the trick. Let me know if that won't do it, and I'll certainly fix it in my version.

- There should be no changes (or few) to the death zone. There should be a gProjectile subclass of gZone (interfacing to OnFire, OnCollide, etc) and a gDeathShot (or similar) subclass of that.

I agree completely, only there for current client compatibility.

Thanks all the for the interest and taking a look so quickly!

the pig

[Luke-Jr]

In my opinion, it will need some changes before it is ready for mainline CVS inclusion. If someone wants to commit the current patch to a CVS branch (shootingrange?; should be based off HEAD, of course) and work toward this stage there, that'd be fine.

Ah sorry, didn't mean to imply this was ready for a commit to HEAD,

You didn't. I just consider that an 'eventually' goal for all features by default

- There should be no changes (or few) to the death zone. There should be a gProjectile subclass of gZone (interfacing to OnFire, OnCollide, etc) and a gDeathShot (or similar) subclass of that.

I agree completely, only there for current client compatibility.

Only gZone is really handled by the clients (AFAIK). The subclasses are all for the game server. My "MCP Attack" game uses three new classes (gMCP, gMCPRoar, and gGoodWave) and it is still compatible with pre-0.2.8.0 clients (though they obviously can't see the colours).
As long as you don't mess with the sync messages (Request and Send Sync functions), there shouldn't be any issues...
Edit: and if you *do* mess with them, make sure you send the gZone sync data *first*-- IIRC, the older clients will just ignore extra data, which is why colours were so easy to add.

[wrtlprnft]

For that brake button abuse: I think we should maybe add a few "generic" buttons to the clients that just get sent to the server, without any direct effect on the client.
That should make it easier to add features in future versions, and if we release a server that uses those buttons we can simply modify their descriptions to the buttons in the client without breaking out older (from the current point in time still future) clients...

[the pig]

For that brake button abuse:

Yeah I noticed the brake being abused quite a bit. I made a change since posting the patch that just uses the brake input and calculates what it thinks the reservoir should be at manually. Seems to work.

[Luke-Jr]

I think we should maybe add a few "generic" buttons to the clients that just get sent to the server, without any direct effect on the client.

In a sense, we already have generic buttons: Instant Chat. But that'd just be a hack to support older clients

This can tie in with changing the keymapping to use names instead of numbers. There should be 3 forms of signals: "action", "+action", and "-action". The latter two represent "begin action" and "end action", for actions which have a continuous meaning (braking, shooting with more energy, accelerating, etc). Thus, I could bind "Mouse 1 Button 1" to "+shoot" (and automatically "-shoot" is bound to the release of the button) and also bind "Keyboard 1 Key Q" to "shoot" for a quick shot.

[/not\Dale]

i downloaded the patch, but i dont kno how to use it in armagetron advance, please i need help from anybody


Sincerely Master Chief, /not\Dale, DM|Dale, and WK|Dale