• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

Fixed System.log: "Can't load texture resource\textures\.tx"

I think the first three instances at least

Inside_Shipyard1.tga.tx *.tga.txdirRESOURCE\Textures\Loading\
Inside_Shipyard1.tga.tx *.tga.txdirRESOURCE\Textures\Loading\English\

locations_locators.c *_locators.cdirPROGRAM\Locations\

the file locations are different in build 14 to build 13

- however engine.ini does refer to the directories involved (so it's not obviously like the European fonts not found example where the wrong info was in engine.ini) - I wonder if there is hard coding (in a dll for example) that is causing the engine to complain despite the game coping (and presumably finding) the re-located textures required at reload.

[[I think I'll try putting copies of this example into the original build 13 locations, redo the same reload and see if the error reports go away - to at least see if it is the changed location (or not)]]

EDIT - sorry forget most of the above - I couldn't see the files in 13 but it's not the location of the files in the first two, but the naming convention that changed to add Inside or Outside as a prefix. So it needs a bit more study of how the change is enacted to see if that gives the right clues. More anon ENDEDIT
 
Last edited:
pedrwyth said:
EDIT - sorry forget most of the above - I couldn't see the files in 13 but it's not the location of the files in the first two, but the naming convention that changed to add Inside or Outside as a prefix. So it needs a bit more study of how the change is enacted to see if that gives the right clues. More anon ENDEDIT
Click to expand...
That loading screen naming convention was changed well after that Build 14 Alpha 8 version from 2008.
 
Pieter Boelen said:
That loading screen naming convention was changed well after that Build 14 Alpha 8 version from 2008.
Click to expand...

OK not that then - when was the practice of putting "Loading\" + LanguageGetLanguage() +"\texturefilename in the entry for the locations.image attribute simplified - at the same time??

One difference could be old style
dirName = resources\texture
image filename = Loading\ENGLISH\textureName

new style
dirName = resources\texture\loading\ENGLISH
image filename = textureName

which if there is reference to the old system remaining somewhere could be looking in the resources\texture directory (being reported as not having the file).

Anyway I'll just follow my train of thought up a blind alley - as I said it might be purely coincidence that there are four calls in the function I happened to pick and thus the four examples I am looking at have no bearing on the problem at all.
 
Last edited:
pedrwyth said:
OK not that then - when was the practice of putting "Loading\" + LanguageGetLanguage() +"\texturefilename in the entry for the locations.image attribute simplified - at the same time??
Click to expand...
I think that was indeed done much earlier.
@konradk did some huge changes between Build 13 and Build 14 Alpha 8, such as the whole Select Storylines and Profiles features.
If I recall, I was at sea at the time and only got those files much, much later.
 
@pedrwyth: I foresee that this one may be a bit more time-consuming to look into than I can afford right now.
But I DO have a Build 14 Alpha 9 installer of some kind, which I could upload.
Would you see a chance to compare Build 13 with Build 14 Alpha 9 to see if you can find what triggered this?
 
Pieter Boelen said:
@pedrwyth: I foresee that this one may be a bit more time-consuming to look into than I can afford right now.
But I DO have a Build 14 Alpha 9 installer of some kind, which I could upload.
Would you see a chance to compare Build 13 with Build 14 Alpha 9 to see if you can find what triggered this?
Click to expand...

Yes that might help obviously the nearer I can get back to build13 the less other changes would get in the way (and avoid me looking at things which changed AFTER that). At least I should be able to rule out a few things that haven't caused it - which also could help in the long run.

Anything else (apart from the profile load/save interface inconsistency stuff I have also been looking at - without much inspiration as yet) is in too much flux for me to bother with for now anyway which is why I am chasing these shadows. Once there is a public release of build 14 then there should be a stable platform (with development proceeding elsewhere) that might give some opportunities to refine problem stuff.
 
pedrwyth said:
Once there is a public release of build 14 then there should be a stable platform (with development proceeding elsewhere) that might give some opportunities to refine problem stuff.
Click to expand...
I am SO looking forward to at least a stable Beta 4!!! :shock

Anyway; Alpha 9 uploading now.

EDIT: Trying to, anyway! :whipa
 
I couldn't get the Alpha 9 to load - the opening menu was there but went to a blank screen after - but hardly felt it was worth chasing after problems with an old version. I do have the files for comparison now of course and suspect it may be to do with the change in how files and directories were structured and called - but I wouldn't say I was currently looking at it with any seriousness
 
hmmmm just a thought.
Maybe the find file Returns a Folder Name sometimes because there are files which are named the same as a Folder in that Folder?
 
That would have to be always and not just sometimes then. But maybe.... :rolleyes:
 
Just an update on this - Looking at build 14 alpha 8 - no joy BUT I note the latest version (build 14 4 6 Feb) is now only giving 3 of these errors on each reload for me :). What has changed (and when) I wonder? Perhaps they'll all fix themselves magically if we wait long enough:D.
 
pedrwyth said:
Just an update on this - Looking at build 14 alpha 8 - no joy BUT I note the latest version (build 14 4 6 Feb) is now only giving 3 of these errors on each reload for me :). What has changed (and when) I wonder? Perhaps they'll all fix themselves magically if we wait long enough:D.
Click to expand...
:rofl

What is the last version where you remember there were four?
I cannot think of anything that changed that should have any effect on this one way or another. :confused:
 
Pieter Boelen said:
I cannot think of anything that changed that should have any effect on this one way or another.
Click to expand...
Yup Thought that would be the case, certainly couldn't see anything in the change log that stood out
What is the last version where you remember there were four?.
Click to expand...

Again sods law - it was pretty much immediately I stopped looking at it. That was the last discussion in early December which was based on 29th November version. I tried 10th January and it was 3 by then, 22nd December still has 4 - So between 22/12 and 10/1 - I have tried the two zips I have in this period and still 4 there after the 5th of January I guess then it's a winmerge of the two to see what (if anything) emerges as a possible candidate. Of course no guarantees that even then it would be relevant to the three remaining. EDIT there is one additional texture in RESOURCE/textures between the two versions(musket.tag.tx) but it isn't as simple as just adding that file into the earlier version (or taking it out of the later one). Still looking ENDEDIT

On another topic thanks for tidying the code I posted on shipyard stuff. It seems like you almost might as well just do the changes yourself at that rate!! ;)
 
