[The Commander]

Minor annoyance,
If I launch my mod with the "-server" command it goes straight into game so I can not set video modes etc. (I would like to use Polymer)
So I have to end up turning it on in the console.

[Lord Misfit]

TX, on Dec 3 2010, 01:50 AM, said:

Fixed in 1732.

Confirmed [so far]. Just got r1732 and see the fix. Thanks very much for the fix.

EDIT: Oh poo, I just remembered another bug [I think]: Toggling Caps Lock doesn't change the captialization/case of letters in the console like it used to [I know it worked back in r1599, but I don't know from which version it stopped working off hand]. I have to hold down shift to change captialization/case. This is annoying since I do a lot of debugging with the console version of "setvar" and "setactorvar" and because vars are case-sensitive.

Also, once again asking this on the subject. Is there a way it can be set that if you use sprite-style for the console display that you can do something [like color difference or shade difference, or something] to allow the person typing to tell uppercase letters from lowercase letters in that mode? It's still impossible to tell in sprite-style mode what letters are what case in the console. Until then I'm stuck using the basic style since it's the only one that uses lowercase or at least allows me to tell the difference. :\

[Hendricks266]

Lord Misfit, on Dec 3 2010, 02:33 AM, said:

Also, once again asking this on the subject. Is there a way it can be set that if you use sprite-style for the console display that you can do something [like color difference or shade difference, or something] to allow the person typing to tell uppercase letters from lowercase letters in that mode? It's still impossible to tell in sprite-style mode what letters are what case in the console. Until then I'm stuck using the basic style since it's the only one that uses lowercase or at least allows me to tell the difference. :\

The bluefont is actually capable of displaying capitalization if you modify the art. Take a look at TX's Project X mod to see how it's done.

[Lord Misfit]

EDIT: All dealt with now. TX told me what I needed to do anyways. From here on out NR will support the SW-style lowercase font in addition to the original uppercase font. o.o

[The Commander]

With the RTS files, using ALT+F4 brings up the game menu for me, all the other numbers work fine though.
I have not traced which version introduced this bug yet.

[dukedude]

If we're talking about Ubuntu here, I don't know if anyone's complained about this one yet. There seems to be a problem with the gun turrets where the turret will fire, but the shot just flashes. You can't shoot the turret, either, but for some reason, you can still kick it. There seems to be a similar deal going on with the protector drones' shrink rays-the ray will explode on top of the drone instead of being shot like it should be. Not having much familiarity with the Duke source code, I can't tell whether this is a paper cut or something that would require a major overhaul of EDuke32.

[Mike Norvak]

I hav a weird problem, eduke doesn´t work without HRP (autoload on) or at least takes long to start. I´m running with Eduke 1734 and Dukeplus. Any suggestion?

