Talk:Portal: Stay Inside/Pre-Reboot-Archive

From Valve Developer Community
< Talk:Portal: Stay Inside
Revision as of 17:53, 3 June 2009 by Remmiz (talk | contribs) (Mod Box Change)
Jump to: navigation, search

Mod Box Change

@ Remmiz: Thanks for the update with the mod box. Was there a change in the MediaWiki stuff that required the new box in order to correctly be listed in the catagory page or something? --GLaDOS 00:02, 4 June 2009 (UTC)

No, but now it's all the same template instead of 6 different ones. It's much easier to update and change now as you just need to modify the single template. Just doing my part in making the Wiki as Object Orientated as possible :) --Remmiz 00:53, 4 June 2009 (UTC)

In Need of Any Help?

Basically, just wondered if you wanted any help in mapping this. I have only just started mapping recently, but I have already got to grips with most things. Contact me here, or it would be preferred if you emailed me. At : [email protected] Thanks in advance, I look forward to hearing from you. Jumpinjax 09:31, 6 February 2009 (UTC)

"just started mapping recently". Maybe spend more time mapping, and then go onto actually making a Mod for that matter, as this is what has become of most Portal maps now days: 08:01, 8 February 2009 (UTC)

Thanks for the advice! Would it help if I showed any screenshots of my work? Also, me and a friend were working on a portal mod. But my friend pulled out after a few weeks. So that went down the drain... -- Jumpinjax 08:29, 8 February 2009 (UTC)



I've been having some problems with lighting lately. The models in my level aren't being lit correctly (WAY too bright) in-game. I think it has something to do with HDR; when I turn off HDR, the models are a little less bright, but it still doesn't look right. One thing I have noticed is that I've altered the textures on all the bright models--is that a factor? It also happens on a VALVe made map (the first background map from Portal; I haven't made a replacement yet). Some of the models (once again, ones with altered textures) are too bright. I've included a sample screenshot--PLEASE HELP!--GLaDOS 03:38, 22 February 2009 (UTC)

EDIT: I've removed the altered textures, and the lighting's back to normal. Probably a bug with the material/texture, and I'll keep playing with it, but any insights or suggestions are still very much appreciated. --GLaDOS 22:00, 22 February 2009 (UTC)

Weird lighting on models.

Level Change Issue

I'm not quite sure what's going on with this, but it's certainly irritating. The testchamber transitions in Portal: Stay Inside employ a simplified version of the elevator mechanic; there's no tracktrain just because I seem to have bad luck with those. Instead, I just have the elevator and door props remain stationary while a trigger_levelchange switches BSPs. I know that means it has to load between every testchamber, but it makes things a bit simpler. In any case, I've run into a problem. The trigger_levelchange operates perfectly; it switches between maps and keeps the player in the same location. However, it seems as though a few prop_dynamics (apparently random, as not all prop_dynamics in the map are included) transfer over between maps. This results in the player being trapped inside the elevator, as the doors from the previous level remain closed. I've noticed this in other projects, and I've come up with two workarounds: I can either A) name the prop_dynamics and use a logic_auto to manually "kill" them, or B) abandon the trigger_levelchange entirely and use a point_clientcommand with a "map <mapname here>" input. The first method is a bit awkward, and the second can disrupt the flow of things, especially if I need the player to return to a previous map. I can think of only one other method: to eliminate the door and elevator props in the second level so that the player would be inside the original "transfered over" props. This would, unfortunately, not solve the problem of the other props in the level being transferred over, and it would make any return impossible. Any workaround seems unnecessary, actually, because I would think that Valve would encounter this problem and solve it. Am I doing something wrong? Has anybody else encountered this problem? Finally, should I post this question on the trigger_levelchange talk page as well? Any thoughts would be greatly appreciated. Thanks! --GLaDOS 20:21, 3 April 2009 (UTC)

EDIT: Just for the record, it's not just prop_dynamics; apparently info_particle_systems are carried over too. Again, does anyone have ANY idea why this happens? I must be doing something wrong, because surely someone has run into this before. --GLaDOS