hompy wrote:Influx the error is in your script... you're swallowing the on_map_change event.
In mortar.py, Line 1164, add
(you really should fix this since it can potentially break a lot of things)
Oops, this is a proper amateur error, and although I still class myself as 'amateur' at coding, I can't believe I overlooked something so simple. Fixed, thanks for pointing it out. I guess I just had my blinkers on.
hompy wrote:
I really like the idea, it was fun to try locally. I'd love to see stuff getting blown away in a full server!
To be honest though, I couldn't figure out how to use it with only the ingame help, and I think some things could be improved a lot.
I strongly believe players shouldn't EVER have to insert commands, much less cryptic codewords with verbose feedback hard to read in a populated server.
This is a tough limitation, I know! How to make it intuitive and accessible to the average user...
It certainly is high praise indeed when it's coming from arguably the best scripter for AoS. I have started working away from relying wholly on commands (such as spade-to-fire and spade-to-destroy), and there are a couple of ideas fizzing around in my head for how to handle use, elevation/traverse and ammo selection.
hompy wrote:
I'm asking a lot, but to show that I care I took some time to try and come up with solutions. (full image here)
There are a lot of good ideas in that graphic, and thanks for taking the time to produce it. I have a few comments on it, though;
Calibration
- Locking the player's movement, in my opinion, is probably going to lead to frustration. Since the current system relies on kicking a player out of use mode when they stray too far away from the mortar, locking them im-place would then require an /unuse command. This would be annoying when you want to run from the area quickly, like when an enemy grenade comes into the bunker.
- I've delved deep into the PySpades code and can't find where the client-side values are kept, so I'm not sure how I would go about making the traverse show up for the health. If you know the way of doing this, I'd love to hear it, because it's caused me some headaches in the past where server-side and client-side values aren't matching.
Alternative to /fire
- I think requiring grenades would severely underpower the mortar, as well as decreasing the overall rate of fire (ROF) to unrealistic and unuseful amounts. Real mortars have a ROF of about 20-30 rounds per minute, which is 1 round every 2-3 seconds. They also don't require an external propellant, the propulsion is caused by a small charge in the bottom of the mortar which explodes when it hits the baseplate.
- Using grenades also limits a player's ability to use them. At the moment, servers can decide whether mortars require any minimum kills and they can also give every player who joins X amount of rounds so they can jump straight on to one.
- Lastly, this would be open to abuse. I've been extremely careful to avoid most, if not all, ways this script could be abused, and using this method of firing would throw a curveball into the mix.
How would you stop a team-mate throwing grenades into your mortar when you didn't want to fire it? How would the script differentiate between a team-mate working as a team with you and a team-mate trying to aggravate you? What happens if you have terrible aim with the grenade and miss?
- I really like the idea of transferring a player's vision to the target zone. There are just a few problems that I can see. Firstly, I wouldn't know how to even start going about scripting this. Second, how would a player fire a salvo (a burst of rounds) off if they're instantly transported to the target zone? And lastly, this could be a bit unfair if an enemy is about to destroy the mortar and the player suddenly teleports back in from limbo and kills them.
Mortar Sounds
- I think most of the rounds do have a distinctive sound (High Explosives aside, which are just 1 grenade at the moment). The type of round you've described in the graphic would really be a cluster bomb. I have thought of adding these, but the main round explodes high in the air to ensure maximum scattering of all subsequent bombs. Shrapnel from normal rounds aren't explosive since they're just bits of metal, and shrapnel is also modelled well enough in the base grenades to really nullify adding it manually to the script.
Thanks for the ideas, though. It's nice to see someone come through with such detailed suggestions and it's certainly food for thought. If you have any more, or comments to my comments, I'd love to hear them as well.
