Forums » Suggestions

Prevent /logoff if you have taken any damage in the last minute,

123»
Dec 18, 2013 Kierky link
Yeah, this should be a no brainer.
Either this or have damage simply cancel an active /logoff.

Obvious exception is in a station, like all logoff timers.

EDIT: the time from taking damage to being allowed to /logoff can be something else if it needs balancing.
Dec 18, 2013 Roda Slane link
- 0.5

I do not wish to see methods that will prevent a player from logging out for an indefinite period of time. You should be allowed to log, when you wish to log, with any delays limited to a reasonable period of time.

If you hail (or pm) a target, while the target is in space, you force the logout timer to be 30 seconds instead of just 10.

What I do want, is to know when they are trying to log out. Let them log out, and let them be destroyed for logging out.

See also: Target Connection info
Dec 18, 2013 Pizzasgood link
+1 billion.

I do think that if the OP is implemented, there should be a "/logoff force" option that logs you out immediately, but leaves the ship drifting while the normal countdown process happens server-side. So if you were just in a fight and haven't docked yet, you'd still get to log out right away so you can leave for work, but your ship would persist for a minute inside the game before it also disappeared (unless somebody tracked it down and caused more damage, which would delay it some more).

If you used /logoff force when the damage-cooldown was not in effect, your ship would only persist for the normal 10 seconds it would have taken to /logoff without the force option.

Also, another +1 billion to notifying the sector when somebody tries to log off.
Dec 18, 2013 Snake7561 link
+1
Dec 18, 2013 draugath link
Some games won't even let you log out properly if you are in combat. So I really don't see any problem with the concept of this. However, the timer should be reset if you jump.
Dec 19, 2013 Kierky link
This idea is more of a lead into what Incarnate has said he'll already do. Basically the ship should persist for as long as it's been taking damage in the last *s , I don't particularly care if the pilot sticks around. lol
Dec 19, 2013 TheRedSpy link
inb4 Roda suggestion thread "Do what you already said you'd do, Incarnate" #rodasideaisbetter
Dec 19, 2013 Roda Slane link
+1

On further consideration, I have decided to change my position. Because I do not wish cap ships to be able to log out of combat, I have decided to support means to prevent a ship from leaving the game while engaged in combat. The OP appears to be pursuing this goal.

See also:
Target Connection info
Sep 11, 2009 incarnate: Longer delay for /logoff in space
Dec 19, 2013 csgno1 link
This is not an issue for capships since the plan is to make them persistent. Logoff won't matter anymore for them. Make the rules you want based on regular ships.
Dec 19, 2013 Roda Slane link
The devs have lots of plans, and some of them will come true, at some point.

Today the problem is cap ships, and tomorrow some other ship. The fact that any ship has influenced the issue proves that restricting log out during combat is the more robust solution.

I do not wish to prevent the player from logging out. just the ship. I would rather not have to do damage to prevent a log out. I would settle for having to hit the ship with a power drain (or repair module). I would prefer to prevent log out by a hail from any armed ship within weapons range.

Edit: I am not really trying to invent, or help invent a way for a character to repair an alternate character's ship, but I wouldn't cry about it.
Dec 22, 2013 draugath link
I had an idea recently that could be a possibility. Rather than trying to detect combat states, require that to logout while in space the player be >5000m from any potential hostile players. In this case, "potential hostile players" is defined as any other player not in the subjects group or guild.
Dec 22, 2013 Pizzasgood link
Yeah, I could live with that.
Dec 22, 2013 Jashen Bonarus link
+1 for draugath's proposal, no to all others.
Dec 22, 2013 Drevent1 link
+1 to draugath idea
Dec 22, 2013 Kierky link
draugath's idea is probably better in practise.
Dec 22, 2013 TerranAmbassador link
+1 to draugath's idea
Dec 23, 2013 tarenty link
What about bots in stations? How does that 5000m affect them? Are they considered, by the game, to be 0m from the station or not in the sector or...?
Dec 23, 2013 draugath link
I don't think that docked players register a distance, so they should be ignored. While they are technically a potential threat, they aren't an active potential threat. The pirate sitting next to you waiting patiently (not shooting) is an active potential hostile player. The player you just received credits from as payment for an object you decided you didn't want to give him is an active potential hostile player.
Dec 23, 2013 Roda Slane link
draugath,

I could support your idea that a player not be allowed to log out in space if a potential player threat is within 5k range.

As you have pointed out, it should ignore players that are in your guild or group.

It should ignore players that can not damage you due to friendly fire restrictions.

It should not ignore players in the station, if you are within 5k of the station. The station is right there. dock.

I would like a player option setting, that any player may choose to exclude themselves from being considered as a potential threat when someone else attempts to logout in space. A hot key for the setting would be nice. The "I am going to kill you" toggle button.

I do not see this as a perfect solution. I do see it as something significantly better than what we have now.

I still wish that the player be able to log, but that the ship remains in game until it meets the requirements to log out in space, for a consecutive period of time. 60 seconds?

edit: deleted the part about guns, ammo, etc... per feedback from pizzasgood.
Dec 23, 2013 Pizzasgood link
Those exceptions mostly seem okay (except the bit about equipped guns and ammo, which is a minor privacy violation). However, I think KISS should be applied here. The more special cases you add, the more likely the devs will make a mistake in implementation, or later on something they change will break things. Those special cases you listed don't really seem worth the complexity cost, at least to me. But yeah, other than that and the bit about guns, I wouldn't mind them.