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

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? --WinstonSmith 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)

Ah, I see. Many thanks, and, by the way, your maps are brilliant. For the record, have you by chance looked at the level change problem further down the page? I don't know if you'd have any input on my situation, but any advice would certainly be a blessing. --WinstonSmith 01:42, 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: TWP.com--Gear 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)

Problems

Lighting

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!--WinstonSmith 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. --WinstonSmith 22:00, 22 February 2009 (UTC)

Weird lighting on models.

No idea if you've fixed this but it may be that you didn't preserve the proper alpha channel when resaving. --Omnicoder 19:05, 10 August 2010 (UTC)

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! --WinstonSmith 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. --WinstonSmith

You aren't using a trigger_transition at all, correct? That should be the only way that entities can transfer across the maps. If you aren't using that, there is no way that they can transfer and you probably have something wrong on the new map. --Remmiz 18:25, 4 June 2009 (UTC)

Nope, no trigger_transitions used. For the record, I compiled both maps in the Portal configuration as well as the mod config in Hammer. Same problem both times, so it isn't the code or anything. At this point, I'm considering just using a point_clientcommand with a map <mapname> input; it would solve the problem (although cheap and dirty) and work in conjunction with the fizzlers--for the testchambers at least-- but I hope I can solve this problem. At some point, maybe I'll rebuild the elevator chamber from scratch and see if it still fails to operate. What could be wrong with the new map? --WinstonSmith 23:15, 8 June 2009 (UTC)

Point_clientcommand transitions are bad because they make the screen go black. At the very least use changelevel instead of map. --Omnicoder 19:07, 10 August 2010 (UTC)

Wow, it's been a while since I checked this page. Actually, I should mention that the problem is fixed. I think. I'm working on reconstructing the elevator shaft, and I believe I know where I went wrong with the first changing. And yeah, the clientcommand is pretty rough; it's much better to construct a levelchange rig.--WinstonSmith 02:06, 15 August 2010 (UTC)