Wanted problems when in the throws of combat
- Thread starter Rath
- Start date
The easy solution is to make the timer global to everyone... all warnings are broadcast to everyone in the vicinity. Think of it as a proxy for the police pilots mood. If you annoy him or he feels threatened you are more likely to get a bounty. To be honest a simple personality simulation for the police would be very easy to implement and would make the game feel more realistic and would be hard to exploit. Individual police could then have their own unique personalities. Also, some systems could become notorious for the police being a bunch of total gits.
I'd even add a small "memory" to individual police pilots that allow them to remember which commanders recently irritated them. The effects of the pilots general "irritation" level + the commander specific short term is used to decide how to respond.I'd like to see bribes added to the game, which would tie in nicely if the police had personalities.
Last edited:
Ozric
Volunteer Moderator
The easy solution is to make the timer global to everyone... all warnings are broadcast to everyone in the vicinity. Think of it as a proxy for the police pilots mood. If you annoy him or he feels threatened you are more likely to get a bounty. To be honest a simple personality simulation for the police would be very easy to implement and would make the game feel more realistic and would be hard to exploit. Individual police could then have their own unique personalities. Also, some systems could become notorious for the police being a bunch of total gits.
I'd like to see bribes added to the game, which would tie in nicely if the police had personalities.
I do love it when people say something would be very easy to implement
I do love it when people say something would be very easy to implement
I'm a physicist and experienced software engineer with a strong understanding of AI. Trust me, it is easy to implement. A basic version could be written as a simple decision tree with some heuristic to decide on the scale of impact. The algorithm would only need access to and ability to store instance local state (to record the state of the actor), so there would be no major issues with scalability. It would be about 100 lines of code or so.
oomwat
Banned
There also seems to be an interesting variant on the accidental shooting issue ... if a police ship accidentally shoots you, then they go red, and then they start firing on you (no doubt because you are red to them).
The 'simple' solution to the accidental shooting issue is for every shot, you get a small fine.
If you take shields down you get a bounty, and if you kill someone you get an additional (bigger) bounty.
Last edited:
For fixed weapons I think it should stay. If you don't have the shot you don't pull the trigger. Although accidents probably shouldn't cause aggro just a fine. Friendly fire shouldn't be hostility it should be a demotion. On gimballed weapons since you can't always see couldn't it just have an iff were it won't fire if blocked by a friendly? Just my thoughts on it.
Yeah it could be easy for like 2-3 people to chase down any ship, shooting 2-3 times each in succession, without any kind of retaliation/bounty on their heads..
I think the solution would be to get a warning (or a fine) if you shoot one time by accident, but give your opponent the right to engage without getting a bounty. That way it couldn't be used to gain some kind of advantage.
I think one "accidental" shot should be treated as friendly fire and fined but not an immediate bounty. The following up shots will however, grant you bounty due to assault.
One "accidental" shot but the target is killed should be considered manslaughter and should have bounty on your head.
One "accidental" shot but the target is killed should be considered manslaughter and should have bounty on your head.
A lot of complex mechanics have been proposed but I think the simpler we make the "rules" the fewer programmers will be tearing their hair out trying to implement it.
How about:
1: A friendly fire situation occurs when two ships are attacking the same target and one is struck by the others fire. If the NPC you hit is not attacking the same target as you, sorry you're out of luck.
2: If no hull damage occurs, no crime, but a nasty message. Damage the hull and things happen as they do now.
This would also cover friendly fire on a non-security NPC or from an NPC on a player. If an NPC hits the player, but doesn't do hull damage when they both have the same target they get away with it but send "Sorry, buddy.."
It wouldn't eliminate every situation but it would cover most, and wouldn't allow exploits because it doesn't apply unless both the shooter and victim have the same target locked.
How about:
1: A friendly fire situation occurs when two ships are attacking the same target and one is struck by the others fire. If the NPC you hit is not attacking the same target as you, sorry you're out of luck.
2: If no hull damage occurs, no crime, but a nasty message. Damage the hull and things happen as they do now.
This would also cover friendly fire on a non-security NPC or from an NPC on a player. If an NPC hits the player, but doesn't do hull damage when they both have the same target they get away with it but send "Sorry, buddy.."
It wouldn't eliminate every situation but it would cover most, and wouldn't allow exploits because it doesn't apply unless both the shooter and victim have the same target locked.
Ozric
Volunteer Moderator
I'm sure you are and I'm sure you know that would fit into their programming without any implications at all.
I'm not going to waste my time discussing this with you. If you haven't got anything useful to contribute why don't you just be quiet.
Last edited:
Solution - Lasers dont damage untargeted vessels.
Its untidy, skill reducing, immersion breaking and a bad mechanic but it stops the accidental clipping of allied ships and also a group grief scenario where lots of cmdrs could hit someone once and kill them without penalty.
Its untidy, skill reducing, immersion breaking and a bad mechanic but it stops the accidental clipping of allied ships and also a group grief scenario where lots of cmdrs could hit someone once and kill them without penalty.
Last edited:
You just quoted most of the reasons why I really don't want to see that mechanic introduced. I'd see that as a serious downgrade. There's plenty of ways to avoid the group grief scenario without dumbing it down that far - the easiest being that doing hull damage should never get a free pass.
Ozric
Volunteer Moderator
Hehe, OK then
You could still shoot someone on purpose without having them targeted.
Ok money where my mouth is, this is relatively simple model that should address the basic concerns.
This is a very simple model but should fix our current gripes with the policing system.
Regarding fines something like this would be good:
fine 100Cr - illegal weapon strike
fine 200Cr + [0, 1000] Cr - illegal weapon strike resulting in damage (fine depends on damage)
BTW there may be the odd typo above.
Code:
A basic police model:
Initial instance state:
police_tolerance = 3 # value depends on government, local factors etc... range is [3-6]
police_warning_expiration_time_offset = 900 # 15 mins per level
police_hit_expiration_time_offset = 300 # 5 mins per level
Per actor state (players + NPCs):
police_warning_level = 0
police_warning_expiration_time = 0
police_warning_rep_modifier = in range [-2, 2] corresponding to hostile, unfriendly, neutral, friendly and allied
police_hit_level = 0
police_hit_expiration_time = 0
Events modifying state:
EVENT hit to shield
* any (actor1) -> wanted actor (actor2)
* no action
* any (actor1) -> clean actor (actor2)
tolerance = instance.police_tolerance + actor1.police_warning_rep_modifier
actor1.police_warning_level += 1
actor1.police_warning_expiration_time = sim.time + instance.police_warning_expiration_time_offset
actor2.police_illegal_hit_level += 1
actor2.police_hit_expiration_time = sim.time + instance.police_hit_expiration_time_offset
decrease_reputation(actor1)
if actor1.police_warning_level < tolerance and actor2.police_illegal_hit_counter < tolerance:
if actor1 is human:
do_warning_and_fine_logic()
else:
give_bounty_to(actor1)
EVENT hit to hull
as above but:
* any (actor1) -> clean actor (actor2)
actor1.police_warning_level += calc_warning_increase(hit.damage)
actor2.police_illegal_hit_counter += calc_warning_increase(hit.damage)
EVENT hit causing death
* any -> wanted actor
* (current behaviour - award bounty to player)
* other -> clean actor
* (current behaviour - place bounty on player, player becomes wanted)
EVENT per_N_sim_frames
if actor.police_warning_level > 0 and actor.police_warning_expiration_time < sim.time:
actor.police_warning_expiration_time = sim.time + instance.police_warning_expiration_time_offset
actor.police_warning_level -= 1
if actor.police_hit_level > 0 and actor.police_hit_expiration_time < sim.time:
actor.police_hit_expiration_time = sim.time + instance.police_hit_expiration_time_offset
actor.police_hit_level -= 1
The function do_warning_and_fine_logic should be fairly obvious, depending on the warning and hit levels you will get a graded warning or fine.
The actor state and logic above also allow the police to warn that another hit on CMDR_blah will result in a bounty, in addition to general warnings.
The calc_warning_increase() function would be a simple damage % to warning level increase: [0-99.9% of hull strength] -> [2,5]
e.g. hit damage is 90% of full hull strength = warning level of 4 (ie you will likely get an instant bounty if you are not v.friendly!).
The particular scale could be a tunable per instance e.g. set by government type etc...This is a very simple model but should fix our current gripes with the policing system.
Regarding fines something like this would be good:
fine 100Cr - illegal weapon strike
fine 200Cr + [0, 1000] Cr - illegal weapon strike resulting in damage (fine depends on damage)
BTW there may be the odd typo above.
Last edited:
Ozric
Volunteer Moderator
My point still stands of are you sure this would be easy to fit into their coding (having no knowledge of how it is structured), without affecting anything else? I work as a Software Tester and so I know all about programmers and their "easy" solutions
I'm sure that FD have already thought of something like this if it is that easy, but then again there's always the possibility that they don't actually want to do anything about it, as this conversation has been going since at least June.
It isn't intended to be actual code solution at this point, it is a pseudo-code model for discussion (i.e. a kind of specification). It fitting into their specific code is moot at this point. But yes, all the components present in this model would already need to be present to some degree for the game to operate as it currently does. If you have experience in game/algorithm design you would know that certain elements have to be present to achieve certain behaviours. e.g. a global simulation timer - this may practically be the real clock time or sim frame count (otherwise how would mission timers work for example?).
I know you seem to take issue with the word easy, but relative to altering code in other sections of a game engine, it is (from experience). If you think of the code as an onion shell of components built on components, the game logic lives at or near to the outermost shell. Modifying anything deeper in the onion e.g. the network infrastructure, the game engine API would be "hard" as modifications would required touching huge parts of the code base and thus would have a high probability of unintended consequences. Given that this model is a peripheral part of the game logic and an instance local decision the probability of unintended consequences is relatively low.
As a developer I actively encourage my users to propose solutions to problems they encounter, particularly the technically literate users. Developers have finite time and they don't always have the luxury of being able to invest time thinking about problems that are a low priority. I don't understand why you seem to have taken against brainstorming a possible user derived solution, given that the users are the very people who will be using the code. Are you aware the whole frame-shift drive idea was derived from the users?
Why don't you start using your testing skills to do something useful like spotting holes in the logic?
I know you seem to take issue with the word easy, but relative to altering code in other sections of a game engine, it is (from experience). If you think of the code as an onion shell of components built on components, the game logic lives at or near to the outermost shell. Modifying anything deeper in the onion e.g. the network infrastructure, the game engine API would be "hard" as modifications would required touching huge parts of the code base and thus would have a high probability of unintended consequences. Given that this model is a peripheral part of the game logic and an instance local decision the probability of unintended consequences is relatively low.
As a developer I actively encourage my users to propose solutions to problems they encounter, particularly the technically literate users. Developers have finite time and they don't always have the luxury of being able to invest time thinking about problems that are a low priority. I don't understand why you seem to have taken against brainstorming a possible user derived solution, given that the users are the very people who will be using the code. Are you aware the whole frame-shift drive idea was derived from the users?
Why don't you start using your testing skills to do something useful like spotting holes in the logic?
Last edited:
Ozric
Volunteer Moderator
As you may or may not have noted I have been testing the game since Premium Beta 1 in June, so yes I am aware of just how many things have been derived from the users, I actually think they "accidentally" broke my create a new ticket page a few weeks ago as they were getting fed up with me
I am also aware of just how many times this discussion has been had and we've had all these suggestions before. It's not a bad thing to have discussions about things, but when people start new topics without checking the old ones you end up with the same ideas being batted around again and I have to ask the same questions again, as I like to pose the other side of the argument to see if people have though about how small things affect the whole. Most are generally ignored as they haven't, some are answered and we move on. Not sure which logic you want me to spot the hole in though.So back to your last point though, before we got distracted, how far would the range of "all" ships be? It would seem harsh to extend the punishment to someone who's 15-20Km away from the battle for example. And if you were in a fight and there was another PC there also fighting, you could deliberately hit the Security until they were one shot away from attacking and then wait for the other PC to make a mistake. A mistake more likely to be made as they don't have the worry about any difficulty in fighting near other ships as they don't have to be as careful with their firing.
Please don't change it - if one player shoots and innocent then it should remain a crime. As players get better they will learn that fighting is not just about multi cannons and the trigger held down permanently...
As you may or may not have noted I have been testing the game since Premium Beta 1 in June, so yes I am aware of just how many things have been derived from the users, I actually think they "accidentally" broke my create a new ticket page a few weeks ago as they were getting fed up with me
So back to your last point though, before we got distracted, how far would the range of "all" ships be? It would seem harsh to extend the punishment to someone who's 15-20Km away from the battle for example. And if you were in a fight and there was another PC there also fighting, you could deliberately hit the Security until they were one shot away from attacking and then wait for the other PC to make a mistake. A mistake more likely to be made as they don't have the worry about any difficulty in fighting near other ships as they don't have to be as careful with their firing.
The model logic obviously. I'm assuming you can program or have at least a little knowledge of structured logic to be able to follow the model, otherwise you wouldn't be a very effective software tester. If you can't follow it:
Each ship has a warning counter, go over a limit you get a bounty. Each ship has a hit counter, if a ship is hit more than a certain limit by anyone, the person hitting them gets a bounty. The police can broadcast warnings bases on the hit and warning state for each ship. The warning level and hit level decays slowly. No-one 15-20 km away would be affected as it is ship local. The police tolerance (ie level of warnings before a bounty) is a tunable parameter that could vary based on rep, government type etc...
I've not seen this model in any of the other threads.