CJLERCH wrote:
Alright, so I've had this problem for a little over a year. The underground salt/rock textures have been screwing with Hammer, and now that I've developed the need for them, it's bothering me. Basically, they render in either red, green, or blur, depending on what axis they're on (this might be normal, I've no clue). Also, it becomes stretched horizontally, in addition to warping every OTHER texture the same way, as well. Any suggestions to fix this?

I think I know the textures to which you refer. Are you using them on brushes or displacements?

FelixGriffin wrote:
CJLERCH wrote:

Alright, so I've had this problem for a little over a year. The underground salt/rock textures have been screwing with Hammer, and now that I've developed the need for them, it's bothering me. Basically, they render in either red, green, or blur, depending on what axis they're on (this might be normal, I've no clue). Also, it becomes stretched horizontally, in addition to warping every OTHER texture the same way, as well. Any suggestions to fix this?

I think I know the textures to which you refer. Are you using them on brushes or displacements?

I've been using them on displacements. Is there a different texture to use or something?

For the viewport, use "textured polygons" instead of "textured shaded polygons"

Quick question. How to make gel blobs cast shadows? Like in the Valve Repulsion Gel Trailer #1.

I try to compile my map (early draft, not finished) and vbsp.exe stops working and the map does not compile. Does anyone know why that might be?

GameBurger wrote:
Quick question. How to make gel blobs cast shadows? Like in the Valve Repulsion Gel Trailer #1.

Try messing around with settings on this entity:

https://developer.valvesoftware.com/wiki/Shadow_control

Bump

Anyone know why/how to prevent Hammer from automagically inserting a dual Portal Device when I test my map? It doesn't do it with the full, uploaded beta maps, so I don't understand why it does it every single time I run the compiles straight from Hammer. If it's of any use, I always use the expert compiler with the exception of when optimizing (seeing visleaf changes as I change the map around).

You can't stop it giving the player a gun, but if you surround the spawn point/elevator with a trigger_weapon_strip set to Kill Weapons it'll destroy the portal gun before the player notices anything happened. If you want the player to have a single-portal device have outputs on the trigger_weapon_strip to Disable itself OnStartTouch, then trigger the "give_portalgun" console command via a point_servercommand (called @command in the global_ents instance if you have it).

CJLERCH wrote:
Anyone know why/how to prevent Hammer from automagically inserting a dual Portal Device when I test my map? It doesn't do it with the full, uploaded beta maps, so I don't understand why it does it every single time I run the compiles straight from Hammer. If it's of any use, I always use the expert compiler with the exception of when optimizing (seeing visleaf changes as I change the map around).

Well, if you mean that your player gets the gun automatically when he is put in the elevator, then I think that what can be causing that is your map name. There is a script managing that (sry I'm far from my computer now to search for it and let you know), and depending on how your map name starts by (sp_ / sp_a1 / sp_a2 / etc), the player will get a one-fire only gun, or the dual fire device. Remember when you played Portal2 and you started getting the primary fire only gun, and it's not until several chambers onwards that you get the dual fire one.

Hello!
I'd like to now if there's any separated model available on the internet for this circular piece of wall_dest models

PedroDeak wrote:
Hello!
I'd like to now if there's any separated model available on the internet for this circular piece of wall_dest models

In a different format? I don't think so, but you can try decompiling it and running the smd and exporting as a different file.

@PedroDeak: I don't think that there's an already existing model like that either, but a good workaround could be to edit that model's texture and create a custom texture with only that circle and the rusted plate, then use it on brushes that size. It won't be a model, but I think it could look good. The other option is to decompile that wall_dest model and edit it erasing the parts you don't need, then recompile again.

josepezdj wrote:
CJLERCH wrote:

Anyone know why/how to prevent Hammer from automagically inserting a dual Portal Device when I test my map? It doesn't do it with the full, uploaded beta maps, so I don't understand why it does it every single time I run the compiles straight from Hammer. If it's of any use, I always use the expert compiler with the exception of when optimizing (seeing visleaf changes as I change the map around).

Well, if you mean that your player gets the gun automatically when he is put in the elevator, then I think that what can be causing that is your map name. There is a script managing that (sry I'm far from my computer now to search for it and let you know), and depending on how your map name starts by (sp_ / sp_a1 / sp_a2 / etc), the player will get a one-fire only gun, or the dual fire device. Remember when you played Portal2 and you started getting the primary fire only gun, and it's not until several chambers onwards that you get the dual fire one.

Alright, thanks. But, do you happen to know the name of the script? The way I name stuff is definitely the cause (sp_cm_month_day_year), and I'd like to see if I can play around with it to make it so my maps (beginning in 'sp_cm') aren't given the portal gun.

No man, I don't remember its name. Give me a couple of days to arrive home and will tell you. However, off the top of my head I think that all map names starting by "sp_" will be given a dual device, except for those starting by "sp_a1" I think... Give it a try.

This is probably a simple problem to solve, but it's driving me crazy. I have a laser field and it works exactly the way it's supposed to, with the one exception that it's not visible. I have the right texture on either side of my trigger_hurt. I'm pretty sure there was an option to set the visibility when I first turned the nodraw brush into a trigger, but now that it exists, I can't find how to make it visible. Do I really need to delete the trigger and make a new one?

Lunch wrote:
This is probably a simple problem to solve, but it's driving me crazy. I have a laser field and it works exactly the way it's supposed to, with the one exception that it's not visible. I have the right texture on either side of my trigger_hurt. I'm pretty sure there was an option to set the visibility when I first turned the nodraw brush into a trigger, but now that it exists, I can't find how to make it visible. Do I really need to delete the trigger and make a new one?

for a laserfield you need a trigger_hurt brush (trigger) and a non-solid func_brush with the correct texture!

Lpfreaky90 wrote:
Lunch wrote:

This is probably a simple problem to solve, but it's driving me crazy. I have a laser field and it works exactly the way it's supposed to, with the one exception that it's not visible. I have the right texture on either side of my trigger_hurt. I'm pretty sure there was an option to set the visibility when I first turned the nodraw brush into a trigger, but now that it exists, I can't find how to make it visible. Do I really need to delete the trigger and make a new one?

for a laserfield you need a trigger_hurt brush (trigger) and a non-solid func_brush with the correct texture!

You're sure? I could have sworn I'd read that I can put the laserfield texture on the outside of the trigger brush. Thanks.

Triggers other than P2 fizzlers are never visible.

@CJLERCH: that script I was meaning is the "sp_transition_list.nut" (inside scripts/vscripts/transitions).

This is at the top of the code:

FIRST_MAP_WITH_GUN <- "sp_a1_intro4"
FIRST_MAP_WITH_UPGRADE_GUN <- "sp_a2_laser_intro"
FIRST_MAP_WITH_POTATO_GUN <- "sp_a3_speed_ramp"
LAST_PLAYTEST_MAP <- "sp_a4_finale4"

Then there is the following code (line 393 and below):

   DumpMapList()

   local portalGunCommand = ""
   local portalGunSecondCommand = ""
   local foundMap = false
   
   foreach (index, map in MapPlayOrder)
   {
      if (MapPlayOrder[index] == FIRST_MAP_WITH_GUN)
      {
         portalGunCommand = "give_portalgun"
      }      
      else if (MapPlayOrder[index] == FIRST_MAP_WITH_UPGRADE_GUN)
      {
         portalGunSecondCommand = "upgrade_portalgun"
      }
      else if (MapPlayOrder[index] == FIRST_MAP_WITH_POTATO_GUN)
      {
         portalGunSecondCommand = "upgrade_potatogun"
      }
      
      if (GetMapName() == MapPlayOrder[index])
      {
         break
      }
   }

   TryDisplayChapterTitle()
   
   if (portalGunCommand != "" && GetMapName() != "sp_a2_intro" && GetMapName() != "sp_a3_01" )
   {
      printl( "=======================Trying to run " + portalGunCommand )
      EntFire( "command", "Command", portalGunCommand, 0.0 )
      EntFire( "@command", "Command", portalGunCommand, 0.0 )
   }

   if (portalGunSecondCommand != "")
   {
      printl( "=======================Trying to run " + portalGunSecondCommand )
      EntFire( "command", "Command", portalGunSecondCommand, 0.1 )
      EntFire( "@command", "Command", portalGunSecondCommand, 0.1 )
   }
   
}

There is also a complete list of all maps in Portal2 in the script, and as that part of the code I posted above seems to say, depending on the map name you'll be given:

• a primary fire gun > from map "sp_a1_intro" to "sp_a2_laser_intro" (non inclusive)

• a dual fire gun > from "sp_a2_laser_intro" to "sp_a3_speed_ramp" (non inclusive)

• a potato gun > from "sp_a3_speed_ramp" onwards until "sp_a4_finale4"

However, since none of us are naming our maps like VALVe's :p, what happens then? there was an old post that Kennkong made on this topic, take a look here.

That was all I know.