.spr and mods bug

posted on June 16th, 2011, 10:39 pm

Hi there seams to be a bug in .spr files that if you try and use @include and link it to itself then it crashes with no error log (eg @include sprites.spr in sprites.spr)

[Tyler]

posted on June 16th, 2011, 10:48 pm

Last edited by Tyler on June 16th, 2011, 10:58 pm, edited 1 time in total.

That command doesn't work in a few. I don't get a crash using it in sprites though, just no icons.

[Anonymous]

posted on June 16th, 2011, 11:22 pm

Last edited by Anonymous on June 17th, 2011, 9:35 am, edited 1 time in total.

I've reported that bug several times with no response.  It makes me mad that some bug reports aren't at least looked into with an acknowledgement.  Here are 4 instances where I reported the same bug with absolutely no response.  The first two were in the bug thread.  And I've posted in other threads about the same bug.  Absolutely none of which got any responses:

---

Mod sprite files have several bugs when they are based on a parent mod.  This causes game crashes.

• They cannot use the @include command to reference a parent file.
• They cannot be copied into the modification directory.

Hey, what about the sprites not being able to be linked up with parent sprites?  It's not good that you have to copy 4 entire sprite files just to modify one sprite.

Well, this mod just hit a wall!  It turns out that the sprite files don't aren't loaded properly when using the @include command to the parent sprite file.  I'm sure that this code is correct.

Code: Select all

sprite_table

@include gui_global.spr

@skip=off

@reference=512
@tmaterial=interface
b_fed_shieldresetC   all_interface_buttons06   0   104   96   96      #   1   2

This mod won't go anywhere if the sprite files don't load properly.

Well, after looking over how the Regent Class mod worked, I was able to get the Buildable Warp-Ins mod working again.  Well, the bug with the @include command not working when linking to a parent file with the same name absolutely must be fixed.

I have made two screenshots of the Descent Class starship.  One has been warped in, the other has been built.  The one that has been built requires research at Starfleet Science.  The one that was warped in does not require any research.

posted on June 16th, 2011, 11:24 pm

People probably don't awnser because it's already a known problem...

posted on June 16th, 2011, 11:59 pm

Why shout at the Devs TCR? I'm sure they are probably already aware of that and they don't respond to every bug personally.

posted on June 17th, 2011, 12:39 am

But to not get it added to the bug table in the bug thread.  That's what I'm really mad at.  I don't care if it's never in the form of a reply as long as it's added to the bug list!

posted on June 17th, 2011, 12:53 am

DEVS, PAY ATTENTION TO THE BUG REPORTS!!!

Was that really necessary? Have you forgotten that FO is a free mod and that the devs don't get paid for their work?

Considering the tone of many of your posts you're lucky that the devs are nice guys, there's quite a few game forums where you would have been banned a long time ago.

posted on June 17th, 2011, 8:31 am

yes, this is known and scheduled to be fixed before release of the next patch. thanks everyone for reporting

posted on June 17th, 2011, 9:35 am

Was that really necessary?

Probably not.  But it does seem like some bug reports get unnoticed, which is a bit aggravating.  I'll remove that part of the post.

[Anonymous]

posted on June 17th, 2011, 10:01 am

Last edited by Anonymous on June 17th, 2011, 10:04 am, edited 1 time in total.

But to not get it added to the bug table in the bug thread.  That's what I'm really mad at.  I don't care if it's never in the form of a reply as long as it's added to the bug list!

firstly i find it odd that this bothers u so much.

secondly ive seen your posts there, im not a modder, so i dont understand and cant test these. it would be helpful if some people could just quote your bug and say "i have it too" that way i can be sure its not system specific and add it.

like right now im gonna try make sense of your first post and find a description for the bug.

so far it looks like:

1) sprites files cant use @include to link to a file of the same name
2) no file can use @include to link to a file of the same name

obviously the first is just part of the second, i just dont know which is true.

there is also

3) sprites files cant use @include at all

i dont understand what most of this means, so i need people to tell me which is the correct numbers.

posted on June 17th, 2011, 10:14 am

Sprite files in the mods directory can't be linked to a parent file.  You have to copy the entire file over to the mod directory just to add a few sprites.  The @include command does work, just not when linking to a parent file with the same name.

posted on June 17th, 2011, 10:16 am

Sprite files in the mods directory can't be linked to a parent file.  You have to copy the entire file over to the mod directory just to add a few sprites.  The @include command does work, just not when linking to a parent file with the same name.

im still confused, which numbers are true?

posted on June 17th, 2011, 10:21 am

Hi there seams to be a bug in .spr files that if you try and use @include and link it to itself then it crashes with no error log (eg @include sprites.spr in sprites.spr)

i am aware only of the non working @include command blade posted in the first post of this thread. as far as i know there are no other problems with the sprite files.

posted on June 17th, 2011, 10:50 am

so thats 1, ill add that as fixed then. thanks

[Atlantis]

posted on June 25th, 2011, 12:06 pm

Last edited by Atlantis on June 25th, 2011, 12:09 pm, edited 1 time in total.

Just to note a couple of things here.

@include does work in sprites, but you can't self-include like you can (now) with odfs. Sprites.spr is an index file, with @includes to all the other '.spr's.

So there is an easy way to put in your own sprites with only a minuscule chance of incompatibility with future FlOps versions, in that you just change the stock FO sprites.spr, and make a new sprite file (my install has atlantis.spr, for example), and just @include it in the sprites.spr file. Sprites.spr hardly ever (if ever) changes, so no errors when new versions are released. Plus, all your sprites are together in one place, separate from everything else.

Once self-include is put in for sprites, it won't be necessary any more, but it will still be a tidy way of doing it.