Skip to content

Conversation

@MjnMixael
Copy link
Contributor

@MjnMixael MjnMixael commented Jul 14, 2025

This PR adds Props as a distinct new object type. Props work very similarly to ships in most cases but there are some key assumptions that make them unique:

  • Props cannot move
  • Props are not interactable except for being collided with

Props are meant to be scenery, set pieces, decoration, or even objects rendered by Lua in the UI only. Props do not take up ship slots and are not limited. Props are created in FRED using the new second dropdown with ctrl-shift-click instead of just ctrl-click
image

Props have a basic set of flags to start:

  • No Collide
  • No FRED
  • No Lighting

Props have a basic set of sexps to start:

  • add-to-collision-group-prop
  • remove-from-collision-group-prop
  • get-collision-group-prop
  • prop-create
  • prop-vanish

Props have basic Lua support including collision hooks and table indexing with a standard set of members and methods. Props are also a valid type for Lua SEXPs. Props are viewable in the F3 Lab as well. Props have stubbed in support for @BMagnu animation system and glowpoints but both are inactive for now.

Props.tbl is modular with -prp.tbm. It supports both +nocreate and +remove. Props can be categorized with colors for easy browsing in FRED. A sample table looks like this:

#PROP CATEGORIES

$Name: Planets
+Color: (0, 125, 0)

#PROPS

$Name: Planet-Antares1
	$POF file: planet-antares1.pof
	$Closeup_pos: 0.0, 0.0, -6000
	$Closeup_zoom: 0.5
	$Detail distance: (0)
	$Category: Planets
	$Custom Data:
	+Val: Category Between the Ashes
	$Custom Strings
	$Name: MapText
	+Value: -1
	+String: The first planet of the Antares System.
	$end_custom_strings

#END

Many thanks to @BMagnu and @Baezon for the assistance in various places of this PR, especially with collisions.

Fixes #4727

@MjnMixael MjnMixael force-pushed the add_prop_object_type branch from 41df668 to 9119837 Compare July 14, 2025 19:14
@wookieejedi wookieejedi added the feature A totally new sort of functionality label Jul 14, 2025
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 2 times, most recently from 560ef58 to 56e68c4 Compare July 18, 2025 20:04
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch from 56e68c4 to 6d47939 Compare July 24, 2025 16:09
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 2 times, most recently from db0b6a8 to 8b802ba Compare July 30, 2025 15:00
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 3 times, most recently from 7e3bbbc to 3d00c18 Compare August 5, 2025 22:15
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 3 times, most recently from 3cea937 to d331d00 Compare August 15, 2025 14:30
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 5 times, most recently from f27e2f0 to 2050d6d Compare August 25, 2025 13:26
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 3 times, most recently from 4dbc80a to 5053b91 Compare September 4, 2025 19:47
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch 2 times, most recently from ef81fc3 to 4ed7f50 Compare September 21, 2025 22:53
Copy link
Member

@BMagnu BMagnu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work.
A few small things, otherwise this is pretty much there.
Just as a list of ToDo you mentioned in the code and that I can think of that should be done in future PRs, as a reference here:
Modelanimation support
Multithreaded collision support
Possibly support as a permanent particle host (think something like a Volcano spewing smoke)

@MjnMixael MjnMixael force-pushed the add_prop_object_type branch from 92fecb8 to 27a65e3 Compare October 17, 2025 14:26
@MjnMixael
Copy link
Contributor Author

Great work. A few small things, otherwise this is pretty much there. Just as a list of ToDo you mentioned in the code and that I can think of that should be done in future PRs, as a reference here: Modelanimation support Multithreaded collision support Possibly support as a permanent particle host (think something like a Volcano spewing smoke)

And full QtFRED support which I'll get to once I finish rewriting sexp tree to be shared between FRED and QtFRED.

@BMagnu BMagnu added the Waiting for Stable Marks a pull request that is to be merged after the next stable release, due to a release cycle label Oct 18, 2025
@MjnMixael MjnMixael force-pushed the add_prop_object_type branch from 2a0a78a to e4e745c Compare December 17, 2025 19:28
Copy link
Member

