CON LIMITATIONS v1-01-2003 Release 1 © RTCM
Reaper_Man
|
CON LIMITATIONS v1-01-2003 Release 1 © RTCM
Reaper_Man
/!\ Attention: These FAQ's where written before the development of EDuke, many limits do not apply anymore. These CON FAQs was written because I believe that there is no one place where CON information can be found - from the
simplest ideas to the most complex effects. After the fall of Dukeworld and 3D Portal, a web-edition of the CON FAQ seems to have been lost, and that leaves Duke RTCM as the only other source of CON information. Though they do have information on CONs and how to edit them, I don't
believe that this information is easily understood by the newest of newbie's. Introduction |
Weapon Limits |
Player |
Counters & Variables As sad as it may be, there are large restraints on what we can and can't do with the CONs. It is impossible to list everything that is not possible through CONs, so this will just be a general-rule page.
The main thing people want to change with the CONs is the weapons. Unfortunately, there is absolutely no way to change what a gun shoots. But, though the use of the Inventory Theory as well as several other techniques, we are able to make it seem as if the player is shooting new/altered weapons. The first 3 weapons, excluding the boot, are all bullet-based weapons. These travel instantly when they are fired, so we can't edit or change the properties of a projectile. We can, however, change the effect they have on the world. Read the Weapons Coding page for more information on how to change the weapons.
One of the other main restrictions we as programmers have, is what we can use to tell what the player is doing. We have only 17 different player event primitives to ask what the player is doing, and even those are fairly vague. We have no way of telling what weapon the player has out, or even if he is shooting, no way to tell what direction he is facing, or whether he is looking up or down. The few things we are able to ask have a few problems with them. ifp phigher, for example, asks if the player is higher than the current actor. Trouble is, how much higher is he? If we wanted to have the actor move up toward the player, we have no way of knowing what angle or speed to move at in order to reach him correctly. In 1999, a project called Enhanced Duke was completed. It was made to allow CON programmers much more access to what the player is doing, and how they can react accordingly. I have yet to learn the eDuke language and syntax, but I will be sure to provide as much information about it as I can when I do learn it.
Information storage is another subject we have restraints on. The ability to ask something about the current environment and store information in-game about it is somewhat limited. The only way we have access to information is to use an inventory item as a counter, and have the game react according to the current value the inventory item(s) are at. Problem - In multiplayer, actors perform certain functions according to the nearest player. If you were to have an actor that changes the screen's color, only the player closest to the actor is effected. If it isn't obvious already, this creates massive problems for global effects, such as flashbangs and other multiple player-affecting effects. Another problem is that, for the most part, we have to give up that inventory item in order to keep the player from destroying CON-set values. With the exception of the BOOTS and the SCUBA GEAR, all of the items can be manually switched on and off. This would create cataclysmic problems if the inventory item was to be used as a global trigger. The only way to prevent the player from using the item is to ask him to not use the item, and change his configuration to exclude it. Of course, they don't always listen. Even the BOOTS and the SCUBA GEAR have their problems. They're my choice items to use since the player can't manually alter their values, but if they were to play a level with slime or lava, or go underwater, the item's values are dropped, and the effects are lost. The only way around this is to make sure no maps have underwater or damage-sectors, but that can make for some dull maps.
|