Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

reaper with no name

  • Content count

  • Joined

  • Last visited

Posts posted by reaper with no name

  1. As I work more and more on maps, my experience with this glitch increases. I literally get it almost every day. There are several trends I've noticed about it:

    1) Size of the map may not be a factor, as I've seen the glitch with levels I've made that are smaller than those of the iwad.
    2) Switching Nodes Builders usually doesn't do jack (at least, not on it's own).
    3) For ZDoom (Doom in Hexen Format) maps, I find that switching the Nodes Builder to zdbsp and then hitting "reload resources" (under tools) SOMETIMES fixes the problem. This may be true for other formats as well, but ZDoom (Doom in Hexen Format) is what I use the most, and it's therefore where I've noticed this the most.
    4) Restarting one's computer SOMETIMES fixes it.

    Now, a couple of days ago I was trying to export a map I had completed. Not surprisingly, the nodes builder decided that was the perfect time to stop working properly. The normal strategies for dealing with this weren't helping. So while looking around at certain nodes builder profiles and seeing that some had the option of not building a reject map, I decided to try applying that same "-R" parameter to the export node builder profile. To my surprise, the export worked perfectly after that. The nodesbuilder and other parameters were not changed at all.

    Now, I may not be the most technically-oriented person here, but this result would seem to indicate that the source of this glitch is somehow related to whatever program/program-component builds the reject map. It's basic scientific methodology: Change one thing in a system and compare the resulting differences. Problem is, this glitch isn't limited to building the nodes for export (as I'm sure any who have encountered this error can testify to). Heck, I've come to EXPECT that every couple days or so I won't be able to use 3-D Editing Mode because the nodes builders refuse to work no matter what I do. Still, the reject thing could at least be a starting point for finding whatever the heck causes this glitch.

  2. Ok, now I've got another problem. I tried the whole "short texture with offsets" thing, and it got me some puzzling and frustrating results.

    Here's an image of what the sink looks like in 3d mode:


    I don't know how to take screenshots in-game, so I can't show you what what it looks like, but the area where there isn't a texture has an effect to it during gameplay that looks a lot like HOM (although I don't believe it is; because this one was static without any "flickering").

    Maybe I'm just doing this stuff all wrong all need to be walked through it step by step. At this point I'm willing to try just about anything.

  3. Didn't know you could do that. I was under the impression that if a texture didn't fit the area it was assigned to that it would "tile" to fill the area. Guess I was wrong.

    So, for clarification's sake, I just need to make a texture that is smaller than the area I'm going to use it with? And if the area is, say, 64 pixels high, I need to apply a texture that is less than 64 pixels high?

  4. Well, I'm trying to make a sink. You know, with a faucet and everything. Of course, as we all know a faucet juts out over the sink. And as we all also know, you can't have two things share the same z-coordinate (unless there's been some huge breakthrough that I don't know about). So, the way I decided to get around this was to make a texture where the top half was normal and the bottom half was transparent; that way it could give the illusion of a faucet over the sink. Problem is, it won't work. As I understand, cyan is the color that doom recognizes as transparent. So I made my texture's lower half cyan. But when I load up the map (or 3d mode, since I'm using doom builder), I just get these black and pinkish stripes where the transparency should be. Even if I copy the color directly from one of doom's normal transparent textures (such as a window), it still refuses to work. This is especially odd because I made a copy of one of doom's transparent textures and went through the normal motions of image importing (to make sure I was importing it correctly) and it's transparency effect worked fine. the exact same color it was using for the transparency was the color I was using for my half-transparent texture, so why the heck would it work for one and not the other?!

    I'm using paint and image analyzer for the image editing, and XWE for the importing, if it helps.

  5. I've seen this problem twice. Neither time was I running XWE (the first time it happened before I even downloaded XWE!). Both times it happened after I had been working on the maps for a long time, however. Perhaps it is related to the size of the map?

  6. A typical cajun bot looks like this:

            name		Samplebot
    	aiming		50
    	perfection	50
    	reaction	50
    	isp		50
    	color		"ff cf cf"
    	skin		base
    	weaponpref	468753201
    I know what all these values are for, but what I'm wondering is this:

    Does a high reaction value mean the bot reacts more quickly or less quickly?

    And by the same token, does a high isp value mean the bot retreats more often or less often?

  7. Yeah, I know there's a ton of other threads like this, but none of them have been any help to me. No matter how I fiddle around with the .ini file, Dehacked doesn't work properly.

    Whenever I run it, all the thing numbers are huge and seemingly random (likely a result of C/C++'s tendency to grab any number in the system whenever a variable is not declared) (see example here. Every single frame/sprite/sound name shows up as "error" (see the aforementioned example and this one. Also, the text in the "text" area makes no sense (see here. Needless to say, after writing my changes and running my doomhack (called doom2, whereas my original is called doom2org), I just get the original game. My config file seems to be fine (I know for a fact that the pathnames and such are correct). The only things I can think of in it that may be causing problems is the version number and/or all those "extra options" in the file that start out ignored via the # before them. However, I have played around with just about all of that to no avail.

    What follows is pretty much anything I can think of that could possibly be relevant:

    Running Windows XP (Service Pack 2)

    Doom2 File Size: 756 KB (775,117 bytes)

    Doom2 File Size on Disk: 760 KB (778,240 bytes)

    Doom2 directory: C:/doom2

    Dehacked directory: C:/doom2/dhe

    Dehacked version 3.1

    Doom2 version data
    Name=Doom 2

    [Version Info]

    [Product Info]
    ProductName=Doom 2

    My Dehacked Configuration Data
    # This is the DeHackEd v3.0a config file.
    # Lines that start with '#' are comments.

    # 'editname' is the name of the Doom exe file to hack. The 'normalname'
    # should be the name of your original (unmodified) Doom exe file. The
    # 'normalname' exe will NOT be modified by DeHackEd, but only referred
    # to at several times for pristine data.

    # For Ultimate DOOM
    editname = c:\doom2\doom2.exe
    normalname = c:\doom2\doom2org.exe

    # For DOOM ][
    # editname = g:\doom2\doom2.exe
    # normalname = g:\doom2\doom2org.exe

    # The name and location of your Doom WAD.
    wadname = c:\doom2\doom2.wad

    # For DOOM ][
    # wadname = c:\doom2\DOOM2.wad

    # The path to your Doom directory. This is where Doom will be run
    # from when you 'r'un Doom inside DeHackEd.
    # pathname = c:\doom2

    pathname = c:\doom2

    # Command line arguments when Doom is run from within DeHackEd.
    params = -skill 4 -warp 1

    # The directory to look for patch files in.
    patchdir = c:\doom2\dhe

    # Determines whether DeHackEd asks if you would like to reload the original
    # exe data every time you load a patch file. It is true by default, but
    # just remove the pound sign from the next line to turn it off.
    askatload = false

    # Whether or not DeHackEd shows the cool logo on startup. True by default,
    # just remove the pound sign to skip the logo.
    loadlogo = false

    # Options for soundblaster cards. sbaddress is the address of your card,
    # sbirq is the IRQ for the card, and sbdma is the DMA channel. Use a
    # DMA of -1 for auto-detect.
    #sbaddress = 220
    #sbirq = 5
    #sbdma = -1

    # Added by John K. for changing THING names
    # namefile = thing.nam

    # The following are all optional, and are included only in the hopes that
    # they might be used to fend off future Doom versions, if any more pop
    # up.

    # Doom version #
    # 0 for Doom 1 1.666
    # 1 for Doom 2 1.666
    # 2 for Doom 2 1.7, 1.7a
    # 3 for Doom x 1.9
    # 4 for Ultimate Doom 1.9
    # version = 2

    version = 0

    # The size of the user-defined Doom exe file.
    # size = 715493

    # These are the offsets for the various data sections...
    # thingoff = 677472
    # soundoff = 645924
    # frameoff = 650396
    # spriteoff = 649844
    # ammooff = 638872
    # weaponoff = 638904
    # textoff = 691064
    # cheatoff = 642244
    # textlength = 24072

    Any help would be greatly appreciated, because I'm practially tearing my hair out over this.