Jump to content
The Dark Mod Forums

Clip Textures on Entities - Functional? Best Choice for Frob Control?


Geep

Recommended Posts

Here's an interesting question. If you apply a clip texture, like monsterclip, to a non-brush entity, does it/should it act like a clip in-game? Certainly, DR filtering treats it as just like any other clip object.

This arose in the context of thinking about atdm:target_set_frobable, and whether mappers will need to deploy it "defensively" and more widely if the new 2.10-dev frob highlight default is not changed. There is no special texture for a target_set_frobable, and a clip texture is traditionally used. In the wiki "Containers, Chests, etc.", Fidcal said:

Quote

In addition, the above prefabs all have a atdm:target_set_frobable clip brush inside to disable frobbing of loot out of a locked chest. Strictly speaking the body and lid block this anyway but it has been known at certain angles and situations depending on the item size and position to accidentally frob an item out of a closed container. So I play it safe and include the atdm:target_set_frobable. Just drag out a brush to almost fill the interior, give it clip texture and right click in ortho grid view for menu and select 'create entity' and choose: atdm:target_set_frobable entity....

Giving target_set_frobable a standard clip texture if its not actually performing that clip function (which I don't know) is misleading. Maybe NoDraw would be a better choice? Of maybe it could benefit from its own custom texture, with text, say "Frob Control"?

Link to comment
Share on other sites

Monsterclip is a special case since it only has any effect if on a worldspawn brush. The other clips simply offer collision regardless of whether they're on brushes/patches/models.

Some entities such as setfrobable make those nonsolid so that they instead act as a way of detecting which entities are within a space. I wouldn't see a need to use a different texture for these entities since you can have as many as you want in your map without inadvertently affecting other things.

I do agree it's annoying that clip entities are treated the same way as ubiquitous worldspawn monsterclip by DR filters.

Link to comment
Share on other sites

Given what you said, here's what I gather would happen for a non-brush entity (like target_set_frobable) with the 3 most popular clip textures:

  • monsterclip -> no effect on player, AI, missiles, moveables MISLEADING TEXTURE, LOOKS LIKE IT BLOCKS AI IN DR
  • clip -> blocks player & AI, not missiles. BLOCKS PLAYER FROM ENTERING TRUNK IF USED WITHIN. IS THAT A BUG (makes frobbing contents harder) OR A FEATURE?
  • player -> blocks player, not AI, missiles

If target_set_frobable was expanded from its traditional use within chests and drawers, to be used as invisible walls to only block frobbing, then none of these sound ideal.

That's why I was considering NoDraw or a new Frob Control texture.

Link to comment
Share on other sites

31 minutes ago, Geep said:

If target_set_frobable was expanded from its traditional use within chests and drawers, to be used as invisible walls to only block frobbing, then none of these sound ideal.

I'm not aware of instances of target_setfrobable acting as an invisible wall. For example, what I did in Down by the Riverside to stop the player from carrying bodies on his shoulder into the next phase was to place a large target_setfrobable brush (textured with clip) in the room that fires the moment the teleportation is triggered, making everything in the room unfrobable. The brush didn't prevent entry to the room.

They can only control frobbing by being triggered when the player is in a position where he should/shouldn't be able to frob the items, by making all items within their volume frobable or not.

Link to comment
Share on other sites

What I imagined, and this might not be true, is that you wouldn't be able to frob through an (untriggered) target_set_frobable to something frobable on the other side.

What I am looking for an invisible shield to stop frobbing (and that would not itself highlight) but not block anything else.

Link to comment
Share on other sites

I've seen froblock entities, usually forming chest bodies. Maybe that's what was meant in the other thread with entities that block frobbing through them?

Link to comment
Share on other sites

The thing about "froblock", which I guess should be parsed as "frob lock" rather than "frob block", is that, in addition to having a lock, it is ordinarily frobable/highlightable. So it's not exactly what's needed either.

Link to comment
Share on other sites

At least when it comes to objects inside containers, it was always easier for me to just set them to hide 0 and use target links from openable element. Since the problem is with ignoring geometry when tracing frob entities, adding more geometry doesn't seem like a solution to me. Making objects invisible until container is open works every time.

Link to comment
Share on other sites

I'm more concerned with the situation where containers are not involved. Either the frob is happening through a wall where you don't want it to, or it's happening through a moveable where you don't want it to. I agree that adding more geometry isn't great as a solution, but setting up triggering to unhide an object in such cases seems like no fun either.

I'd rather have some spawnarg I could set on anything, say, "frobshield 1", that would render it impervious to frobbing of anything behind it that you can't see. Even if the 2.10 player had frob highlighting with depth turned on.

Link to comment
Share on other sites

  • 2 years later...

Slight necro...

 

What would be useful is a global surface parameter that allows frob to stick to non-solid, invisible surfaces. Then it would be possible to define a material like this:

textures/common/nodraw_frobable
{
	description		"used to make invisible, nonsolid brushes that nevertheless accepts frobs"

	qer_editorimage textures/common/nodraw_frobable.tga
	nonsolid
	noshadows
	allowfrob    //new global surface param
}

Then it would be child's play to do all sorts of useful things like:

* Make barred gates less irritating by painting the bars with it, so that you don't have to aim pixel-perfect at the visible geometry. Facing the gate, even looking between the bars, will do- and being non-solid you could still shoot projectiles through it.

* Less messing about with atdm:target_set_frobable brushes which, let's face it, are finicky and often don't work right. If you want to block a frob, just make a func_static out of the new nodraw_frobable material and then just trigger the func_tastic to remove the frob block.

* If you need a frobable shape for an object that differs significantly from its visible shape or collision surface, a frob_peer made of this would be perfect. Regular nodraw doesn't work, and the various clips are pretty gunky for this purpose.

My missions:           Stand-alone                                                      Duncan Lynch series                              

                                      Down and Out on Newford Road              the Factory Heist

                                                                                                  A House Call

                                                                                                  The House of deLisle                                                                                                  

                              

Link to comment
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.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...