EDuke32 CON mod

[DeeperThought]

Clever. I would need to add to the actor code for each monster type telling them when to spawn the sprite. I guess they would spawn it when the bot is alive and within a certain distance from the monster. One nice side-effect of this is that the bot won't seek monsters that aren't executing code yet, which means it's less likely to get distracted by monsters that are behind walls, and it won't get the player into trouble by pressing ahead into areas with sleeping monsters. Live monsters would have to keep spawning the invisible sprites so that the bot would know their current location.

Your solution sounds good, but I think I will try a quick-and-dirty solution first. I can have the bot stand over the body of a dead monster and emit a short range blastradius -- enough to destroy the body but not enough to do anything else. Maybe I can make him do a little jump so it looks like he's stomping on it.

Edit: TerminX, I tried your solution but the game crashes when I try to implement it. eDuke says there is a CON parser error and to email my cons to you. In the log, the error line says:
fatal error: Default processing in parse(): 0, 22

I have the monsters spawning the invisible sprite every tick in which the holobot is alive. As a result, the game crashes the instant the holobot is spawned. I have tried two different tilenums for the invis sprite, one of them is CROSSHAIR, and the other is some random one I don't remember (but it wasn't a number being used for anything else that I know of). The actor code for the invisible sprite is simply:

useractor notenemy CROSSHAIR 0
cstat 32768
ifcount 2 killit

the line in the monster actor code that spawns the sprite is:

if ifvare holobotflag 1 spawn CROSSHAIR

[DeeperThought]

I've got a Holobot that works fairly well now, but there are still a few issues to work out. When you activate the Holobot (the inventory item formerly known as HoloDuke) Duke will throw the little HoloDuke statue. It bounces a couple of times, then it spawns the Holobot.

There is nothing holographic about the Holobot. It will attack any nearby enemies with the chain gun, running towards them as it does so. It can be hit and destroyed (in a big explosion), but enemies won't shoot at it deliberately. If there are no enemies around, the Holobot will follow you (stick to you like glue). As it runs, it will periodically jump, thus enabling it to get over some obstacles. It does get stuck in doorways sometimes, and it won't swim or jump out of water (all of which I will try to fix).

There is a problem where it will try to attack enemies that it can't reach (e.g. behind walls). If this happens, you can toggle the holobot's mode from "Auto" (the default mode) to "Follow" (where it ignores enemies and follows you) by pressing the action key. Toggle back again when you want it to attack.

I'll probably post my CONs with the new holobot in the next day or two.

Edit: I can't get the Holobot to jump the way I want him to. Here is the line that makes him jump as of now:

ifvare holocount 60 ifai HOLOBOTGO { ai HOLOJUMP setvar holocount 0 }

This makes him jump every 60 ticks (using my own counter).

BUT, if I use this line...

ifvare holocount 60 ifp phigher ifai HOLOBOTGO { ai HOLOJUMP setvar holocount 0 }

...then he never jumps, even when the player is higher. However, when the player is higher, he will periodically twitch, as if trying to jump. I have tried variations on this, including using the get actor/player commands to detect whether the player is higher instead of using ifp phigher and the result is the same.

[KillerBudgie]

I really like the modified CONS. But I find that the double-jump is a bit hard to utilize when you're in a pinch. But when double-jumping while you are using Steroids, you can jump to amazing heights. But if you miss you'll take some falling damage

[DeeperThought]

Originally Posted by KillerBudgie

I really like the modified CONS. But I find that the double-jump is a bit hard to utilize when you're in a pinch. But when double-jumping while you are using Steroids, you can jump to amazing heights. But if you miss you'll take some falling damage

There was a problem with double-jump being too picky about the timing, but I fixed it a few days ago. Are you sure you have the latest version?

[KillerBudgie]

Yeah, I do have your latest version. The one with a Jetpack mod, where you can smash into certain enemies by using "Boost Mode"

[DeeperThought]

OK, here is a new version that includes the Holobot. I've included a readme this time. Enjoy.

DTCONS.zip

[KillerBudgie]

Originally Posted by DeeperThought

OK, here is a new version that includes the Holobot. I've included a readme this time. Enjoy.

Attachment 4823

Hmm, Very nasty piece of work! It'd be good if it could shoot more than just the Chaingun Cannon and could learn to double-jump. But, it is very good DeeperThought!

(If you want to know what my avatar is. It is my cat: Marmy, staring at the camera! He is known to eat almost anything you put in front of him)

[DeeperThought]

Originally Posted by KillerBudgie

