[CSGO] Curving Flash

[VinciT]

Tired of bouncing flashbangs off walls to get that perfect pop flash? Say no more! With Curving Flash, you'll have the ability to execute the perfect pop flash every time. While holding a flashbang, press the weapon inspect key (F by default) to switch the throwing mode.




How to install:

1. Install Source.Python.
2. Download the latest release of Curving Flash from the bottom of this post or GitHub.
3. Extract the files into your game server's root folder (../csgo/).
4. Add sp plugin load curving_flash to your autoexec file (../csgo/cfg/autoexec.cfg).
5. Restart your server.

You can see the flashbangs in action in this short video:

Changelog

v1.3

• Added a way for other plugins to control when and how the player(s) can curve their flashbangs (more info).

v1.2.1

• Added the French translation - thank you very much L'In20Cible.
• Fixed a bug that prevented the plugin from getting loaded with the autoexec/server.cfg file.

v1.1

• General code cleanup (thank you L'In20Cible).
• Implemented translations.
• Improved flashbang bounce detection.

v1.0

• Initial release of the plugin.

Latest release

curving_flash_v1.3.zip

(12.97 KiB) Downloaded 1297 times

Older releases

curving_flash_v1.2.1.zip

(22.7 KiB) Downloaded 1310 times

curving_flash_v1.0.zip

(7.44 KiB) Downloaded 1425 times

[Ayuto]

Awesome idea and great implementation! I really like the way you program :)

[VinciT]

Thank you Ayuto! That really means a lot to me.

[decompile]

This is awesome. I love the video :D

5 stars, if this was a review

[VinciT]

Thanks! I'm glad you enjoyed the video, it was really fun to make!

