UFO:Alien Invasion
Development => Coding => Topic started by: Yatta on March 18, 2010, 10:53:03 am
-
Maybe automatic weapons could behave differently in reaction fire mode. They are supposed to be the best weapons to shoot at a moving enemy.
Here's what I was thinking about :
- Soldier is on "reaction fire" with its automatic weapon.
- An enemy is moving in front of him.
- After the enemy spent enough TU moving in front of the soldier, the reaction fire starts.
- The soldier then shoot 1 bullet at the enemy for every x TU (depending on weapon's firing rate) spent by that enemy.
- Once doing reaction fire to that enemy, the soldier should not be able to react to another enemy move in the same round.
It would allow the shooter to 'track' the enemy movement with its automatic gun (quite like cheap TU gun shoot that can happen multiple times on a move), instead of just shooting all the burst at a single point of the enemy course. Would look more realist, and give some 'specialization' to those automatic guns.
I think I might be able to code that if it could be interesting for the official version.
-
I'm not one of the project leaders but you definitely have my support on your idea.
-
Are you talking about splitting the burst of an automatic weapon or rapid single shots in semi-automatic mode ?
The first wouldn't make sense according to my own calculations, the latter sounds reasonable to me, but would change the balance of the game.
-
The first : splitting the burst of an automatic weapon.
Why doesnt it make sense ?
Im currently working on a prototype, but im having difficulties - im not familiar with C and the project, and weapon/fire definitions gives me a headache.
-
Why doesnt it make sense ?
1. Select an amount of seconds per TU. I took 0.5, ie. 1 sec to move one square.
2. Select a 'realistic' rate of fire for your auto gun. I know of assault rifle 600 and MG 1200 rounds per minute.
==> I end up with 10-20 shots while the actor moves one square.
At the army we were told to produce tiny bursts of 3-5 shots (it's close to impossible to get less than 3 shots from the MG, not to mention a change of direction during those 3 shots). So I think it's ok if the complete bust is targeted at just one square.
-
UFO:AI rpms arent realistic. For instance, during the time it takes for a soldier to run on 20 meters, another soldier can only shoot a 20-rounds burst. One could count to 20 faster than that. So I wont be trying to add realist rpm in the reaction fire if the 'normal' fire isnt realist itself.
Anyways its not possible to consider a TU as an unit of time equivalent to X seconds, since it doesnt work like that : fast soldier doesnt use less TU-time to do an action : they just have more TU units to spend, so you cant base your rpm on the enemy's TU. Well I know you know all this already, its just to make my logic clear. ;)
So what I am doing is searching in the firedefs of a weapon, which firedef shoots the more bullets, and base the 'tu-rpm' of the weapon on that. Then I know the weapon can shoot 1 bullet every x TU spent by then enemy - and use the enemy's speed to influence that 'tu-rpm'.
-
...'tu-rpm'... ... 'tu-rpm'.
Just a small comment, wouldn't that be rptu (rounds per time unit)? Or rpTU?
-
Actually yes, I didnt really tought oh it, just kept 'rpm' because it was a known accronym ;)
-
I'm not preaching realism for a UFO game ;) I was just reacting to:
Would look more realist, ...
And you're right oc, TUs don't have much to do with time. It's a rather abstract unit. Think 'action points'.
Another thing to think about:
- The soldier then shoot 1 bullet at the enemy for every x TU (depending on weapon's firing rate) spent by that enemy.
Have you already looked at that part of the code ? I'm only 98% sure, but I fear you'll only get control when the actor has reached a square, that is after 2,3 or 4 TUs depending on the type of move.
-
Yes I did, I also had to modify a little the way an actor spend his point while moving (code wise, it doesnt change a thing ingame).
So the end result is that when an actor moves to the newt tile, it calls the "spending TU" function to spend the 2 TU, and this tells all active reaction shooter tracking this target to check if thats enough time to shoot their next bullet(s).
The whole system works right now, and its quite interesting to see sometimes :
Reaction fire can be triggered by an enemy reaction fire, so during your turn, you can have a soldier with RF enable, and an enemy in view. You tell another soldier to move.
It triggers the enemy RF.
As that enemy spent TU to shoot, it calls for potential RF shooters who might want to shoot at him.
Your RF soldier shoots back to cover your moving soldier.
Im not sure if that has any real strategic application, tough. Its just fun to see the chain reaction ;)
-
1. Congrats ! :) If you managed to implement that, you seem to have a better understanding of the event system than I do. I hope you will also help us with some event-related bugs ;)
2. Guess it's time for you to upload the .diff to our patch tracker at SF. (a line of code can tell more than a 1000 words (TM)).
3. Reaction fire of my own troops during my own turn ?? That *must* be discussed with Winter/BTAxis/Mattn imho. Maybe on IRC ? But I guess you could easily eliminate that just in case.
4. Did you also cover the case when the actor is killed in mid-move ?
5. Do you also have a map where the effects of your patch can easily (and more or less reproducible) be observed ? You may consider to modify the alien spawn points of an existing map.
-
The prototype fully work(ed), but I recently began to have to *very* frequent crashes on seemingly unrelated code (netstream things, external dll, TR_TestLine_r() ...).
I dont know that much about coding, but I clearly done something wrong at some point. My current theory is that I gave bad input to a function that directly handles stuff in memory, and this could be causing that random mess. Ill be trying to find what I did wrong, but if you have a clue on what might cause such behavior, ill be glad to hear it.
Other that that, has soon as the crashes are resolved, Ill show you the results, by source or in video - Im not sure my code could be included as it, I really started tweaking the code out of curiosity, and didnt tought I would go that far (the g_reaction.c is almost entirely rewritten) - so its far from clean.
Note im still a novice on C coding, and I dont have a clue on how to generate a .diff or put anything on the vss, which might be a good thing for the moment.
About the actor killed while moving : I had that crash during dev, but could tame it. Not sure I did it in a clean way, tough.
-
... and I dont have a clue on how to generate a .diff
Rightclick the file->tortoise->Create patch
-
thanks, ill give you that when I get to solve the crash thing.
-
you should maybe upload it to this forum topic, so others can have a look and maybe help you with the error
-
Thanks to Duke, the crash is gone.
Im now working on correcting a TU bug, and tweaking a few things. A .diff should be made available in the next 10 hours.
-
Here's the .diff file.
But first, some reading :
Context notes :
- I started editing UFO AI source to test personnal gameplay ideas and tweaks a few things to my taste. So the modifications arent limited to a new Reaction Fire mode (see below).
- Im not familiar with the project structure and some modifications might be out of place.
- The modifications could break game balance (not sure if really sensible), and probably differs from UFO:AI creator's vision.
- The modifications most certainly arent compatible with multiplayer games (stuning does not apply to aliens, mobility for multiplayer weapons are not set, im pretty sure some network code is missing).
- I like well enclosed things. i will use { } for even the simplest "if", and over parenthesis maths things.
- Ive added "(yatta)" in most comments so if something breaks arrounds those comments, you know you can blame me.
- I used lots of "gi.BroadcastPrintf(PRINT_CONSOLE ..." for debugging, so you'll find quite a few, commented out.
- Novice coding errors or complexity is to be expected.
- No difference between the two RF modes.
WTF ?!
This might be your reaction in some situations, where soldiers start shooting altough you didnt give them the order.
What happens is the following : you have soldiers ON RF. One of them moves, trigerring an alien RF, but as the alien start aiming/shooting, one of your other soldier, who had the alien well spotted already, start shooting too. Follows a quick gun fight for the burst duration. Yes two burst can be fired at the same time.
What it does :
- Changed Reaction Fire behavior. RF now depends on character's mind (mainly) and speed. Other factors included : target's speed, position and activity, weapon mobility ...
- Point survey : When you right-click with the mouse to make your soldier face a direction, you now also register an "Aim Point" : if an enemy enters that point, your soldier has a bonus to trigger its reaction fire. Very good to guard doors & building corners.
- Changed burst fire system. Your soldier wont discharge the full burst at one point when RF shooting at a moving enemy, but rather will shoot while the enemy move.
- Added critical hits : depending on the type of weapons, you can inflict more damage, or do special effect sur has making fall (well, sit), lose weapon, stun (except aliens), panic, ...
- Stun on hard hits : your soldiers might faint when badly hit. Bad : you have one less active soldier on the field. Good : he can be healed at the hospital. A little chance to keep good soldiers alive, and makes accepting combat losses easier.
- Tried to tweak camera travels during shoots to gain time and lose sickness. Not so successful.
- Dazed (flashbang grenade) now makes the actor start with half the TU on next round
- Actors loses a few TU when hit.
Precise changes in the files :
weapons ufo files : added 'mobility' parameter
cl_actor : added message writing PA_POINT when orienting a soldier with mouse
e_time : barbaricly tried to reduce camera travels delay
e_event_actormove : ActorDoMove returns on actor death
e_event_actorstartshoot : changed cameraroute to reduce camera travels in ActorStartShoot
scripts : added the mobility parameter for weapon defs
g_actor : RF modes reserves no TU, dazed unit start round with half TU, barbaric return on ActorInvMove to handle (in case of weapon drop/destruction by RF), changed how TU are handled at some points, added func g_ActorUseTU needed for RF
g_client : when reseting time units, reset a param for RF, modified how TU are used, added message PA_POINT handling (for aiming point)
g_combat : added critical hits & effects (can be turned off by setting the COMBAT_CRITICAL_FACTOR to 0, critical effects table depending on weapons damage type, stun chance on hard hits (for humans only to avoid easy capture of live alien), TU loss on hit, modified ShootSingle to add inaccuracy on RF, removed obsolete RF functions, modified ClientShoot to handle new RF and new management of bursts
g_local : added / removed stuff for new RF
g_main : remove of prototype of obsolete RF functions
g_match : made uncouncious-yet-alive soldiers have low health after a mission (so they HAVE to be healed before next mission
g_move : added a default AimAt point when moving soldiers, flag IsMoving for ents to manage RF accuracy
g_reaction : well ... mostly rewritten / changed
g_round : removed a call to an obsolete RF function
game_h : added an array to manage awareness of actors
inv_shared : added 'mobility' parameter
q_shared : added 'PA_POINT' message for AimAts
-
Point survey is interesting. Me and my brother actually did something similar in our homebrew rules for the board game Space Crusade. You could choose to concentrate your overwatch on two adjacent squares in your LOF, giving you a bonus to the overwatch roll, or you could choose to overwatch everywhere in your LOF, but not both.
For proper incorporation in UFO:AI, it would need some visual representation.
-
Yes, it does need a visual clue that your soldier is watching a point. Adding visuals on the battlefield should be one of the next things ill explore.
-
I scrolled through the patch once.
1. Not bad for a 'C-novice' :) It certainly needs quite some tweaking, but I bet you will easily accomplish that after a few hints and examples.
2. As the code is not just an add-on but instead replaces quite a lot of existing code, the main task will be to consider the sideeffects, ie. if it can break anything that you didn't even know exists.
3. The patch covers a bunch of features and is by far too big to be applied at once, so it must be split to one patch per feature or even more. Easy to do.
@BTAxis:
Before asking yatta to rework and split his patch, we need the game designer's decision which features to implement. I'm just a stupid coder (TM).
@Yatta:
I saw you even fixed typos in comments :) If you extract them from your big patch, I will certainly commit them.
If you don't know how to extract them, plz ask in advance.
-
Aha, yes, the typos, sometimes the urge to correct them is too big ::)
1. Thanks for the compliment ! ;D
2. Side effects is what I fear, I did had to use some thing I didnt understand fully, and while coding I was never really sure where was the line between server and client ...
3. Ill be waiting for instructions on what/if a part is to be kept, to clean it up and give the patch.
IME, here's my personnal tought of that experimentation so far :
- I like having my soldiers efficiently covers each other. Altough AI cant set AimAt points, they are also more efficient with reaction fire. I end up paying far more attention to covering, line of sight, and planning strategic moves, and I like it. But it might not please other players.:
- Soldiers sometimes fainting when hit hard : kinda like it - the "pheww, he's not dead" feeling. A chance to keep your precious ones.
- Critical : Im not sure. On one side, I dont think it changes anything on the combat, on the other side, it adds little unexpected things, that can slightly reduce monotony (especially the weapon loss and other special effects - plus I like the idea that once you buy/produce a weapon, its not 'immortal' anymore). Could be more focused on this 'unexpected' part than 'critical damage' maybe.
- RF on your own turn : some might say disturbing for some, id rather say surprising (once again, a little less monotonous). To me it feels like the soldiers have some initiative of their own, making you feel less 'alone' in the fight.
- bullet-per-bullet burst reaction fire system : I definitely prefer the song "Singing In the Rain" to "someone suddendly thrown a bucket of water at me".
I hope project game designers will be interested in this, as I have quite a few other tweaks in my mind.
-
wow - big patch.. thanks.
but (sorry, there is always a but from my side ;) )... watch out the coding guidelines. you make our all life harder by applying your own style. see the wiki for the coding guidelines or just browse the code to see how the code is written.
i will have a look at this patch once i find the time.
but splitting it into smaller pieces would be nice. one for typos, one for reaction fire, one for the mobility and so on.
-
Point survey is interesting.
Agreed.
-
https://sourceforge.net/tracker/?func=detail&aid=2975339&group_id=157793&atid=805244
patch tracker item created
-
it would be cool if you could extract the point survey patch as a small "point-survey-only" patch.
-
this is a quick start - but the relevant parts are still missing.
-
The point survey system is built on the new reaction fire system. Since ive mostly rewritten the whole thing, im not sure how to include point survey on the regular RF structure. However i suppose it would be rather easy to do, you just have to register the point at the time you make a soldier face, and then give a bonus for reaction fire when enemies are close to that point.
But there might be a problem : if i got it right, on the normal RF, when an enemy actor moves, and one of your soldier can see him and has RF on, he will get that enemy as his RF target (does not mean he'll fire), and wont change until next turn. Which means if another enemy moves, even on the survey point, he will be ignored as a target is already acquired.
To check for this search for something like ent->reactionTarget or such.
btw, anyone tried the patch ?
-
i tried it - but only a few minutes until it crashed. there was an error in some vec2_t and after that vec[0] = ..., vec[1] = ..., vec[2] = ... somewhere, i can't remember where exactly. but it was a change in your patch, so it should be easy to find for you. if you would clean that patch up, put some more stuff into the scripts, watch out the coding guidelines, this could maybe be integrated into our svn after 2.3.
-
put some more stuff into the scripts
What do you have in mind ?
Ill check for that crash, and coding guidelines, and try to release a clean -or at least more stable- version.
-
What do you have in mind ?
Aren't you connected yet? Make sure you get infected by XVI! :D
-geever
-
https://sourceforge.net/tracker/index.php?func=detail&aid=2975339&group_id=157793&atid=805244
^^added some comments here
-
Here are the updated patch. Pretty straightforward :
- file "...AND_other_tweaks" still includes the other gameplay tweaks from the original patch
- file "...MINUS_other_tweaks" has the following *removed* : actor starts round with half TU after being dazed, critical hit system, actors stunned by high damage, stunned actors HP set to very low when mission ends, sniper accuracy tweak.
- for both files : used no brackets "if", removed commented code, removed broadcast debug messages, removed typo corrections, used _("Blah blah.") for messages, tried to follow coding guidelines, corrected the vec2_t bug.
Note that :
The new TU spending system is required for the new RF system. It would not make much points not to include the survey point (aimAt) since the goal is to have a new RF patch. All this requires new struct elements, new functions, definitions, network messages on both moving, combat, and reaction firing domains, also required edition of ufo weapon def files. Hence : lots of files are still impacted with the 'MINUS' patch.
IMPORTANT :
I hand-modified the .patch files, and im not 100% sure i did it right. Use with caution.
-
if (ent->aimAt[0]==0) isn't working imo - 0 is a valid grid position
if (ent->aimAt[0]==0) memcpy(ent->aimAt,to,sizeof(ent->aimAt)); doesn't meet the coding guidelines
ent->IsMoving = qtrue; => ent->isMoving = qtrue;
float react = 80000/(((ent->chr.score.skills[ABILITY_MIND]*2)+ent->chr.score.skills[ABILITY_SPEED])*((ent->chr.score.skills[ABILITY_MIND]*2)+ent->chr.score.skills[ABILITY_SPEED])); doesn't meet the coding guidelines - whitespaces ;)
edict_t *ent1 = NULL; please chose another name
int best_shots = 0; please use camelCase
ent->NextReactionShoot = 1+(mobility*(diff/45)); please use camelCase and add whitespaces
awareAdd = (1 - ((diff/45)*(mobility/6)))*2;
awareAdd = max(0.1,awareAdd);
coding guidelines - there are more locations so i won't report this anymore here.
i know that i'm picky about this - but a lot of people are working on the code - they all have to understand it and read it. so coding guidelines are a must-have.