Modern Warfare Mod brings World in Conflict from the Cold War into the Modern Age. It also ups the ante on realism and authenticity in every role – Infantry, Armor, Support and Air, while trying our best to keep everything relatively balanced for fun and interesting gameplay.

Forum Thread
  Posts  
FLINT System (Games : World in Conflict : Mods : WIC: Modern Warfare Mod : Forum : General Mod Discussion : FLINT System) Locked
Thread Options
Jun 5 2020 Anchor

Hiya Blahdy,

I was having a peruse through the updates again when a question came to mind

Is the FLINT system something that can stand on its own, or is it (will it) be reliant on the MassTech Engine?

Correct me if I am wrong, but from what I understand there is a seperate Python based VM running.
Is this just recieving in/out values from WIC itself, or is it heavily intertwined with datastructures/objects coming from MassTech that would prevent you from using this elsewhere?

For instance, is it concievable that the FLINT system could run as a standalone python project, where you could hardcode a timeline of events to feed into it in place of WIC?

This is just out of curiosity, as a fellow dev, about how the system you guys have built works.

blahdy
blahdy Data-Linked AA-12
Jun 12 2020 Anchor

Hi flames09,

The FLINT scripts are neither too intertwined with WiC engine, nor is it modular enough to be simply plugged in elsewhere. Basic premise of the FLINT system looks like this:

1. It uses Velocity-Verlet integrator, written in Python. This can be easily executed/replicated in any other game or any other environment.

2. It uses and assumes world coordinate system, even to make steering commands to the missile (it does not add acceleration command onto local orientation). This may or may not be a problem, depending on your target game's working environment.

3. It uses basic math Vector3 functions provided by MassTech engine, which is basically Python classes written to represent Vector3 x, y and z as mutable object, and relevant math facilities for things like Normalize(), vector Length(), Rotation Matrix, etc. All of these basic math facility functions will need to be provided by the target game environment, and FLINT scripts will have to be appropriately modified to use these facilities.

4. Lastly, FLINT assumes operation in 27 frames per second and it uses WiC's ShooterBase Python module to interface itself with the game. This will need to be converted to work in target game's environment but it should be pretty easy to do so.

The way Python shooters work in game is as follows: (1) WiC initializes Shooter(0) parasite for unit's shooter. The shooter is a PythonShooter and it invokes WiC's Python interpreter and loads ShooterBase class. (2) once ShooterBase is loaded in game, WiC's python Interpreter calls Aim() function inside the Python script. Aim() function is expected to return True, when unit has completed aiming itself and is ready to fire a bullet; Aim() function is expected to return False, if unit is still aiming its turret to the target and needs more time to aim. (3) Once Aim() function in the script has returned True, FireProjectile() function in the script is then called by WiC's python interpreter.

The way FLINT agent works to interface itself with WiC is that FLINT agents always return False on Aim() function. When executing Aim() function, instead of aiming a turret or aiming /something/, FLINT script performs all of its integration and missile physics and agent functions (including homing loop) in the given frame. To move to the next frame, FLINT script returns Aim() as False, to force the game to invoke it again on next frame. The process continues in endless loop. When FLINT script needs to self-terminate the missile (for proximity fuse detonation, or impact with ground), Aim() returns True and detonation function is triggered.

As an example, FLINT script for RIM-162 ESSM was recently uploaded to Github here: Github.com


Jun 12 2020 Anchor

Thanks for the detailed writeup Blahdy, and huge props for posting the exemplar code on github (is that the start of a bigger push to public storage of FLINT?)!

Has perfomance been a significant issue during development, given that (from my understanding) you are running the physics sim of rocket propulsion outside of WiC and feeding the results back in for each FLINT agent Shooter and Target? If so, what sort of methodology have you guys used for creating efficent python code (is it mostly trial by error?)?

blahdy
blahdy Data-Linked AA-12
Jun 12 2020 Anchor
flames09 wrote:

Thanks for the detailed writeup Blahdy, and huge props for posting the exemplar code on github (is that the start of a bigger push to public storage of FLINT?)!

Has perfomance been a significant issue during development, given that (from my understanding) you are running the physics sim of rocket propulsion outside of WiC and feeding the results back in for each FLINT agent Shooter and Target? If so, what sort of methodology have you guys used for creating efficent python code (is it mostly trial by error?)?

Mostly trial and error. We limit FLINT to run at 27 fps for both performance reasons, but also primarily for network messaging queue reasons. Sending updates at full 120-200fps overloads network buffer so missile movements look unbearable.

The only downside to running at 27fps is that WiC's copterMover unit class tries to lerp every frame when update is not provided -- this is the reason why FLINT missiles often have jerky movement especially on high refresh rate screens. It's not as noticeable to be a showstopper, but annoying nonetheless.

But outside of this, we haven't really run into much performance issues; I think modern CPUs just don't care, unless you're doing something really silly in Python (i.e. iterating multiple times through a really long for/while loop, etc).

Reply to thread
click to sign in and post

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.