EDuke32 2.0.0devel 20100727
Application parameters: -game_dir DukePlus 
Using D:/EDUKE32/HOST-DUKEPLUS/ for game data
Using DukePlus/ for game data
Windows 7 (build 6.1.7600) w/ nedmalloc.dll
Initializing DirectDraw...
Searching for game data...
Using D:/EDUKE32/HOST-DUKEPLUS/DukePlus/ for game data
Using 'duke3d.grp' as main game data file.
Compiling: EDUKE.CON (36 bytes)
Including: DukePlus/dpcons/DUKEPLUS.CON (410671 bytes)
Using DEF file: dukeplus.def.
Wrote eduke32.cfg
Wrote settings.cfg
Using config file 'DukePlus/dp.cfg'.
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
Including: DukePlus/dpcons/DEFSPLUS.CON (54312 bytes)
Including: DukePlus/dpcons/USERPLUS.CON (58072 bytes)
Including: DukePlus/dpcons/LIGHTS.CON (26026 bytes)
DukePlus/dpcons/LIGHTS.CON: In state `paltoRGB':
DukePlus/dpcons/LIGHTS.CON:839: warning: duplicate case ignored.
Including: DukePlus/dukebike/DUKEBIKE.CON (87216 bytes)
Including: DukePlus/dpcons/HUDPLUS.CON (67030 bytes)
Including: DukePlus/dpcons/PLAYERPLUS.CON (125401 bytes)
Including: DukePlus/dpcons/MONSTERPLUS.CON (230388 bytes)
Found 1 warning(s), 0 error(s).
Resizing code buffer to 125624*4 bytes
Script compiled in 57ms, 125616*4b, version 1.4+
3011/11264 labels, 749/2048 variables
307 quotes, 46 strings, 40 events, 428 actors
Initialized 24.0M cache
Loading 'dukeplus.def'
Warning: Failed including duke3d.def on line dukeplus.def:1
Warning: Failed loading MD2/MD3 model "highres/sprites/characters/1405_duke.md3"
Warning: Failed loading MD2/MD3 model "highres/sprites/firstperson/2524_pistol.md3"
Warning: Failed loading MD2/MD3 model "highres/sprites/firstperson/2530_clip.md3"
Warning: Failed loading MD2/MD3 model "highres/sprites/firstperson/2532_cliphand.md3"
Definitions file 'dukeplus.def' loaded.
RTS file DUKE.RTS was not found
Initializing OSD...
Switching kb layout from 0000080A to 00020409
Initializing DirectInput...
  - Enumerating attached game controllers
  - No game controllers found
Uninitializing DirectInput...
Executing "DukePlus/dp_settings.cfg"
Executing "autoexec.cfg"
Disabling desktop composition...
Setting video mode 1152x864 (32-bit windowed)
Enabling ATI FBO color attachment workaround.
OpenGL Information:
 Version:  2.0.6747 Release
 Vendor:   ATI Technologies Inc.
 Renderer: ASUS X1550 Series   
Cache contains 995096253 bytes of garbage data
Initializing music...
Initializing sound...
 
Wrote DukePlus/dp.cfg
Wrote DukePlus/dp_settings.cfg
Uninitializing DirectDraw...

There's no crash log.

[Danukem]

Norvak, on Dec 15 2010, 07:09 PM, said:

I hav a weird problem, eduke doesn´t work without HRP (autoload on) or at least takes long to start. I´m running with Eduke 1734 and Dukeplus. Any suggestion?

I can't replicate that here. It will start with or without the HRP, with or without autoload checked.

[Chip]

Here's something that I would like to suggest as a small bug but I can't be sure if its really a bug or if I have somehow done something silly with my code but basically, htowner doesn't seem to always record the ID of the actor who fired the projectile.
In my code, my actor constantly checks for htextra and as soon as it becomes a positive value, the actor then checks the htowner tag but more oftern then I would like, the value comes back -1.

For example, last night, I (the player) was shooting one of my actors with the Pistol. It took 4 shots before that actor obtained a htowner value that matched the player's ID.

[Danukem]

Chip, on Dec 17 2010, 12:14 PM, said:

Here's something that I would like to suggest as a small bug but I can't be sure if its really a bug or if I have somehow done something silly with my code but basically, htowner doesn't seem to always record the ID of the actor who fired the projectile.
In my code, my actor constantly checks for htextra and as soon as it becomes a positive value, the actor then checks the htowner tag but more oftern then I would like, the value comes back -1.

For example, last night, I (the player) was shooting one of my actors with the Pistol. It took 4 shots before that actor obtained a htowner value that matched the player's ID.

If htpicnum is APLAYER, then you know it was the player and you can get the ID from player[THISACTOR].i

The only time that would be wrong is in multiplayer if the player doing the damage was not the closest one.

[LeoD]

Starting with svn1729 my self-compiled (tdm-gcc 4.5.1) EDuke bails out after the startup window:

(gdb) run
Starting program: c:\Programme\_No_Installer\Duke Nukem/eduke32.debug.exe -noautoload
[New Thread 3068.0x650]
nedmalloc: nedpfree() called with a block not created by nedmalloc!

Program exited with code 03.
(gdb) bt
(gdb) No stack.

Attached thumbnail(s)

• 

[Plagman]

It looks like parts of it are compiled with nedmalloc while other parts aren't. Have you tried cleaning with `make veryclean` and rebuilding from scratch?

[LeoD]

Plagman, on Dec 18 2010, 11:25 PM, said:

It looks like parts of it are compiled with nedmalloc while other parts aren't.

Btw, the working executables run with or without nedmalloc.dll hanging around in the EDuke directory (?).

Plagman, on Dec 18 2010, 11:25 PM, said:

Have you tried cleaning with `make veryclean` and rebuilding from scratch?

Yes.

I'll try to nail it down to a single source file.

[Plagman]

Yes, it's supposed to dynamically load nedmalloc.dll; if it fails, it falls back to a codepath that doesn't use it. However, I think synthesis binaries are built without nedmalloc support, loadable or not; it's possible something regressed that breaks nedmalloc support and no-one noticed because they get the most use.

[Plagman]

Ah, I think I understand. Can you confirm that rev 1737 fixes the problem for you?

[LeoD]

Confirmed when applied to svn1735. Thanx!
(Build flow is broken since svn1736, see Hendricks266' posting in the other thread)

[Helixhorned]

Norvak, on Dec 16 2010, 04:09 AM, said:

I hav a weird problem, eduke doesn´t work without HRP (autoload on) or at least takes long to start. I´m running with Eduke 1734 and Dukeplus. Any suggestion?

(...)
Cache contains 995096253 bytes of garbage data
(...)

There's no crash log.

With a gig of garbage data I could imagine that you can keep your PC working quite a while, especially since I found some N^2 code in its handling http://forums2.duke4...tyle_emoticons/default/tongue.gif.
So my suggestion would be to temporarily rename textures and textures.cache and see whether the problem disappears. Just out of curiosity, how big is your textures file and how many lines does textures.cache have?

[Helixhorned]

Actually, I believe it will already start misbehaving at a cache size of 2GiB due to use of signed 32-bit ints, so it's probably that.

[Mike Norvak]

Helixhorned, on Dec 19 2010, 05:53 PM, said:

With a gig of garbage data I could imagine that you can keep your PC working quite a while, especially since I found some N^2 code in its handling http://forums2.duke4...tyle_emoticons/default/tongue.gif.
So my suggestion would be to temporarily rename textures and textures.cache and see whether the problem disappears. Just out of curiosity, how big is your textures file and how many lines does textures.cache have?

WTF!!!!!! Look at the attached file

Anyways i made a new Eduke folder and install all from zero, it works. But why the texture files got that size?

[LeoD]

Bump.
"const char *s_buildDate" in global.c still says "20100727". Wouldn't it be a good idea to update that automatically during the compilation process so that it says something like "svn1752-20110104"? That might help a lot to identify the executable actually used when someone posts his eduke32.log.
In addition I think that adding the current configuration (files/variables) to the log should be helpful as well. I was about to report a weird bug yesterday when i finally noticed that the config file got messed up somehow.

[TerminX]

DeeperThought, on Oct 27 2010, 12:02 AM, said:

A few days ago I found what appears to be a CON compiler bug which prevented me from re-organizing my code in the way I wanted. I have reproduced the problem using a slightly modified version of the original CONs, which are attached.

What I did was I put most of the action, move, and ai definitions in a separate file instead of having them right before each actor.

So the top of GAME.CON looks like:

include DEFS.CON
include USER.CON
include ACTIONS.CON

The game crashes when it tries to compile ACTIONS.CON

Compiling: GAME.CON (139170 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
Including: ACTIONS.CON (12177 bytes)
Fatal Signal caught: SIGSEGV. Bailing out.
g_errorLineNum: 0, g_tw: 0

Uninitializing DirectDraw...

There is absolutely nothing in ACTION.CON that wasn't pasted from GAME.CON

Fixed in r1825.

LeoD, on Jan 7 2011, 09:33 AM, said:

Bump.
"const char *s_buildDate" in global.c still says "20100727". Wouldn't it be a good idea to update that automatically during the compilation process so that it says something like "svn1752-20110104"? That might help a lot to identify the executable actually used when someone posts his eduke32.log.
In addition I think that adding the current configuration (files/variables) to the log should be helpful as well. I was about to report a weird bug yesterday when i finally noticed that the config file got fucked up somehow.

Also fixed.

[Gambini]

Fire and Fire2 sprites are floating in the air until half second after you see them. This is an heritage from the original game but not by that it´s less annoying.

Octabrains mind-crusher projectiles get stuck in no actor sprites and do never dissapear neither stop their looping sound. This didn´t happen in the original game.

Decal sprites clip the walls in Polymer (hey doesnt seem to happen anymore!) it has to be fixed no more than a week ago.

Parallaxed fake "ror" seems to be improved in polymer (at least it works from one side) but it´s still broken.

The example map is included so it can serve as a test board.

Notice in the screenshots how the only renderer that shows that green thing as a plane-from bottom to top wall is Polymer.

Also, look how the octabrains are already dead and cold and their projectiles still fight to go across the sprites.

The fire screenshot is just to show how they float when the map starts.

I can make more example maps if it´s needed.

Attached thumbnail(s)

• 
• 
• 
• 
• 

Attached File(s)

•  Buuuugs_.rar (810bytes)
  Number of downloads: 251

[Danukem]

Gambini, on Mar 4 2011, 06:58 PM, said:

Fire and Fire2 sprites are floating in the air until half second after you see them. This is an heritage from the original game but not by that it´s less annoying.

Unfortunately, that appears to be due to this retarded CON code from the original game:

state firestate

  ifaction 0
	ifrnd 16
	{
	  action FIRE_FRAMES
	  cstator 128
	}

But you can start them already half-submerged (cstat 128), and then they won't move down. The animation will still delay a random length of time, though.

[bullerbullerseven]

The dude in the "wanted" sprite looks like my father when he were about 20 to 30 years old lol

[Hendricks266]

DeeperThought, on Mar 4 2011, 09:06 PM, said:

state firestate

  ifaction 0
	ifrnd 16
	{
	  action FIRE_FRAMES
	  cstator 128
	}

Damnit Todd!

[Danukem]

Actually I just realized the purpose of the randomization. They didn't want all the fire animations to be perfectly synchronized.

[TerminX]

Patching FIRE and FIRE2 to automatically display with cstat 128 before the code runs is no problem. I also just located the bug with COOLEXPLOSION1 so that will be fixed soon as well.

[Scott_AW]

How about keeping it from falling through objects? I've put a caldron ontop of a pillar, but the fire falls right through. I also don't have my barrels fall, because when stacked they fall through eachother. Know any way around this?

[Gambini]

Great!

There´s one last thing and i will stick my head into the sand again and wont bother anymore.

In duke3d.exe, jfduke, proasm port and ancient eduke32 versions this is how sky tile 79 "cloudyskies" look: (three first attachments)

And the last screenshot is how it looks now in Eduke32, no need of more than one screenshot because the problem is that the sky isnt animated.


I remember when it was introduced, about 2008 march. Because i complained about sky tile 94 being buggy in polymost, it had black strips all around. I don´t know what went wrong, but there must be a way to make both things work as before. The problem regarding #79 tile affects all renderers while the old problem with #94 tile affected polymost only.

Attached thumbnail(s)

• 
• 
• 
• 

[Gambini]

Scott_AW, on Mar 5 2011, 12:58 AM, said:

How about keeping it from falling through objects? I've put a caldron ontop of a pillar, but the fire falls right through. I also don't have my barrels fall, because when stacked they fall through eachother. Know any way around this?

Since your project is a mod, there must be lots of ways to fix those things (arent you the voxel mod guy?) but understand that making fire stand on sprites if it werent the original intention can screw up some old maps that make use of that. there´s always somebody taking advantage of these issues, so it´s not fair to resign the workability of their maps just to make modern mappers life easier.

I´m not the law, but i think we all have to be respectful with the original game and don´t mess with its stuff.