Hmm, Very nasty piece of work! It'd be good if it could shoot more than just the Chaingun Cannon and could learn to double-jump. But, it is very good DeeperThought!

(If you want to know what my avatar is. It is my cat: Marmy, staring at the camera! He is known to eat almost anything you put in front of him)

Cats make good avatars. I've used my cat as an avatar on another forum.

As for the bot: making him jump higher and giving him different attacks would be very easy. However, I have a whole list of problems that are harder to deal with

-He can't get through some doorways. I have no idea why, and I don't know how to fix it. I have determined that making him smaller doesn't help, nor does using a different sprite. Adding insult to injury, monsters can walk right through these doorways with no problem.

-He can't get out of water (that's why I made him self-destruct in water). This is also true of the monsters -- even monsters that can jump or move vertically, such as the jetpack troops, the lizardmen, and the newbeasts all get stuck in water.

-He won't shoot on the z-axis. To fix this I have to get him to calculate the angle to his target and then use zshoot.

-Monsters won't shoot at him. I have to add some code to each monster to fix this (although most of it can be in one state that each monster calls).

-He tries to attack monsters behind walls. Being able to detect walls is the first step in fixing this.

[KillerBudgie]

Originally Posted by DeeperThought
Cats make good avatars. I've used my cat as an avatar on another forum.

As for the bot: making him jump higher and giving him different attacks would be very easy. However, I have a whole list of problems that are harder to deal with

-He can't get through some doorways. I have no idea why, and I don't know how to fix it. I have determined that making him smaller doesn't help, nor does using a different sprite. Adding insult to injury, monsters can walk right through these doorways with no problem.

-He can't get out of water (that's why I made him self-destruct in water). This is also true of the monsters -- even monsters that can jump or move vertically, such as the jetpack troops, the lizardmen, and the newbeasts all get stuck in water.

-He won't shoot on the z-axis. To fix this I have to get him to calculate the angle to his target and then use zshoot.

-Monsters won't shoot at him. I have to add some code to each monster to fix this (although most of it can be in one state that each monster calls).

-He tries to attack monsters behind walls. Being able to detect walls is the first step in fixing this.!

Did you? What does the cat look like?... Damn it! I'm going off the subject, time for the reason why I was really on here:

Even masterpieces have their limits, but it'd be good to have an AI team-mate to fight with you! (Try completing the game on "Damn I'm Good"!)

[DeeperThought]

In my next update, Commanders will fire guided projectiles instead of RPGs. The guided projectiles are actually actors that move toward the player and explode when they get close. They can be destroyed in flight with a single shot from any weapon, but hitting them can be tricky (they tend to fly low, so ducking is helpful). I've got it working now, except that the fireballs refuse to change direction on the z axis more than once. Programming actors would be a lot easier if they just did what they were told

[TerminX]

I suspect that you may not be telling them right. Anyways, you are free to contact me via one of the IM accounts listed in my profile if you have any questions that aren't terribly time consuming.

[DeeperThought]

I am having a problem where my actors are not as tall as they are supposed to be. They LOOK tall enough, but the upper halves of their sprites do not block and cannot be hit by weapons. I can set cstat to block and be hit by weapons, but it only works on the lower half. Also, it does not seem to matter what sprite I use, or what sprite I start from when defining actions. I have confirmed that it is always the lower half of the sprite that is solid and it is relative to the sprite's size.

This is causing several problems. My holobot almost never dies, because shots go right through his upper half. The guided fireballs that I made for the commanders are too difficult for the player to hit. Worst of all, the personal forcebarrier that I am making will only block shots on the upper half of the players body (the forcebarrier is an actor that stays right in front of the player until it takes enough damage and gets destroyed).

[Usurper]

Are you doing any type of custom art? Adding things into the art files or using md2/md3/kvx models?

[DeeperThought]

Originally Posted by Usurper

Are you doing any type of custom art? Adding things into the art files or using md2/md3/kvx models?

No, none at all.

[TerminX]

The dimensions are those of the first sprite of the actor (i.e the one you defined the actor as).

[DeeperThought]

Originally Posted by TerminX

The dimensions are those of the first sprite of the actor (i.e the one you defined the actor as).

Yes, that was the problem! The proportions are determined by the sprite referred to in the definition, even if you use action to make it look like a different sprite. The trick is to find starting sprites that are the right size but are not already being used as actors.

[Usurper]

Originally Posted by TerminX

The dimensions are those of the first sprite of the actor (i.e the one you defined the actor as).