Last edited:
You doing it definitely saved me the trouble of thinking about it.
Brainless merging is much easier. So thanks once again for your help. :cheers
 
It seems to me that default PotC (no Build mod added) would give these types of texture errors in it's error log.
 
This... has been bugging me for yonks. :bonaparte

It looks like bad ship data or something like that. Maybe this...
Code: 
[Ships\Ships.c]

string GetShipDecksTexture(ref chref, string deck)
{
   if (!CheckAttribute(chref, "ship")) return "";
   int st = GetCharacterShipType(chref);
   if (st == SHIP_NOTUSED) return "";
   aref ship; makearef(ship, chref.ship);
   string path = "";
   if (deck != "" && CheckShipAttribute(ship, &ShipsTypes[st], "DeckTexturesDir." + deck)) {
     path = "Locations\decks\" + GetLocalShipAttrib(ship, &ShipsTypes[st], "DeckTexturesDir." + deck);
     //if (CheckDirectory("RESOURCE\Textures\" + path, "*") == 0) path = ""; // [MYEDIT]
   } else {
     if (CheckShipAttribute(ship, &ShipsTypes[st], "DeckTexturesDir")) {
       path = "Locations\decks\" + GetLocalShipAttrib(ship, &ShipsTypes[st], "DeckTexturesDir");
       //if (CheckDirectory("RESOURCE\Textures\" + path, "*") == 0) path = ""; // [MYEDIT]
     }
   }
   return path;
}
Note the commented parts - I haven’t seen head of tail or the error since I did that.

:walkplank
And what is “Unable to open resource\sounds\#loading_knippels“all about? The code looks fine. :shrug
 
Last edited:
You must log in or register to reply here.
Back
Top