Wouldn't this thread be better suited in the mapping section? Or at least a duplicate of it there as well.
[QUOTE=Ha3;29336894](2) { ***leaked*** message,
FindPortalSide errors,
"Entity <entity> leaked!" message,
Pointfile generated }
--> The -alldetail compile option is missing. Use the Compiler "Expert" mode button and check if "-alldetail" is present in VBSP settings.
If you have removed the "-alldetail" in purpose in hope to avoid world brushes being turned into func_detail, then there is an unknown issue about all this, because if you have the structure_seal 6-entity set up, it doesn't work either.[/QUOTE]
I've never run into this during my brief run with the Alien Swarm SDK. The error showed up once, but re-centering the leaking entity's origin fixed it. Granted, none of the small handful of maps I've compiled without -alldetail have been anything complicated, so perhaps that has something to do with it
Also, I'm sure there is a reason, but why use the alien swarm SDK instead of the hl2 one?
[QUOTE=Mr. Smartass;29336968]Also, I'm sure there is a reason, but why use the alien swarm SDK instead of the hl2 one?[/QUOTE]
The texture version is unsupported, I think. Loading it in hl2 hammer just crashes.
[QUOTE=Mr. Smartass;29336968]Also, I'm sure there is a reason, but why use the alien swarm SDK instead of the hl2 one?[/QUOTE]
If I remember correctly, it's due to the new version of VTF being used in Portal 2. I know the files refuse to load properly in Portal 1, so it's probably like that in all the Orange Box games.
[QUOTE=Kyo;29336954]I've never run into this during my brief run with the Alien Swarm SDK. The error showed up once, but re-centering the leaking entity's origin fixed it. Granted, none of the small handful of maps I've compiled without -alldetail have been anything complicated, so perhaps that has something to do with it[/QUOTE]
Well this is the one I'm not getting. The experiment I've went through was:
- A room with 6 walls, with textures not from Portal 2
- A player start
- A light
- A portal gun
I tried to compile without the -alldetail, and I got this particular case of errors (2). This is different from error (1). Then I was curious and added a structure_seal. It also error'd with error case (2).
Then I added the -alldetail again, while keeping the structure_seal, and it compiled nicely.
But it obviously does the effect I don't want (making the brushes non-paintable, plus the skybox thing).
I checked, and none of the three entities have had origin helpers. Compiling the same map (without structure_seal) with Orange Box engine did fine (since it didn't contain Portal 2 textures). The portal gun would just happen to be a unrecognized entity by the game engine anyways, not by the compiler.
[QUOTE=Ha3;29337114]Well this is the one I'm not getting. The experiment I've went through was:
- A room with 6 walls, with textures not from Portal 2
- A player start
- A light
- A portal gun
I tried to compile without the -alldetail, and I got this particular case of errors (2). This is different from error (1). Then I was curious and added a structure_seal. It also error'd with error case (2).
Then I added the -alldetail again, while keeping the structure_seal, and it compiled nicely.
But it obviously does the effect I don't want (making the brushes non-paintable, plus the skybox thing).
I checked, and none of the three entities have had origin helpers. Compiling the same map (without structure_seal) with Orange Box engine did fine (since it didn't contain Portal 2 textures). The portal gun would just happen to be a unrecognized entity by the game engine anyways, not by the compiler.[/QUOTE]
Odd. The map I had the issue with had
- info_player_start
- weapon_portalgun
- 2 prop_dynamics
- 1 trigger
- 1 clip brush
- 1 info_target
The trigger was the one that leaked, but like I said, re-centering it's origin fixed the issue.
Convert whole Portal 1 for Portal 2 as a co-op campaing.
Still requesting a tutorial on panels, and how to make them able to be applied portals to.
[QUOTE=Tovleman;29337702]Still requesting a tutorial on panels, and how to make them able to be applied portals to.[/QUOTE]
If you want panels without portal-able surfaces attached, it would just be a prop_dynamic with it being given the input to play animations. I imagine to get a portal-friendly surface on there you'd need to parent a func_brush to it. But I can't be sure, haven't played with it enough.
If you want to fix the way the Swarm SDK compiles things, then remove the "-alldetail" parameter in the advanced compile.
[editline]21st April 2011[/editline]
[QUOTE=Kyo;29337744]If you want panels without portal-able surfaces attached, it would just be a prop_dynamic with it being given the input to play animations. I imagine to get a portal-friendly surface on there you'd need to parent a func_brush to it. But I can't be sure, haven't played with it enough.[/QUOTE]
Where the panel finishes animating, place a func_brush textured with nodraw_portalable, and set it to disabled by default. When it finishes its animation, enable the func brush.
[QUOTE=Randdalf;29338193]If you want to fix the way the Swarm SDK compiles things, then remove the "-alldetail" parameter in the advanced compile.
[editline]21st April 2011[/editline]
Where the panel finishes animating, place a func_brush textured with nodraw_portalable, and set it to disabled by default. When it finishes its animation, enable the func brush.[/QUOTE]I love you
But I can't stick brushes *to* the arm?
[QUOTE=Tovleman;29338377]But I can't stick brushes *to* the arm?[/QUOTE]
Assuming your arm has a static finishing position, there's no need to. I don't think portals are allowed on moving surfaces.
Shouldn't they be possible now in the Portal 2 engine? Since now you can place portals in maps?
Though the Portal Gun may have the disability for Portals not to move as a design intentionally added, rather than engine limitations. But map portals should theoretically be moveable, right?
[QUOTE=Randdalf;29338519]Assuming your arm has a static finishing position, there's no need to. I don't think portals are allowed on moving surfaces.[/QUOTE]
There was a moving surface where you could place portals when you [sp]destroyed the neurotoxin factory[/sp]
[QUOTE=Randdalf;29338519]Assuming your arm has a static finishing position, there's no need to. I don't think portals are allowed on moving surfaces.[/QUOTE]
They are. Remember the part where you have to slice all the cables with a moving portal?
[QUOTE=Randdalf;29338519]Assuming your arm has a static finishing position, there's no need to. I don't think portals are allowed on moving surfaces.[/QUOTE]
But it looks so nice! And it's funny to experiment with the arms.
Also for the panels, when they have finished moving into position, give them a kill input and have a brush with the appropriate material spawn instead.
[QUOTE=Mr. Smartass;29338723]Also for the panels, when they have finished moving into position, give them a kill input and have a brush with the appropriate material spawn instead.[/QUOTE]
But how do I make a func_brush follow the movement of the arm in question?
[QUOTE=Simspelaaja;29338642]There was a moving surface where you could place portals when you [sp]destroyed the neurotoxin factory[/sp][/QUOTE]
I'm 99% sure that was some sort of trickery because there were a ton of other times that could have been utilized, but wasn't.
[QUOTE=NoFaTe;29324907]
Credits:
[b]- Whoever made that model renaming script[/b]
- The guy who made BSPSource
- Valve
[/quote]
I created the script originally for importing l4d1 models into Gmod. :P
I'm glad to see it's been useful for years !
[QUOTE=MasterG;29338835]Can this not be done with parenting?[/QUOTE]
No, it cannot. I tried everything. It just stays there and the arm moves RIGHT THROUGH IT!
[QUOTE=Tovleman;29338754]But how do I make a func_brush follow the movement of the arm in question?[/QUOTE]
Do all these steps:
- Make sure your prop_dynamic is in BindPose animation for calibration
- Pre-parent your brush to the arm prop_dynamic
- Create a logic_relay or a logic_auto that, when activated, does the following ONCE:
Let <relay> call your <brush> with input SetParentAttachmentMaintainOffset with parameter "panel_attach"
PS: Animation blending is weird. Make sure that animations never blend together by making the I/O of your arm perfect.
Blend: Calling a new animation while another non-idle is still playing
[QUOTE=Ha3;29339059]Do all these steps:
- Make sure your prop_dynamic is in BindPose animation for calibration
- Pre-parent your brush to the arm prop_dynamic
- Create a logic_relay or a logic_auto that, when activated, does the following ONCE:
Let <relay> call your <brush> with input SetParentAttachmentMaintainOffset with parameter "panel_attach"[/QUOTE]
I will report back if I did this right. Also, you are like a bare-butt saint sent from the heavens.
[QUOTE=PieClock;29338829]I'm 99% sure that was some sort of trickery because there were a ton of other times that could have been utilized, but wasn't.[/QUOTE]
There are other unusual tricks, like [sp]there was this part where you are about to be crushed by a dozen crushers, in this part it doesn't matter which portal you make to reach the safe rail; No matter whether you put the right or the wrong portal under your feet, you will be saved (the "wrong" would happen to lead you directly to the pit). The game seems to invert seamlessly the color of the portal on the safe rail if you happen to put the wrong one[/sp].
[img]http://cloud.steampowered.com/ugc/541766098683073018/471D3A8BF07032D103AB977FFD870E0683E9F692/[/img]
Got gels working :buddy:
[QUOTE=boomer678;29340712][img_thumb]http://cloud.steampowered.com/ugc/541766098683073018/471D3A8BF07032D103AB977FFD870E0683E9F692/[/img_thumb]
Got gels working :buddy:[/QUOTE]
:razz:
I love the test chamber textures.
Sorry, you need to Log In to post a reply to this thread.
