Page 31 of 54

Re: Split: Re-scaling experiment

Posted: Wed Mar 29, 2017 7:55 pm
by pleiadian
Diziet Sma wrote: Tue Mar 28, 2017 8:19 am
V3.02 Win64 build, with Ship Library fix applied, bundled with the Rescale OXP, download link:

https://www.dropbox.com/s/teo9ia9phdesh ... 2.zip?dl=0
For some reason this build is not respecting Griff's shader ships. Everything else is working, as it seems.

Re: Split: Re-scaling experiment

Posted: Wed Mar 29, 2017 8:03 pm
by another_commander
Any non-core ship should appear off-scale with this build, unless like-shipped to one of the core ones. I would recommend testing on a completely clean installation.

Re: Split: Re-scaling experiment

Posted: Wed Mar 29, 2017 8:11 pm
by pleiadian
That's not what I meant... I meant the textures and shaders are not shown and/or respected.

Re: Split: Re-scaling experiment

Posted: Wed Mar 29, 2017 8:43 pm
by Redspear
pleiadian wrote:
That's not what I meant... I meant the textures and shaders are not shown and/or respected.
That's weird, it shouldn't do anything to them...

Can you please confirm if it also happens to entites that have not been rescaled e.g. stations, pythons, transporters, anacondas?

Re: Split: Re-scaling experiment

Posted: Wed Mar 29, 2017 9:42 pm
by Diziet Sma
pleiadian wrote: Wed Mar 29, 2017 7:55 pm
Diziet Sma wrote: Tue Mar 28, 2017 8:19 am
V3.02 Win64 build, with Ship Library fix applied, bundled with the Rescale OXP, download link:

https://www.dropbox.com/s/teo9ia9phdesh ... 2.zip?dl=0
For some reason this build is not respecting Griff's shader ships. Everything else is working, as it seems.

Hmm.. that's odd.. they're working on my installation.
another_commander wrote: Wed Mar 29, 2017 8:03 pm
Any non-core ship should appear off-scale with this build, unless like-shipped to one of the core ones. I would recommend testing on a completely clean installation.

Griff's shader versions, (with a few exceptions) are all like_shipped to the core ships. I haven't had any problems with them.

I'll take a look at the issue first chance I get, but here downunder, my work day is just starting, so it will have to wait until this evening my time (GMT +10).

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 8:06 am
by pleiadian
Redspear wrote: Wed Mar 29, 2017 8:43 pm
pleiadian wrote:
That's not what I meant... I meant the textures and shaders are not shown and/or respected.
That's weird, it shouldn't do anything to them...

Can you please confirm if it also happens to entites that have not been rescaled e.g. stations, pythons, transporters, anacondas?
This appears to be the case, yes. Not sure how to fix.

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 8:18 am
by Getafix
Astrobe wrote:
Astrobe wrote: Wed Mar 29, 2017 5:09 pm
Lol, I have four slightly different copies of Oolite now...
another_commander wrote:
another_commander wrote: Wed Mar 29, 2017 5:38 pm
Welcome to the club. :-)
Image
...
...multiply this by 10 O/S variations! :x (9 VMs and one native SLAX on a usb stick)
Image
Apologies for for the off-topic, but I couldn't resist nagging again! :P

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 11:11 am
by Cody
<chortles>

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 3:03 pm
by Redspear
pleiadian wrote: Thu Mar 30, 2017 8:06 am
This appears to be the case, yes. Not sure how to fix.
Another question: are you using the (outdated but functional) rescaling oxp or the shipdata changes implemented in the core (as a_c adjusted them)?

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 6:27 pm
by pleiadian
I pulled the current 1.85 code from GutHub, and compiled. I replaced the .exe (which had a siye of 25 Megs) with the one provided here (5 Megs), and installed the OXP bundled in the same download. I end up only being able to use vanilla textures.

I will pull the code again, but do all the changes myself including shipdata.plist, the other changes mentioned here, and then try it again. Maybe that helps.

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 6:57 pm
by another_commander
Haven't tested or tried to reproduce it, but to me it looks like the rescaling experiment OXP's shipdata may be overriding the Griff's ships' one. This should not be a problem if you incorporate the rescaling experiment's changed plists inside the Resources folder.

Edit: As for the 25 vs 5MB, the one you generated contained also the debug information, while the one distributed had it stripped. It's still basically the same executable.

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 8:05 pm
by pleiadian
I also would like to mention that I am unable to pull code from this repo in its entirety:

https://github.com/Garryck/oolite-rescaling-experiment

I can do the initial clone, however when I am attempting to pull the submodules, I am asked for username and password, which always fails.

Seems as if I have no choice but pull the normal 1.85 code, and do the changes (described earlier) myself. I then have a clean rescale branch to test with.

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 8:35 pm
by another_commander
Before you go into all this trouble, maybe you can try one thing: From Dizzy's package, take the plists and scripts and drop them in their corresponding locations in Resources, then remove the rescaling OXP. See if this makes Griff's ships work.

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 9:12 pm
by phkb
pleiadian wrote:
I can do the initial clone, however when I am attempting to pull the submodules, I am asked for username and password, which always fails.
I'm getting this same issue. My solution was to copy the missing submodules from my 1.85 source to the appropriate spots in the rescaling tree. That enabled me to compile.

Re: Split: Re-scaling experiment

Posted: Thu Mar 30, 2017 9:15 pm
by another_commander
Re submodules: The solution is inside the Readme.md file, right at the bottom:
If you've cloned the source from a forked repository instead, this may not work - due to relative directory paths in .gitmodules, git tries to download the submodules from the fork instead of the original oolite repository. A workaround is to copy the file .absolute_gitmodules onto .gitmodules, then perform the submodules init, then replace .gitmodules with the relative path version. eg, on Unix:

$ cp .absolute_gitmodules .gitmodules
$ git submodule update --init
$ git checkout -- .gitmodules
You should now have access to the submodules, without git complaining that .gitmodules has changed or including .gitmodules in pull requests.