Oolite Bulletins

Umm...the real JK Lasers.

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.

CustomLasersv0.2 WIP test version is now available for download. Requires oolite1.77trunk.

https://www.box.com/s/239c4936de4a870bf940

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)
-8 new lasers including 2 dual mode mining/combat lasers.
-various code tweeks.

Playtest results may be reported here and are greatly appreciated.

Have fun with this!

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)

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.

Capt. Murphy wrote:

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)

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.

Not quite but now v0.21 works excellent with both of these fine oxps.

CustomLasersv0.21 WIP test version is now available for download. Requires oolite1.77trunk revision 4975.

https://www.box.com/s/c4204065566e3003fc80

What's new:
-Now works excellent with extended shipyards and ship storage helper oxps.
-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)
-8 new lasers including 2 dual mode mining/combat lasers.
-various code tweeks.

Playtest results may be reported here and are greatly appreciated.

Have fun with this!

Hi CSOTB,

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.

Capt. Murphy wrote:

Code: Select all

Warning: removeFrameCallback(): invalid tracking ID.
    Active script: customlasers 0.21
    customlasers.js, line 5574:
       removeFrameCallback(this.clm);//----------

Hi CSOTB,

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.

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!

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?

See from here.

And indeed, it's not a normal thing (yet).

Commander McLane wrote:

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?

See from here.

And indeed, it's not a normal thing (yet).

I did see that and I also saw from cim's post above it:

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 just don't think witchspace events should fire off while docked. I think that's buggy behaviour.

CommonSenseOTB wrote:

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 just don't think witchspace events should fire off while docked. I think that's buggy behaviour.

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?)

cim wrote:

CommonSenseOTB wrote:

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 just don't think witchspace events should fire off while docked. I think that's buggy behaviour.

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?)

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.

CommonSenseOTB wrote:

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?)

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.

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.

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

cim wrote:

CommonSenseOTB wrote:

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?)

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.

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.

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

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.

I am not normally given to thread necromancy but felt it necessary , considering the recent release of 1.77 to resurrect this thread as It makes available these purchasable weapons to the player in the latest release.

hello there!
i have CustomLasersv0.21 installed and it works fine most of the time.
but sometimes when i leave witchspace, the laser doesn't fire when i hit the *a* key. it is just like as if there was no weapon installed. but when i change the view and hit the *a*key and then change back to forward view, the laser fires normally. this works even when you have no laser installed on the other views.

the only thing i am missing is different type of crosshairs, because it is always the ones of a pulse laser independently which laser i have installed.

best regards!