UFO:Alien Invasion
Archive => Bugs prior to release 2.3 => Topic started by: sinister on April 13, 2010, 08:57:41 pm
-
i've just updated ufoai (29368, linux64)
when I select any of my troops in battlescape appears message like "hudenable 5" (or other number, depending on solder) and "sinister: hudenable 5" in console (it's pretty annoying :))
I removed keys.cfg but messge still appears.
also i've just cauch "Error: Received signal 11." when i tried to remove reserved TU ::)
-
I think Mattn repaired this in r29379, I am not sure though:
CIA-80 tlh2000 * r29379 /ufoai/trunk/base/ufos/ui/althud.ufo: * fixed hudenable for althud
Maybe you could test this version ?
Unfortunately I cannot help you with your 'signal 11.'-error.
-
if you find a way to reproduce the TU reservation, please post a backtrace (see debugging section in our wiki)
-
i'll try
Updated to revision 29388. (game says that 'build 29368')
when post-processing shader effects enabled rendering area in battlescape became smaller than window (see screenshot)
(http://img412.imageshack.us/img412/8034/bugnh.jpg)
cursor moves green selection cube but do not point into it
also ufoai/base/maps/city/citybldl_4x4_2a.map builds infinity time (i waited for 2 hours, stoped compiliing amd removed this file)
-
> also ufoai/base/maps/city/citybldl_4x4_2a.map builds infinity time
2 hours aren`t infinite, it can compile for a 4-6 hours.
-
strange, other maps compiles much quicker (about a 10 minutes)
-
strange, other maps compiles much quicker (about a 10 minutes)
citybldl_4x4_2a.map is the first in the new city RMA and it works at a much higher level of detail than existing maps (especially the lighting). There have been a lot of optimizations in the last couple days, so you might try getting the latest and compiling that. It's currently not playable (ie - no aliens exist on the map) anyway, so you could leave it for now.
-
At least I can confirm that it takes *ages* to compile that map, even on my i7 :(
That map alone already took more time (30+ mins and still compiling) than I used to need for compiling *all* the maps.
==> there is something 'fishy' about that map.
-
At least I can confirm that it takes *ages* to compile that map, even on my i7 :(
That map alone already took more time (30+ mins and still compiling) than I used to need for compiling *all* the maps.
==> there is something 'fishy' about that map.
Mattn did a lot of optimization work on it shortly after adding to trunk, but it's still going to be hefty compared to existing maps. Is it inappropriately hefty? I don't know. To my knowledge there are no errors that are causing the long compile times. It's just that the lighting and brush complexity far exceed any previous map for UFOAI. In addition, though I don't think this matters at compile time, the texture sizes used were in general doubled from the sizes commonly being used.
I'd be very interested in hearing more feedback about this. I pushed it at mattn's urging, but without any clear idea about how far is too far. I can't even compile the map on my machine (a puny laptop from 2005), but after the map loads in game (a little longer than other maps) it's very playable. I experience no excessive lag when flying the camera around.
But if you or someone with more technical knowledge wants to take a close look at the compile to see if there is something fishy that may be adding to the compile time, I'd be very grateful. It's my first map.
-
Hmmm. If we want beautiful (ie. rich detail) maps, we'll have to deal with loooong compile times.
Compile time heavily depends on 'brushes * lights', so if you find a way to reduce the # of lights, it would certainly help.
If that doesn't help, we'll need to separate this map (and maybe some others eg. alienbase) from the regular maps. Maybe skip it in compile_maps.bat and create some compile_special_maps.bat.
-
average users don't need to compile maps by themself.
-
Compile time heavily depends on 'brushes * lights', so if you find a way to reduce the # of lights, it would certainly help.
I may try and reduce the lights in the car elevator, but I don't want to cut down on the lights around the upper floor balconies as they really make the map stand out.
Another change I've considered is turning the columns into single brushes. I made them complex when I was in the early stages of developing the concept for the building, and now that it's complete I think it might stand alright without that complexity.
-
average users don't need to compile maps by themself.
Contributors (this includes the testers) have to. And I claim highest comfort for the contributors.
-
You could try that switch that lowers the resolution of the lightmap. That'll usually speed up the compilation by a lot.
-
If used with compile_maps.bat, wouldn't that switch reduce the lightmap resolution of *all* the maps ?
-
Sure. Some like compile_maps.bat /fast, or so on. Also you can run this cmd as "compile_maps.bat city", to include only that folder.
-
Also you can run this cmd as "compile_maps.bat city", to include only that folder.
If 'city' continues to take ages to compile, we'd need something like "compile_maps.bat -city", to *ex*clude only that folder.
-
Duke, I'm working on some optimizations, but city will continue to take ages to compile even after this. And it will only get longer as more tiles are added (right now there's only one building, but in the future there will be several).
You could run /fast on the city folder before you run the regular compile_maps.bat, because it should only compile .maps that are newer than their .bsps (if I'm remembering correctly).
-
you can also just use the
map-get.py upgrade script from contrib/scripts
-
Notabene: In this community I'm probably the one who has the *least* problems with ufo2map compile times :)
So I'm not asking for myself, I'm just trying to anticipate the problems that *others* will run into if H-Hour continues to add such beautiful maps/tiles.
@H-Hour:
Don't change the columns. They may not add to the gameplay, but they add to the atmosphere. The only thing I ask from you is to look for places where you can achieve the *same or an equivalent* result with less lights and/or brushes.
-
currently the process to fetch the surface list of each level is calculated each frame, this can be optimized to make this process less cpu-bound. R_GetSurfaceLevelList or something like that was the name of the function. This would already greatly improve maps with a lot of brushes/faces.
-
@H-Hour:
Don't change the columns. They may not add to the gameplay, but they add to the atmosphere. The only thing I ask from you is to look for places where you can achieve the *same or an equivalent* result with less lights and/or brushes.
It's too late, I already made the changes, but I actually think the columns work just as well. If you compile and feel differently, please let me know as it can be reverted. But I felt that the building fits together as a whole a little bit better with the newer (cheaper) columns I used.
-
H-Hour, I looked @ the latest versions of the (simplified) columns & have to tell you honestly that they really do not look half as good as the old ones...
The massive design of the old ones looked much better imho...
You should not really care too much about the compiling times of your map as the gamer will not have to compile the map anyway, like Kildor already mentioned & I am really wondering why Duke with the fastest computer around here shouts so often & so loud & makes you change your great design >:( ;) ;D...
You rather should take care of short loading times in-game. This can be achieved in many ways & can be optimized & applied @ a later stage of development of your map also, but do not sacrifice visual quality for shorter compilation times...