Interstellar Settings

[caracal]

Unless you've got the saveanywhere.oxp installed (does this still work?)

I just tried it with trunk, and the "equipment" didn't appear in any OXP station where I docked, which was a taxi stand, a constore, and a seedy space bar. Dunno about 1.74.

[DaddyHoggy]

Unless you've got the saveanywhere.oxp installed (does this still work?)

I just tried it with trunk, and the "equipment" didn't appear in any OXP station where I docked, which was a taxi stand, a constore, and a seedy space bar. Dunno about 1.74.

hmmmmmm

[Eric Walch]

Unless you've got the saveanywhere.oxp installed (does this still work?)

I just tried it with trunk, and the "equipment" didn't appear in any OXP station where I docked, which was a taxi stand, a constore, and a seedy space bar. Dunno about 1.74.

That oxp uses a lot of deprecated or already removed methods. Specially the "setPosition" were the oxp relies on, has been removed from 1.74 (Was already giving deprecated warnings in 1.73)

However, we now have a dockPlayer() what would make things a lot easier to code for Frame.

[Kaks]

I've no doubt that the moment Frame's RL lets off a bit, we'll have a shiny new saveanywhere (and hopefully the new Damnation OXP he teased us with this video too! )

[Disembodied]

I think the ultimate solution to the career criminal path should be some kind of network of pirate coves or similar that can be used to save. Thats assuming that a criminal career is worth (Im not making a value judgement here, if its wanted then cool) supporting properly.

I think it is, myself (despite having nothing but one expired offence to my name, when I accidentally launched from a main station with a ton of salvaged narcotics on board). Like DaddyHoggy says, it breaks the immersion if hardened, most-wanted criminal scum sidle in to the main station, dock and then trade with impunity, just so they can save their game; it's a bit like being able to dock with Thargoid carriers. Plus, more career options enhances everybody's game. I'd get to feel even more smug about my exemplary good behaviour, because there would be a viable alternative.

Of course, one thing which would also need to change, to make piracy a truly viable career, would be the behaviour of offender and fugitive NPCs. Maybe the player could get a criminal reputation, similar to the transport and passenger reputation, linked to the bounty. The higher the player's crime rep, the less likely it is that pirate ships will attack them. There would always be a chance – no honour among thieves etc. – but generally speaking, if you build up a reputation as a criminal then other criminals will tend to leave you alone.

A high crime rating, though, would also result in more bounty hunters and eventually police squadrons chasing after you. And pirate coves should be vulnerable to the occasional Navy raid ...

[Poro]

That's one thing that would tempt me to the 'dark side' - ganging up with a bunch of friendly pirates and taking on a navy capital ship. Arrrr me hearties!

[another_commander]

However, we now have a dockPlayer() what would make things a lot easier to code for Frame.

Just wanted to comment here that - at least for me - StationEntity.dockPlayer() works fine on both trunk and 1.74 and both for console and scripts. I am not sure why caracal had problems with it earlier. dockPlayer() docks the player instantly, without refusal messages or anything like that.

[Thargoid]

One would wonder about whether system.mainStation.dockPlayer was attempted rather than system.mainStation.dockPlayer(). The former will just tell you it's existing code in trunk, the latter will actually execute it.

[caracal]

However, we now have a dockPlayer() what would make things a lot easier to code for Frame.

Just wanted to comment here that - at least for me - StationEntity.dockPlayer() works fine on both trunk and 1.74 and both for console and scripts. I am not sure why caracal had problems with it earlier. dockPlayer() docks the player instantly ...

I guess I was calling it wrong or something. I thought it over some more, and split my script, which had previously been a ship script attached to the station, into a ship script and a world script. I left the event handler for playerRequestedDockingClearance in the ship script, and moved the handler for playerDockingRefused into the world script. Now at least the call from the world script works; haven't gotten to the point of testing the ship script code yet. And yes, it docked me instantly.

I still haven't managed to get it to call the playerRequestedDockingClearance function in the ship script, presumably because the station doesn't actually require docking clearance. (I'm reluctant to add the requires_docking_clearance token, but I guess I could just for testing.) When I request it, I get one of a couple of different cheery messages basically saying, "Oh, don't bother," but nothing from my own script.

One thing that concerns me, as I noted in the edit of my previous message, is that there's no "station" parameter given to the playerDockingRefused handler, so you have to figure out which station refused your request in another way. What that would be, I'm not sure yet. Or does that message only ever come from the main station? In a ship script, I assume it would be "this", the station object that owns the method, but in a world script, dunno.

... without refusal messages or anything like that.

Yes but ... in my case, it still played the audio file associated with the autopilot-denied event, and it posted the "Station refuses to issue docking instructions." console message. And then it docked me anyway. I assume that's because I'm calling it from the docking-refused handler, and those messages have already been sent.

I'll be testing all of this some more, although the earlier discussion in this thread has pretty much convinced me that this wouldn't be an OXP anybody would want, so it's kinda moot. Now I'm just playing with it to learn a bit more about the scripting environment.

[caracal]

One would wonder about whether system.mainStation.dockPlayer was attempted rather than system.mainStation.dockPlayer(). The former will just tell you it's existing code in trunk, the latter will actually execute it.

Hey now! I'm just a dumb ol' hillbilly, but I ain't that dumb! Here's the complete code for one of my functions, specifically the one in the world script that actually works:

Code: Select all

// Let my fugitives dock!
this.playerDockingRefused = function ()
{
    // Shouldn't we find out which station refused the request?
    Player.consoleMessage ("How rude!");
    System.mainStation.dockPlayer ();
}

Earlier in the thread, a_c mentioned a "StationEntity", which I haven't found in the docs. But the above code works as expected, so I guess it doesn't matter.

[another_commander]

StationEntity is a generic name describing the class to which the function belongs, meaning that the dockPlayer() function is only applicable to stations.

As for the refusal messages appearing, then docking, I believe you are correct that it is because the dockPlayer() is executed inside the playerDockingRefused handler.

[JensAyton]

It’s called Station in Javascriptese.

[Kaks]

dockPlayer() function is only applicable to stations.

---and carriers, aka big ships with docking ports!

Basically anything (or any game entity, if you will) that has its isStation flag set to 'true'.

Caracal, to find out which station the player is trying to dock to, I'd check player.ship.target.isStation to begin with.

If you get no joy wit that one, you might want to look into filteredEntities, specifically:

Code: Select all

this.findThatStation = function()
{
    function isStationEntity(entity)
    {
        return entity.isStation;
    }
  
    return system.filteredEntities(this, isStationEntity, player, 25600);
}

That should give you a an array with all the dockable entities (carriers, stations, rock hermits, hoopy casinos, etc...) in scanner range, listed from the nearest to the furthest away...

[Cmd. Cheyd]

Hmm, I wonder if it would be desirable, and - more intriguingly from a personal point of view - actually achievable if we were to 'correct' this drawback for 1.75 & (M)NSR...

A few OXPs seem to rely on the current behaviour IIRC.

Backtracking some, because I was out of town all weekend, but this would be an excellent change as well as the while "Save Anywhere" thing. I have an OXP idea hanging in the background that would require both.