[TerminX]

Well, it's not specifically that tile, but an offset from MAXTILES.

[Fox]

What minus 2,053 stands for?

[Fox]

Is it possible to return the flags of the current "definegametype" in a gamevar? I realized how lame it is to use "ifvare COOP" to check for the game type.

[NightFright]

Hendricks266, on 31 March 2013 - 01:41 PM, said:

Ah, crap.

Steam\SteamApps\common\Duke Nukem 3D\gameroot\classic\DEFS.CON
Steam\SteamApps\common\Duke Nukem 3D\gameroot\classic\GAME.CON
Steam\SteamApps\common\Duke Nukem 3D\gameroot\classic\USER.CON

TerminX, it looks like we've hit another issue. Perhaps instead of adding the directory, we should just copy DUKE3D.GRP and DUKE.RTS as Plagman suggested.

Seems TX has addressed this issue with rev. 3637. Now Eduke32 is just using the grp files from the Steam directories. Great stuff!

[Stabs]

helix can you add another default command to the a.m32 like a headlight for working in darker areas, alt+num2 turns a point light on in the players position that follows you with about a 2000 radius at 255 255 255, its kinda like playing minecraft mapping in the dark, and i know i could dick with the r_shadescale but then its going to looking different in the game, and this would be a really nice feature I think more than myself would use if possible.

I carry around SE's with me like candles exploring ancient tombs, and sometimes they end up clipping through walls and they never return which is another bother.

Also i noticed PALs on walls were not updating correctly in 3d mode rendermode 4 untill you slightly changed a texture.

Liztroops will not jet pack through ROR levels either, but that has probably already been brought up and if it could of been fixed it if it could be.

[Fox]

That's a problem with Liztroop code which checks for the height of the current sector:

    ifp phigher
    {
      ifceilingdistl 128 nullop
      else
        ifactornotstayput
          ai AITROOPJETPACK
      break
    }

I don't think there really is anything that can be done without changing the original CON.

[TerminX]

That's an interesting issue. Would making those original ifceilingdistl/iffloordistl commands TROR-aware break anything?

[Diaz]

Probably not. It wouldn't break anything for me, let's see what other mappers who use TROR have to say.

[Helixhorned]

TerminX, on 05 April 2013 - 06:06 AM, said:

That's an interesting issue. Would making those original ifceilingdistl/iffloordistl commands TROR-aware break anything?

Wait a moment, let's do some analysis first before changing commands. Ifceilingdistl and iffloordistl check against actor[].ceilingz/floorz. Doing a quick grep for assignments of these members shows that it's a bit inconsistent at the moment: sometimes values coming from the already TROR-aware getzrange() are used, while in other places, either the sector members are taken over directly or the slope z value is calculated and used.

[fgsfds]

Is there any other way instead of using pal 4 to make black "shadow" font? Using alternative palette ruins it.

Also, why the crosshair is white in software?

Attached thumbnail(s)

• 

[Hendricks266]

I think we use pal 4 as a shortcut but I'm not sure. I think it may still be "optimized" if we make it pal 4 but with the maximum darkest shade. Thanks for the report.

[Helixhorned]

DanM, on 05 April 2013 - 02:02 AM, said:

helix can you add another default command to the a.m32 like a headlight for working in darker areas, alt+num2 turns a point light on in the players position that follows you with about a 2000 radius at 255 255 255, its kinda like playing minecraft mapping in the dark, and i know i could dick with the r_shadescale but then its going to looking different in the game, and this would be a really nice feature I think more than myself would use if possible.

Can do.

I, in r3648, said:

a.m32: Implement a Polymer "head light" emanating from your position in 3D mode.

Toggled with Ctrl+Shift+[KP-]. Variable 'headlight_range' controls its range.
For the implementation, a new event EVENT_PREDRAW3DSCREEN was added.

What I forgot to mention is there has to be an active Polymer light in the map to display the head light. There is no way to create lights from m32-script, so it just takes the light with index 0, repositions it and tweaks some of its members. When you disable the head light again, it should go back to its old position. However, I only tested that with SE lights, it might be broken for lights created by loading a maphack.

[Fox]

fgsfds, on 05 April 2013 - 09:04 AM, said:

Is there any other way instead of using pal 4 to make black "shadow" font? Using alternative palette ruins it.

The default palettes are hard-coded in the menus (and Eduke32 only add fuel to the fire), so I would recommend not to use them, start at pal 30.

===//===//===

I am having some trouble trying to make a mod compatible with HRP. The biggest problem I have is that the new textures or palettes don't overwritte the HRP ones.

It is forcing me to use undeftexture and undefmodel for every new tile, and it still doesn't work properly because it doesn't undefine setuptile. I wish tilefromtexture would already do that for me, i.e. erasing anything regarding that texture in above lines.

And the issue with palettes is that since all I need are simply RGB values, so I use tint. However it doesn't do anything to palmaps defined prior to it...

[Mblackwell]

Fox, on 05 April 2013 - 11:04 AM, said:

The default palettes are hard-coded in the menus (and Eduke32 only add fuel to the fire), so I would recommend not to use them, start at pal 30.

===//===//===

I am having some trouble trying to make a mod compatible with HRP. The biggest problem I have is that the new textures or palettes don't overwritte the HRP ones.

It is forcing me to use undeftexture and undefmodel for every new tile, and it still doesn't work properly because it doesn't undefine setuptile. I wish tilefromtexture would already do that for me, i.e. erasing anything regarding that texture in above lines.

And the issue with palettes is that since all I need are simply RGB values, so I use tint. However it doesn't do anything to palmaps defined prior to it...