Shit, I never realized that.

[DeeperThought]

In order to do some geometrical calculations, it would be helpful to know a few things about ang. First, what is ang = 0 ? I mean, if an actor has ang 0 and it moves forward, is it moving in the positive direction on the y axis without moving on the x axis, or what? Second, what number in ang equals a full rotation? 360? I will try to find these things out for myself, but it will save a little time if someone can tell me.

[Usurper]

Check out a sprite in build or mapster. If the angle is 0, it's facing right on the map. Every 45 degrees is 512 build units. So straight down is 512, left is 1024, and straight up is 1536.

[DeeperThought]

Originally Posted by Usurper

Check out a sprite in build or mapster. If the angle is 0, it's facing right on the map. Every 45 degrees is 512 build units. So straight down is 512, left is 1024, and straight up is 1536.

Thanks. I can see that I cannot put off using a map editor much longer, if only to get information that I need for CON modding.

Ultimately, what I need is an equation. Given that the player is at coordinates x, y and facing angle a, I need to know the x, y coordinates of an object that is directly in front of the player at distance d.

[DeeperThought]

EDIT: I feel like a real dumbass now, but I seem to have fixed the one big problem (and possibly the second problem as well) simply by removing the unnecessary move command from the ai. I have no explanation as to why including a move command that did nothing would cause the problems I described. Oh well, I think writing all this down helped, because I don't think I would have tried that otherwise. I'm going to leave my long post here anyway, because I'm still hoping that someone has an explanation (but I'm not holding my breath).

I've made an actor that serves as a barrier between the player and monsters. It's transparent, but it absorbs shots until it takes a certain amount of damage and dies. The cool thing about it, though, is that when the player is firing, it lets the shots through (by temporarily changing the cstat value). To ensure that it is always in front of the player, it calculates where it should be every tick, then writes directly to the x y z coordinates in its sprite structure (thus "teleporting" it every tick). It is like a plexiglass shield that hovers in front of the player, absorbing damage but allowing the player to fire through it at monsters. In theory.

There are two problems. One: When facing certain directions in certain areas of certain maps (that is, most areas of most maps) it vanishes, only to return again when one moves back to a position in which it can appear. This usually happens even when it is not anywhere near any objects that might obstruct it. For example, flying in certain open areas in the first map of DC, it will suddently disappear. Once you go inside the White House, it is nowhere to be seen over 90% of the time. And there is nothing random about it; it will always disappear and reappear at the same places and angles. Moreover, I know that the barrier is not being killed because of the fact that it reappears when I go outside (if it were killed, then I would have to press the button that spawns it again). Also, when it disappears, it does not block shots. I cannot tell if it really is in the position it is supposed to be in but has somehow been rendered non-functional and invisible, or what (I need to add some debugging code, obviously). I have noticed that the places it disappears are places that tend to be more complex geometrically. Even the open areas in which it disappears are ones that are right across from buildings or other complex structures. I have tried changing its size to make it smaller, and it makes no difference. I have tried changing the distance from the player, all the way down to zero, and it makes no difference -- it still disappears and reappears in the same places.

The second problem: Sometimes it does not block shots like it is supposed to. The only time the cstat is changed to non-shootable is when the player is firing. The cstat change (and the change back to normal) are tied directly to a change in color palette -- it turns red when the player is firing, then it returns to blue afterwards. The problem is that sometimes it fails to block shots even when it is blue and the shots are fired directly at it.

PHP Code:

gamevar barrierflag 0 1 /* true when the barrier is set to be spawned by the player */
gamevar barrierup 0 1 /* true when the barrier is alive */
gamevar firing 0 1 /* true when player is firing a weapon */
gamevar openbarrier 0 1 /* stores the time at which the barrier was "opened" (i.e. made nonshootable) */

define BARRIER 1657

onevent EVENT_USEMEDKIT
    /* doesn't deduct points from medkit yet */
    getplayer[THISACTOR].last_extra temp
    ifvarg temp 99 ifvare barrierflag 0 ifvare barrierup 0
        {
        setvar barrierflag 1
        /* do other stuff */
        }

endevent

/* next line goes in the player actor code */

ifvare barrierflag 1 { spawn BARRIER sound TELEPORTER setvar barrierflag 0 }

action BARRIERON  0 1 1 1 5
move BMOVE 0
ai BARRIERFACE BARRIERON BMOVE faceplayer

useractor notenemy BARRIER 200
ifai 0 
    {
     spritepal 1 sizeat 64 32 ai BARRIERFACE  cstat 770  setvar barrierup 1
    } 
    

