[taylor]

This just has various bug fixes compared to 2007-10-07, none of which are related to the normal map stuff (in case you were having problems before and think it might be fixed).

Windows build
Linux and OS X builds to follow tonight/tomorrow.

Normal map test pack (so there won't be any complaints about it not being here too )


Changes include:
 - minor performance boost for GLSL code path texture state handling (may be a little buggy, can't replicate)
 - (possibly) working docking/docked model animations
 - allow for model animations to work properly on indestructible subobjects
 - fixed afterburner trails not working the first time a mission is played
 - FRED hack/fix to allow it to run under Wine without requiring path hacks (for use under Linux)
 - bug fixes for beam section cleanup that would break when using +remove
 - fix for Mantis #1387 (add "2D Mission" checkbox to FRED mission specs window)
 - fix for Mantis #1473 (ship-subsys-guardian-threshold SEXP crash)
 - added KeldorKatarn's side-turret fix

[Snail]

Side turrets work now? Cool.

Umm..

[attachment deleted by ninja]

[taylor]

Umm..

Hehe, see, the GLSL "performance boost" is a little buggy. 

It did manage to work for me in testing, before I put out the build, but I'll rework that code quickly and re-upload the builds within the next hour.


EDIT:  Ok, build updated.  It should work like before now.

[Tolwyn]

Side turrets work now?

the feature is still in need of testing, but yes, side mounted turrets should work now.

[ARSPR]

Taylor, do you remember my post in 1007 build about pilot corruption (http://www.hard-light.net/forums/index.php/topic,49939.msg1010413.html#msg1010413)?

Here you have a related issue (I think): The first mission, a cutscene, causes external view (PAD *) not to work in that game run, and sometimes a pilot corruption:

• Use Blue Planet MOD.
• Create a new pilot.
• Although I suppose it doesn't matter, select "Don't show me hints again".
• Select Blue Planet campaign in Campaign room.
• Go to simulator>Campaign missions and use Ctrl-Shift-S to select the second one: "A blue planet ..." (BP-01-1.fs2).
• Start the mission and press "PAD *". You get the expected external view.
• Quit the mission. Go to mission simulator again and then start the first mission "Departure" (BP-00.fs2), or, if you prefer, just press Continue in mainhall to start the campaign normally.
• Press ESC to end the mission or wait till it finish (time compression is quite handy).
• If you start now the second mission, (just as campaign continuation, or from mission simulator), you can't get the external view. When you press "PAD *", you just get a ding sound.
  (Actually, You don't need to play the second mission before testing. If you just create a new pilot and start the campaign, you can check how external view doesn't work in the second mission).
• If you quit the game, restart it and restart the second mission, the external view works again.
• And if you start cycling through second mission > ESC > first mission > ESC > ... (again and again in simulator), sooner or later your pilot is corrupted. You can detect the pilot corruption because in the second mission you start flying in a GTF Hercules. But till now, I haven't found any EXACT replicable corruption trigger. I'll continue testing ...

[taylor]

I'm still looking into the pilot corruption issue, but I haven't been able to replicate it yet.  Going through the code I can't seem to find an issue either. If you can find another way to replicate it more easily/reliably then let me know and I'll take another look.

The Blue Planet mod appears to trigger several different bugs though, and I'm looking into that at the moment.  It's possible that the pilot corruption has nothing to do with the pilot file code itself, but instead happens because of some totally unrelated code bug that this mod just happens to trigger.  That also means that it could be build/platform specific, which makes it more difficult to track down.

[ARSPR]

I THINK I GOT IT:

(All missions played in simulator through Ctrl-Shift-S):

• Use Blue Planet mod.
• Create a new pilot.
• Select Blue Planet Campaign.
• Edited>>> Start the 1st mission "Departure" and press ESC to return to mainhall. (Only needed to cause the External view issue. For pilot data corruption you don't need this first run of the 1st mission).
• Start the 2nd mission "A blue planet ...". External view doesn't work if you played the 1st mission.
• Quit the mission and then QUIT THE GAME.
• Restart the game and select the same pilot.
• Start the 1st mission again and quit it.
• Then start the 2nd mission and the pilot is corrupted (you are in an Herc)

Confirm if you can replicate it or if you need me to perform more test runs. I'm going to test with official 3.6.9.

EDITED------- Tests with 3.6.9.:

• Pilot corruption also happens.
• But it doesn't have the external view issue. PAD * always work.

I'll try to pinpoint when PAD * issue appeared ASAP.


REEDITED ---------

External view not working after 1st mission appeared in XT0520. XT0510 works fine.

(Nevertheless XT0510 has the pilot corruption issue as expected).

[taylor]

Ok, I get the pilot corruption now.  I'll try and track it down later tonight.

[ARSPR]

I've perform another test:

• I've created a new pilot, then I've selected the campaign and I've started it.
• In this way I've passed the 1st mission and, in the 2nd one, I've pressed ESC to mainhall.
• I've exited the game and restarted it with the same pilot.
• I've gone to simulator where now I've got "Departure" as the only available mission. So there's no need to use Ctrl+Shift+S trick to play it. I've started and quitted it.
• Then I've continued the campaign, (so I start playing "A Blue planet..."), and the pilot becomes corrupted nevertheless.

So it seems the corruption has nothing to do with non-canon use of simulator through Ctrl+Shift+S trick. Without "cheats" you can also get it.

(I hope this can narrow your bug-hunting work a little  )


PS. Just to check you've read it as my last update in my previous post has been after your post: PAD * issue started in XT0520, XT0510 works fine.

[Snail]

Interesting bugs. Must say that it has to be a good job on testing.

[taylor]

So far I haven't found anything related to corruption, but there is definitely something wrong with it, behavior wise.  In my tests so far I can only get the ship to change when I run the 1st mission, then the 2nd.  If I don't bother loading the 1st mission then it doesn't mess up.  Following your procedure of 1st -> 2nd (no bug) -> exit -> 1st -> 2nd (bug), I can see see that the 1st mission does actually set the player ship to the Herc.  But in the "no bug" case, the ship gets reset in the 2nd mission, and in the "bug" case it doesn't.  So there appears to be some inconsistent behavior, but no actual file corruption (in the case specific to the ship getting set wrong anyway).  I'm trying to track down the difference between the two cases now so I can change it to work properly.


The external view problem was easy enough to solve though.  The first mission locks the perspective, and the code never resets that "locked" variable when you move to the next mission, which keeps the view controls disabled.  It looks like Goober fixed a bug in the sexp, which in turn make it work correctly, which in turn pointed out another bug in the code. But, it has officially been found and fixed now. 

[ARSPR]

So far I haven't found anything related to corruption, but there is definitely something wrong with it, behavior wise.  In my tests so far I can only get the ship to change when I run the 1st mission, then the 2nd.  If I don't bother loading the 1st mission then it doesn't mess up.  Following your procedure of 1st -> 2nd (no bug) -> exit -> 1st -> 2nd (bug), I can see see that the 1st mission does actually set the player ship to the Herc.  But in the "no bug" case, the ship gets reset in the 2nd mission, and in the "bug" case it doesn't.  So there appears to be some inconsistent behavior, but no actual file corruption (in the case specific to the ship getting set wrong anyway).  I'm trying to track down the difference between the two cases now so I can change it to work properly.

Taylor, take in mind that even the first 1st isn't needed. So it also happens with:  New pilot -> 2nd (no bug) -> exit -> 1st -> 2nd (bug).

And also returning to the origins. If you test with:  New pilot -> "Forced entry" mission -> Exit -> 1st -> "Forced entry", you get this wonderful ship loadout screen (which really seems a pilot corruption):

[attachment deleted by ninja]

[taylor]

There in indeed a bug in the loadout restore code, but I'm not quite sure what to do about it yet.  I'll test out some things, and if all goes will for me then I'll PM you a test build to double-check that the problem is fixed and that no new issues crop up.

The problem stems from a load order issue, where the loadout mission name (for which the current loadout data is valid) gets set to the current mission, but the loadout data itself is from the previous mission.  Due to this the code simply thinks that the loadout data is for the current mission, when it was actually for the previous mission instead.  I can't really fix the load order issue, so I have just made use of a previous hack to avoid a similar situation (technically the same situation, just for the loadout data itself).  I'm not sure if this fix is sound though, so it will need a bit of testing before I will commit the change.

I'll PM you with a test build link later tonight.

[Nuke]

im getting ready to uv map my vulture v3, at first i was planning to overlap of uv space. im intrested in what frame of reference the normals are relative to. the engine nacels oin this thing for example are all identical. if i make each one a subobject, with a different orientation, can i use the same normal map on each and have the lighting calculated correctly? another thing is this thing is gonna also be an animation whore. with each subobject moving independantly would the lighting be calculated properly for each. this is gonna be the first time i make a normal map for a complete ship. i just want to be sure i get the details right.



all the articles ive read say that i cant mirror the uv map, but is that entirely true?is theres ome 5up3r1337 way around that limitation, like if the normals in the map were relative to the surface normal. id post this in modding but i want taylors opinion on this as hes the one who knows the ins and  outs of his implementation of the normal mapping shader.

[taylor]

all the articles ive read say that i cant mirror the uv map, but is that entirely true?is theres ome 5up3r1337 way around that limitation, like if the normals in the map were relative to the surface normal. id post this in modding but i want taylors opinion on this as hes the one who knows the ins and  outs of his implementation of the normal mapping shader.

I want to say that it would work, but I can't say that for sure.  DaBrain and Bobboau know far better than me how all of that works, I just wrote the code.

I would say just try it and see what happens. 

[Nuke]

thats probibly whats gonna end up happining. wouldnt be the first time i redid a model from scratch

[ARSPR]

Taylor, look at your PM but it seems you fixed both bugs. 

OTOH, do you remember this small issue about the white loading bar?

Well, I haven't seen it any more. But sometimes, (in fact, it's pretty common), I get the loading screen and, inside the loading bar progress, you can see again the loading screen stretched down to fix inside that available area. It's much prettier than a fully white bar, but it's strange nevertheless 

Sorry but I cannot post any screenshot. "Print Screen" doesn't seem to work in that exact moment.

[taylor]

Yeah, I'm working on that loading bar issue right now.  I haven't figured out where it's coming from yet, but it does affect more than the loading bar.  It's definitely something screwy with the OpenGL texture code, I just need to figure out what.

[VulturEMaN]

ah it's good to see another forum moved to SMF ^.^

Just tried this build and I got the following on launch:

Error: The required OpenGL extension 'GL_ARB_multitexture' is not supported by your current driver version or graphics card.

File: gropenglextension.cpp
Line: 440


Call stack:
------------------------------------------------------------------
------------------------------------------------------------------

I'm running a 8600GTS and have the latest drivers, so I dono wtf is up lol.

[ARSPR]

Yeah, I'm working on that loading bar issue right now.  I haven't figured out where it's coming from yet, but it does affect more than the loading bar.  It's definitely something screwy with the OpenGL texture code, I just need to figure out what.

I suppose this also has to do with the same issue. Sometimes when I get the exit window I can see a huge cursor as background (it's even animated as Blue Planet mod one). I upload a screenshot. IIRC this doesn't happen with previous build.



[attachment deleted by ninja]