View Issue Details

IDProjectCategoryView StatusLast Update
0001956FSSCPgameplaypublic2012-12-01 07:08
ReporterKeldorKatarn Assigned Tokarajorma  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformIBM PCOSMS WindowsOS VersionVista SP1
Product Version3.6.11 
Summary0001956: Disarm/Disable results in protection for some ship classes for others not.
DescriptionThe problem with this is, that this behavior is hardcoded.

I vote for placing the power to decide this behavior in the hands of the mission designer and make it a flag in FRED, keeping the original behavior as default (how to best achieve that must be discussed).

Hardcoding AI behavior of this magnitude is always a bad decision in my opinion. It made sense for most retail missions but it may not make sense for future fan missions, maybe even some FS1 Port missions and certainly not for all mods.
Additional InformationIt should be possible to specify whether an order to disarm/disable a ship results in the protection of said ship or not. And most of all, that should be possible for ANY ship class, and not hardcoded to be active for some ship classes and inactive for others. That's bad design in my opinion and I'm 100% sure this can be made more flexible without harming retail behavior.
TagsNo tags attached.

Relationships

duplicate of 0000744 closedGoober5000 Inferno - protect-ship and play-dead don't work 
parent of 0002143 resolvedkarajorma A wing with 2 simultaneous ai-destroy-subsystem goals does not work as expected. 

Activities

Goober5000

2011-09-02 14:40

administrator   ~0012794

Karajorma told me the other day that this had been fixed by adding options to objecttypes.tbl. Bumping it over to him to confirm.

karajorma

2011-09-04 10:40

administrator   ~0012797

It's now based on ObjectTypes.tbl.

I'll leave this open to remind me to make an override in FRED so the mission designer can toggle behaviour for whichever ships they want to.

Goober5000

2012-07-02 07:17

administrator   ~0013789

Bump...

The Trivial Psychic

2012-07-22 13:16

reporter   ~0013878

The table option in question appears to be here: http://www.hard-light.net/wiki/index.php/Objecttypes.tbl#.24Protected_on_cripple:

However, the default table listed at the bottom of the page suggests that large classes of ships such as "capital" and "supercap" have it disabled, though it has been this class of ship that Inferno has been encountering this behavior. I'll do some testing and see if either the table option actually does the opposite of what it describes (so YES is actually NO and visa versa), or if a secondary table option such as this one: http://www.hard-light.net/wiki/index.php/Objecttypes.tbl#.2BIgnored_on_cripple_by:

That said, the description of this other table option doesn't seem to match what we've been encountering.

karajorma

2012-10-28 13:23

administrator   ~0013999

Is this still an issue? I seem to remember discussing it on a thread on HLP but I can't remember the resolution.

karajorma

2012-12-01 07:05

administrator   ~0014239

Looking back at R5961, I'm pretty sure this is by design actually. The original code my fix replaced contained this line.

// Only protect if _not_ a capital ship. We don't want the Lucifer accidentally getting protected.
if (!(Ship_info[Ships[shipnum].ship_info_index].flags & SIF_HUGE_SHIP))
    Objects[aip->target_objnum].flags |= OF_PROTECTED;

Basically it's set to NO in the objecttypes table because those classes didn't get protected in the original code either. If you want to change that behaviour you need a new objecttypes.tbl or .tbm. It's not a code error cause if I set those ships to YES, the Lucifer would become protected in the last mission of FS1 and the AI would stop attacking it.

Issue History

Date Modified Username Field Change
2009-07-07 17:09 KeldorKatarn New Issue
2009-07-08 03:48 Goober5000 Status new => assigned
2009-07-08 03:48 Goober5000 Assigned To => Goober5000
2011-06-24 04:44 Zacam Category --------- => gameplay
2011-09-02 14:40 Goober5000 Note Added: 0012794
2011-09-02 14:40 Goober5000 Assigned To Goober5000 => karajorma
2011-09-04 10:40 karajorma Note Added: 0012797
2012-07-02 07:17 Goober5000 Note Added: 0013789
2012-07-21 23:22 Goober5000 Relationship added duplicate of 0000744
2012-07-22 13:16 The Trivial Psychic Note Added: 0013878
2012-10-28 13:23 karajorma Note Added: 0013999
2012-12-01 07:05 karajorma Note Added: 0014239
2012-12-01 07:06 karajorma Status assigned => resolved
2012-12-01 07:06 karajorma Resolution open => fixed
2012-12-01 07:08 karajorma Relationship added parent of 0002143