Messages

1

Feature Requests / Re: UFO information on store/sell?

« on: May 26, 2011, 08:06:53 pm »

I think he's referring to the fact that post-mission decision to sell or store the UFO only gives you a percentage value of how intact the UFO is but no indication whatsoever of type, which you only learn when the message "UFO Scout/Fighter/Harvester/etc is being transported to UFO Yard X"

If that one single identifier was added to that screen, it should have absolutely nothing to do with UFO yard management per se.

In that window the UFO type is displayed, if you know it. So you have to research the UFO before you get the display.

2

Tactics / Re: What's your favorite weapon?

« on: May 19, 2011, 06:01:06 pm »

On range of about 5 cells, my soldier can put all three rounds from plasma rifle burst into target, but always score jsut one or two hits from burst using bolter or needler.

According to the weapon definition the plasma rifle has less spread than the bolter and needler, so I'd expect something like that.

That makes those two weapons a lot worse since their performance on short to medium ranges is terrible.

Well, repeat your test and put a wall between your soldier and the alien. ...
Does the result make the plasma rifle useless?
You see different weapons give different advantages. Other wise we wouldn't need this thread.

3

Bugs prior to release 2.4 / Re: Soldiers ignoring react fire settings.

« on: May 19, 2011, 05:27:03 pm »

There are several conditions that must be met before RF happens. So you should not expect it every time an alien is visible.

4. The very lowest react fire setting Snap Shot or similar seems to work better.

The alien must be visible long enough. I think it is RFTU/4. So the fire modes with less TU work "faster/better".

Then there is a problem with TU Reservation. When you activate RF the TU for the active fire mode are reserved. This is not updated if you change the firemode for RF. So if spend all unreserved TU you don't have enough TU for RF.

4

Bugs prior to release 2.4 / Re: Crash/Freeze when killing last enemy

« on: April 18, 2011, 06:58:24 pm »

This bug is already reported. See GroundCombat->end print-stats press-key|mouse->freeze-game - ID: 3152326

I can reproduce this with WinXP.

Now I after kill enemy do pause (ca 60s), and all is OK. ;-)

The time seems to depend on the System. For me it is only several seconds.

5

Bugs in older version (2.3.1) / Re: Bug: autostand move

« on: January 08, 2011, 10:07:43 pm »

I made a Bugfix for autostand-feature - ID: 3025283, but I don't know if it was applied to the 2.3 branch.

Please check if a soldier always stands up or moves crouched for crouched movement that costs between 12 and 18 TUs.

6

Feature Requests / Re: more strategy in 2.4

« on: January 06, 2011, 10:18:57 pm »

Productions is also to slow.
I'm barely able to feed a coilgun with ammunition ( to much ground combat )

Just found there is a bug, that resets productiontime when you load a savegame. Maybe that is the reason for the slow production.

7

Mapping / Re: new +forest map and tiles

« on: January 06, 2011, 12:11:37 pm »

There is a hole in the ground in front of the crashed scout, maybe you can fix this while you work on the other forest tiles.

Can somebody please check a bug I might have found with the randomize option. Just to make sure it is not my installation (2.4 dev IA 32 Nov 2 2010 Win32 Debug build 1288676501).
At my version this bug is only found in the campaign mode. Aliens get assigned randomly, civilians also. Phalanx troopers behave strange. The actors are not randomized, but the weapons loadout. Meaning my sniper always starts at the same position, but has a different weapon from another actor each time. It looks like weapons only are randomized.

Yes, the equipment is randomized. Thats actualy one of my snipers with the assaultrifle in the screenshot.

8

Bugs prior to release 2.4 / Re: Savegame broken

« on: January 05, 2011, 05:09:34 pm »

I don't know what's realy broken.

I wanted to load a savegame from rev 7d9e60e9291d8c496b2edeb37e32dd528ed8f44e but I got an errormessage.
After I reverted the change in 0498978de289000387fa032ff8cac3c01684a8b3 could load the old savegame.

I actualy could load a savegame that is saved with 0498978de289000387fa032ff8cac3c01684a8b3 after I reverted that change.