/* variables have all been declared earlier, obviously */
getplayer[THISACTOR].posz temp
getplayer[THISACTOR].posx x
getplayer[THISACTOR].posy y
getplayer[THISACTOR].ang angvar 

addvar temp 9000
setactor[THISACTOR].z temp /* if I don't do this it starts above the player */

/* this next code breaks the player's angle down into 16 categories and sets the location of the barrier accordingly -- it is just a placeholder for an equation that will set it precisely */

ifvarl angvar 128 addvar x 1024
else
ifvarl angvar 256 { addvar x 874 addvar y 533 }
else
ifvarl angvar 384 { addvar x 724 addvar y 724 }
else
ifvarl angvar 512 { addvar x 533 addvar y 874 }
else
ifvarl angvar 640 addvar y 1024
else
ifvarl angvar 768 { subvar x 533 addvar y 874 }
else
ifvarl angvar 896 { subvar x 724 addvar y 724 }
else
ifvarl angvar 1024 { subvar x 874 addvar y 533 }
else
ifvarl angvar 1152 subvar x 1024
else
ifvarl angvar 1280 { subvar x 874 subvar y 533 }
else
ifvarl angvar 1408 { subvar x 724 subvar y 724 }
else
ifvarl angvar 1536 { subvar x 533 subvar y 874 }
else
ifvarl angvar 1664 subvar y 1024
else
ifvarl angvar 1792 { addvar x 533 subvar y 874 }
else
ifvarl angvar 1920 { addvar x 724 subvar y 724 }
else { addvar x 874 subvar y 533 }

setactor[THISACTOR].x x
setactor[THISACTOR].y y


ifvare firing 1 /* if the player is firing */
    {
    getplayer[THISACTOR].player_par temp
    setvarvar tempb openbarrier
    addvar tempb 6 /* it will stay nonshootable for 6 ticks */
    ifvarvarg tempb temp {  cstat 515  spritepal 2 }
    else {  cstat 770  spritepal 1 setvar firing 0 }
    }

ifp pdead setvar barrierup 0
ifhitweapon ifdead { setvar barrierup 0 killit }

enda 


[DeeperThought]

This update (version .2) adds two new features. Commanders fire guided projectiles that can be destroyed in mid-air. For the player, I've added a forcebarrier that is activated by using 50% of a medkit while the player has full health. The forcebarrier absorbs incoming fire, but allows the player to shoot through it. More details in the readme.

I have not tested these features very much...please let me know about bugs or suggestions. In particular, I want to know if the barrier seems worth using, or if it seems overpowered. I am also curious as to the difficulty level of the new commander and whether his projectiles do strange things (e.g. get stuck in places).

DTCONS.zip

Edit: I made another small update that greatly improves the positioning of the forcebarrier.

Edit2: Found and fixed a fairly serious bug in which various flags were not being reset when a new level is started, which prevented the player from respawning a barrier if one was active at the end of the previous level, and other similar problems.

[The Commander]

What are you next plans DeeperThought?

[DeeperThought]

Originally Posted by The Commander

What are you next plans DeeperThought?

My next plans for the mod...

First I want to make sure that everything is working correctly. Do all the different "kill me" women spawn baby aliens? I need to crank up the probability for testing purposes and observe them all to find out. Does the forcebarrier work in combination with the boost mode smash monster power? Little things like that.

I want small to mid-sized monsters to be knocked backwards when hit by the shotgun at close range, and possibly stunned for a second as well.

I've been thinking about doing something with weapon vulnerability/invulnerability. Blue lizmen have been invulnerable to the freezer since the beginning, but maybe I could add more stuff like this. For example, the bosses could flash different colors, indicating vulnerability to different types of attacks (one color for bullets, another for explosives...)

I was thinking of adding a new kind of trooper, one that breaks apart into tiny troopers when it is killed. The tiny troopers would fly around you like insects.

[DeeperThought]

It finally dawned on me that by creating useractors I can greatly increase the inventory of spawnable effects. Since I'm not including any new graphics in my mod, the effects must all be based on the original tile sequences, but there is still a lot that can be done. For example, it was very easy to make a larger explosion. You can put the following code in your game.CON; then, if you replace "spawn EXPLOSION2" with "spawn BIGEXPLOSION" anywhere in the code of other actors, you will get the much bigger explosion whenever that code is executed.

define BIGEXPLOSION 1900 /* for reference, EXPLOSION2 is 1890 */