@BMagnu BMagnu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wanted to comment on SEXP ergonomics when I saw the model_instance thing, so I'm giving this a short look-over again. Should all be fairly simple, but better to root out anything now than after it's merged

} else if (obj->type == OBJ_RAW_POF) {
model_num_a = Pof_objects[obj->instance].model_num;
} else if (obj->type == OBJ_PROP) {
model_num_a = prop_id_lookup(obj->instance)->model_instance_num;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait a minute, should this not be model_num rather than model_instance_num here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is prop object, which doesn't have model_num. model_instance_num looks to be equivalent.

} else if (other.obj->type == OBJ_RAW_POF) {
model_num_b = Pof_objects[other.obj->instance].model_num;
} else if (other.obj->type == OBJ_PROP) {
model_num_b = prop_id_lookup(other.obj->instance)->model_instance_num;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above

Comment on lines +621 to +623
{ "add-to-collision-group-prop", OP_ADD_TO_COLGROUP_PROP, 2, INT_MAX, SEXP_ACTION_OPERATOR, }, // MjnMixael
{ "remove-from-collision-group-prop", OP_REMOVE_FROM_COLGROUP_PROP, 2, INT_MAX, SEXP_ACTION_OPERATOR, }, // MjnMixael
{ "get-collision-group-prop", OP_GET_COLGROUP_ID_PROP, 1, 1, SEXP_ACTION_OPERATOR, }, // MjnMixael
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Playing around with this, as a slight ergonomic improvement, is it not possible to make the original collision group sexps just accept ships and props?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iirc the original sexps are tuned pretty specifically for ships and it would require a new sexp_tree type (ship or prop) I think. Honestly this PR has been sitting so long I don't really remember how it works under the hood anymore.

Copy link
Contributor Author

@MjnMixael MjnMixael Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, yes I looked at this. This requires significant overhead just for the one combined sexp to work. You'd need a new Sexp Tree type, OPF_SHIP_PROP, and all the extra code that requires. You'd need to do that for both FRED and QtFRED. Then you'd need to change the ship versions of these sexps to accept OFP_SHIP_PROP instead if just OPF_SHIP and adjust the sexp code to have two paths. This also requires adjusting all the error checking for these sexps to be able to return a new "invalid ship or prop" error type.

This would be a user-facing improvement for sure but I, quite honestly, don't want to do all that work just for these barely used sexps. If there were other more common sexps that could benefit from OPF_SHIP_PROP then it might be more justified.

@@ -1479,6 +1488,7 @@ struct wing;
// Goober5000 - stuff with caching
// (included in the header file because Lua uses the first three)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment should probably be updated to 4

Comment on lines 209 to 222
auto ship_entry = eval_prop(node);

// if this is a shipname type, we want the name of a valid ship but not the ship itself
// (if the ship is not valid, return an empty string)
if (argtype.first == "propname") {
return LuaValue::createValue(_action.getLuaState(), ship_entry ? ship_entry->prop_name : "");
}

if (!ship_entry || (ship_entry->objnum >= 0)) {
// Name is invalid
return LuaValue::createValue(_action.getLuaState(), l_Prop.Set(object_h()));
}

auto objp = &Objects[ship_entry->objnum];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of this is called ship, but should probably be called prop, both in comments and variable names

Comment on lines +414 to +417
SCP_string get_prop_table_text(const prop_info* pip)
{
char line[256], line2[256], file_text[82];
int i, j, n, found = 0, comment = 0, num_files = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're already doing a round 2 here:
Is it possible to consolidate this with the function above, as they basically do the same thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on where you want to draw the line. Right now, iirc, this matches the code structure that ships do. If I update this are you going to want me to update ships also?

Copy link
Contributor Author

@MjnMixael MjnMixael Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this, I'd rather not for now. This whole file could use consolidation and cleanup. However, this Props PR does a ton of changes already. I'd rather keep the change here as additive and later on someone can consolidate get_weapon_table_text, get_ship_table_text, get_asteroid_table_text, and get_prop_table_text as much as makes sense.

@MjnMixael MjnMixael force-pushed the add_prop_object_type branch from e4e745c to 1ae73c7 Compare January 30, 2026 18:50
@MjnMixael MjnMixael added this to the Release 26.0 milestone Jan 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature A totally new sort of functionality Waiting for Stable Marks a pull request that is to be merged after the next stable release, due to a release cycle

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Idea: New object type for terrain

5 participants