So, mostlikely the savegame(file) is not broken. But I think the commit 0498978de289000387fa032ff8cac3c01684a8b3 breaks the loading mechanism.

9

Bugs prior to release 2.4 / Re: Savegame broken

« on: January 05, 2011, 03:20:08 pm »

according to Git Bisect

Commit:0498978de289000387fa032ff8cac3c01684a8b3

* init the cgame mode in GetCGameAPI

is the culprit

10

Newbie Coding / Re: UI Adjustments.

« on: December 05, 2010, 01:03:27 pm »

btw speaking of which any chance for that ammo container/node/whatever, so we can show which ammo the weapon is loaded with in the hud similar to the base container (i would have created an entry on source forge but it has declared a crusade against my laptop  )

Just learned how to do something like that.
Are you still interested in such a node?

11

Newbie Coding / Re: UI Adjustments.

« on: November 07, 2010, 10:16:45 am »

When I`ve played last time, there was at least one difference. RF-single reserved TU for single shot, and RF-multi reserved as much TU as possible. That`s all.

That makes sense and sounds like a good enough reason to keep it.

From the changehistory it looks like it was (accidentally?) removed 8 month ago, but it should not be to difficult to to make it work again. On the other hand I am not aware that anybody complained about that, so it maybe was not used at all.

12

Bugs in older version (2.3.1) / Re: Calculation of TUs for movement - erroneous (sometimes)

« on: November 07, 2010, 10:12:29 am »

The only *clean* solution imho is to disallow 'new selection while moving'.

I don't know if the data is available or if this interferes with other parts of the code, but when the forbidden list is calculated, the current possition of a moving actor could be replaced with its destination. With that we get the right pathing informatin after the selection.

13

Newbie Coding / Re: UI Adjustments.

« on: November 04, 2010, 04:02:35 pm »

i don't the chance yet to verify this statement, are you really sure about this? there is rf-multiple and rf-single stuff in the game lib code the last time i looked at it.

Yes STATE_REACTION_ONCE and STATE_REACTION_MANY are still in use (just checked that with a month old copy of the master branch)

But most of the time the code handles the existing UI. (e_event_actorstatechange.c, cl_hud.c and cl_hud_callbacks.c).
In g_ai.c, g_ai_lua.c and g_morale.c the state is only set.
g_client.c handles the "Request to turn on multi- or single-reaction fire mode." and uses the same code for both states.

g_reaction.c only checks if one of the states is set and handles both the same way.

So I am quite shure: at the moment STATE_REACTION_ONCE and STATE_REACTION_MANY work the same way.

14

Newbie Coding / Re: UI Adjustments.

« on: November 03, 2010, 07:13:29 pm »

Here is an image showing what I want to accomplish with the reaction fire reservation buttons.

At the moment the "Multiple shots" button does nothing extra. I think it is a relict from the time, when the TU for RF was taken from the next turn. (And it should be removed.)

15

Bugs in older version (2.3.1) / Re: Calculation of TUs for movement - erroneous (sometimes)

« on: November 03, 2010, 06:49:12 pm »

I'm convinced no actors were selected during another actor's movement, on that turn.

That was a lie... Well, I remember I was convinced, but all current evidence suggest it was a lie.  =\

No problem with that.
You actualy managed to refine a vague bugreport to reproducable behaviour.

not a bug, but the cement barriers near the spawn has only one space between them, which "fucks" the path finding because inpatient people like me tend to select the next soldier before the first one has finished his movement.

Cramped positions are a problem - it happened to me once or twice in a harvester.
As a workaround either move one step or select an other actor

The code uses
- a routing table (which places are walkable. Constant !)
- a pathing table (where an actor can walk with his TUs. Dynamic.)
- the 'forbiddenList' (places occupied by other actors. Very dynamic.)

If I remember that right there are 2 pathing tables (one for the "client" and one for the "server")
Here it seems the pathing table at the client is only updated when a selected actor moves or a new actor is selected.
The best solution would be to update this pathing table if any actor moved. And if that is to time consuming, update the table when an actor reaches its destination.