[TerminX]

That one is probably an unintentional side effect of making floor sprites act like they're the ground in situations where you have a sprite bridge or something above water. It's easy to fix like you mentioned, but there's probably a user map somewhere that relies on this functionality for something.

[Danukem]

TX, on 28 April 2011 - 12:26 PM, said:

I think the tripbombs have always been like that... otherwise in maps like E1L3 where stuff moves to reveal the bombs, the bombs would just blow up if they were armed before the effect was triggered.

Even if that's the case, the delay could be reduced significantly. I suppose I could try doing it with CON code, if I could figure out what to mess with.

[Gambini]

TX, on 28 April 2011 - 12:56 PM, said:

That one is probably an unintentional side effect of making floor sprites act like they're the ground in situations where you have a sprite bridge or something above water. It's easy to fix like you mentioned, but there's probably a user map somewhere that relies on this functionality for something.

Right, although unlike the "above water ground sprites" this is there from the beginning. I did never took "advantage" of this problem -for putting an example- but a few maps do (like having an underwater part that is not underwater). In any case, it is possible (and has been made before) to solve this problem by putting regular blocking sprites at the bottom of these relative to floor sprites.

[TerminX]

DeeperThought, on 28 April 2011 - 01:52 PM, said:

Even if that's the case, the delay could be reduced significantly. I suppose I could try doing it with CON code, if I could figure out what to mess with.

Altering delays for stuff like that is too close to changing how the gameplay works for my tastes.

[Danukem]

EDIT: I was wrong, the tripbombs are harmless and will not explode until the laser lines spawn, so reducing the delay would impact gameplay.

I may go ahead and change it for my own mods, though, since it doesn't make sense for the laser lines to spawn only after the player makes a visit.

[Forge]

Helixhorned, on 28 April 2011 - 12:43 PM, said:

I recently stumbled upon this strangeness: when underwater, floor-aligned sprites will make Duke behave as if on ground when he's over one. It's easy to fix but I haven't checked if it happened with Duke3D, and whether it served a purpose in that case.

I brought this up quite some time ago when I was making my last map. Zaxtor makes use of this effect in at least one of his maps, so "fixing" it will ruin his work.

If the floor aligned sprite is on the floor, then making it unblocking will not cause the problem. If it's an underwater bridge or scaffolding/balcony, then some simple sprite work can be used to overcome the problem.

[The Commander]

Helixhorned, on 28 April 2011 - 12:43 PM, said:

I recently stumbled upon this strangeness: when underwater, floor-aligned sprites will make Duke behave as if on ground when he's over one. It's easy to fix but I haven't checked if it happened with Duke3D, and whether it served a purpose in that case.

I read about this some time ago on this page.

http://infosuite.duk...rences_oddities

Also includes other odd happenings.

[MusicallyInspired]

I was playing Episode 4 today and noticed that sprites and models aren't mirrored when viewed through a mirror. Making it difficult to read the message in E4L2 in the bathroom. The boxes on the walls aren't mirrored either. Is this a known issue? I couldn't find it mentioned.

[Stabs]

Would it be possible to include a command line which allows me to set an autoexec.cfg, currently i can only set certain startup commands through the additional settings cfg that is created with the standard controls file,

so i need to have a preset bunch of 4 of them and you need rebind your controls each time, it would be much easier if i could just have 4 files with only the commands i needed to be able to be called upon at startup

[TerminX]

I don't understand what you're asking. Support for autoexec.cfg has been in there for years.

[Stabs]

TX, on 07 May 2011 - 10:03 PM, said:

I don't understand what you're asking. Support for autoexec.cfg has been in there for years.

well i want to define a specific autoexec, right now i only have -cfg which makes a whole new set of cfgs, for controls and gfx settings

now i have 4 different sets of gfx options i could run through autoexec, but i need to define these files in the eduke command line, so i suppoed

-cfga - specifys autoexec.cfg name to use

ive tried setting the name as low_autoexec.cfg but it just makes a whole new set of controls and settings under that name

[Danukem]

I just wrote another 3 posts in order to help someone use the HRP, and it turned out to be the old autoload checkbox not showing because the font size was > normal in Windows issue. This comes up a few times a month in the forums, not to mention there may be people who give up without posting. Seems like fixing it should be fairly high priority.

[MusicallyInspired]

I thought we were doing away with the autoload thing altogether at some point?

[Danukem]

MusicallyInspired, on 09 May 2011 - 03:58 PM, said:

I thought we were doing away with the autoload thing altogether at some point?

Apparently, the latest HRP installer puts the files in autoload, so we are a LONG way from getting rid of it. Like a lot of things in life, it's fine if used properly.

[SolidSnake2017]

Don't know if its been addressed, but with the newest HRP/eduke, weapon animations are really choppy, out of sync with rest of the game since I get 60fps fine in polymer.

[MusicallyInspired]

I could never figure out how the autoload folder works correctly what with the DUKE4D.GRP folder inside it and all. I just use custom folders for Polymer and Polymost.

[The Commander]

The DUKE3D.GRP should be in the same folder as the eduke32.exe files.
If there is some folder called "DUKE3D.GRP" then that one is new to me.

The only thing I would put in the AUTOLOAD folder (even though it should not be used now) is the HRP.zip's

[Skulldog]

The Commander, on 09 May 2011 - 09:45 PM, said:

The DUKE3D.GRP should be in the same folder as the eduke32.exe files.
If there is some folder called "DUKE3D.GRP" then that one is new to me.

