project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Edi

Pages: 1 2 [3]
31
Bugs prior to release 2.3 / Crash to Geoscape from Battlescape
« on: April 21, 2010, 10:45:48 am »
Build: 29482

Just moving a soldier along a wall in the battlescape crashed the battle to geoscape.

The relevant part of the ufoconsole log is as follows:


Code: [Select]
2010/04/21 11:35:53 ==== InitGame ====
2010/04/21 11:35:53 SV_AssembleMap: Sequential map assembly in 2 ms
2010/04/21 11:35:53 CM_LoadMap: "-oriental/or_ +craft_drop_firebird +house_b +house_c +house_e +house_f +craft_crash_fighter +house_c +trees_a +house_a +house_a +well +trees_b +trees_b +stand_b +stand_a" "-24 8 0 0 16 0 -8 0 0 0 -24 0 8 0 0 -24 -24 0 8 16 0 0 -8 0 8 -8 0 -24 0 0 16 -16 0 16 -24 0 -24 24 0 -16 24 0 -8 24 0"
2010/04/21 11:35:55 Rerouted for RMA in   1.0s
2010/04/21 11:35:55 checksum for the map '+oriental': 328065310
2010/04/21 11:35:55 ufo script checksum 3151923691
2010/04/21 11:35:55 Created AI player (team 0)
2010/04/21 11:35:55 Created AI player (team 7)
2010/04/21 11:35:55 -------------------------------------
2010/04/21 11:35:55 Connecting to localhost...
2010/04/21 11:35:55 connection attempt from loopback connection
2010/04/21 11:35:55 load material file: 'materials/oriental.mat'
2010/04/21 11:36:00 R_ParseStage: Failed to resolve texture: tex_material/desert001
2010/04/21 11:36:04 R_ModLoadTags: found 100 frames in models/objects/vegi/palm_a/palm1.tag but model has 101 frames
2010/04/21 11:36:04 Starting the game...
2010/04/21 11:36:04 Edi has joined team 1
2010/04/21 11:36:04 music change to David01 (from van_geoscape)
2010/04/21 11:36:04 music change to ufo2 (from David01)
2010/04/21 11:36:04 (player 0) It's team 1's round
2010/04/21 11:36:04 Edi has taken control over team 1.
2010/04/21 11:36:05 MN_ExecuteSetAction: node "root.team_selection.bt_actor8@disabled" doesn't exist (source: hud.hudenable)
2010/04/21 11:36:05 MN_ExecuteSetAction: node "root.team_selection.bt_actor8@disabled" doesn't exist (source: hud.hudenable)
2010/04/21 11:36:05 MN_ExecuteSetAction: node "root.team_selection.bt_actor8@disabled" doesn't exist (source: hud.hudenable)
2010/04/21 11:36:23 Shutdown gametype 'Campaign mode'
2010/04/21 11:36:23 Shutdown server: Quitting server.
2010/04/21 11:36:23 ==== ShutdownGame ====


From that, if you wanted me to pick the likely culprit, it would be

Code: [Select]
2010/04/21 11:36:00 R_ParseStage: Failed to resolve texture: tex_material/desert001
2010/04/21 11:36:04 R_ModLoadTags: found 100 frames in models/objects/vegi/palm_a/palm1.tag but model has 101 frames

On the same map, one of the house components has a bug on the first floor where you can't move past a table even though there should be space between it and the wall. So to get to the stairs going up, you have to go all the way around.

I will upload a screenshot later, right now I have to go.

32
Bugs prior to release 2.3 / Geoscape strangeness (minor)
« on: April 21, 2010, 09:04:29 am »
I installed the latest build by Destructavator yesterday and everything seems really peachy so far, but I did run across a minor strangeness with the geoscape.

If you repeatedly start a campaign, then exit, start again and so forth, after about five or six repetitions the geoscape goes haywire. It starts zooming in and out so fast that the geoscape looks like it's just flickering. Moving the geoscape stops this, but it was an interesting observation nonetheless.

