
http://www.jklasers.com/
This is very amusing. Which came first? Who inspired who?

I guess I'll have to give more respect to the JK Pulse Laser.

Moderators: winston, another_commander
It seems to be OK with version 0.12 of Extended Shipyards, along with version 0.16 of Ship Storage Helper. There was a bug in Ship Storage Helper version 0.15 that seemed to be the problem.CommonSenseOTB wrote:What's new:
-Original lasers are now replaced by the virtual ones automatically when starting a new game or buying a new ship.(Not yet compatible with extended shipyards)
Not quite but now v0.21 works excellent with both of these fine oxps.Capt. Murphy wrote:It seems to be OK with version 0.12 of Extended Shipyards, along with version 0.16 of Ship Storage Helper. There was a bug in Ship Storage Helper version 0.15 that seemed to be the problem.CommonSenseOTB wrote:What's new:
-Original lasers are now replaced by the virtual ones automatically when starting a new game or buying a new ship.(Not yet compatible with extended shipyards)
Code: Select all
Warning: removeFrameCallback(): invalid tracking ID.
Active script: customlasers 0.21
customlasers.js, line 5574:
removeFrameCallback(this.clm);//----------
Thanks for finding this Capt. Murphy. So let me get this straight. I now have to check if I'm docked while entering and exiting witchspace??? Surely this is a bug in the game to trigger witchspace events while docked? So anything that stops and starts timers and framecallbacks during the witchspace transit is now gonna have this problem as this scenario might throw a wrench in the whole works. Nearly all my stuff shuts down in this way and will have to be modified and tested as for framecallbacks I don't leave in isValidFrameCallback testing code. Still even for those that do leave in this code, some behaviours might change as things that will trigger on witchspacing may happen while docked at a carrier that goes into witchspace. Maybe we need a viewtopic with a sticky under expansion packs about it as a constant reminder. Sheesh!Capt. Murphy wrote:Hi CSOTB,Code: Select all
Warning: removeFrameCallback(): invalid tracking ID. Active script: customlasers 0.21 customlasers.js, line 5574: removeFrameCallback(this.clm);//----------
This has come up in debug console a couple of times in various scenarios. It's reproducible in this way - spawn a Carrier of some description (I used the Behemoth), dock with it, giving it an exitSystem() command via the console then launch.
See from here.CommonSenseOTB wrote:So let me get this straight. I now have to check if I'm docked while entering and exiting witchspace??? Surely this is a bug in the game to trigger witchspace events while docked?
I did see that and I also saw from cim's post above it:Commander McLane wrote:See from here.CommonSenseOTB wrote:So let me get this straight. I now have to check if I'm docked while entering and exiting witchspace??? Surely this is a bug in the game to trigger witchspace events while docked?
And indeed, it's not a normal thing (yet).
I just don't think witchspace events should fire off while docked. I think that's buggy behaviour.cim wrote:There are certain bugs in the way this is handled in 1.76.1 that may give slightly odd results if you try it; they are on my list to fix as the trunk version of them is more serious.
I think that bit is correct, though. OXPs need to know when the player enters a new system, regardless of how they got there. Those events need to fire or lots of things will break. (Or do you mean that ships with a docked player should not be allowed to enter witchspace at all?)CommonSenseOTB wrote:I just don't think witchspace events should fire off while docked. I think that's buggy behaviour.cim wrote:There are certain bugs in the way this is handled in 1.76.1 that may give slightly odd results if you try it; they are on my list to fix as the trunk version of them is more serious.
When you put it like that I suppose then it's an either/or situation. Either don't allow it to happen or every oxp with frame callbacks and timers that switch on/off when entering/exiting witchspace and even just regular scripts with those events as triggers will have to be checked for unintended behaviour and fixed. That could be a mammoth task. I predict lots of unintended bugginess when docked players enter witchspace. Will create lots of work for me as perhaps in some cases even when I think it's fixed for this, a behaviour might be different than what was intended. You guys do what you want. I'm not the best scripter in the world and in most cases everything I put out is at the limits of my abilities at the time of release. The problem I see in all this is that it creates incompatibilities in existing oxps whereas new features in 1.77trunk even typically are backward compatible still with existing oxps even if they don't use the new features. Thus my thought that this is actually a bug(not a feature) that I guess someone wants to exploit to make an oxp with. I'm not sure what the solution is, the carrier oxp idea being discussed sounds ok to me, and I'll do my best to maintain compatibility with it , but it does sound like to me that lots of problems will result for some or even many oxps.cim wrote:I think that bit is correct, though. OXPs need to know when the player enters a new system, regardless of how they got there. Those events need to fire or lots of things will break. (Or do you mean that ships with a docked player should not be allowed to enter witchspace at all?)CommonSenseOTB wrote:I just don't think witchspace events should fire off while docked. I think that's buggy behaviour.cim wrote:There are certain bugs in the way this is handled in 1.76.1 that may give slightly odd results if you try it; they are on my list to fix as the trunk version of them is more serious.
It could be, yes. But hitchhiking on a jumping ship can "work" in 1.76.1 already, so banning it would also be a change of behaviour.CommonSenseOTB wrote:When you put it like that I suppose then it's an either/or situation. Either don't allow it to happen or every oxp with frame callbacks and timers that switch on/off when entering/exiting witchspace and even just regular scripts with those events as triggers will have to be checked for unintended behaviour and fixed. That could be a mammoth task.cim wrote:I think that bit is correct, though. OXPs need to know when the player enters a new system, regardless of how they got there. Those events need to fire or lots of things will break. (Or do you mean that ships with a docked player should not be allowed to enter witchspace at all?)
shipWillLaunchFromStation
shipWillEnterWitchspace
shipWillExitWitchspace
shipExitedWitchspace
shipLaunchedFromStation
never fires at all.So at this point I'll just wait to see what you boys figure out before even thinking of attempting any oxp compatibility fixes then.cim wrote:It could be, yes. But hitchhiking on a jumping ship can "work" in 1.76.1 already, so banning it would also be a change of behaviour.CommonSenseOTB wrote:When you put it like that I suppose then it's an either/or situation. Either don't allow it to happen or every oxp with frame callbacks and timers that switch on/off when entering/exiting witchspace and even just regular scripts with those events as triggers will have to be checked for unintended behaviour and fixed. That could be a mammoth task.cim wrote:I think that bit is correct, though. OXPs need to know when the player enters a new system, regardless of how they got there. Those events need to fire or lots of things will break. (Or do you mean that ships with a docked player should not be allowed to enter witchspace at all?)
Part of the problem with 1.76.1 may be that the events fire in a bit of an odd order:
shipWillLaunchFromStation
shipWillEnterWitchspace
shipWillExitWitchspace
shipExitedWitchspace
shipLaunchedFromStation
never fires at all.
Actually, in 1.76.1 it's possible to crash Oolite by hitchhiking on a jumping ship, if you don't launch before its wormhole expires, which may be why it's never caught on as a means of transit