Page 4 of 4

Posted: Thu Jul 29, 2010 10:44 pm
by Frame
okay, I'm on my way to bed, ill try to reproduce it tomorrow , and if successfully ill PM you download instructions and exact steps on how to reproduce it..

BTW kopparberg is one little city in full decline :-(.. and dear lord do I really come to have a new favoured hate insect knots (knotter in Danish).. We couldn't go outside without being surrounded by these and bitten everywhere..

Posted: Fri Jul 30, 2010 11:53 am
by Frame
Ahruman wrote:
Sorry, but no. If those are different scripts, they’ll be different this objects, and there can be no conflict. The apparent fix is a coincidence.

Any actual information about the crash would be welcome.
After a good nights sleep, it seems has nothing to do with the timers, I'm struggling to reproduce it. The backup I thought I had a box.net seems to have been overwritten, with a new version that I uploaded for Caracal & Svengali to test & have fun with.

But with the old version that crashed even they had crashes, so it was not just limited to my machine.

There was really no specific information related to the crash, other than there was 20 ships engaged in a skirmish firering missiles at each other using timers to determine when to check and might fire these...

i tried using

Code: Select all

ship.fireMissile()
even when the ship had no missiles onboard to try and see if that was triggering the CTD,, since the ship was sometimes getting standard missiles upon spawn, and firering these and therefore not "refilling" the missile stock onboard with

Code: Select all

ship.awardEquipment("EQ_OXP_SPECIAL_MISSILE")
that was in a script attached to the owner of the missile

and therefore sometimes hitting ship.missiles = 0, if not properly checked before a missile launch.

but so far no crash, and given the illusive nature of the crash, I do not have any usefull information that could hint why it crashed.

and I have run out of time since I have to visit the in-laws for a full week.. so I cannot pursue this any further for another week.. (gotta get that portable)

Cheers... Frame...

System Demux v.2 has arrived

Posted: Sun Aug 01, 2010 8:16 am
by Dr Beeb
Thanks for inputs earlier for code improvements. New version at wiki page
http://wiki.alioth.net/index.php/System ... 8Oolite%29

A bit of file bloat creeping in as I doubled the resolution on the gas giants and replaced a few of the textures. The suggestion for cube maps I will look into. Eric and I 'think' this version is compatible with Famous Planets 1 and 2.5 and will defer to them, let us know if this is not the case.

Right now System Demux v. 2 plows through and ignores whatever System Redux 1 or Deep Horizons System Redux 2 are trying to do, so if problematic let me know, or suggestions on compatibility. You may want to remove them to try out System Demux.

Re: System Demux v.2 has arrived

Posted: Sun Aug 01, 2010 9:00 pm
by Eric Walch
Dr Beeb wrote:
Eric and I 'think' this version is compatible with Famous Planets 1 and 2.5 and will defer to them, let us know if this is not the case.
There will be an anomaly in galaxy 3 to 8 with the current version of Famous planet. In those systems it claims 5 systems for retexturing, but it has no textures for those planets, even when FP tries to apply those missing textures. When entering such systems, Oolite will log an error because it cant find the texture for those planets. But because FP has claimed that system, SD will not texture that planet either. And that list is also used by SR 1.0 and 1.2 and 2.0. (FP updates their internal lists with this wrong information). So those oxp's will also fail to texture those 5 planets per system.
But that is a bug in FP that hopefully will be fixed soon.

Re: System Demux v.2 has arrived

Posted: Mon Aug 02, 2010 9:21 pm
by pagroove
Eric Walch wrote:
Dr Beeb wrote:
Eric and I 'think' this version is compatible with Famous Planets 1 and 2.5 and will defer to them, let us know if this is not the case.
There will be an anomaly in galaxy 3 to 8 with the current version of Famous planet. In those systems it claims 5 systems for retexturing, but it has no textures for those planets, even when FP tries to apply those missing textures. When entering such systems, Oolite will log an error because it cant find the texture for those planets. But because FP has claimed that system, SD will not texture that planet either. And that list is also used by SR 1.0 and 1.2 and 2.0. (FP updates their internal lists with this wrong information). So those oxp's will also fail to texture those 5 planets per system.
But that is a bug in FP that hopefully will be fixed soon.
Yes that was in the original code. Thargoid made an example for each galaxy. But you can safely remove those lines out of the .js file.

I will probably patch some things when I have the time and by the way Eric. Also got your pm. I know there is a redundant data directory in Famous Planets. Actual I asked Lestradae some time ago to remove the directory and then zip the file again. Because he's hosting the package. That also means that I don't have to upload it. I ask him again.

Posted: Mon Aug 02, 2010 9:24 pm
by pagroove
Anyone already tried to run FP2.5. along with Deep Horizon and Sytem Demux. With that combination you can already have a lot of different textures?

Posted: Tue Aug 03, 2010 7:44 pm
by pagroove
Isn't it better to merge some oxp's. We now have 3 oxp's in development:

Sytemredux v2
Deep Horizon
and System demux.

If you merge them in one super oxp and polish the textures so they have the same look to each other. Or is that a bad idea?

Dr Beeb, Nice textures BTW.

Posted: Tue Aug 03, 2010 9:43 pm
by Eric Walch
pagroove wrote:
If you merge them in one super oxp and polish the textures so they have the same look to each other. Or is that a bad idea?
Its a bad idea as they now all have a style of their own. That way the player can make a choice what to install.

Re: System Demux

Posted: Sun Apr 08, 2012 10:09 am
by Eric Walch
I have been using system_Demux since it came out. I mainly use it to add additional planets and moons. I disabled retexturing of the main planet.

It had just two bugs:
- this oxp uses fixed distances to the main planet and not distances based on planet radii. With big main planets it could result in moons that are closer to the planet than stations.
- moons are placed random around the planet and not in an orbit. You would expect a position, more or less above the equator.

Today I played a bit with the moon addition script and decided to reposition them, by recalculating orbits around the planets equator. If other want to experiment with it, replace the current this.addMoons() function with the following two:

Code: Select all

this.addMoons = function()    
{
	var sys_info = this.system_info[galaxyNumber * 256 + system.ID] & (0x0F >> (4 - this.max_moons)); // & F 7 3 1 0 = &3

	var moon_bank = (system.ID >> 4) & 1; // Take 4th bit to switch between the four banks when only 2 moons needed.
        
        var unused_bits = (this.system_info[galaxyNumber * 256 + system.ID] & 0x0F) >> 2 ; // 0:3 

        var sys_idxa = ((galaxyNumber + system.ID + unused_bits) & 7)+1 ; // keep in range 0:7 as only 8 texture files.
        var sys_idxb = ((sys_idxa + 0 + (unused_bits >> 1)) & 7)+1; // adds 1 max.
        var sys_idxc = ((sys_idxa + 1 + unused_bits) & 7)+1; // careful, mustn't overlap with each 
        var sys_idxd = ((sys_idxa + 2 + unused_bits) & 7)+1; // otherwise positions the same.

        moon_bank = moon_bank & (this.max_moons < 3) ; // ignore and set back to zero if 3 or moons wanted.

// log("Redux moons using banks : " + moon_bank + " , with info " + sys_info  + " with bits " + unused_bits + " starting at index a = " + sys_idxa) ;

    var orientation = system.mainPlanet.orientation;
    var up = orientation.vectorUp();
    var radius = system.mainPlanet.radius;
    var position = system.mainPlanet.position;
	if ((sys_info & 0x01) & (1-moon_bank)*1)  {
        this.addMoon("moonA" + sys_idxa, 1, orientation, up, radius, position);
	}

	if ((sys_info & 0x02) & (1-moon_bank)*2)  {
        this.addMoon("moonB" + sys_idxb, 2, orientation, up, radius, position);
	}


	if ((sys_info & 0x04) | ((sys_info & 0x01) & moon_bank*1)) {
        this.addMoon("moonC" + sys_idxc, 3, orientation, up, radius, position);
	}


	if ((sys_info & 0x08) | ((sys_info & 0x02) & moon_bank*2)) {
        this.addMoon("moonD" + sys_idxd, 4, orientation, up, radius, position);
	}
}

this.addMoon = function (ID, orbit, o, u, r, p)
{
    var moon = system.addMoon(ID);
    var random = system.scrambledPseudoRandomNumber(system.ID+orbit)*Math.PI*2;
    moon.orientation = o;
    moon.position = p.add(o.rotate(u,random).vectorForward().multiply(r*(3+orbit/2)));
}

Re: System Demux

Posted: Sun Apr 08, 2012 10:34 am
by SandJ
Eric Walch wrote:
- moons are placed random around the planet and not in an orbit. You would expect a position, more or less above the equator.
No, I would have expected a position arbitrarily in orbit, not necessarily around the equator. So I went and looked for the evidence to argue and I am now wiser. Fancy that - the only moon we can see is an exception!

Thank you for the education, Eric.