Messages

46

Coding / Re: Destructible Terrain

« on: March 19, 2010, 05:37:53 pm »

Just curious : Has there been performance tests made of maps built with func_breakables ? (and does func_breakable still work in the current engine ?).

Since we dont need every single bit of a map to be destructible, but rather walls and things that blocks the movement, this might be worth a test.

True, the lighting is still a problem but - no offense meant - the maps beauty isnt exactly a key features of the game - well, the not-so cutting-edge graphics engine has its limits. So im not sure the visual loss of such feature would be important enough to occult the gameplay improvement. Plus, since that would let mappers in control of what is destroyable, they could find tricks and wisely place lights to make shadow errors discrete.

I dont know anything about the pathfinding system, tough.

47

Coding / Re: [SUGGESTION] Reaction fire automatic weapons behavior

« on: March 19, 2010, 02:30:52 pm »

Actually yes, I didnt really tought oh it, just kept 'rpm' because it was a known accronym

48

Coding / Re: [SUGGESTION] Reaction fire automatic weapons behavior

« on: March 19, 2010, 11:43:22 am »

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'.

49

Coding / Re: How to loop through firedefs ?

« on: March 18, 2010, 11:58:49 pm »

Thanks, ill do that.

50

Coding / Re: [SUGGESTION] Reaction fire automatic weapons behavior

« on: March 18, 2010, 11:58:25 pm »

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.

51

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.

52

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.

53

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.

54

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 ?

55

Windows / Re: Win32 Development Binary Installer Links

« on: March 14, 2010, 02:55:09 am »

Wait, I found what was wrong :

I first tried to install the release, but noticed the base folder wasnt were my current installation was. So I cancelled the installation and restarted it to point to the right folder.

The problem is that the installer, when run again, does not check for the integrity of the pk3.7z file that already exists in the temp folder. So the installer sees the pk3 file already here and does not bother re-creating it. Tries to open it, fails.

Solution : Just delete the pk3.7z file from your temp folder (c:\users\*username*\appdata\temp\ for Windows 7).

56

Windows / Re: Win32 Development Binary Installer Links

« on: March 14, 2010, 02:39:56 am »

I have the same .pk3 problem.
I tried to install over my current UFO AI install.
Also tried in a new folder, didnt work.

Also, does that version make soldiers to actually use reaction fire ?

57

Feature Requests / Re: Map did not end when all aliens dead - arrghh!

« on: January 04, 2010, 12:21:38 am »

Hello, just discovered that game today and so far its best find of the year (huh ... figures).

However, altough its my first game, I encountered the bug described on this topic, in the map displayed on the screenshots.
I've moved my soldiers everywhere in the map ("not behind that fridge either ? damn. Wait, maybe he's disguised as this fat civilian ? *BANG* ... hm, seems not.").

Im not sure of the version number, its the stable release that's currently available for download from the main page.

I really cant say for sure, but I would say the problem could be located near the "blue zone" pointed by ZebTa. Im pretty sure I saw an enemy arround here at some point while moving, did not shot it, and never saw it again. Since my game's still running, ill try to put my soldiers arround here and see if one falls.