Why St. Lucia Unchecks the "Relic" Objective

[grayman]

Professor: "Class, can anyone tell me why the Relic objective unchecks near the end of St. Lucia?"

 

Grayman: "Oooh-oooh! Pick me! Pick me!"

 

Professor: "Yes, Grayman?"

 

Grayman stands up. "Well, it's because when you leave the church, you pass through a trigger brush that targets a target_setobjective_state to uncheck objective 9. Here, I'll write it on the board."

 

Grayman strolls to the chalkboard and writes

 

target_setobjective_state:
obj_id1 = 9
obj_state = 0

 

Professor: "Hmmmm. And what does that have to do with losing the Relic objective? Is that objective 9?"

 

Grayman studies the board. "Oh, wait a minute. I left something out." Grayman scribbles on the board and adds:

 

obj_idN = 1

 

Professor: "And the Relic objective is objective 1?"

 

Grayman: "Yessir."

 

Stupid kid at back of classroom: "But N is not a number! The code should ignore it!"

 

Grayman: "That's what I thought until I read the code. It looks for any string that begins with "obj_id" and treats it as a valid spawnarg."

 

Class and Professor: "Aaaaaahhhh. So that's why the Relic objective gets unchecked."

 

Grayman returns to his seat, confident in the knowledge that he'll get an A in this class. And for extra credit, perhaps later he'll reveal that another target_setobjective_state that unchecks objective 10 also includes a nasty "obj_idN" spawnarg set to "1".

[grayman]

St. Lucia has three problematic entities using "obj_idN":

 

UNcheckEscape9

UNcheckEscape10

SetStatueDamagedObjective

 

The obj_idN spawnarg should be removed from each. The last one will give you the Relic when you damage the statue. So anyone who's bypassed the Relic will have the "got Relic" objective checked off. I doubt if anyone's reported this, because the player most likely has the Relic at this point.

 

The following forms of obj_id* appear in the existing missions:

 

obj_id[0|1|2|3|4|5|6|7|8|9|10|...]

 

obj_idN

 

obj_id

 

No other missions have problems in spite of the varied syntax.

 

 

[Serpentine]

So anyone who's bypassed the Relic will have the "got Relic" objective checked off. I doubt if anyone's reported this, because the player most likely has the Relic at this point.

 

A friend reported that to me, verbally a few days ago... I dont make such a good bugtracker irl.

 

If you've made the changes on a local copy just upload it somewhere and I/we can test and get an updated release sorted out?

[grayman]

A friend reported that to me, verbally a few days ago... I dont make such a good bugtracker irl.

 

Aha! Confirmation.

 

 

If you've made the changes on a local copy just upload it somewhere and I/we can test and get an updated release sorted out?

 

I haven't created/tested a corrected map.

[Tels]

I guess the "objd_idN" comes from the documentation, which often uses "...N" to refer to a spawnarg with an arbitrary suffix (which can be numeric, but also anything else). Somebody probably copied it by mistake?

[Fidcal]

Probably my fault. I think it was one I put in to show in the editor meaning for the user to change it. What I didn't know at that time was that it resolved to 0. But I was sure this had already been sorted out long ago and the map fixed. Possibly that was on the original demo and it crept back into this release.

 

I guess it's up to me to fix up because ultimately I will have to upload it anyway. I'll add it to my todo.

[LEGION]

Hmm, but recently there was on update for St.Lucia and there were no longer Objective-uncheckings. I finished that update mission.

But if you´re going to make an update: Please give the carpets finally the carpet-step-sound, that always bugs me.

Edited October 10, 2010 by LEGION

[grayman]

Hmm, but recently there was on update for St.Lucia and there were no longer Objective-uncheckings. I finished that update mission.

But if you´re going to make an update: Please give the carpets finally the carpet-step-sound, that always bugs me.

 

I totally missed that update.

 

If the relic objective bug was fixed in that update, I apologize for revisiting old history. I was being guided by issue #2391, which Fidcal filed three days ago.

 

I DL'ed v1.01 and indeed the obj_idN spawnflags are gone.

 

Why file #2391, then?

Edited October 10, 2010 by grayman

[LEGION]

Most likely Fidcal forgot about his own fixes! But considering where he tips his fingers in all the time...

 

note: I´m sure I got that phrase totally wrong, what I meant: He´s working so much with TDM, he shall be forgiven.

Edited October 10, 2010 by LEGION

[Fidcal]

I really can't remember. That was six months ago? If someone reported the problem more recently I added it to bugtracker. I think I said somewhere I thought this had been fixed but just not time to keep check. I'll mark the bugtracker resolved.