project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Yatta

Pages: [1]
1
Design / Engineers and Scientists hiring
« on: March 25, 2010, 08:01:43 pm »
Why is it necessary to select every single scientist and engineer when you are hiring ? Afaik they dont have any unique stats.
I suppose it would make it easier if scientists and engineers were bought as 'items'. Or is something planed with their stats who would justificate to pick one more than another ?

2
Hello.

I tought its worth mentioning here : ive made an experimental patch for ufoAI, involving a new reaction fire system, changes how burst are handled, adds a critical hit system, and a few others tweaks.

All the details, the warnings and the .diff file are available here : http://ufoai.ninex.info/forum/index.php?topic=4564.msg35244#msg35244

3
Coding / How to find battlescape map information ?
« on: March 22, 2010, 06:36:50 pm »
Yop.

I want to experiment with assigining spawn position for actors (i.e. not using predefined spawn points), so im looking for information.

Id like to know how to find the coordinates and size of the UFO tile, and dropship tile, and if theres a way to check if a coordinate is valid (is that position in a wall, in the air, ...).

With this, ill test some theory on spawning troops inside the dropship (I think having to manage the deployment is part of the fun, with the risk due to all your soldiers being in pack and very sensible to reaction fires & AoE), and spawning aliens at not-random points (once you're used to maps, you know where they'll spawn) depending on how quick Phalanx troops came to the place and other parameters.

4
Coding / Help needed on weird crash
« on: March 20, 2010, 06:27:12 pm »
Hello, im having trouble with my custom build, the game crashes, but all I get from the callstack is this :



Its not always exactly the same error, but always a nt*** gibberish, or sometimes I get a correct callstack pointing to TR_TestLine_R, but I couldnt find anything wrong in that.

I hope someone can give me a clue on what to do to correct that crash, because im lost.

5
Coding / How to loop through firedefs ?
« on: March 18, 2010, 10:46:38 pm »
I have an edict_t ent, and I want to know what firedefs are available for the weapon in its right hand.
What should I do ?

My goal is to find which fire def shoots the most bullets.

6
Coding / [SUGGESTION] Reaction fire automatic weapons behavior
« 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.

7
Coding / [SUGGESTION] New accuracy system
« on: March 18, 2010, 10:43:45 am »
Im thinking about a new accuracy system, especially affecting burst weapons, with each new bullet being fired in a direction relative to the previously shot bullet (and including weapon spread and solider aiming skill of course).

I think it would make bursts look and effect more realist : Currently, in a full auto burst from a machinegun, done by a not so skilled standing soldier can have one bullet be shot at 45° on the left of the target, and the next one at 45° on the right. It is not physically possible for the soldier to rotate a heavy weapon 90° between two rapid fire bullets, out of recoil, even if he wanted it !

I think I could code that, if anyone's interested.

8
Coding / [SUGGESTION] Actor's visibility, actors perception
« on: March 18, 2010, 09:36:25 am »
I was thinking about a 'graphical' way to check for actor to actor visibility :

- *Check for Visible Actors (VA) visible by the Observer Actor (OA) with the usual ray tracing system
- Use a very small temp graphical buffer (BF) to render the VA from OA point of view (first person) :
    - Define a small viewport, with a small FOV (zoomed in), to render a 10x20 picture of what OA sees when looking at VA,
    - Make the VA visible in the map (not to the player, since it will only be rendered to the BF for the test),
    - **Color everything but the actor in black (using light or vertex color or any trick), and set the actor color to red.
    - **Check the total red color ammount (RCA) of the rendered picture.
    - The RCA is the base visibility value.

*:optionnal, for performance; **: "is that possible ?"

You can then applly view modifiers to RCA : reduce the result if its night unless OA has night goggles, reduce the result if the VA has some sort of camouflage, augment the result if the OA has detection devices (heat camera, targeting computer ...), and so on ...

Pros :
- Reliable estimation of how 'visible' the VA is, even behind multiple complex objects, based on what the OA actually sees,
- "Naturally" harder to spot far enemies : The further the alien is, the less red pixels will be rendered,
- Give good support for visual detection devices and camouflage,
- Could be used to estimate % chance of hit.

Cons :
- Is it possible with quake engine ?
- Render / color ammount check time ? Since the detection must happen at every step of the OA, this detection system cant take long or wont be appropriate.

Other possibilities :
- A similar render of the enemy could also be used ingame in a side window to show the player what the OA actually sees (applying effects depending on the detection devices the soldier has) and check if the shoot would hit.
- Even more, you could use this window to tell the soldier where to shoot on the target :
For instance when an enemy is behind a small wall, you might want to shoot a little above the wall instead of just aiming for the enemy center. Think about the farm map, with the fences arround the fields that are just at the right height to block any shoot from a crouched soldier to an enemy center point (i HATE those fences).

Bad idea ?

Pages: [1]