I managed to replicate it just by repeating the procedure. On one occasion it also broke the zooming, so that instead of the smooth transition, zooming was step by step at set intervals. Restarting the entire game fixed that. There is nothing in the ufoconsole.log to indicate any of this.

In any case, this is at best a very minor issue that causes no problems and is easily worked around, but I figured I should report it just to be thorough.

Running Windows XP SP3 with Radeon HD4870 and the latest drivers.

33
Mapping / Problem with Bridge Map
« on: April 03, 2010, 10:24:44 pm »
Okay, some background:

I haven't got the first idea on how to use the mapping tools and am only going to be able to install them once I've downloaded the latest dev release that includes Radiant, but yesterday I encountered a map bug with the Bridge map (the one with the big railway bridge). Unfortunately I didn't have the foresight to take a screenshot, that only occurred to me later. I also have crap-all experience using the Sourceforge bug tracker to report this properly, so I figured posting here would be the safest bet.

Near the dropship, right below the cliff there is a fenced area with a car hulk, boxes, coils and other random junk scattered around that can provide cover. There is one place there that has some sort of glitch that either screws up the movement calculation algorithm or does something else. It is a corner between a big overturned industrial coil reel and a stack of boxes.

When I moved a soldier there, he got stuck. He could move into that square just fine, could turn around in it, but he could NOT move out of it again. The first time I tried to move him, the game deducted the TUs required for the move but he didn't go anywhere. Same on the second try. After that, it did not even give me the option to try to move him, everything was indicated as being inaccessible and he remained in this stuck mode until the end of combat.

If someone here who understands mapmaking has the inclination to look into this, check that section of the map and possible validation issues it may have, it would probably be helpful for the game, since the way the alien spawn points and the dropship start location are set up, that particular piece of buggy real estate is THE place to take cover on that half of the map.

If the description of this issue is sufficiently accurate, maybe it will allow either a fix into the SVN or otherwise proper reporting with the relevant technical details.

Thank you for your time.

34
Windows / Bug or Feature? Keybindings & language
« on: March 16, 2010, 08:53:22 am »
Hello,

First post here, and I want to thank everyone involved for an awesome game. :D

However, I ran into some very strange behavior yesterday when I installed the latest dev release of UFO: AI, from muton's compilation. The filename was ufoai-2.3-dev-29004-Debug-pentium3-O1-sse-7z-small-win32.exe and it installed quite handily.

I use the English language version, but for some reason when going into the input options and looking at the keybindings, they appear in Finnish. I'm located in Finland, and that's what the Windows location info says, but I have an English language Windows XP Pro and I do not ever use any programs localized to Finnish if I can help it. I could change the language of the game interface to anything I chose from the list, but no matter what I picked, the keybinding explanations stayed in Finnish.

It seems like for some reason the game was using the selected interface language files for everything else, but it always mapped the keybindings to the Windows location info and picked that language for them. I found this HIGHLY annoying. It's also an issue for users who may be in other countries and have their PC location info set according to that and then get something that is only gibberish to them. It is also an issue if there are multiple users in the same household who speak different languages and only use one language in common.

There is a workaround:

Go to the [drive]:\[installdirectory]\UFOAI-2.3-dev\base\i18n directory, make a new directory (e.g. Archive) and dump all the language subdirectories except the one you want in there. This forces the game to use the only available language file to display the keybindings in the correct language regardless of any other settings. Obviously this workaround locks the game into that one language and you need to restore the appropriate archived directories to their normal location to have the option to change the interface language.

To me, this behavior seems to be a bug, but since I know next to nothing about the architecture and the mechanics of the interface, I'm not quite sure. It could be a feature as a result of certain coding issues, but it is certainly not expected behavior. It could also be a Windows issue, which is why this post is here. For this reason it should be looked at if anyone finds the time.

Thank you for your time.

Pages: 1 2 [3]