[taylor]

Try to lock the  perspective in FRED (or try mission 0 in SoL).

However... I would not even really consider this a bug...

Hmm, I'll give that a try in the next day or two and see if I can't track it down.

Go ahead and Mantis it though, since there is a good chance that I'll forget about it, and I would certainly consider this a bug.

[ARSPR]

Well, I've discovered two issues afterburners trails not showing (3.6.9. works fine) and while I was investigating this one I found a pilot data corruption (3.6.9. also has it). OTOH Mantis is down...

Downloading it all now.  I should be able to fix the AB trail problem later today, but I'm not sure what's up with the pilot file corruption.  I'll go through the various files, figure out what's going on, and try to get it fixed for a new test build next week.

I've been trying to pinpoint when the missing AB trail issue started to happen and I get it even since XT0124 
I've confirmed it happens with -no_glsl too and with/without window mode.

It also happens with CVS0807, CVS0815 and CVS0922. Only "official" 3.6.9. (3rd version) works fine.

OTOH, I've tried running some debug builds and they all crash. I remember running some of them in my old WinXP system, so I feel that there's something in Vista that debug builds don't like. A typical error detail (Windows has closed the program... bla, bla, bla) is:

(I've made a translation to English between brackets)

Code: [Select]

Firma con problemas:
  Nombre del evento de problema: APPCRASH       (Name of event with trouble)
  Nombre de la aplicación: fs2_open_3_6_10_debug-20071007T.exe     (Application name)
  Versión de la aplicación: 1.0.0.1    (Application version)
  Marca de tiempo de la aplicación: 47099af9   (Application time stamp)
  Nombre del módulo con errores: fs2_open_3_6_10_debug-20071007T.exe (Name of module with errors)
  Versión del módulo con errores: 1.0.0.1  (Version of module with errors)
  Marca de tiempo del módulo con errores: 47099af9  (Module with errors timestamp)
  Código de excepción: 80000003   (Exception code)
  Desplazamiento de excepción: 0018f1b7  (Exception displacement)
  Versión del sistema operativo: 6.0.6000.2.0.0.256.1   (OS version)
  Id. de configuración regional: 1034   (Regional configuration Id)
  Información adicional 1: af8a  (Additiona information 1)
  Información adicional 2: 4d575f71dab28f6b5bd01237b1c31051   (Additiona information 2)
  Información adicional 3: 849b  (Additiona information 3)
  Información adicional 4: 7f1ebf22c0a760f16f14d27d49191081   (Additiona information 4)

Official debug 3.6.9. also crashes but just before doing it, it gives the next FS2 warning:

Code: [Select]

Warning: weapons.tbl(line 149:
Warning: Error parsing XSTR() tag XSTR(
", 3245)

File:J:\src\cvs\fs2_open_3_6_9.final\code\Parse\PARSELO.CPP
Line: 657
[This filename points to the location of a file on the computer that built this executable]

Call stack:
------------------------------------------------------------------
    lcl_ext_get_text()    lcl_ext_localize_sub()    lcl_ext_localize()    stuff_string()    stuff_and_malloc_string()    stuff_malloc_string()    parse_weapon()    parse_weaponstbl()    weapon_init()    game_init()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 75bc3833()
    ntdll.dll 76f7a9bd()
------------------------------------------------------------------

If you want me to post some more info or perform some other specific tests, just ask.

[taylor]

I've been trying to pinpoint when the missing AB trail issue started to happen and I get it even since XT0124 
I've confirmed it happens with -no_glsl too and with/without window mode.

It's fixed already, don't worry.

It was just a simple load order issue.  The graphics were being paged in like they were supposed to, but since the trails are setup on a ship when it's created, and ships are created during mission parse (before page-in), the textures weren't loaded at the time the ship was created.  That's also why simply doing a reload fixes the problem, since it can easily re-assign the textures again since they remain loaded.

I fixed it by breaking the AB trail setup into it's own function, so that it can be called both which a ship is created, and when textures are paged in.  That makes sure that it will always work.


Regarding the other problem, it is actually supposed to crash there with a debug build.  Well, it's an Int3(), which causes a program interrupt.  As the 3.6.9 debug warning reports, it's simply a table error and not a code issue.  Warning popups are still disabled in stable CVS builds, since I'm still working on the new code for that, otherwise you would have gotten the exact same message in newer builds.

[Spidey-]

err... so stupid question, i'm running a 7900GS--do the new features only work on an ATI card?

[chief1983]

No, your card should be very supported.  Just make sure you have a fairly recent driver set.  Probably forceware 100 and up are good, if you have issues just grab the latest, I think they're known to work pretty well.

[ARSPR]

I've been trying to pinpoint when the missing AB trail issue started to happen and I get it even since XT0124 
I've confirmed it happens with -no_glsl too and with/without window mode.

It's fixed already, don't worry.

Thanks Taylor.

OTOH, have you discovered what got wrong with the pilot files?

[Kaboodles]

Is framerate supposed to decrease steadily with proximity to ships?  In extreme close-ups my framerate dips into the mid-teens.  I don't recall this ever happening before.

[CiberWizZ]

hi, i compiled this build under Linux, and i  have a few problems.

In my current mission i have to escort Galatea through an asteroid Field or whatever...

I noticed a lot of breaks during gameplay using ./fs2_open_r  -mod fsport,mediaVPs    the same happens with   ./fs2_open_r

Using ./fs2_open_r  -mod fsport,mediaVPs -glow results  in a complete break as soon as the mission starts, well 1 or 2 frames later...

with ./fs2_open_r  -mod fsport,mediaVPs -spec before the mission started i was choosing another ship for me and as soon as i did it it broke, the above happened as well.

haven't tried the other args...

Note: when i say "it breaks" i don't mean it crashes. I have to kill the X to sort this problem...(using ubuntu with latest ati drivers)

what do you think?

CiberWizZ

[Turey]

What version of fs2_open did you compile?

Perhaps you should try out the precompiled 3.6.9 builds?

[CiberWizZ]

Hi, i compiled the build mentioned on this post meaning 2007-10-07 stable branch (Xt version) a normal configuration.

Yes i have tryed the official build. I've seen some screenshots of this build in action and wanted to try for my self. I may be new to this community but i'm starting to take an interest in this project. Because of that i'm posting my problems in order to help those to come and have the best this community has to offer.

My regards,
CiberWizZ

[chief1983]

Try running the _d build if you compiled it, and see if you get any useful output, go through the errorlog maybe, etc.  Also, what video card and drivers do you have?  Open source?  Binary?

[Smutmulch]

I've been having a similar problem to CiberWizZ, with the build from the first post here and any build from CVS over the last few months.  That is, repeated crashes, especially when using extra command line arguments or mods.  Most of these occur one or two frames after entering a mission.  The crashes that are recoverable simply report a segmentation fault.  The official build still works for me, but has the annoying bug that asteroids are never generated, making some missions impossible.

my system:
ubuntu 7.10 (recently updated, which fiddled with a lot of graphics issues.  problems were much less severe with 7.04)
radeon x300 with 8.37.6 drivers

CiberWizZ:
first of all, are you using xgl?  I've only been able to run fs2_open at all from a non-xgl failsafe session.
Also, have you tried running on a separate X display?  there's a tutorial in the wiki, and (though it has the potential to break security) it has both made fs2 more reliable for me and when crashes have occurred it's been shooting me back to my desktop.  YMMV.


I'll go try a debug build soon and see what happens.. have exams tonight so it might be a few days though.

[chief1983]

Isn't that Gutsy?  I thought it was still in beta testing.  I tried Beta 1, it was a piece.  I wouldn't expect anything to run right on it until it's released.

[jr2]

Right... and to make it to the point of release, we need gutsy people. 

[CiberWizZ]

3.6.9 didn't generate asteroids for me either... that was the main reason for me to try to compile.

CiberWizZ:
first of all, are you using xgl?  I've only been able to run fs2_open at all from a non-xgl failsafe session.
Also, have you tried running on a separate X display?  there's a tutorial in the wiki, and (though it has the potential to break security) it has both made fs2 more reliable for me and when crashes have occurred it's been shooting me back to my desktop.  YMMV.
I'll go try a debug build soon and see what happens.. have exams tonight so it might be a few days though.

I'm using the 8.41.7 ati driver (propriety) with my x1600 on feisty. I don't use xgl ( at least until AIGLX  is supported ,soon  ) Haven't tried to use another X for the game....

chief1983 I suppose thats the debug version....how do i choose that version to compile?

[chief1983]

That I can't say, it may just be some sort of option you can pass during config, I don't really know.

[ARSPR]

3.6.9 didn't generate asteroids for me either... that was the main reason for me to try to compile.

This thread is going offtopic really fast ...

Nevertheless, I bet that this problem is just that you are not using -jpgtga launcher flag. The problem is that old fsopen versions do no use jpg and tga textures by default. So the asteroids are just invisible. This option is now enabled by default.

[karajorma]

In 3.6.9, yes. The -jpgtga flag has been removed in builds after 3.6.9 and both formats are always used now. So compiling your own build from the source or using this one should have fixed that problem.

[castor]

A little tip for anyone annoyed by the ship lab zoom over/undershoot (sort of)

In code/lab/lab.cpp, below line 715 (Lab_viewer_zoom += scale_y;), add the following

Code: [Select]

CLAMP(Lab_viewer_zoom, 0.08f/sip->closeup_zoom, 1.8f/sip->closeup_zoom);

[taylor]

A little tip for anyone annoyed by the ship lab zoom over/undershoot (sort of)

In code/lab/lab.cpp, below line 715 (Lab_viewer_zoom += scale_y;), add the following

Code: [Select]

CLAMP(Lab_viewer_zoom, 0.08f/sip->closeup_zoom, 1.8f/sip->closeup_zoom);

Uhh, no, you can't do that since it would crash when you are viewing weapons (as sip is NULL in that case).  Plus it makes the zoom behave in a non-uniform manner, which was avoided on purpose.