The only thing I would put in the AUTOLOAD folder (even though it should not be used now) is the HRP.zip's

That Duke3d.grp folder gets created in the autoload when you use the Old Hrp install file.

[MusicallyInspired]

Yeah, what Skulldog said. I don't even have ZIPs right now. Everything is unzipped. Do the ZIPs happen to work in custom folders? Or only in the autoload folder?

[Hank]

MusicallyInspired, on 10 May 2011 - 12:43 PM, said:

Yeah, what Skulldog said. I don't even have ZIPs right now. Everything is unzipped. Do the ZIPs happen to work in custom folders? Or only in the autoload folder?

The zips work in my folder, custom. (I use PeaZip, a simple and free zipper). With all those tiles and sounds, it's cleaner then all those folders, and those tiles are a lot of work, I don't want anyone getting any ideas - methinks.

[TerminX]

DeeperThought, on 09 May 2011 - 01:42 PM, said:

I just wrote another 3 posts in order to help someone use the HRP, and it turned out to be the old autoload checkbox not showing because the font size was > normal in Windows issue. This comes up a few times a month in the forums, not to mention there may be people who give up without posting. Seems like fixing it should be fairly high priority.

I'm not really sure how to go about fixing it, honestly. I don't know enough about GUI programming on Windows to know what to change to take the font size into account when sizing the window.

[trencheel303]

DeeperThought, on 02 November 2010 - 04:23 PM, said:

I don't know how it slipped my mind until now, but I was playing today and it happened again. Sometimes when you throw a pipebomb and it bounces off of something, it goes into a permanent moving state, in which it slides slowly but does not flip from side to side. In this state it cannot be picked up but you can still detonate it. It happens most often when throwing one into a room from a crawlspace (like the one in in the stripper bar of E1L2). It's very annoying because the pipebomb usually bounces back into the crawl space with you, and since you can't pick it up you have to give up on using pipebombs since using it would be suicide.

I get this as well, and it happens particularly bad in vents.

DeeperThought, on 28 April 2011 - 12:10 PM, said:

Sleepy tripbomb laser lines: I'm not sure when this started, but I'm pretty sure it wasn't always like this. When you walk into an area with tripbombs, it takes a while for the laser lines to spawn. They seem to wake up like actors, waiting until they have a line of sight to the player for a second or so. As a result, you can get killed because the tripbombs explode as you walk past and there are no lasers yet to warn you. The lasers should be spawned when the level starts.

Inappropriate squishing: This one has been around since 1996, but that doesn't make it any less annoying. It's pretty funny when the player gets squished by opening a swing door. I know by now to get the hell out of the way when opening a door towards myself to get into a bathroom or whatever, lest my bloody jibs go flying in every direction (although most of the time the door will merely stop or push the player aside). What really bothers me are the times when I squish myself by just walking forward into an area where the z gap becomes smaller. Simply put: it should not be possible for the player to squish himself without some outside help. The only times the player should get squished are when he is growing back up to regular size from being shrunk, or in situations that involve moving sectors (and by "moving", I mean either horizontally or vertically). EDIT: The one exception to that rule would be when the player touches a sky wall (i.e. a wall that looks parallaxed), but in that case the player is moving into a sector where the floor and ceiling have the same height. We can make an exception for that and still fix the annoying problem.

trip bombs have always done that. The one at the end of the corridor just after the blue key door in E1L4 *still* catches me out sometimes.

As for your second paragraph, yes. Inappropriate squishing due to bugs in the original engine are exactly the kind of thing I'd like to see fixed. The sewer in E1L2 and in Freeway are notorious for this.

[TheCycoONE]

TX, on 11 May 2011 - 09:20 AM, said:

I'm not really sure how to go about fixing it, honestly. I don't know enough about GUI programming on Windows to know what to change to take the font size into account when sizing the window.

I'm not looking at the source right now to know if it's appropriate but: http://msdn.microsof...v=vs.85%29.aspx is probably something like what you need. Otherwise specify the font yourself and let user preference be damned.

[themaniacboy]

Is it also possible to fix the ati-related graphics problem ?
You know, the white squares problem.

The crosshair is a white square, the text are white squares.
The solutions given to me are not working, only rolling back, but that sucks because i miss all the fixes.

[TerminX]

themaniacboy, on 12 May 2011 - 01:17 PM, said:

Is it also possible to fix the ati-related graphics problem ?
You know, the white squares problem.

The crosshair is a white square, the text are white squares.
The solutions given to me are not working, only rolling back, but that sucks because i miss all the fixes.

That was fixed a couple of months ago.

[Gambini]

Quote

Microsoft is conducting an online survey to understand your opinion of the MSDN Web site.

lol I didn´t know Microsoft and Mikko Sandt were working so closely.

[Helixhorned]

Rockets don't pass through teleporting water. This was introduced in r1500...

[XThX2]

Make a little slow ceiling door in mapster, give it's MusicSFX actor lotag and hitag (open and finish sounds). Try to open the door. Looks fine. Do it fast, press open quickly a few times and it's sounds go crazy. (Finish sound gets swapped with open sound etc... weird thing. Don't really know how to explain this one)

[Gambini]

Wasn´t that like that from the beginning? Same happens with SE 8 (open door lights) and that´s old as Duke.

[TerminX]

Helixhorned, on 13 May 2011 - 03:02 AM, said:

Rockets don't pass through teleporting water. This was introduced in r1500...

Eh? r1500 is one of your commits and doesn't change anything in game land that I can see...