action BIGEXPLODE -10 29 1 1 4

ai BIGBLOWUP BIGEXPLODE

useractor notenemy BIGEXPLOSION TOUGH

ifai 0 { sizeat 128 128 ai BIGBLOWUP }
ifcount 42 killit
enda

I replaced the death explosion of the pig tank with BIGEXPLOSION (this made sense considering the huge blast radius of that explosion). I'm sure I'll find other uses for it.

I've also got a SMALLEXPLOSION, and I'm going to make a BIGSMOKE and some other stuff to spice things up. I suspect there are lot of tile sequences that could be made to look fresh with resizing, changes of color, transparency, etc. And of course, since these are actors, they can spawn other actors and do other cool stuff.

[Usurper]

I think you can simplify that a great deal.

define BIGEXPLOSION 1900 
action BIGEXPLODE -10 29 1 1 4

useractor notenemy BIGEXPLOSION 0 BIGEXPLODE
  sizeat 128 128
  ifactioncount 29 killit
enda

Since there are 29 frames, and you want to see each one once, using ifactioncount is the surest way to make sure your timing is right.

Plus, you can define the starting action in the useractor declaration without having to use ai at all. (You can have useractor <actortype> <name> <strength> <action> <move> <ai> all on the starting line, though the last 3 are optional.)

We used to actually recycle the EXPLOSION2 actor back in pre-EDuke32 days in order to create actors who ignored a sector's shade. Depending on what spawned EXPLOSION2, it would take on a different action or other properties. I don't miss having to do that at all.

[DeeperThought]

Originally Posted by Usurper

Since there are 29 frames, and you want to see each one once, using ifactioncount is the surest way to make sure your timing is right.

I see now. So actioncount is the number of animation frames of the current action that have been displayed, regardless of the delay between frames. Thanks for your help. I won't even pretend to understand your last paragraph, but it sounds like you had to do some pretty nasty stuff back in the day.

Using your code, I discovered that I had the number of frames wrong (I had been cutting it off before the end). Now I've got the frames right (it's actually 24), but it pauses for almost half a second on the last frame. Odd.

[Jblade]

What he means is that the EXPLOSION2 actor was the only actor who didn't automatically take on the shade of the sector it was in (like all other sprites do) so they could use it to create sprites that used their own shade values.

[Usurper]

Yeah, somewhere in my rambling there I forgot to mention that you should add the spritenoshade <tile> command somewhere in the cons for that actor.

[SS4_Gogeta]

>.< for some reason i can't play with your con mod. Eduke32 says it has errors in it

[DeeperThought]

Originally Posted by SS4_Gogeta

>.< for some reason i can't play with your con mod. Eduke32 says it has errors in it

Make sure you are using Eduke32 version 1.3.1 It will not work with 1.3.0

Let me know whether that works.

[nova10]

Originally Posted by DeeperThought

Make sure you are using Eduke32 version 1.3.1 It will not work with 1.3.0

Let me know whether that works.

Yes, you have to upgrade to the latest Eduke32 version. It worked for me

[SS4_Gogeta]

wow ok.... see i tried the eduke32 in the HRP (which was 1.3.0) BUT, i downloaded the latest version and it won't work even without the edited con files

[DeeperThought]

Originally Posted by SS4_Gogeta

wow ok.... see i tried the eduke32 in the HRP (which was 1.3.0) BUT, i downloaded the latest version and it won't work even without the edited con files

"it won't work" is a little vague. What exactly does it say in eduke32.log ?

I'm assuming you mean it won't run at all, not just that it won't use the hi-res graphics.

[The Commander]

Originally Posted by SS4_Gogeta

wow ok.... see i tried the eduke32 in the HRP (which was 1.3.0) BUT, i downloaded the latest version and it won't work even without the edited con files

Even if your using the HRP or not it should work with the latest version of eduke32. are you sure you installed it propley? like deeperThought said what does your log file say?

[SS4_Gogeta]

EDuke32 1.3.1-1 (Mar 14 2006 14:01:53)
Copyright (c) 1996, 2003 3D Realms Entertainment
Copyright (c) 2006 EDuke32 team

