[DavoX]

Thanks TerminX

[Micky C]

Fox, on 16 May 2013 - 01:18 PM, said:

That's true, but it has always been like that.

Yes, but we haven't always had polymer, which has weapon-spawned dynamic lights that make the traditional visibility flash redundant. If a toggle for that was to be added, not only could people use it for polymer maps, but also maps with fog in the other renderers where it breaks atmosphere. So it's got all the bases covered.

[Fox]

The weapon lights doesn't necessarily make it redundant, since they have a limited radius, compared to the infinite flash from the DOS game.

[Micky C]

Fox, on 17 May 2013 - 06:22 PM, said:

The weapon lights doesn't necessarily make it redundant, since they have a limited radius, compared to the infinite flash from the DOS game.

The limited radius (not to mention the colour) is more realistic, and less atmosphere-breaking in large outdoor areas. I'm saying having them both at the same time makes one of them redundant. I know we have to keep legacy support which is why a toggle is ideal.

[Fox]

It's not like that would make that much of a difference, since EXPLOSION2 or NATURALLIGHTNING also clear the whole map.

[Danukem]

Fox, on 17 May 2013 - 07:01 PM, said:

It's not like that would make that much of a difference, since EXPLOSION2 or NATURALLIGHTNING also clear the whole map.

Most maps don't even have lightning, and shooting weapons is far more frequent than explosions, so yes it would still make a big difference.

I don't recall whether explosions clear visibility in polymer. Arguably they should not, since they already emit lights.

[Fox]

Fox, on 01 May 2013 - 07:40 AM, said:

By the way, is it possible to add SoundToggle, FXVolume, MusicToggle and MusicVolume to the avaiable userdef structures?

By the way, I want specifically to reproduce the Bonus screen, which the sound BONUSMUSIC is only played if the Music option is On.

    if (!(ud.config.MusicToggle == 0 || ud.config.MusicDevice < 0))
        S_PlaySound(BONUSMUSIC);

I don't know if MusicDevice is still used in Eduke32, or if it isn't redundant in the above case.

Alternatively a gamevar that returns if the music is on or off would be acceptable too.

[Mia Max]

Those flash lights are defenitiv atmosphere-killer

It looks so bad fireing this gun, pistol and freezer.

+it drops framerate.

Attached thumbnail(s)

• 
• 

[NightFright]

