Messages

16

Tactics / Re: Combat Medics

« on: July 09, 2012, 09:38:42 pm »

Also true, but then you have the current problem in that pistol weapons are pretty much ignored as pointless because why use one when you can just use a rifle instead? The starting difference in soldier stats is generally negligible except for the odd exceptional recruit, using a weapon with an 18 skill doesn't seem to have much difference to using one with 23 and that range is more common than anything outside it.

Pistols have two big things going for them: very low minimum TU usage and one-handed use. The latter in particular means you can have a different damage type in each hand—in 2.4 I often had soldiers with a laser pistol in one hand for ranged combat and a monoknife in the other for when they rounded a corner smack into a hostile. In 2.5 the plasma pistol is currently so good that a knife is no longer necessary, but a grenade in hand can be very handy (8 TUs instead of 10 to deploy). When particle beam pistols come onto the scene, plasma pistol+PBP becomes viable.

As for backup weapons, for most purposes I find that the machine pistol is the only pistol small enough to serve backup—and that's obsolete almost as soon as the game starts.

~J

17

Tactics / Re: Combat Medics

« on: July 08, 2012, 06:01:54 pm »

I do this too, but it has me wondering if this is something that should be "fixed"... Have you ever tried administering stuff from a First Aid kit while still holding an assault rifle or grenade launcher? Perhaps they should be changed to two-handed held and not just firing like the rocket launcher currently is, making the idea of a Combat Medic as originally described here more useful.

But realism shouldn't just be enforced where it's inconvenient for the player. If it's important to be realistic about how many hands a medkit takes to apply, it should also be important to be realistic about the fact that an assault rifle or grenade launcher would be on a strap, enabling it to be "dropped" and recovered quickly and without detachment (so you can "drop", move, and then recover). So on and so forth.

~J

18

Feature Requests / Re: Damage buildings/wall by rockets and/or explosives

« on: July 06, 2012, 06:37:04 am »

Can someone actually explain why destructible terrain is impossible? No one's ever given a clear explanation of why it's impossible, at best we get excuses or vaguely condescending "it's too technical for you" type responses.

It's constantly stated that the Q2 engine can't handle it, and yet I can boot up Quake 2 right now and blow open a wall in the first level.

I'm not sure there really is a useful explanation other than "it's too technical for you", in no small part probably because it's also too technical for the devs. Destructible terrain is, you may notice, pretty unusual as a feature (and Quake 2 certainly does not feature it—the occasional destructible entity gussied up to look like terrain is a much simpler beast entirely), and I wouldn't expect the devs to have done anything in the area even if they were all employed in the gaming industry (which I have no reason to believe they are).

This isn't to say that it's deep, unknowable magic, but apparently someone did in fact do the hard work of researching to see if implementing it was feasible, and came back with the answer "no". They don't seem to be around anymore, so assuming the devs still trust that person's judgement redoing that research just to give you a better answer doesn't seem entirely reasonable.

~J

19

Tactics / Re: Combat Medics

« on: July 05, 2012, 11:05:42 pm »

I still carry a medpack on each soldier, but it's handy to be able to patch someone up quickly when things are hot.

Again, though, "quickly" is 20 TUs instead of 22. You really find the savings that valuable?

~J

20

Discussion / Re: Review & Suggestions

« on: July 05, 2012, 04:39:20 pm »

I didnt explain myself very well: there should be missions where is really important to capture live aliens, otherwise no one will  try to capture them (only for research).

I agree that the lack of any reason to capture more than 10 aliens is a problem, but this strikes me as a bad way to deal with the issue.

~J

21

Discussion / Re: Funny Things

« on: July 05, 2012, 04:36:54 pm »

Careful, keep talking like that and you'll get even less variety in mission map selection

~J

22

Discussion / Re: Enemy on Earth Question

« on: July 03, 2012, 08:28:33 pm »

Enemy on Earth the research proposal is working, or at least was in the recent past. I've never seen civilians actually attack, though.

~J

23

Bugs in stable version (2.5) / Re: Build of 2.5-dev fails to initialize com_genericPool before use on Darwin/Clang

« on: June 29, 2012, 11:17:11 pm »

Bringing some stuff back home from IRC:

I had asked for guidance on whether the candidate solution was acceptable in general, whether only com_genericPool should receive the initialization-before-main treatment, and whether it should be in platform-specific code or if all platforms should initialize com_genericPool before main. I got a request for a demonstrative patch and gave the following:

Code: [Select]

@ -661,6 +661,11 @@ void R_ReallocateTexunitArray(gltexunit_t * texunit, int si
                r_state.active_texunit = texunit;
 }
 
+void really_init() __attribute__ ((constructor));
+void really_init(){
+  com_genericPool = Mem_CreatePool("ufomodel");
+}
+
 int main (int argc, char **argv)
 {
        Com_Printf("---- ufomodel " VERSION " ----\n");
@@ -673,7 +678,6 @@ int main (int argc, char **argv)
                Exit(1);
        }
 
-       com_genericPool = Mem_CreatePool("ufomodel");
        com_fileSysPool = Mem_CreatePool("ufomodel filesys");
        vid_modelPool = Mem_CreatePool("ufomodel model");
        vid_imagePool = Mem_CreatePool("ufomodel image");
(Which, of course, applies to src/tools/ufomodel/ufomodel.cpp—I was overzealous in not copying administrative debris)