Compiling: GAME.CON (151190 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
Version 1.4+ CON files detected.

Compiled code size: 16207/65536 bytes
1900/11264 labels, 268/1024 variables
0 event definitions, 207 defined actors

Initialising Windows DirectX/GDI system interface
Loading OPENGL32.DLL
Initialising DirectDraw...
- Loading DDRAW.DLL
- Enumerating display devices
* Primary Display Driver
- Creating DirectDraw object
- Checking capabilities
Detecting video modes:
- 640x480 8-bit fullscreen
- 480x360 8-bit fullscreen
- 512x384 8-bit fullscreen
- 640x400 8-bit fullscreen
- 320x200 8-bit fullscreen
- 800x600 8-bit fullscreen
- 1024x768 8-bit fullscreen
- 1280x1024 8-bit fullscreen
- 320x240 8-bit fullscreen
- 400x300 8-bit fullscreen
- 640x480 16-bit fullscreen
- 640x480 32-bit fullscreen
- 320x200 16-bit fullscreen
- 320x240 16-bit fullscreen
- 400x300 16-bit fullscreen
- 480x360 16-bit fullscreen
- 512x384 16-bit fullscreen
- 640x400 16-bit fullscreen
- 800x600 16-bit fullscreen
- 1024x768 16-bit fullscreen
- 1280x1024 16-bit fullscreen
- 320x200 32-bit fullscreen
- 320x240 32-bit fullscreen
- 400x300 32-bit fullscreen
- 480x360 32-bit fullscreen
- 512x384 32-bit fullscreen
- 640x400 32-bit fullscreen
- 800x600 32-bit fullscreen
- 1024x768 32-bit fullscreen
- 1280x1024 32-bit fullscreen
- 1152x864 8-bit windowed
- 1024x768 8-bit windowed
- 800x600 8-bit windowed
- 640x480 8-bit windowed
- 640x400 8-bit windowed
- 512x384 8-bit windowed
- 480x360 8-bit windowed
- 400x300 8-bit windowed
- 320x240 8-bit windowed
- 320x200 8-bit windowed
- 1152x864 32-bit windowed
- 1024x768 32-bit windowed
- 800x600 32-bit windowed
- 640x480 32-bit windowed
- 640x400 32-bit windowed
- 512x384 32-bit windowed
- 480x360 32-bit windowed
- 400x300 32-bit windowed
- 320x240 32-bit windowed
- 320x200 32-bit windowed
Initialising DirectInput...
- Loading DINPUT.DLL
- Creating DirectInput object
- Enumerating attached input devices
* MOUSE: Mouse
* KEYBOARD: Keyboard
- Creating keyboard device
- Creating mouse device
Initialising mouse
CONTROL_Startup: Mouse Present
Initialising timer
Loading art header.
initcache(): Initialised with 33554432 bytes
Loading palette/lookups...
mmulti: This machine's IP is 192.168.1.4
RTS Manager Started.
Adding DUKE.RTS.
Using .RTS file: DUKE.RTS
Setting video mode 320x200 (8-bit fullscreen)
- Creating primary surface
- Getting back buffer
- Allocating offscreen buffer
- Creating palette
Uninitialising DirectDraw...
- Releasing palette
- Releasing back-buffer surface
- Releasing primary surface
- Freeing offscreen buffer

that's all it said. the HRP and eduke32 1.3.0 works fine normally, but see i put the newer version into my duke3d folder and all it did was show the eduke startup window then show a black screen like it's about to start running. then i hear the windows error sound then eduke just shutdown completely and windows didn't give me an error message <.>

[DeeperThought]

You're eDuke32 is quitting right after it sets the video mode and before it starts the sound. It's strange that it's trying

Setting video mode 320x200 (8-bit fullscreen)

If I were you, I would run setup.exe and configure the video and sound -- check to see if it is set to that extremely low resolution and change it to something reasonable if it is.

[TerminX]

There's some sort of crash issue with the 8 bit renderer that neither JonoF nor I have been able to figure out yet. The next version of EDuke32 defaults to the highest video mode supported out of the following list: 1024x768x32, 800x600x32, 640x480x16 and 320x240x8.

[DeeperThought]

The first thing that occurred to me was that maybe his card doesn't support 320 x 200. I mean, 200? I didn't even know that was possible.


I am posting another minor update.

-Most monsters will now shoot at the Holobot at least some of the time.

-Fixed a bug where a single activation of the medkit could both heal the player AND spawn the forcebarrier (that is, unless you managed to press the key for only 1/32 of a second!) Now it requires a separate activation.

-Added a big explosion; right now it is only used when a pig tank is destroyed (DukeNuke coming soon!)

-Forcebarrier now turns gray when it has less than 50 life left.

DTCONS.zip

[SS4_Gogeta]

well i just changed some things in the configuration, and it works great now. very cool con mod. *is gonna download the update when i get home*