no nav ights on llama
-
- Bounty Hunter
- Posts: 182
- Joined: Sat Jul 21, 2007 5:14 am
- Location: Western MA
no nav ights on llama
just small white squared these used to blink i think
Machine: P4 prescott 3.2 Ghz, 2Gb ddr ram, 2 80g seagate sata drives in raiad stripe config nvidia 6600 gt oc card sidwinder pro FF2
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
-
- Expert Mercenary
- Posts: 988
- Joined: Thu Jun 15, 2006 1:02 am
- Location: Somewhere in the vastness of space
- Contact:
Haven't touched the largest part of animations yet except splash screens and sun flares. Blinking lights should be working as before. If not, there might be some data corruption from your side. You can scan your stderr for any "file not found" messages. Post here if you find anything.
EDIT:
Booh. After recompiling the latest svn I can reproduce the error of blinking lights showing as white rectangles (means texture not found), so I can only assume that it comes from the latest code changes after SVN revision 12323. It might be safemode's vsconfig includes or ace123's faction relations. The problem points to animations that are related to unit meshes but remains to be analyzed.
EDIT:
Booh. After recompiling the latest svn I can reproduce the error of blinking lights showing as white rectangles (means texture not found), so I can only assume that it comes from the latest code changes after SVN revision 12323. It might be safemode's vsconfig includes or ace123's faction relations. The problem points to animations that are related to unit meshes but remains to be analyzed.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Apparently we still have some extremely small images as dds files in data.
all the black.png files in the animations dirs needs to be png.
But that's not the couse of the issue. Something wasn't changed in the name changing or something got clobbered in the code looking for the new names because none of the ship animations are finding their textures. this is what you get when you dont have a texture, white block.
all the black.png files in the animations dirs needs to be png.
But that's not the couse of the issue. Something wasn't changed in the name changing or something got clobbered in the code looking for the new names because none of the ship animations are finding their textures. this is what you get when you dont have a texture, white block.
Ed Sweetman endorses this message.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
This has probably been occuring for a while now. It's probably related to my "relative retrieval" updates so that we search our available root paths looking for the file with the relative path to /data ...rather than absolute paths to where we find the .ani
The issue is in animations, we include the texture inside the dir we find the .ani. For some reason, flare's dont work this way. perhaps i need to add a check and if the file isn't in the current dir path, to try /textures/filename
i should have a fix tonight, if this is the cause.
Edit:
Stupid one line fix. Can't believe nobody noticed the bug until now. No idea how i missed it.
In any case, still strange about how flare's aren't in their directory, guess they're cross-referenced.
Also, if you have an nvidia card, use the latest drivers 173.14.05...for linux anyway. Game looks quite nice with correctly behaving atmo now and blinkin lights and what not
The issue is in animations, we include the texture inside the dir we find the .ani. For some reason, flare's dont work this way. perhaps i need to add a check and if the file isn't in the current dir path, to try /textures/filename
i should have a fix tonight, if this is the cause.
Edit:
Stupid one line fix. Can't believe nobody noticed the bug until now. No idea how i missed it.
In any case, still strange about how flare's aren't in their directory, guess they're cross-referenced.
Also, if you have an nvidia card, use the latest drivers 173.14.05...for linux anyway. Game looks quite nice with correctly behaving atmo now and blinkin lights and what not
Ed Sweetman endorses this message.
-
- Explorer
- Posts: 9
- Joined: Mon Jun 09, 2008 6:11 pm
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
new bins haven't been built against the fix in svn, which is already there. 1 liner. You can't fix it by shuffling the data dir around in the mean time. The names of those particular files are really messed up, and they depend on the last special file loaded (unit, sprite,animation). It's not the actual filename that is mangled, but the path to it.
In VS we have some special files that are basically scripts with lists of textures in them. We treat these files special since they are listed without a path, we assume they are loaded relatively to the special file we loaded. Now what we do is save the path to that special script to a variable, and then subsequent textures are loaded using that path. Now, what was happening was the previous path to the last special file loaded was being used as the path to textures currently being loaded because the extra variable was being assigned part of the path that it shouldn't have been and it was being done at the wrong time. Big no no. So we get a new filename each time we get a unit that references these lights because it's using a different path each time to reference it. Even if you fixed up /data to work with the first instance (llama), it'll be broken when another unit references those textures. you'd have to "fix" it for each unit, and it would be totally dependent on the order in which the units are loaded
The best you can do right now is hope for someone in win32 land to build you a new bin soon
In VS we have some special files that are basically scripts with lists of textures in them. We treat these files special since they are listed without a path, we assume they are loaded relatively to the special file we loaded. Now what we do is save the path to that special script to a variable, and then subsequent textures are loaded using that path. Now, what was happening was the previous path to the last special file loaded was being used as the path to textures currently being loaded because the extra variable was being assigned part of the path that it shouldn't have been and it was being done at the wrong time. Big no no. So we get a new filename each time we get a unit that references these lights because it's using a different path each time to reference it. Even if you fixed up /data to work with the first instance (llama), it'll be broken when another unit references those textures. you'd have to "fix" it for each unit, and it would be totally dependent on the order in which the units are loaded
The best you can do right now is hope for someone in win32 land to build you a new bin soon
Ed Sweetman endorses this message.
-
- Explorer
- Posts: 9
- Joined: Mon Jun 09, 2008 6:11 pm
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
there's nothing to checking out the "binary" repo in svn. you svn co win32 then run vs without moving anything.
If you want to build svn and then use it with your svn pull of the win32 repo (which has /data), then just copy your build directory to win32/build it'll work just like if it was in /bin plus when you svn update, it wont conflict with anything.
this is assuming in VC++ you build to a new directory, not build inside the source tree. Oh, and you'll want to copy over the same libs in /bin, only using the ones you built VS with, over to your new win32/build directory.
If you want to build svn and then use it with your svn pull of the win32 repo (which has /data), then just copy your build directory to win32/build it'll work just like if it was in /bin plus when you svn update, it wont conflict with anything.
this is assuming in VC++ you build to a new directory, not build inside the source tree. Oh, and you'll want to copy over the same libs in /bin, only using the ones you built VS with, over to your new win32/build directory.
Ed Sweetman endorses this message.
-
- Explorer
- Posts: 9
- Joined: Mon Jun 09, 2008 6:11 pm
I build a new exe (attached) and it works (I forgot how long building a large C++ project takes...), I only forgot to include the icon. But building vssetup (probably not needed) and vsserver generates a few errors.
I first installed the 0.5.0 setup, and tried to update that with TortoiseSVN, which only downloaded the bin directory after I deleted that. And when I tried to add the data repro, it deleted the bin directory.
I first installed the 0.5.0 setup, and tried to update that with TortoiseSVN, which only downloaded the bin directory after I deleted that. And when I tried to add the data repro, it deleted the bin directory.
You do not have the required permissions to view the files attached to this post.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
You can't use the pkg and svn update it. svn doesn't work that way.
you have to start out with an svn pull of win32, then you can update that and be kept up to date with /data and builds of win32 bins as we make them. If you're gonna build your own, you'd svn co the vegastrike repo (like maybe you did), and build vegastrike in an external directory. Then stick it and all the libs it needs into a directory in your win32 repo. SVN wont bother that directory, and you can use it to test your builds against the/data dir that comes with the win32 repo.
you have to start out with an svn pull of win32, then you can update that and be kept up to date with /data and builds of win32 bins as we make them. If you're gonna build your own, you'd svn co the vegastrike repo (like maybe you did), and build vegastrike in an external directory. Then stick it and all the libs it needs into a directory in your win32 repo. SVN wont bother that directory, and you can use it to test your builds against the/data dir that comes with the win32 repo.
Ed Sweetman endorses this message.
-
- Explorer
- Posts: 9
- Joined: Mon Jun 09, 2008 6:11 pm
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
-
- Explorer
- Posts: 9
- Joined: Mon Jun 09, 2008 6:11 pm
Ah, sorry.
It is just, that this version includes the shaders and tutorial, and that it looks like the missions are adjusted as well. The visible difference is quite big. It feels like a quite different version.
Btw, the autopilot and docking broke during my last mission, but that could be because I had caps-lock on, or I didn't include the right libraries.
It is just, that this version includes the shaders and tutorial, and that it looks like the missions are adjusted as well. The visible difference is quite big. It feels like a quite different version.
Btw, the autopilot and docking broke during my last mission, but that could be because I had caps-lock on, or I didn't include the right libraries.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact: