Topics

1

Artwork / Camouflage patterns

« on: October 26, 2014, 06:11:04 pm »

As all of you know, new and pretty soldier models lack camouflage suits. Since I'm not a texture painter, I cannot help with it much, but at least I can generate some camouflage texture patterns to use. Hopefully our artists will like those

Technical details:
Size: 256x256 pixels
Type: fractal pixel camouflage
Varieties: arctic, forest, desert, urban

2

Bugs in stable version (2.5) / Bug with high-detailed maps (city2, city3, mansion) being broken is intentional

« on: January 29, 2013, 11:26:36 pm »

As a part of making engine to be fully compliant with OpenGL ES 1.1 (needed for mobile hardware), we had to put certain restrictions on the rendering engine, causing those maps to be broken. Problems with those maps are well known, and they will be fixed for 2.5 release version.

Please do not make bug reports about it. Thanks.

For the adventurous, here are instructions for modifying the files to disable these maps.

3

Mapping / Procedural water - why not?

« on: August 31, 2012, 07:39:23 pm »

Personally, I don't like current water at all. Current "water" swirling material could be good for Quake's murky basins,  is not good for simulating the kind of water we usually meet; even more, it behaves differently in FFP and GLSL renderers, which somewhat breaks the "mansion" map (and maybe some others).
I've been thinking about it a lot, considering various ways, but was always returning to the same thought: we can use the same approach as in Cossacks, using the procedural water simulation to create random, realistically-looking water. And they were doing on 100 MHz Pentium, remember? It was fast enough.
Finally, today it somehow dawned on me, so I've understood how to make simplest possible fluid solver, so after a few hours it was written, tested and tweaked to look like real water (it is not physically correct, but is based on real world hydrodinamics).
It is relatively fast: unoptimized version, being written entirely in Java consumes only about 1% of CPU while rendering 256x256 heightmap at 20 frames/sec.

I'm attaching it to the post, so everyone could play with it and say whether it is good or not. Requres Java Standard Edition (SE) 1.6 or later. Download, extract fluidsolver01.jar from the archive and run with "java -jar fluidsolver01.jar"
Click or click-drag mouse to disturb water, there are no built-in wave generators for now.

4

Feature Requests / Reaction fire & TU reservation

« on: August 29, 2012, 04:34:11 pm »

Personally, I don't like how those are handled currently, and got some ideas for improvement. Mentioned those a few months ago at IRC, but was too lazy for proper explanation Anyway, now it is written, so here goes:

First, what we should do when designing the UI and underlying game logic, is to consider how easy it would be for player to understand and to interact with. Which requires understanding of what and when player would want to do with UI controls, and how often. And that brings us to the topic: reaction fire and TU reservation controls.

Why anyone would reserve TUs for firing? To avoid accidentally spending them on moving, of course! There simply could be no other reason. But current design does more: it prevents TUs reserved for shooting ... from being used for shooting! What is the logic behind this? I fail to see it.
To continue with, not only TU reservation, but RF TU reservation prevents player from shooting. For me, it is illogical too: first, any reasonable player would fire a gun only if he got an alien he is able to shoot at, and in that case saving TUs for RF is a bad strategy, since the earlier you have killed that alien, the better; second, firing a gun in UFO:AI requires three step sequence: click the "crosshairs" icon, select firemode, select target; there is almost no chance to do that by accident, so no protection is needed. RF TU reservation should not block a player from firing a gun. He expressed his decision to spend those TUs by following a sequence of UI manipulations and there is no reason to add more -- that will just add extra frustration.
Even more, current system got a rather complex logic with two TU reservation pools: one for RF and other not for RF, which stack, rather than overlap. To me, that seems to be overcompicated logic: if player reserves TUs for shooting ... he just reserves TUs for shooting, not for "one way of shooting" and the "other way of shooting after the first shooting is done, if any". Try to imagine the combat situation when that could be needed!
Most likely, the only difference is whether he will use them for shooting on his turn, or leave them reserved for RF on the alien turn. Hence, two reservation systems are not needed: one is enough.

So, my proposals are:
1) Instead of what we got now, just make a pair of on/off switches, with first of them enabling TU reservation, and other enabling the reaction fire. That should be enough of controls.
2) There should be a global control for people like me who want RF to be always on (could completely remove "RF" button from the battlescape UI).
3) Reserved TUs should NOT be protected from being spent for firing or reloading.
4) A little extra: no "RF firemode selection". RF should automatically use a firemode which will deliver the max damage for available TUs. When alien jumps you from behind the corner, it's not a time for conserving the ammo. You just pull the trigger and don't release it until one of you is dead, that's all.

Opinions, anyone?

5

Bugs in stable version (2.5) / Savegame that crashes 980e88 for me

« on: May 30, 2012, 03:52:39 pm »

Loading that save randomly crshes said revision. If game was loaded ok, saving it immediately creates save with the same (mis)behaviour.

6

Offtopic / The REAL geoscape

« on: May 17, 2012, 02:51:11 pm »

Hi, and sorry for being absent for some time.

Here is the interesting thing that appeared recently: the video taken from the Elektro-L, the new Russian weather monitoring satellite. It is geostationary, so view is almost like one in the game, and takes 121 megapixel shot every 30 minutes.
Youtube link (recolored to true color, satellite shoots in 4 color components to be able to see the foliage): http://www.youtube.com/watch?v=FGEm30fdRoo

Also, for those who interested, here the short launch video (alas, it was overcast, so rocket hides behind clouds very fast): http://www.youtube.com/watch?v=vcJQmljCiOk

7

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?

8

Coding / [RADIANT] CSG subtract [Shift+U] operation could generate better geometry

« on: February 24, 2011, 04:07:41 pm »

I'm not sure if it should be discussed here or in the "mapping" forum, but "coding" looks more likely. So, here goes:

Today I have tried to create playground for testing transparencies (there are not much of them in game), and immediately stumbled upon a problem with CSG subtract. Cutting holes with simple (box) brushes results in more or less editable geometry, but that's not true for more complex shapes.
For example, cutting a box with cone results in multiple narrow, odd-shaped "splinter" brushes, some with a very low volume. Such geometry is very hard (sometimes outright impossible) to edit, and ufo2map doesn't like it very much, complaining about microbrushes. I've even got wrong ufo2map output (polygons where they should not be) in a relatively simple case.

All of that happens because Radiant takes the simples approach possible -- it just (recursively) cuts brush A with all planes of brush B, slicing out wedge-shaped brushes with all cuts but first and last.
That's not the only method possible: brush A could be cut some other way, generating more editable and generally safe geometry. One of them, which I like the most, is to cut brush A into pyramids based on the brush B sides. For a 2D example, look at the attached drawing.

Opinions?