[Wanderer]

Reviving the old discussion regarding objecttypes - or rather finally making the darn thing actually function how it should. On basic level this means expanding the system (objecttypes.tbl or xxx-obt.tbm) to replace every single instance of SIF_<SHIP TYPE> & SIF_<SHIP SIZE> and their next of kins. I made earlier (years ago) patches with this as a goal but they were never implemented.

Now then, this job is not exactly too difficult or demanding. It is laborious though. On basic level it merely requires for replacement of every reference to SIF_<SHIP> booleans or structures controlled by the booleans with options to objecttypes table (in ship.h), addition of the necessary variables/definitions to ship_types struct in ship.h, adding default values for the current ship types to globalincs/def_files.cpp. However some of the occurrences could be included (consolidated?) under single option to the table. Also some could also be just descriptive - i.e. option to define if a ship is thought of being large or small etc.

One quite important matter however remains - how to make sure ships actually have objecttype defined for them. As it stands the code does not appear to require them to have any which means that every single instance where the values from the objecttypes are checked essentially requires some additional measures. Way i see it there are three options, (1) demand that every ship has a valid references to an existing objectype, (2) construct 'default' or dummy objecttype which is set by default but could not be edited via objecttypes.tbl (so it could be accessed in absence of actually defined objecttype without actually resorting to option number 3), (3) add safeties to every single instance a check from the objecttypes.tbl is made.

Opinions and views on the issue are welcome.

[chief1983]

I'm not sure how to address your last question, but as far as if anyone starts actually going through making these changes again, perhaps instead of a bulk commit, these could be done one flag at time in separate commits, and we maintain a running checklist of all the ones that need to be removed?  If it was done this way over time, nightlies could be used to possibly catch any bugs introduced by the individual flag replacements.  I suggest because while this is a huge task, it does seem like it can be done piecemeal effectively.

[Wanderer]

To clarify.

Retail ship classes have associated objecttypes properly defined in def_files.cpp - however what i referred to were the ships and stuff created by modders. They are not guaranteed to have an associated objecttype. This means in every instance where objecttype the validity of the associated objecttype has to be checked - as does the current code which does not (afaik, please correct me if i am wrong) require any ship class to actually be associated with an objecttype. Which is the reason why i suggested either making a requirement for every ship to have an associated objecttype - an option which might annoy modders. Or alternatively to make a dummy or default non-editable 'blank slate' objecttype to which every ship class would be associated by default - unless of course defined otherwise in the table (like all retail ship classes are) - such 'blank slate' objecttype should make it possible to have every ship class a guaranteed association to a objecttype even if none would have been defined in the ships.tbl.

Better ideas are welcome of course.

[Wanderer]

Anything?

[chief1983]

Well, I already weighed in here and followed up on IRC, but it sounds like this last concern might affect modders more than coders.  Maybe it should be posed in a more public area?

[Wanderer]

Well, I certainly won't object should the thread be moved to the public area.

[Goober5000]

It seems like the logical thing to do is provide a default objecttype for each of the retail ship classes.  Isn't that what the code already does?  That way you'd guarantee you'd have an objectttype, which is effectively point (1) in your first post.

And yes, I agree with chief that this should be done piecemeal.  Easier to review patches that way.

[Wanderer]

It seems like the logical thing to do is provide a default objecttype for each of the retail ship classes.  Isn't that what the code already does?  That way you'd guarantee you'd have an objectttype, which is effectively point (1) in your first post.

And yes, I agree with chief that this should be done piecemeal.  Easier to review patches that way.

Yes, every retail ship is guaranteed that. But not every ship the code handles. Because it does handle quite a few of non-retail ships as well. These are not guaranteed to be associated with an existing objecttype. Which means that every single reference to say Ship_types[sip->class_type] is potentially hazardous since code does not seem to be making sure that 'class_type' is actually set to non-default values (default being -1, which tends to be a rather bad choice when trying to reach into an array)

[chief1983]

Ok, so I went to refresh my memory on ships.tbl, and while you could have created new ship types in objecttypes.tbl before, this has never really been supported.  So really people have still been limited to modifying retail ship types right?  If that's the case, don't we just need a default object type specific for all retail ship types, which is what we have now, and then to see if anyone modified the object type in objecttypes.tbl for an existing ship type, we use that instead?  There are many non-retail ships, but to my knowledge they've all used retail ship types unless they really wanted to break things by trying to make a new ship type.  I could be wrong here but I thought we always said "don't make new ship types unless you want to make baby jesus cry."

[Wanderer]

AFAIK some mods wrote their own but I'm not sure if they were implemented properly or not. That however is besides the point. If they created new one then there would be a proper objecttypes.tbl entry for it and likely also a proper index value for accessing it. It might not work how any sane person would prefer it to work but it shouldn't crash the game. Issue is more related to ships without any objecttypes associated with it. From coding POV i really don't care if the objecttype that might be referred to would act like lobotomized patient but i would like to make sure that it would be impossible to use invalid value for accessing the arrays.

Also IIRC the instructions were at one point to issue two objecttypes - one which would refer to the user defined objecttype and another one which would define the 'SIF-type' - something like ( "gunship" "cruiser" ). I never tried that nor do i have any knowledge as to how it actually would have worked.

Addendum - even in retail data there already exists 'no type' objecttype. It however is not assigned by default and needs to be separately set. What i proposed was that any ship object without a valid objecttype (retail or user defined, i really don't care which one) would default to using the 'no type' definition which would be set - if possible - non-editable via tbms or the lot. So that regardless of what happens - custom objecttypes.tbl for example - there would always exist a valid default objecttype.

[chief1983]

That sounds like a good way to go then, it shouldn't hurt retail and I can't see any mods that were done in a sane manner being affected either.