graphic changes 0.5 -> svn?

[dagg]

not quite a vs bug, but more of a mod bug, I'm testing vs from the svn on the vegatrek mod, now for some reason, instead of space graphics I see white exterior, I've wanted to know if there was a change in something related into space graphics in the svn?

[ace123]

If you are referring to a background, yes, I do recall a backwards-incompatible change with backgrounds.

I don't remember why this happened but it was something to do with cubemaps. I'll see if I can figure out the solution. Would be nice to make sure it can remain backwards compatible--just like how Debian/Ubuntu shipped the 0.4.3 data with the 0.5 binary and everything still worked.

[dagg]

ok, I'll wait

[ace123]

Could you paste a system file with that shows up with the white texture?

And also I would be interested in the image files you are using for the background? Can you point me to a subversion folder with them? If not, what file format are they? What are they named?

[dagg]

origin system is sol, here is the link to the svn: https://svn.wcjunction.com/vegatrek/tru ... Sol.system
user name is username password is password.
the background is black, I guess that it is this: https://svn.wcjunction.com/vegatrek/tru ... /black.png because there is not black file under https://svn.wcjunction.com/vegatrek/tru ... background.
I have no similar issue when running the game on the vs data

[ace123]

Thanks for linking me to the broken system file.

It would appear that a few places in the code where ".bmp" was previously hardcoded, it had changed to ".image". I didn't want to break the code too much, but in all three places I added a check first for the .image file and then for the .bmp file. This should be committed in revision 12548.

It's not just vega trek--a lot of mods had this problem and I believe that this is the only thing keeping the engine from remaining backwards-compatible it is worth fixing.

And apparently the mass rename was the same reason that the quit dialog was not showing up--so I guess I caught two bugs with one flyswatter, so to speak

Hopefully you don't run into any more problems (I'm still stumped about the boost issue--have you managed to get it compiling with the included version for now?)

[dagg]

thanks for addressing the issue, what format are the .image files? I guess they are a known format but with a name change, I've tried to id the format but for no avail.

on the other subject, the game compiles fine with the boost included.

[dagg]

white space bug is out, new bugs is in, first, there is no cross-hair for the destination system (e.g. no relative direction of GetNavSelectedSystem()), after I reach the max distance from the config file where I should get to the destination system, the info screens fliker, I hear a hit sound and I don't get to the system.
maybe this will help, output shows this line alot:

Code: Select all

Unit is the active player character...changing scene graph

[ace123]

The reason for the change is that VS doesn't care what extensions the filenames have. The backgrounds used to be called ".bmp" but last I checked I think the engine doesn't even support BMP files anymore--they are now mostly all DDS or PNG.

So now everything is called .image no matter what format it really has--and any good graphics program can figure out what format the files are supposed to have.

I thought the point is that the relative direction doesn't matter. You just warp in any direction.

But I think there is a config option to turn on the crosshair. I think it was turned off because it was too confusing.

[dagg]

right but still we would like to point the ship into the right direction then warp, it is kinda stupid to point the ship into the sun, engage the drive crash into the sun and the end up in another system...
I using the same config file which I've used for vs-0.5.0 and had a cross-hair for that.
still ignoring this don't fix the issue of the bug I've found, if you want, I can screen capture it in a movie and post the link.

[dagg]

ok, did more research, the flickering bug occurs only if you select a destination from the shift+m window that is opened by default when you start the game, if I close and open it, no flickering occurs. is there a way to prevent the window to open at start?
now the missing cross-hair is not the default, it is the selected target, I cannot see it for in system target to, what makes me believe it is connected to the bug you've fixed, maybe the image isn't being recognized.

[loki1950]

is there a way to prevent the window to open at start?

That is also a config file toggle
As for the image not showing how have you defined the path to it look for the simple things first it's amazing how often it happens Lo these many years of bug hunting as i wrote my first code long ago

Enjoy the Choice

[dagg]

is there a way to prevent the window to open at start?

That is also a config file toggle
As for the image not showing how have you defined the path to it look for the simple things first it's amazing how often it happens Lo these many years of bug hunting as i wrote my first code long ago

Enjoy the Choice

well because I have no ability to upload changes nor do I have the time, I leave it to the devs.
I have not defined anything, let me ask this, does the config file from the svn is different from the config file in 0.5.0?

[loki1950]

There have been some variables added and a few toggles as well check the commit logs for specifics it's there do a history of the file in the repo svn is a data base use it

Enjoy the Choice

[dagg]

looked but not found anything

[ace123]

I found where it is displayed: gfx/nav/navscreen.cpp line 160.

The variable is "times_to_show_help_screen" in section general. It defaults to 3, so you want to set it to 0 to turn off the help screen, since . It is likely that it has simply not been set so you might have to add that one yourself.

[dagg]

thanks.

[dagg]

any hints why the selected target cross-hair is not visible? I think it is visible in vs thought, is it a image file?

[dagg]

ok, changed the config intro, no good, no sun is visible.

[ace123]

The variable for the navigation crosshairs (target system) is:
<section name="graphics">
<section name="hud">
...
<var name="drawNavSymbol" value="true">
...
</section>
...
</section>

The crosshair is drawn using lines in OpenGL--no textures.

ok, changed the config intro, no good, no sun is visible.

Sorry, but I don't quite understand what you are talking about here. Do you mean the picture of the sun inside of your targetting computer? Because that is related to the same problem as the white backgrounds so it should have been fixed.

[dagg]

nope, there is the nav pad screen that is showed by default when you enter the game for the first time, I want to disable it, now using the method loki suggested done it but there was no visual sign of the sun.

[ace123]

I'm still confused, sorry. Those problems seem to me to be completely unrelated.

Setting the varible I suggested (times_to_show_help_screen inside of "general") to 0 should have gotten rid of the nav screen on startup. But it should not affect anything else at all.

Still don't understand what you mean by "there was no visual sign of the sun." Does it not appear at all? Can you target it? Does the HUD image show up? Can you hit "8" to get view the camera pointing at it?

[dagg]

ok, tried the drawNavSymbol suggestion, no go, still no symbol.

now this is strange, the help screen thing suddenly works... not clue why

[ace123]

I have a suspicion that the reason things weren't working is because you may have had a typo which led to a XML parsing error, and then most of the options wouldn't be loaded.

Did you add the variable
<var name="drawNavSymbol" value="true">
inside of the <section name="hud">?
(Also, check if that variable is already there--I remember it used to have a different default a few years ago).

[dagg]

Code: Select all

                  
                        <section name="hud" >
                                <var name="PadlockViewLag" value="0" />
                                <var name="draw_weapon_sprite" value="false" />
                                <var name="DrawTargettingBoxes" value="true" />
                                <var name="drawNavSymbol" value="true" />
                                <var name="min_target_box_size" value=".01" />
                                <var name="DrawTheirRelationColor" value="true" />
                                <var name="drawAllTargetBoxes" value="false" />
                                <var name="drawAlwaysITTS" value="false" />
                                <var name="radarType" value="WC" />
                                .
                                .
                                .
                        </section>

it is set. about the help screen, probably was a typo