[L'In20Cible]

That is indeed a cool idea, well done!

That said, you know me... here are some points:

• ../curving_flash.py#L27: That method isn't static, so this should rather be:
  

  Syntax: Select all

  player.view_angle.get_angle_vectors(None, right, None)

  
  
  
• ../core/players.py#L54: Since your PlayerCF class makes use of the internal caching, you don't really need that dictionary. It is rather redundant, since the instances are already stored into PlayerCF.cache so you could simply do the following to retrieve cached instances:
  

  Syntax: Select all

  player = PlayerCF(index)
  player = PlayerCF.from_inthandle(index)

  
  
  
• ../curving_flash.py#L43: Should not the start be the flash position towards where it is going? Actually, the flash does an S instead of a C as illustrated in the following picture:
  
  
  
  You can see it first does a curve to reach the player's view vector which looks quite weird to me.
  
  
• ../core/commands.py#L16: Doesn't seem to be used anywhere, so not needed.
  
  
• ../core/commands.py#L23-L26: Slight inaccuracy here, because time() is called twice and might not be the same depending how long what is in-between took to execute. Should rather retrieve it once and assign it to a local variable. Additionally, you should rather do a from time import time, so that the interpreter do not have to dynamically resolve that method from that module every times you call it (avoid unnecessary getattr, etc.).
  
  
• ../core/commands.py#L22: That dictionary is never cleaned up so it will just grow over time to maxplayers which can also cause issues if an index is re-use as it will use the time of the last player, etc. To be honest, this should really be defined into your PlayerCF instances as you retrieve it in there anyways so may as well ditch an extra dictionary.
  
  
• ../core/flashbangs.py#L67: Instead of looking that every think, wouldn't it be better to just externally listen for the bounce event patiently waiting for the engine to let you know? This sure sound more optimized to me.
  
  
• ../core/flashbangs.py#L56: The angle should be None. Setting the same angle is redundant.
  
  
• ../core/flashbangs.py#L73 → self.base_velocity
  
  
• ../core/listeners.py#L35: Should rather use an entity delay. Otherwise, if a plugin does Entity.create('weapon_flashbang').remove() your callbacks will be working with an invalid index.
  
  
• ../core/listeners.py#L28 → base_entity.owner_handle
  
  
• ../core/players.py#L10: Why not use translations? I would PR french strings.
  
  
• ../core/players.py#L35-L41: Since you know everything ahead of time except for the indexes, there is absolutely no reason to instantiate that sound for all players. Just globalize it and .play(index) when needed.
  
  
• ../curving_flash.py#L37: I don't thin hard-coding the animation index is a good idea. While this is true for the default model, it can be different for custom ones. You should rather look into the studio package to extract it from its name.
  
  
• ../curving_flash.py#L30: That is certainly a property we could add to the Player/PlayerMixin class (though, as an Entity, rather than BaseEntity). Feel free to make a PR.

[VinciT]

That is indeed a cool idea, well done!

Thank you!

That said, you know me... here are some points:

I would expect nothing less.

../curving_flash.py#L27: That method isn't static, so this should rather be:

Syntax: Select all

player.view_angle.get_angle_vectors(None, right, None)

Oh that's nice.

../core/players.py#L54: Since your PlayerCF class makes use of the internal caching, you don't really need that dictionary. It is rather redundant, since the instances are already stored into PlayerCF.cache so you could simply do the following to retrieve cached instances:

Syntax: Select all

player = PlayerCF(index)
player = PlayerCF.from_inthandle(index)

It's like a bad habit. Whenever I start working on a new project, the first thing I do is create dictionaries for players/entities/weapons. I completely forgot about internal caching.

../curving_flash.py#L43: Should not the start be the flash position towards where it is going? Actually, the flash does an S instead of a C as illustrated in the following picture:



You can see it first does a curve to reach the player's view vector which looks quite weird to me.

I wouldn't say the trajectory is an S, more like a wider/stretched C. I did this to give the player an easier way to get their pop flash right - by aiming at the corner itself and not away from it. It also gives the flashbang more breathing room when the player is really close or even touching the wall, as can be seen here:

[*]../core/commands.py#L16: Doesn't seem to be used anywhere, so not needed.

It is used when the player inspects their weapon, to check if they're holding a flashbang. But now that I've been reminded about internal caching, I guess I could use the Weapon class. Or even better - player.active_weapon.

../core/flashbangs.py#L67: Instead of looking that every think, wouldn't it be better to just externally listen for the bounce event patiently waiting for the engine to let you know? This sure sound more optimized to me.

I was trying to avoid using an EntityHook, as the bounce event doesn't provide the index of the projectile. Seeing as _think() will get called a maximum of 5 times per flashbang, I didn't think there would be much of an impact on performance. Although I might hook CFlashbangProjectile::BounceSound() and use that instead.

../core/flashbangs.py#L73 → self.base_velocity
../core/listeners.py#L28 → base_entity.owner_handle

Another bad habit of mine.

../core/listeners.py#L35: Should rather use an entity delay. Otherwise, if a plugin does Entity.create('weapon_flashbang').remove() your callbacks will be working with an invalid index.

I'm checking if the flashbang has an owner before notifying the OnFlashbangCreated listener. If a plugin does the quick create().remove() thing, the flashbang will have an invalid owner inthandle (-1).

../core/players.py#L10: Why not use translations? I would PR french strings.

Awesome! I haven't played around with translations yet - guess it's time to do some learning.

../curving_flash.py#L37: I don't thin hard-coding the animation index is a good idea. While this is true for the default model, it can be different for custom ones. You should rather look into the studio package to extract it from its name.

Haven't used that package at all, I'll check it out.

../curving_flash.py#L30: That is certainly a property we could add to the Player/PlayerMixin class (though, as an Entity, rather than BaseEntity). Feel free to make a PR.

Seeing as I'm beyond rusty with C++, I could add it to the Player class. Although I think it'd be better if someone added it to PlayerMixin instead.

Thank you for the pointers, L'In20Cible.

[L'In20Cible]

Seeing as I'm beyond rusty with C++, I could add it to the Player class. Although I think it'd be better if someone added it to PlayerMixin instead.

It would likely be implemented the same as Entity.parent, where EntityMixin.parent_inthandle is implemented on the C++ side and Entity.parent in Python as an Entity instance. So it would be something like Player.view_model that returns an Entity instance from its PlayerMixin.view_model_handle attribute or something like that. I'm sure you can figure that out! (don't feel pressured tho, no obligation to dig into it if you don't want to )

[VinciT]

• General code cleanup (thank you L'In20Cible).
• Implemented translations.
• Replaced the way bounces are detected in order to improve performance.

You can find the updated plugin at the bottom of the first post.

[VinciT]

• Added the French translation - thank you very much L'In20Cible.
• Fixed a bug that prevented the plugin from getting loaded with the autoexec/server.cfg file.

[NosferatuJoe]

Wow this is a very interesting plugin. It's the first time I've seen something like this, and I also like how you display your plugins, makes me hyped right away. I might want to implement this on my warcraft server which is being launched tomorrow, just not sure how I can use python plugins like this and make them trigger by a race. I'm using an eventscripts emulator to run my races though, so it might be a little harder.

[VinciT]

Thank you for the kind words Joe!
What you're asking for could be achieved with a simple server command that can enable or disable the curving flashbangs for the specified player (userid).

I'm heading out right now, so I can't add the command right away. But I'll try to implement it as soon as I get back.

[VinciT]

Do you want to use Curving Flash as part of another plugin? Maybe as a passive skill or an item that can be picked up? With the 1.3 update, you can!
Check out the integration with other plugins section for more information.

[L'In20Cible]

• Added the French translation - thank you very much L'In20Cible.
• Fixed a bug that prevented the plugin from getting loaded with the autoexec/server.cfg file.

Had a quick look at your recent changes and here are two points that caught my attention:

• Since ../data/plugins/curving_flash/CBaseGrenade.ini is specific to CS:GO, it should rather be located into ../data/plugins/curving_flash/csgo/CBaseGrenade.ini. The type manager internally uses GameConfigObj, meaning that you don't even have to change where you create that type from because when you create a type from ../data/plugins/curving_flash/CBaseGrenade.ini it effectively results into a merge of the following files (like how SP's data files are structured):
  

  Code: Select all

  ../data/plugins/curving_flash/CBaseGrenade.ini
../data/plugins/curving_flash/<engine>/CBaseGrenade.ini
../data/plugins/curving_flash/<engine>/<game>/CBaseGrenade.ini
  Where the game specific data overwrites the engine, which in turn overwrites the base/shared data, etc.
  
  
• The second point is pretty much a reiteration of:
  

  ../core/listeners.py#L35: Should rather use an entity delay. Otherwise, if a plugin does Entity.create('weapon_flashbang').remove() your callbacks will be working with an invalid index.

  I'm checking if the flashbang has an owner before notifying the OnFlashbangCreated listener. If a plugin does the quick create().remove() thing, the flashbang will have an invalid owner inthandle (-1).

  Now that OnNetworkedEntityCreated is a thing, your on_entity_created could be simplified to
  

  Syntax: Select all

  @OnNetworkedEntityCreated
  def on_entity_created(entity):
      if 'flashbang_projectile' not in entity.classname:
          return
  
      # Delay the call by a single frame, otherwise the flashbang won't be
      # properly initialized.
      entity.delay(0, OnFlashbangCreated.manager.notify, (CurvingFlash(entity.index),))

  And your on_flashbang_created to something like
  

  Syntax: Select all

  @OnFlashbangCreated
  def on_flashbang_created(flashbang):
      """Called when a 'flashbang_projectile' has been fully created."""
      owner = flashbang.owner
      if owner is None:
          return
      player = PlayerCF(owner.index)
  
      ...

  Which seems overall cleaner to me, and would address at least 2 potential issues (the entity is deleted before the delay is processed and/or the player left the server).

Check out the integration with other plugins section for more information.

Just a thought regarding this; would not this be best to use a ../custom/ package for everything that is shared and can be externally integrated? I can certainly see your current implementation resulting into problems if plugins are loaded/reloaded into different order, etc. because your curving_flash.core will be purged, causing the old classes to remain alive into an outdated scope potentially causing duplication and randomness really hard to debug.

[VinciT]

Thank you for the pointers, L'In20Cible. I'll rework the plugin to use a custom package if I have time tomorrow.