Mattn suggested that in ufo some other systems needed to be working before memory pool initialization could occur, but I whipped up the following:

Code: [Select]

diff --git a/src/ports/macosx/osx_main.cpp b/src/ports/macosx/osx_main.cpp
index 74e177d..97d8cbe 100644
--- a/src/ports/macosx/osx_main.cpp
+++ b/src/ports/macosx/osx_main.cpp
@@ -54,6 +54,11 @@ static void SetWorkingDirectory ()
                Com_Printf("Failed to get path of main bundle\n");
 }
 
+void really_init() __attribute__ ((constructor));
+void really_init(){
+  com_genericPool = Mem_CreatePool("Generic");
+}
+
 /**
  * @brief The entry point for OSX server and client.
  *

which worked, at least as far as I could tell, without further issue.

~J

24

Bugs in stable version (2.5) / Re: Build of 2.5-dev fails to initialize com_genericPool before use on Darwin/Clang

« on: June 28, 2012, 07:25:09 pm »

Ok, so it's groundwork for using the pools transparently in the future. Time to install that VM, then!

~J

25

Bugs in stable version (2.5) / Re: Build of 2.5-dev fails to initialize com_genericPool before use on Darwin/Clang

« on: June 28, 2012, 05:33:15 pm »

Repeating a question from IRC in case no one ends up seeing it there:

Do we know that there are clear benefits to the redefinitions? Benchmarks showing clear performance improvements, or additional known-valuable information about allocations, or somesuch? I'm considering digging into Nokim's issue, but I want to make sure that they're actually worth salvaging before putting in the effort.

~J

26

Bugs in stable version (2.5) / Re: Build of 2.5-dev fails to initialize com_genericPool before use on Darwin/Clang

« on: June 28, 2012, 05:24:59 pm »

It's not clear to me exactly what distinction I was trying to draw there. Maybe I'd just gotten confused.

My best candidate for a solution at the moment (other than removing the operator redefinitions) is to stick memory pool initialization, at least for com_genericPool, into a function with a constructor attribute to force initialization before main. As a solution it makes me feel a little unhappy, but I've confirmed that it works on ufomodel at least.

~J

27

Tactics / Re: Combat Medics

« on: June 25, 2012, 03:44:15 pm »

[…] if the medikit is not already in hand, you probably won't be able to apply a patch until the turn *after* you get behind cover.

For a soldier with a two-hand-fire, one-hand-hold weapon, it's only an additional two TUs to pull a medkit from the holster. For one-hand-fire I generally prefer to have them have a weapon in each hand for better flexibility (plasma pistol and monoknife is a perennial combo, or plasma pistol and grenade).

~J

28

Tactics / Re: Hoverbots. AARGH!

« on: June 22, 2012, 02:32:56 pm »

No, you don't need to start a new game. They should appear as long as you have reached the stage in the game when they are scripted to appear.

Well, that and wait for a new mission to spawn.

~J

29

Bugs in stable version (2.5) / Re: Build of 2.5-dev fails to initialize com_genericPool before use on Darwin/Clang

« on: June 22, 2012, 02:31:18 pm »

the std::min/std::max change was made by me as a little optimization. it now uses the inline versions of min/max, not the macros, thus, it only executes the statements that are given to the functions once.

Sorry, what I meant was: the addition of the new/delete operator redefinitions occurs in a commit whose commit message only discusses std::min/std::max. I was asking for expansion on the operator redefinitions—the rest of the changes in the commit are indeed std::min/max related.

My guess is that external libs start to use our operator new. And do so before pool get initialized. And this should be linker-related, not compiler.

Yeah, that's what I concluded—though I'm not sure it's linker-related, as it does seem to be doing exactly what it was told. I'd been looking to see if there wasn't something that should be done to restrict the scope of the redefinition, or if SDL might not have some way to provide an initialization block that would run before SDL's internal initialization, but no dice.

So I commented out those new and delete operator and have all running fine. They are supposed to speed up allocating memory and get some stat on it, but i prefer stability.

Are we sure the redefinitions are (ostensibly) purely an optimization?

You can try to set breakpoint in operator new to find when it's first time called. And from where.

For about five minutes I was smacking myself on the forehead wondering why I didn't think of this, but I realized that it's because I already have the stack trace (posted above). In any event, since it happens strictly before anything in the UFO:AI entry point runs the details of precisely where it all goes wrong don't seem critical.

On the other hand, I think this makes for a satisfactory explanation of why the uninitialized pool only shows up on OS X (it just happens that on OS X SDL's initialization generates a call to new that doesn't appear on other platforms).

But other than simply removing the operators, I'm still no closer to identifying a solution.

~J

30

Tactics / Re: Hoverbots. AARGH!

« on: June 21, 2012, 08:12:02 pm »

Hovernets are easy targets for grenades. I can't say for combat hovernet, but regular one can be killed with one frag grenade. Plasma is better of course. So one GL in squad is "must have" now.

I haven't checked the damage adjustments for difficulty levels higher than Normal, but at the moment a frag grenade or 25mm HIT grenade is a guaranteed kill out to 1/3 of blast radius (further for HIT). Combat Hovernets are much more resistant and almost guaranteed to take at least two grenades (a direct hit with a maximum-damage HIT grenade will kill in one shot).

~J