You should able to set shade to 128 to guarantee black on all pals. In fact fading to something like shade 40 was how I achieved the particle effects in Top Shooter (though now it could be done using the .alpha member).

[Fox]

Yeah, but black is the only pal I don't have any issue. So...

[Mblackwell]

I was really addressing the question/comment from fgsfds, sorry to confuse.

[Helixhorned]

Gambini, on 02 April 2013 - 01:21 AM, said:

Does anybody know the name of the battlelord ANM file in duke3d.grp? I want to replace it but I can´t find its file. I have logo, cineov2, cineov3, radlogo, duketeam, and vol4-1-2-3-e1-e2 etc.

Where the hell is it?

NEVERMIND. it´s a set of tiles

True, the E1 ending sequence is realized as C code which draws some tiles and plays according sounds. I was first thinking of allowing an IVF replacement for the E1 ending as well as adding four bits to disable playback of any of the four episode bonus scenes (requested by Mikko in the scripting thread). However, I think it would still be pretty arbitrary... e.g. what if only a part should be disabled, etc...
A much more cleaner solution would IMO be a general cutscene system where you could define animations and sounds to be played back, and start them whenever desired.

[Fox]

deleted

[Stabs]

cheeers helix, will be testing out that headlight today

EDIT : got it working, says headlight enabled just not sure what is meant by the index 0 part

EDIT2: Works now, think i was running the 64 bit version, Thanks helix this is great no more carrying around an SE like some old man in a dungeon

[Stabs]

does seem to be a slight problem with the headlight and noclip, sometimes, but not always it will result in a CTD if you clip through a wall with the headlight on.

maybe a check so headlight will never work if full noclip is on

[Mark]

I'll have to try this feature. I'm wearing out my F11 key.

[Micky C]

I feel like I'm being kept in the dark about something (no pun intended), what's the significance of having the mapster camera project a spotlight? Working in dark areas, or is there something more to it?

[Mark]

You've got it right. Just for working in dark areas. I'm tired of raising the F11 brightness every time I make a change or add something and then have to lower it back down to check how it looks.

ADDED: I just tried it out. Works great. It has the added benefit for me of being a close Mapster duplicate of the flashlight mod I'm using for my maps.

[Stabs]

Trooper Mick, on 07 April 2013 - 05:07 AM, said:

I feel like I'm being kept in the dark about something (no pun intended), what's the significance of having the mapster camera project a spotlight? Working in dark areas, or is there something more to it?

I work with maps that have a uniform shade that is basically black, that's how old brush based engines worked, in dark areas you really can't see anything and this helps find texture alignments and find se sprite easier in dark areas, speaking of which all game code sprites should always be full bright, there is no point showing their shade value, you usually enter manual values if you need them anyway, they also should by default have no blocking properties.

[Mark]

I agree about the full brightness and non blocking. BTW, is there a way to configure key presses when Mapster loads up? Every time after it loads I have to press the "caps" key once to set gravity, the "i" key to hide the TROR texture, and ' + x to turn on SE lights. And then when Mapster exits it would be nice to shut the caps keep off again.

[Stabs]

Mark., on 07 April 2013 - 09:30 AM, said:

I agree about the full brightness and non blocking. BTW, is there a way to configure key presses when Mapster loads up? Every time after it loads I have to press the "caps" key once to set gravity, the "i" key to hide the TROR texture, and ' + x to turn on SE lights. And then when Mapster exits it would be nice to shut the caps keep off again.

probably goes a far as saying the hrp se sprites should have a bright green background instead off black for even easier locating, or even giving them their own unique background color for each se so they are even more easily identified when grouped together tightly


for example s could have a bright green and activator could have a bright pink, its never something you see in game should easily qualify as a candidate for some drastic changes given how its used.

[Helixhorned]

DanM, on 06 April 2013 - 11:03 PM, said:

does seem to be a slight problem with the headlight and noclip, sometimes, but not always it will result in a CTD if you clip through a wall with the headlight on.

Fixed in SVN HEAD btw, thanks for the alert!

[Jblade]

Helixhorned, on 05 April 2013 - 08:03 AM, said:

Wait a moment, let's do some analysis first before changing commands. Ifceilingdistl and iffloordistl check against actor[].ceilingz/floorz. Doing a quick grep for assignments of these members shows that it's a bit inconsistent at the moment: sometimes values coming from the already TROR-aware getzrange() are used, while in other places, either the sector members are taken over directly or the slope z value is calculated and used.

So what should be done in this case? Would changing the commands work then? I think it would be best if they did just automatically account for TROR sectors - it wouldn't affect the original levels at all would it?

[Stabs]

I might aswell send helix what i have made as a map, it has all sorts of complex ror geometry, mainly sloperd GEO's not to mention other enemies, like octabrains, commanders and drones that can also fly, i was really hoping that RoR would make for some interesting combat scenarios but the way the monsters see RoR is gunna neee some work, really hoping to use recon cars i just hope they can fly through RoR levels

edit : even an issue with lizmen ready to jump, through a ror layer they take a small delay before jumping.

[Forge]

not exactly a paper cut and i don't recall this being brought up before (though it probably has)

don't know if this is do-able, but i won't until i ask and get berated for being a dumbass

example:
i can drop a map and its midi file (with the same name as the map file) in a directory external to the duke root directory, start the game, select user map, scroll to the directory the map is located, the game will launch the map and the accompanying midi is recognized and played

i was wondering if the same can be done for art files?

is there a way to make the game recognize art files in a directory external to the duke3d root when a user map is selected in that same external directory?

more convenient than having to drop the art file into root. also prevent forgetting the thing is there and having it conflict with something else.

thanks for your time to read this, and i apologize if that time is wasted because it's been answered already