Console Command: Unfreeze

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: Console Command: Unfreeze

by Osiris Kalev » Mon Oct 23, 2006 11:36 pm

Just to let you know, one example of carrying a property over between maps is MassMouth 2. It carries over a 3/4 speed for the player between maps and keeps adding on, therefore slowing you down every level. It was playable at first, but after 10 levels or so, you run at an extremely slow rate.

by HotWax » Mon Oct 23, 2006 2:32 pm

Good point, and glad to hear it's being changed.

by Graf Zahl » Mon Oct 23, 2006 2:27 pm

I agree that this properties should be cleared when exiting a map. Let's hope I don't forget it. Just assuming that this is carried over won't work anyway. What if a map is started from the console?

by HotWax » Mon Oct 23, 2006 1:42 pm

While I agree with you, the potential that it could break existing WADs as a side-effect does exist.

On the other hand, changes have been implemented before that break functionality, so I guess this is up to the devs to decide if it's worth it.

I'm not sure about the behavior of the changemap command, but it wouldn't be too far-fetched to think it should run unload scripts. It's meant to act in every other way as if somebody hit an exit switch, right?

by Risen » Mon Oct 23, 2006 12:38 pm

In other words, any map that uses PROP_FROZEN should contian a script that runs at map unload to remove it, with the exception of maps that are specifically designed to start the next map frozen. But do unload scripts even run if the changemap command is used?

To me, it would seem more logical for this property to be cleared between maps, and the author can elcect to set it upon the next map's start. Is anyone aware of a mod where this property is intentionally used across maps?

by HotWax » Mon Oct 23, 2006 12:11 pm

/highly agree

If your friends are engaged in a coop or DM testing session to make sure the scripts work, enable sv_cheats. Otherwise, it should be disabled and any issues like the one you had before should be considered a script bug.

by Graf Zahl » Mon Oct 23, 2006 11:00 am

This is only there to counter PROP_FROZEN settings that get lost due to typical testing actions. It has no place whatsoever in regular gameplay.

by Enjay » Mon Oct 23, 2006 10:54 am

Then unfreezing would be a cheat and undesirable for players to have access to it. If the mapset has been made properly, and has subsequent maps, scripted steps should be made to ensure all players are unfrozen on entering the next map.

Personally, I'm not overly bothered about the command's status as a cheat, but it does seem to fit into the debug/cheat category more comfortably than being allowed as an open console command IMO.

by Risen » Mon Oct 23, 2006 10:38 am

Yes, but what about something similar in deathmatch? Someone could build turrets which toggle the frozen property while they are using them.

by Enjay » Mon Oct 23, 2006 10:30 am

If you trust your coop mates +sv_cheats 1 should do it. No?

by Risen » Mon Oct 23, 2006 10:16 am

Graf Zahl wrote:Done. I agree, this is needed when testing maps that freeze the player.
Only as a cheat? What about the scenario I proposed?

by edward850 » Sun Oct 22, 2006 3:18 am

yay, new cheat/debug command

by Graf Zahl » Sun Oct 22, 2006 3:04 am

Done. I agree, this is needed when testing maps that freeze the player.

by Doomguy0505 » Sun Oct 15, 2006 1:22 am

SetSelfProperty (Property) (Value)

by edward850 » Mon Oct 09, 2006 1:04 pm

what do you suggest then (I'm out of ideas)

Top