Page 2 of 2

Posted: Sat Jun 26, 2010 9:51 am
by caracal
DaddyHoggy wrote:
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.

Posted: Sat Jun 26, 2010 10:54 am
by DaddyHoggy
caracal wrote:
DaddyHoggy wrote:
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

Posted: Sat Jun 26, 2010 11:07 am
by Eric Walch
caracal wrote:
DaddyHoggy wrote:
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.

Posted: Sat Jun 26, 2010 12:09 pm
by 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! :) )

Posted: Sat Jun 26, 2010 12:21 pm
by Disembodied
Cmdr James wrote:
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 ...

Posted: Sat Jun 26, 2010 12:50 pm
by 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!

Posted: Sat Jun 26, 2010 2:05 pm
by another_commander
Eric Walch wrote:
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.

Posted: Sat Jun 26, 2010 2:10 pm
by 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.

Posted: Sun Jun 27, 2010 12:26 am
by caracal
another_commander wrote:
Eric Walch wrote:
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.
another_commander wrote:
... 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. :shock: 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.

Posted: Sun Jun 27, 2010 12:31 am
by caracal
Thargoid wrote:
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! :P 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.

Posted: Sun Jun 27, 2010 7:20 am
by 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.

Posted: Sun Jun 27, 2010 9:05 am
by JensAyton
It’s called Station in Javascriptese.

Posted: Sun Jun 27, 2010 2:34 pm
by Kaks
another_commander wrote:
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...

Posted: Mon Jun 28, 2010 5:27 pm
by Cmd. Cheyd
Kaks wrote:
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.