Jump to content
The Dark Mod Forums
Sign in to follow this  
Sotha

Beleaguered Fence broken due to TDM change

Recommended Posts

This is a bug report, but spoilerified for those who have not player Beleaguered yet.

 

 

The tunnel, below the cell block, with the bodies, with "Guardians", the two statues who have torches.

 

Until recently, the player lit the torches to get in the crypt. This does not work anymore: lighting the torches no longer open the doors.

 

The system works like this: the torch lights target the unfrobable doors. Switching the torch light on/off with a flame opened and closed the doors.

 

So it would seem like extinguishable light targetting something else do not work anymore.

 

Looks like a tdm change has broken something and most likely this applies to all maps with extinguishable lights targeting something. Anyone know any such maps, maybe they should be tested as well?

 

 

 

:(


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

This sounds serious, please add an entry on the tracker with severity "Major" and/or high prio, I'll have a look.

Share this post


Link to post
Share on other sites

There are/were changes to the extinguishable lights that target entities, but the changes were so that things now work, instead of being broken. It sounds serious that this breaks this map, I'll have a look, too.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Doh'! *slaps himself with a wet trout*

 

Of course! The new code does a lot of complicated things to make lights work, but I do not see anything that would work with a door! I guess "On()" on a FrobmoverDoor does not open/close. I'll be on it.

 

Tracked: http://bugs.angua.at/view.php?id=2676

 

And fixed in SVN with revision #11736 including 3 testcases (a rotating door, a sliding door, and a button on the wall, which is linked to a light).

 

@Greebo: The entire fix is two lines in script/tdm_light_holder.script, so I guess if we want to push this out, we could just update our tdm_base01.pk4?


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

I'll be on it.

 

I am assuming I do not need to do the bugreport then.:D


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

I am assuming I do not need to do the bugreport then.:D

 

It's already fixed :) Sorry for the inconvience.

 

One thing I had trouble with is that it is seemingly impossible from a script to figure out what the entity in question is. For Lights, you'd need to call On/Off, but for BinaryFrobMovers you need to call Open/Close and I have no idea which one to use. Luckily, calling both at the same time Just Works[tm].

 

The other, more complicated fix would have been to give BinaryFrobMovers the two scripting events On() and Off() and redirect them to Open()/Close(). Luckily, this is not nec, as it would mean a code change (opposed to a simple script change).


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

It's already fixed :) Sorry for the inconvience.

 

One thing I had trouble with is that it is seemingly impossible from a script to figure out what the entity in question is. For Lights, you'd need to call On/Off, but for BinaryFrobMovers you need to call Open/Close and I have no idea which one to use. Luckily, calling both at the same time Just Works[tm].

 

The other, more complicated fix would have been to give BinaryFrobMovers the two scripting events On() and Off() and redirect them to Open()/Close(). Luckily, this is not nec, as it would mean a code change (opposed to a simple script change).

 

Nice. Does this mean that Beleaguered Fence is broken until the next patch or is there a possibility to somehow auto-patch this critical issue only?


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

Nice. Does this mean that Beleaguered Fence is broken until the next patch or is there a possibility to somehow auto-patch this critical issue only?

 

As I wrote above, it is a two-lines change in script/tdm_light_holder.script, and we should be able to push out just this file (respectively tdm_base01.pk4). I think it would be better if greebo handles this (as he has access to the mirrors and whatnot), but I can build a fixed tdm_base01.pk4 file for you if this helps.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

The reason was the removal of the activateTargets( self ); call. I see that there were problems with that, but I guess setting up a proxy script function should do the trick?

 

Instead of:

 

tdm_light_holder::toggle_child =>

 

call a pseudo-virtual script function:

 

tdm_light_holder::toggle_child =>

 

Something like this:

 

thread callGlobalFunction( child.getString("light_holder_activated_script"), child );

 

Lights have a "light_holder_activated_script" pointing to a global function turning lights on or off, binaryfrobmovers have open() and close() in their implementation. It's working pretty similar as the "frob_action_script" spawnarg. And more importantly, the default function for light_holder_activated_script would just call activateTargets(), restoring the standard behaviour as it was before the breaking change.

 

(And the one method in tdm_light_holder should be called toggle_children, not toggle_childs, shouldn't it?)

Share this post


Link to post
Share on other sites

The reason was the removal of the activateTargets( self ); call. I see that there were problems with that, but I guess setting up a proxy script function should do the trick?

 

Instead of:

 

tdm_light_holder::toggle_child => <call specific implementation like child.Off() child.Open(), etc.>

 

call a pseudo-virtual script function:

 

tdm_light_holder::toggle_child => <call function as defined in child's def which contains the specifics>

 

Something like this:

 

thread callGlobalFunction( child.getString("light_holder_activated_script"), child );

 

Lights have a "light_holder_activated_script" pointing to a global function turning lights on or off, binaryfrobmovers have open() and close() in their implementation. It's working pretty similar as the "frob_action_script" spawnarg. And more importantly, the default function for light_holder_activated_script would just call activateTargets(), restoring the standard behaviour as it was before the breaking change.

 

The problem with "activateTargets()" is that it is different from On/Off, it always toggles, that is not what the light holder entities are supposed to do, they are supposed to turn things on/off in sync. E.g. if you turn off a light that is supposed to open something when lit, it should close/deactivate it when off. Unfortunately, there is only Activate(), no Deactivate(), and what Activate() does is wildly different for each class :/

 

As for the proxy function, I think it might work, but it would also complicate the setup quite a bit, and not gain us much (as it already works now). You'd also suddenly need to set the spawnarg on all entities pointing to the right function. Plus, it calls yet-another-script function, which then calls the same event.

 

So I am not sure we need to go down this route. The only case I can see is another entity class which has it differently (e.g. has no On()/Off() events and no Open/Close events). But do we do have such a case?

 

Edit: Implementing the check/call for such a spawnarg might still be a good idea, so the mapper could create custom entities that do something different altogether. However, it is already possible to simply insert a target_callfunction entity, and have that just call the function, and skip the entire On/Off thing completely. Or at least it should be possible, I have to test it.

 

(And the one method in tdm_light_holder should be called toggle_children, not toggle_childs, shouldn't it?)

 

Er, yes. Changed it. :blush:


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...