Messages

211

Mac / Re: bugs (in Mac version at least)

« on: September 23, 2011, 08:07:19 pm »

Hi,
I have played with my 2.4-DEV PPC version for a couple of nights now.
Apart from the GL shading problems I noted the following bugs, but I am not sure if they are intentional, just not done yet or actual issues.

Guess I can give you some pointers here

Second problem appears in the tactical maps.   If I shoot at an alien, there is no weapon sound, no "tracer" of a projectile and
no animation of an impact etc.    A flamethrower doesn't produce any flames or anything.  There's no indication of a hit
or anything - if I kill an alien, it will scream and die, but it seems there is something missing.

That's obviously a problem with a particle system, which is responsible for rendering tracers, explosions and such. Most probably, you have some problem with reading the .ufo files defining those particles.

Reaction fire from an alien happens
almost instantly, so it looked like in many cases, I would line up a shot and click the mouse and the alien would shoot back
in the same instant, so it looks like my trooper shot himself!

That's an actual bug, and I'm constantly forgetting to report it

Also, in the Credits view, there's  a collection of troopers, some great music and their names.    They are all headless warriors however,
so they look a bit weird.   Please supply heads for these brave troopers!

Again, heads are defined in .ufo files (unlike the models IIRC), so it's probably the same problem.

Thirdly, as mentioned previously, the Save game slots do not display any text, but appear to save/load just fine in spite of a "save slot corrupted" message.

A some sort of generic text file processing problem? Remember, saves are zipped XML files, essentially, the texts. Maybe you have stumbled upon some sort of text-processing problem specific to big-endian machines?

Lastly,  enabling any GL features "not supported" will overload my G5, the fans kick in and the mouse cursor becomes very unresponsive.

Enabling GL shaders is a big performance hit as for now. Future optimizations should (and will) address this problem.

212

Mapping / Re: new +forest map and tiles

« on: August 21, 2011, 12:26:39 am »

tilli, thanks a lot for finishing a new map theme! But -- why didn't you use a transparent, flowing water material? Current one you are using looks more like plastic than water

PS: See the dam map for example of transparent water.

213

Mapping / Re: Looking for tips on reducing polys

« on: August 16, 2011, 06:43:14 pm »

So, if I understand you correctly, two detail brushes that touch each other can split each other, even though they won't split the "regular" brushes around them?

They do not need to touch each other -- even if face plane (which is infinite) of one brush intersects some other brush it can cause a split.

That's interesting, and could be the source of a lot of the polys in hub especially, where I have used a lot of boxes slightly rotated but stacked on top of each other.

That's possible.

PS: Will commit patch to compiler's initial splitter in a few hours.

214

Mapping / Re: Looking for tips on reducing polys

« on: August 16, 2011, 04:31:10 pm »

At first, detail brushes in UFO:AI do not cause world brush splits, but can split each other -- they still are in the BSP tree. Older Quake engine got true detail objects (func_detail), but they got removed.

Second, those unnecessary splits are because BSPT builder heuristics chose bad splitplane from faces of nearby object and minced everything in the same node horisontally. And did that several times. To test that, I changed intial splitter (ConstructLevelNodes) to make splits every 128 units and snap them to 64 unit grid (old version was just recursively bisecting the map by longer axis until all segments are shorter than 256 units). That reduced bad splitting a lot, and also reduced face count for complex maps. For example, alienb2/ab_hub was reduced from 13.5K faces to 10.5K -- more than 20%. Guess that should be in master

Third, you can always use hint brushes to isolate geometry from being splitted or cause unneeded splits of nearby brushes. I've checked -- they work ok (sometimes there is a random split of unknown origin, but nothing more).

PS: All shots are from hub tile, right? You didn't say from which tiles they were taken ...

215

Newbie Coding / Re: The GIT problem

« on: June 15, 2011, 09:00:06 pm »

Just before thread gets locked I have a proposal: we could make online zipped copy of master branch (~2 GB now), so everyone could download it after setting up git, unzip without caring for git quirks (everything will be configured properly in the .git/), and have a working local repo.

Objections?

216

Artwork / Re: Material parameters (to avoid super-shiny textures)

« on: June 11, 2011, 05:18:22 pm »

Just for everyone to know, r_default_specular and r_default_hardness console vars are already available. For a week in fact

217

Artwork / Re: Texture replacement thread

« on: June 07, 2011, 07:59:14 pm »

Now that I know about PNG optimization, they will be getting optimized.

Alas, PNG optimizer you are using is not the best one:

Code: [Select]

>pngout.exe /f5 complex004.png complex004_.png
 In:   16436 bytes               complex004.png /c2 /f5
Out:   13247 bytes               complex004_.png /c2 /f5
Chg:   -3189 bytes ( 80% of original)

>pngout.exe /f5 dirt002_high.png dirt002_high_.png
 In:  390111 bytes               dirt002_high.png /c2 /f5
Out:  372172 bytes               dirt002_high_.png /c2 /f5
Chg:  -17939 bytes ( 95% of original)

You really should consider trying the pngout -- it's absolutely free, the only drawback is it being a command line tool.

PS: Thanks for the texture work!

218

Artwork / Re: Texture replacement thread

« on: June 03, 2011, 09:07:18 pm »

thanks also for the higher res textures, we will apply them once Sandros patch is working.

Until patch is finished, you can mass rescale textures by using the Python script. It is located at src/tools/scripts/map_scale_textures.py

Code: [Select]

cd where_ufoai_is/src/tools/scripts/
python map_scale_textures.py ../../../base/maps -r texture_name scalex scaley
Will rescale ALL occurences of texture_name in base/maps/...../*.map

For example, if you replaced 128x128 tex_buildings/floor024 by 512x512, call it like this:

Code: [Select]

cd where_ufoai_is/src/tools/scripts/
python map_scale_textures.py ../../../base/maps -r  tex_buildings/floor024 0.25 0.25


219

Bugs prior to release 2.4 / Re: Geoscape Message List in Windowed Mode

« on: May 19, 2011, 11:23:41 pm »

Why not change the resolution to be somewhat lower? Personally, when playing windowed I set game to use 1600x900 window at my 1920x1080 monitor. Covers almost all desktop area, but doesn't give such problems.

220

Artwork / Re: Material parameters (to avoid super-shiny textures)

« on: May 15, 2011, 01:56:14 am »

Editing the .mat file would mean to edit it for each texture separately afaik, that is why I was asking...

Sure, but that will be needed only for testing stage -- when good default values will be found, they will be hardcoded into game.

I vote for the new r_default_specular & r_default_hardness variables, which then can be overridden for defined textures via material system.

If my amount of free time allows will code those vars, then.

AFAIR Arisian did some coding on this issue & the maximum value was set to 1.0 then: (http://ufoai.ninex.info/forum/index.php?topic=3181.msg38560#msg38560)

Thanks, read the whole thread. It explains how all that default material values mess did happen

221

Artwork / Re: Material parameters (to avoid super-shiny textures)

« on: May 15, 2011, 12:40:47 am »

Simplest method would be to edit the .mat file. On the other hand, there are r_specular and r_hardness console variables in the game, but they act as multipliers, not the default values. It would be possible to change them to be the deafult values, or, even better, introduce a new r_default_specular and r_default_hardness variables.

Edit:
I mean, the values in the .mat file just replace the default parameters, so creating them will result in the very same image as by changing the default values. They are treated just the same.

222

Artwork / Material parameters (to avoid super-shiny textures)

« on: May 15, 2011, 12:24:44 am »

As all of you are have noticed, changes in the renderer brought one very unpleasant feature: all textures that do not have material parameters "specular" and "hardness" defined are reflective to the point of oily, or even metallic look.

This is because of fixing the bug which prevented assignment of default material parameters to textures (in most cases), but current default parameters are not good: they are all set to 1.0, which is very shiny. Looks like it would be a good idea to set some different, better material parameters, but since I'm no artist, I want to ask people of arts -- what values are the best ones?

223

Bugs prior to release 2.4 / Re: Material System's Flares always drawn behind models or ...

« on: May 10, 2011, 10:42:13 pm »

Looks like I've found where the problem with those flares on gate map lies. They are rendered for the detail brushes, not the world ones, and while changing code to ensure a global rendering order I somehow missed the possibility for detail brushes to have effects.
Will fix that, but not instantly -- should think how to organize code better. Anxious hacking at code is bad

224

Bugs prior to release 2.4 / Re: Material System's Flares always drawn behind models or ...

« on: May 10, 2011, 05:07:18 pm »

Hmm, those flares on gate map not only rendered incorrectly, but also have broken visibility check (shining through a solid wall). Will investigate what causes that.

225

Bugs prior to release 2.4 / Re: Settings roll over between missions

« on: April 20, 2011, 07:32:01 pm »

Personally, I would like the option to (automatically) set initial reaction fire mode at the beginning of combat. Setting them to max autofire anyway at the 1st round ...