Can't enter in Sol/Sol system in 0.5

Find any bugs in Vega Strike? See if someone has already found it, or report them here!
Post Reply
rescbr
Star Pilot
Star Pilot
Posts: 4
Joined: Thu Apr 01, 2004 8:46 pm
Location: Sao Paulo/Brazil
Contact:

Can't enter in Sol/Sol system in 0.5

Post by rescbr »

When jumping to Sol/Sol from Sol/Alpha Canis Major, the game halted with an Application Error. Editing the savegame to go to Sol/Sol gives the same error. From stdout, it seems that VS can't found textures/sprites of some planets.
It's a 0.5 beta from here; i'm running Win 2003.

(forgot to save stderr/stdout of the "official way" to go to Sol/Sol (via Alpha Canis Major. These stderr/stdout are of the hackish way (savegame edition))

The interesting part from stdout:

Code: Select all

Unit file mercury not found
Unit file ven not found
Unit file phobos not found
Unit file asteroid not found
Unit file asteroid not found
Unit file asteroid not found
Unit file asteroid not found
Unit file jupiter_vgr not found
Unit file io not found
Unit file europa not found
Unit file callisto not found
Unit file saturn not found
You do not have the required permissions to view the files attached to this post.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

I see the line:
Avoided fatal error in deleting star system Sol/Sol


The code in question is this:

Code: Select all

	while (_Universe->getNumActiveStarSystem()) {
		if (_Universe->activeStarSystem()!=this) {
			activ.push_back(_Universe->activeStarSystem());
		}
		else {
			fprintf(stderr,"Avoided fatal error in deleting star system %s\n",getFileName().c_str());
		}
		_Universe->popActiveStarSystem();
	}
i.e. there is a stack of active star systems, and it tries to keep any of those star systems from being equal to the one that is being deleted.

Possibly this code is broken in a case where such a situation happens and later on it attempts to dereference the dead starsystem. I'm only speculating based on the message... I have never seen this myself.

Another plausable explanation is that you just ran out of memory by having loaded too many starsystems.
rescbr
Star Pilot
Star Pilot
Posts: 4
Joined: Thu Apr 01, 2004 8:46 pm
Location: Sao Paulo/Brazil
Contact:

Post by rescbr »

ace123 wrote:Another plausable explanation is that you just ran out of memory by having loaded too many starsystems.
I don't think so, i've loaded Sol/Ogawa to jump to Sol/Alpha Canis Major, then go to Sol/Sol. Even editing the savegame to start in Sol/Sol don't work.
Hmm... using ls -R and find on the Windows partition (now i'm in gentoo) i saw all files VS says it can't load (mercury, ven, etc) don't have a .system file, only textures.
(damn ntfs partition... only root can read it)

Code: Select all

aliatis data # ls -R | grep -i earth | grep .system
alienearth.system
sol_earth.system
earth.system
^ .system is found ^

Code: Select all

aliatis data # ls -R | grep -i jupiter | grep .system
aliatis data #

aliatis data # ls -R | grep -i jupiter
jupiter.png
jupiter_vgr2-Jonsson.jpg
^ Only textures found ^

edit: PS: it's possible to share the same data dir? i don't wanna to download the entire svn repository, only the source code.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

Even editing the savegame to start in Sol/Sol don't work.
What do you mean by that? Does the game crash if you put Sol/Sol there?

Actually you might be experiencing differences due to Line Feeds. I've seen that cause python errors, as well as other odd bugs when using a Windows data directory.

Windows stores new lines by using both "line feed" and a "carriage return" characters, but Unix operating systems only use "line feeds"

The thing is that Unix files will generally work on windows (except for windows text editors like Notepad and Wordpad which will corrupt those files).

So if you want to do this I recommend installing Cygwin on windows, and then using SVN from Cygwin to update, which will be compatible with SVN on Linux.

However, I'm not entirely sure about this. The safest thing is to use separate directories for both.

My fstab line for NTFS partitions is:
UUID=08C404A5C404975A /win ntfs-3g defaults,nls=utf8,umask=007,gid=46,noatime,nodiratime 0 0

The only thing I changed is the ntfs-3g.

The UUID part is some magic that the Ubuntu installer added. Basically it allows users in group 46, which for me is called "plugdev" to modify things.

If you are using a different distro you can replace gid=46 with uid=1000 to allow your primary user to use the ntfs mount.
rescbr
Star Pilot
Star Pilot
Posts: 4
Joined: Thu Apr 01, 2004 8:46 pm
Location: Sao Paulo/Brazil
Contact:

Post by rescbr »

ace123 wrote:
Even editing the savegame to start in Sol/Sol don't work.
What do you mean by that? Does the game crash if you put Sol/Sol there?
Yeah... the savegame starts with

Code: Select all

Sol/Sol^<money>
and still crash. Those stderr|out are from this savegame. I've uploaded it on rapidshare. http://rapidshare.com/files/62133708/savegame.bz2
(writing another system on savegame works, no crash. Jump to Sol/Sol, crash!)
Aeon

Post by Aeon »

I can confirm that the game crashes everytime I attempt to enter the Sol System, on an XP box. I wonder if the system just hasn't been fully written yet, and maybe the Sol System files from 0.4.3 could be copied over to 0.5.0 directory....
KhymMahn
Explorer
Explorer
Posts: 10
Joined: Sun Oct 14, 2007 10:15 am

Post by KhymMahn »

I also had problems once when 1st jumping to Sol system, the system would simply freeze. After a reboot, I could access the system normally. I play v0.5 on a Vista box.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

Sounds like it could just be running out of Memory. Maybe there are a lot more textures and things in Sol.
Aeon
Star Pilot
Star Pilot
Posts: 5
Joined: Thu Nov 08, 2007 1:50 am

Post by Aeon »

I figured it out. Many of the images used in the new Beta (.jpg, .png) are corrupted or compressed with an unknown algorithm. I downloaded the stable version of VS and replaced all of the files in beta/textures/sol and beta/textures/sol2 with their counterparts from the stable version. There were a few new files in the Beta, so I copied other images with the same format and dimensions, renamed them and replaced the corrupted files. In Windows, you can identify most of the corrupted images because they will fail to display thumbnails and won't open in any image editor that I know of. I edited the default save file to start in sol/sol, and it loaded right up! Even one corrupted image will prevent VS from loading and will crash the game. You can tell which file VS crashed on because it's the one that hangs while the game is loading, shown at the bottom left of the loading screen. There are also other corrupted images in other directories that need fixing.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

Yes, but that is exactly the problem.

Vega Strike has software methods to decompress those images on computers with old/broken drivers/hardware.

However, I suspect it doesn't recognize in this case that your graphics card is not able to read those compressed textures, so the graphics card interprets that data as garbage.
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Post by Neskiairti »

you know? i bet thats part of my problem.. why certain things arnt showing up!
Aeon
Star Pilot
Star Pilot
Posts: 5
Joined: Thu Nov 08, 2007 1:50 am

Post by Aeon »

The computer at my school uses an Intel 82945G graphic chipset on 2.8Ghz P4 w/ 1 Gb RAM. However, it shouldn't matter what kind of hardware I am using, Photoshop CS2 can open just about every single image format out there, and it won't open most of the images in the new VS Beta. I'd like to find out what program was used to compress the images in VS Beta.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

@Aeon Photoshop will open those file you needs the right plug-in the format is industry standard going back at least 10yrs and yes that GPU is crippled in the driver ATM.The program used to compress them came from Nvidia but was patched by safemode one of the devs this thread should give you the background http://vegastrike.sourceforge.net/forum ... php?t=9132 and some links

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Aeon
Star Pilot
Star Pilot
Posts: 5
Joined: Thu Nov 08, 2007 1:50 am

Issue Resolved!

Post by Aeon »

Thank you loki for your quick reply! I read the thread you suggested, and followed the links to Nvidia's developer tools, and installed the Photoshop plugin for DDS. I tried opening up beta\textures\sol\callista.png, but Photoshop thew up an error. However, when I renamed the file to calista.dds, Photoshop was able to open the file without errors. This got me thinking. I knew that the game crashed when loading densering.png from Sol/Sol, so I navigated to that directory, and sure enough, densering.png and earthspecular.png were the only two files in that folder that were not compressed with DDS. After opening them in Photoshop and saving them as densering.dds and earthspecular.dds, and then renaming them to densering.png and earthspecular after deleting the originals, I was able to load the Sol/Sol system without any errors. I noticed that about 95% of the images in VS Beta are compressed with DDS, and about 5% are not. If VS Beta crashes when trying to load an uncompressed PNG file, like in Sol/Sol, then perhaps it is unable to determine whether or not an image is compressed prior to loading it, and defaults to DDS compression, causing an exception when loading uncompressed images. Also, as an experiment, I found a non-compressed image that didn't crash the game, beta\sprites\mouse.bmp, saved it as mouse.dds in Photoshop, and renamed it back to mouse.bmp after deleting the original uncompressed version. I launched VS Beta, and the compressed version works fine, and there is a noticeable reduction in jerkiness when moving the mouse quickly across the menus. I made a list of all uncompressed images in VS Beta for the Dev Team and included it as an attachment.
You do not have the required permissions to view the files attached to this post.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

thx Aeon i think that will prove useful 8) lots of the GUI elements are not compressed because they cause a crash if they are damed if we do and if we don't :wink: it seems

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Aeon
Star Pilot
Star Pilot
Posts: 5
Joined: Thu Nov 08, 2007 1:50 am

Post by Aeon »

loki1950 wrote:lots of the GUI elements are not compressed because they cause a crash if they are
I tediously compressed all of the .png's and .jpg's (left the .bmp's the way they were) and I have been playing the game without a hiccup for several days now. Perhaps the crashing was due to another error....anyway I'm happy :D
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

PNG's (real png's) are not compressed not by accident, but on purpose. It is intended that anything graphic wise encoded to png is intended to be lossless, thus we dont compress it with dds. Not on the fs as a dds file and not in graphics memory.

It was also intended that there remain a uncompressed (as lossless as possible) archive mirroring the data directory of all the graphics. This should be useable to those few people who cant load DDS files, though it's purpose was to act as a master repository for editing graphics in the game.

We tried to catch all the png's and make sure they were all small, since they aren't compressed. If we missed much though, the uncompressed textures could easily use up all your graphics memory.

I'm gonna be getting back into some light work on VS this christmas vacation, next week or so. work has been unforgiving for my various hobbies. Cleaning up the graphics handling and such work that i started months ago is my main goal. Maybe do a bit of documenting
Nukl3ar
Explorer
Explorer
Posts: 13
Joined: Sat Dec 29, 2007 3:57 pm

Post by Nukl3ar »

Is there a current solution to this problem for those of us who don't use Photoshop? I'm having the problem of having saved a game in Sol/Sol - now it crashes when trying to load. I was hoping to base out of that sector/system so my 8 yr old could mess around and learn how our solar system is laid out. Thanks for any replies.
Str
Explorer
Explorer
Posts: 14
Joined: Mon Dec 24, 2007 6:19 pm

Post by Str »

i had the same problem, used the Windows Tool "DDS Converter" to transfer the two files "densering.png" and "earthspecular.png" to the *.dds format... i've zipped the two files, which are already renamed to .png files... see the attach.. just unzip it and copy the two files on their place in your data folder :) (data/textures/sol2)
You do not have the required permissions to view the files attached to this post.
Nukl3ar
Explorer
Explorer
Posts: 13
Joined: Sat Dec 29, 2007 3:57 pm

Post by Nukl3ar »

Thank You, Thank You, Thank You!!!! I have GIMP here but wasnt sure if it would work to fix the files. Thanks Again. :lol:
Post Reply