2018-02-24 10:03 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001956FSSCPgameplaypublic2012-12-01 02:08
ReporterKeldorKatarn 
Assigned Tokarajorma 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformIBM PCOSMS WindowsOS VersionVista SP1
Product Version3.6.11 
Target VersionFixed in Version 
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.
Attached Files

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

-Notes

~0012794

Goober5000 (administrator)

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

~0012797

karajorma (administrator)

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.

~0013789

Goober5000 (administrator)

Bump...

~0013878

The Trivial Psychic (reporter)

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.

~0013999

karajorma (administrator)

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

~0014239

karajorma (administrator)

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.
+Notes

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