Something I noticed with older mods/addons using custom art: Some are using modified tiles009.art based on Duke3D v1.3d. This includes the old 3DR logo which is shown at the beginning (tile #2456, if I am not mistaken). This will be displayed with totally messed-up colors in EDuke32. If you replace the tile with the one from v1.5, everything looks OK.

Does the old logo use a different palette, or are special settings applied to make the new logo look correctly? It's only a minor issue, but I was still wondering why it doesn't seem to work.

[Helixhorned]

Mia Max, on 20 May 2013 - 07:17 AM, said:

Those flash lights are defenitiv atmosphere-killer

Visibility flashing can be disabled for other weapons by adding analogous code to my previously posted mutator.

[TerminX]

NightFright, on 20 May 2013 - 08:07 AM, said:

Something I noticed with older mods/addons using custom art: Some are using modified tiles009.art based on Duke3D v1.3d. This includes the old 3DR logo which is shown at the beginning (tile #2456, if I am not mistaken). This will be displayed with totally messed-up colors in EDuke32. If you replace the tile with the one from v1.5, everything looks OK.

Does the old logo use a different palette, or are special settings applied to make the new logo look correctly? It's only a minor issue, but I was still wondering why it doesn't seem to work.

It uses a different palette, contained in 1.3D's DUKE3D.GRP (and directly on disk as LOOKUP.DAT). If you pack the LOOKUP.DAT from 1.3D into the GRP for a mod based on 1.3D it should be alright.

[NightFright]

TerminX, on 20 May 2013 - 08:32 AM, said:

It uses a different palette, contained in 1.3D's DUKE3D.GRP (and directly on disk as LOOKUP.DAT). If you pack the LOOKUP.DAT from 1.3D into the GRP for a mod based on 1.3D it should be alright.

Very well. Thank God I actually happen to have both versions of the game...

[Mia Max]

Helixhorned, on 16 May 2013 - 01:13 PM, said:

It's a five-line CON mutator though:

// EDuke32 mutator to prevent the pistol from lighting up the scene.

// EVENT_RESETWEPONS runs from G_EnterLevel() for each player.
onevent EVENT_RESETWEAPONS
    // NOTE: we use the predefined 'gs' global to avoid defining our own
    // gamevars.

    // pistol
    setvarvar gs WEAPON1_FLAGS
    orvar gs 256  // WEAPON_NOVISIBLE
    setvarvar WEAPON1_FLAGS gs
endevent

Edit: the point being, it's a bit arbitrary to pick one particular "game tweak" to be included into the EDuke32 executable, especially if it can be replicated with little effort with CON.

It doesn't work.
I've created a con file with your code and included it into eduke.con
It was loaded correctly, no errors, but there's still flash for pistol.

I'm not a coder and I don't understand english very well, so it's very difficult to understand anything about that. Sorry.

Can I get some help, please?

[Diaz]

The only way that worked for me was to set the flags constantly in EVENT_GAME.

onevent EVENT_GAME

ifactor APLAYER
{
orvar WEAPON1_FLAGS 256
orvar WEAPON2_FLAGS 256
etc...
}
endevent

[Danukem]

Mia Max, on 21 May 2013 - 05:05 AM, said:

It doesn't work.
I've created a con file with your code and included it into eduke.con
It was loaded correctly, no errors, but there's still flash for pistol.

I'm not a coder and I don't understand english very well, so it's very difficult to understand anything about that. Sorry.

Can I get some help, please?

Maybe DukePlus -- which you are using for your map -- also sets the flags and is overriding the mutator. That's the most likely problem. I have a few minutes so I will look into it now.

EDIT: Yes, the pistol flags are set every time you switch from one pistol to akimbo, or change pistol settings in the menu. So for example, picking up a second pistol will override the flags set at level start. I'll see what I can come up with as a solution.

[Danukem]

@Mia Max: Here is my solution.

Use the attached CONs. Add a weapon options controller sprite to the map (tile #2962). Give it a hitag of 2. This should turn off flashing. Note that you may also set lotag and use the sprite to set other weapon options, but this isn't necessary.

You can also control it in the console:

setvar noweapflash 1

Attached File(s)

•  dpcons.zip (207.51K)
  Number of downloads: 373

[Mia Max]

Thanks a lot!!
I'll try it out

This is something I've always wanted for Duke Nukem 3D

EDIT:

It wooorks!
I'm so happy right now

Again, thank you!

[Paul B]

This post isn't about Polymer. But about Eduke itself.

I was wondering if it would be possible to have the EDUKE32 Program notify the user when Polymer fails to initialize during the start of EDUKE so they know their PC doesn't support it rather than automatically loading the Classic renderer and bitching because of graphical glitches when they play a map that requires Polymer.

The end user should be prompted with a message as such: Your system does not meet the hardware requirements for the Polymer Graphics System. Would you like to continue and use the Classic renderer instead? Yes/No

Infact, it would be nice to select a map property or attribute that only allows a Polymer designed map to be played in the Polymer renderer only. I think it would put an end to people using the wrong mode for the intended map.

For instance, a map with no attribute would play in all renderer's. A map with a Polymer Attribute would only load using the Polymer system. A Map with a Polymost would only load in Polymost. And if the map had two attributes then it would play in both those modes but not using classic.

That's just my two cents for the day.

[Diaz]

I'm all for that. My stuff looks all black in renderers other than Polymer due to either lack of sector lighting, 8-bit art, or both.

[TerminX]

That would certainly be possible, but the question is where to shoehorn the value into the existing map format in a way that it won't fuck up mods that make extensive use of reading values from arbitrary structure members (like for Duke Plus effects, etc). Maybe a simple compatibility flag could be packed into the "filler" member of sprite 0 or something, since end users really aren't supposed to be using that for anything... it only exists to pad the structure so that the members are aligned correctly for faster memory access. It's an 8-bit value, but we would only need 3 of those bits to implement something that allows a map to specify it doesn't work on classic, doesn't work on Polymost or doesn't work on Polymer.

[Danukem]

 TerminX, on 21 May 2013 - 02:24 PM, said:

That would certainly be possible, but the question is where to shoehorn the value into the existing map format in a way that it won't fuck up mods that make extensive use of reading values from arbitrary structure members (like for Duke Plus effects, etc). Maybe a simple compatibility flag could be packed into the "filler" member of sprite 0 or something, since end users really aren't supposed to be using that for anything... it only exists to pad the structure so that the members are aligned correctly for faster memory access. It's an 8-bit value, but we would only need 3 of those bits to implement something that allows a map to specify it doesn't work on classic, doesn't work on Polymost or doesn't work on Polymer.

The other issue is that it would be an unreliable indicator, because polymer maps already released would not contain the flag, and only a portion of future maps would, since not all mappers would know about the feature or care.

Why not just check for SE49 and SE50 sprites? That should be a good litmus test as to whether a map is intended for polymer. There is really no test for the other renderers but with the recent changes to polymost it doesn't matter as much.

[Helixhorned]

 Trooper Dan, on 22 May 2013 - 07:10 AM, said:

Why not just check for SE49 and SE50 sprites? That should be a good litmus test as to whether a map is intended for polymer.

Yeah, this seems like a reasonable heuristic. I'm against forcing a particular renderer for a given map though. Maybe EDuke32 could display a subtle message for some time and consider it done then.

[Diaz]

But perhaps it would be possible to give us modders the possibility of specifying (rather than forcing) what renderers are allowed. Maybe via the console, so the parameter could be added to the map's specific .cfg. Another cvar could be used to skip that behavior, so it's not forced. It would make even more sense for mods than for individual maps; I think a Polymer or Classic only mod looks more "professional" by running only the way it was intended to, rather than allowing the player to, let's say, run a Polymer mod in classic then get a black and incorrect art mess. Then we have to specify everywhere that the mod is not intended for classic.

[TerminX]

Checking for the presence of Polymer light sprites in a map is in no way a suitable alternative to allowing a mapper to specify that their map only runs in classic, or only runs in Polymost, or only runs in Polymer. Some people want it more so that maps can be prevented from running in Polymer due to draw distance or performance issues, or prevented from running in classic due to a lack of classic assets... it is in no way solely about making sure Polymer maps only run in Polymer, which is the only aspect your suggestion addresses. I think you're completely missing the point.

[Helixhorned]

TX: OK, I see. My point is that a modder/mapper should not have the authority to dictate a particular choice of renderer. If the user wishes to use a different than the recommended one, it should be possible.

As for the implementation, doing it via OSD commands which would presumably run from a <mapname>.cfg file is at least non-intrusive in this case, unlike overriding user preferences like r_shadescale (which are currently not reset on finishing a map, as far as I can see). It's still a bit hackish though.

EDIT: my bias has a background. As much as I admire the awesomeness of the DNF mod, that "funny" tile covering the screen when one switches into Polymer is a bit unfair IMO. Yes, voxels aren't implemented there and DNF uses quite a bit of them, but that shouldn't prevent me from trying it out just for the heck of it. Especially now with ART mapping, it should be pretty interesting.

[Diaz]

 Helixhorned, on 22 May 2013 - 09:32 AM, said:

TX: OK, I see. My point is that a modder/mapper should not have the authority to dictate a particular choice of renderer. If the user wishes to use a different than the recommended one, it should be possible.

As for the implementation, doing it via OSD commands which would presumably run from a <mapname>.cfg file is at least non-intrusive in this case, unlike overriding user preferences like r_shadescale (which are currently not reset on finishing a map, as far as I can see). It's still a bit hackish though.

It should be possible to choose different renderers as long as the map doesn't look a mess, which is why I think it should be specifiable by modders. It's just a matter of making things cleaner. Maybe I can see someone running a Classic map in Polymer for the added dynamic lights, but I see no point in running a Polymer mod, which only uses 24-bit assets and models, in Classic mode.

For these cases, we could have a way to specify if the "choose renderer" option is grayed out in the menus, and perhaps the "Use models" option too. It looks really dirty if changed. Anyways, this is just a cosmetic thing, should not be high priority at all.

Cvars not resetting after being set from a <mapname>.cfg is not desirable behavior and should be addressed, IMO.

[Paul B]

I dont see what the big deal of allowing the mapper to dictate which renderer he wants his map displayed in by setting a map attribute.

If the attribute isn't set in the map nothing changes, meaning the map can be playable in all renderers and it breaks nothing. This would only be an option moving forward to insure future maps are played respectively in their most compatible format making people aware of the maps requirements for best overall experience and consistency.

[Danukem]

 Paul B, on 22 May 2013 - 10:22 AM, said:

I dont see what the big deal of allowing the mapper to dictate which renderer he wants his map displayed in by setting a map attribute.

If the attribute isn't set in the map nothing changes, meaning the map can be playable in all renderers and it breaks nothing. This would only be an option moving forward to insure future maps are played respectively in their most compatible format making people aware of the maps requirements for best overall experience and consistency.

By the way, it's pretty easy to prevent a map from working with certain renderers by using CON code. The variable rendmode contains the rendering mode, and can linked to code that prevents gameplay and provides an explanatory message if the wrong renderer is being used. It's a simple procedure.

I agree with Helixhorned that allowing the map file itself to prohibit the player from using a certain renderer is the wrong way to go.

[Diaz]

I wasn't aware of the existence of the rendmode variable, sorry about that.

Although I still believe it's ugly to be able to easily switch rendmodes and usage of models with the menus on mods that don't have 8-bit assets.

[TerminX]

 Helixhorned, on 22 May 2013 - 09:32 AM, said:

EDIT: my bias has a background. As much as I admire the awesomeness of the DNF mod, that "funny" tile covering the screen when one switches into Polymer is a bit unfair IMO. Yes, voxels aren't implemented there and DNF uses quite a bit of them, but that shouldn't prevent me from trying it out just for the heck of it. Especially now with ART mapping, it should be pretty interesting.

Why is that "unfair"? The maps are huge and exceed the distance that Polymer can currently render. They don't want their vantage points and other scenes containing far-away sectors to be ruined.