[Jblade]

that's simple enough, cheers!

[0815Jack]

Hi,

i have updated my installation to the latest synthesis build and noticed some changes in the polymer renderer regarding shadows and shading in general. I really like the new features, but is this still work in progress? In many areas of the levels the shadows fit perfectly, but in lot of cases it's too dark (my personal opinion). And it does help using the night vision goggles, cause the shader seems somehow to overlay it.

[darkprince227]

Happy new year, folks!

I just downloaded the latest eduke build, I noticed for some reason the vacation.grp wasn't listed on the startup thing along with duke3d.grp etc. Is it supposed to be this way?

[enderandrew]

darkprince227, on 02 January 2018 - 02:14 AM, said:

Happy new year, folks!

I just downloaded the latest eduke build, I noticed for some reason the vacation.grp wasn't listed on the startup thing along with duke3d.grp etc. Is it supposed to be this way?

That doesn't sound like a Polymer/rendering bug so this probably isn't the right thread to discuss that. But I downloaded the latest Synthesis build as well from 12/29 and I can't replicate the behavior. Everything looks good on my end.

[darkprince227]

enderandrew, on 04 January 2018 - 10:50 AM, said:

That doesn't sound like a Polymer/rendering bug so this probably isn't the right thread to discuss that. But I downloaded the latest Synthesis build as well from 12/29 and I can't replicate the behavior. Everything looks good on my end.

You're right, it wasn't an eduke problem the vacation.grp I was using seemed to be broken, so I made a fresh one and bada-bing. We're in progress

[Jblade]

I just discovered a strange issue involving SIDEBOLT1 - as of snapshot 6248, they appear broken ingame (visually they seem to shrink to half size on the x dimension)

link to snapshot they stopped working properly:
http://dukeworld.duk.../20170623-6248/

link to last snapshot they did work in:
http://dukeworld.duk.../20170622-6242/

[Hendricks266]

darkprince227, on 04 January 2018 - 12:45 PM, said:

You're right, it wasn't an eduke problem the vacation.grp I was using seemed to be broken, so I made a fresh one and bada-bing. We're in progress

You shouldn't need to make a vacation.grp yourself. EDuke32 will accept VACA15.SSI as taken directly from the original CD release, as well as VACATION.GRP as found in Megaton and the Anthology / Kill-A-Ton 2015 entry on Steam.

Jblade, on 04 January 2018 - 02:25 PM, said:

I just discovered a strange issue involving SIDEBOLT1 - as of snapshot 6248, they appear broken ingame (visually they seem to shrink to half size on the x dimension)

Fixed in r6605.

[Jblade]

Thanks - much appreciated.

Is there an ability to rename main menu commands yet btw? Specifically, I'm looking to replace the Help menu with something like 'Go to HQ' which'll load one of the AMC base maps up. I'm pretty sure I can already do the loading base thing, it's just the string name I need to change. I'm seeing all sorts of interesting stuff in the synthesis (including the ability to flat out remove it and credits* from the menu) but I'm not sure if what I'm asking is possible yet.

EDIT: Also, I'm not sure this is actually a bug but ambient sounds with a hitag over 32767 don't play anymore; was it always the case that sounds shouldn't of worked over that hitag value, or is it indeed a bug? I'll look into tracking down the snapshot if you think it's not intended behaviour.

[Hendricks266]

Jblade, on 29 January 2018 - 01:29 AM, said:

Is there an ability to rename main menu commands yet btw?

No, and this is not on my roadmap.

Jblade, on 29 January 2018 - 01:29 AM, said:

EDIT: Also, I'm not sure this is actually a bug but ambient sounds with a hitag over 32767 don't play anymore; was it always the case that sounds shouldn't of worked over that hitag value, or is it indeed a bug? I'll look into tracking down the snapshot if you think it's not intended behaviour.

It has to be r6581. It may indeed be the case that those sounds did not work in the original game. However if there are no side effects I would be willing to re-allow them.

[Jblade]

So I take it that it's not a trivial thing to implement then? That's fair enough, I can disable it for now and when/if the time comes I can add that ability into the menu, cheers.

Quote

It has to be r6581. It may indeed be the case that those sounds did not work in the original game. However if there are no side effects I would be willing to re-allow them.

They worked fine and I didn't see any side effects but that's not to say there might not of been some issues around regardless. I can add some con code that will automatically set the volume back down to the max if it's higher, it's no big deal.

[Jblade]

About the autosave feature btw, Dan brought up a good point in the Hectic Realm thread that at the moment it just keeps piling up and piling up saves. Would it be possible for you to restrict this to a set of like 4 or something, similar to GZdoom?

[Hendricks266]

Jblade, on 29 January 2018 - 04:25 AM, said:

They worked fine and I didn't see any side effects but that's not to say there might not of been some issues around regardless. I can add some con code that will automatically set the volume back down to the max if it's higher, it's no big deal.

They should be fixed now. Please let me know if you find any other behaviors broken when hitags and lotags are > 32767 (aka < 0).

Jblade, on 04 February 2018 - 10:45 AM, said:

About the autosave feature btw, Dan brought up a good point in the Hectic Realm thread that at the moment it just keeps piling up and piling up saves. Would it be possible for you to restrict this to a set of like 4 or something, similar to GZdoom?

The autosaves only "fork" a new file when 1) you use the Save Game menu or F2 (as opposed to F6 quicksaving) to make a new manual save and then the `save` or `savenn` CON commands run, or 2) the `save` or `savenn` CON commands run with a different index than when you previously ran it.

I would recommend fixing your ID numbers.

[Jblade]

Ah cool - I did alternate autosaves since IIRC there was a issue where it would autosave again as soon as you loaded the game and I got told that it was intended behaviour or something like that, it's been a few years since I asked about it.

[Hendricks266]

Try that again, there have been some more changes in this area in the past year. The re-save on load may no longer happen.

[Danukem]

There are two different HUDs which share screen_size == 4

There's the regular one which shows ammo count as a number, and then one notch "above" that there is the special EDuke32 one which show an ammo icon on the right side, etc., and it is still considered size 4 (there is also size 0 with no HUD at all).

My questions is, is it possible in CON to detect which of those two size 4 HUDs is being used? So far I have not found a way. In case it wasn't obvious, I want my display code to do different things depending on the HUD.

[Hendricks266]

Try ud.althud.

[Danukem]

Hendricks266, on 14 February 2018 - 10:58 AM, said:

Try ud.althud.

Ah. I saw that struct and I thought it meant that it would be set when the user has the alt hud as one of the huds that gets cycled through, I didn't realize it was only set when the hud was actually being displayed.

EDIT: If you look at the wiki entry, it clearly says that setting it to 0 disables that hud. Anyway I will go test this now.

[Fox]

Recently I changed it so that the alt hud is displayed when you use the + and - keys. It used to be a second option in the menu, which is more-or-less what the Wiki is referring to.

[Danukem]

Fox, on 15 February 2018 - 09:10 AM, said:

Recently I changed it so that the alt hud is displayed when you use the + and - keys. It used to be a second option in the menu, which is more-or-less what the Wiki is referring to.

That makes sense. I updated it just now.

[Jblade]

Is there any way to activate a SE12 light switch via CON code? Seems like an operatesectoreffector would be a useful option to have, if there's nothing similar already.

[VGA]

Using the Polymer renderer, is it normal that I see sprite flickering (z-fighting?) on things like broken fire hydrants, broken toilets and even sometimes self-destruct buttons? I mean, is this a known deficiency of the Polymer renderer? I tried Polymost and it doesn't happen but I want the lighting goddamnit!

(I am playing the WT content with the stopgap thing)

[Gambini]

Hello.

I´m having some audiovisual issues with latest Eduke32 builds, which I hope someone can address.

I have been using Eduke32 4102 (from 2017) for eduke32 and a 2013 mapster32 build which already supports usetileshades, until Trooper Dan jumped onboard, who suggested to keep builds up to date, mostly for coding reasons.

Now I´m using 6788 and I´m having the following problems:

Sound doesn´t work, only music. Tried deleting eduke32.cfg and tinkering with sound values. I have a Realtek onboard audio, on a gigabyte mobo.

Visibility has changed drastically and console commands like r_usetileshades, r_shadescale, r_usenewshading don´t do anything when entered on the console.

This is how it looks like on mapster32 from 2013 (right after the usetileshades thingie was added):



This is how it looks on the 4102 build from 2017 (notice how dark things are at the distance):



And this is how it looks now on 6788, almost like before but now with a parallax glitch (notice the vertical strips of misalligned sky above the buildings on the distance)




This is what both autoexec.cfg and m32_autoexec.cfg read, at least the r_usetileshades command seems to work on the autoexec for Eduke32:

r_shadescale 0.65
r_usenewshading 2
r_novoxmips 1
r_usetileshades 2

Hope anything can be done about it.

[Hendricks266]

I don't know what could be the issue with sound. Could you bisect the problem?

Ideally you should not touch r_usenewshading, r_usetileshades, r_shadescale from your autoexec. The defaults we ship with are designed for an experience as accurate to Classic as possible. The only reason the toggles even exist is for compatibility with things released in the past. For something still in development, fix your maps. Let us know if Polymost differs from Classic.

I have an idea of what the parallax issue is. I believe it is related to a change Fox made. As a test, I think you can disable r_parallaxskypanning (or something named similarly). However, do not add that to any autoexec files.

[Gambini]

Thanks for your answer. I will take a closer look at the sound thing.

Are you saying I should not use custom values for a mod with custom content? I have these maps in the making from long ago and those are vaules I found fit for them after a lot of work. Not to mention the other mapper working on it has a notch less of a technical understanding of this kind of things, which means reversing 4/5 years of work would be suicidal for our project. It´s never been said before those parameters would eventually end in arbitrary fixed values. Please consider exceptions for experienced users.

[Hendricks266]

Let the lesson be to always design your shading in Classic. For fixing existing maps, it is possible that an m32script can be designed to make quick work of the task.

[Danukem]

Hendricks266, on 23 March 2018 - 02:46 PM, said:

Let the lesson be to always design your shading in Classic. For fixing existing maps, it is possible that an m32script can be designed to make quick work of the task.

Sure, if it's a simple linear change, like changing all shade or visibility values by certain numbers. But if it's more complicated than that, then it will prove problematic.

I'm interested to hear what Gambini will say about the classic shading rule. To my knowledge, he has always cared about how maps looked in classic and I find it hard to believe that he had not paid attention to that when designing those maps.

[Gambini]

Sure. The problem is that since i have been using models, i run only polymost with r_usetileshades 2 and those shading parameters i posted as my autoexec.cfg.

There is sadly no such thing as a magic mapster32 script which may adjust all parameters involved on restoring what i have achieved after a lot of fine tuning. i doubt anyone would tinker with them unless they have at least a rough idea of what they are doing. So I don´t see no reason for them being locked.

Quote

Let the lesson be to always design your shading in Classic. For fixing existing maps, it is possible that an m32script can be designed to make quick work of the task.

There´s no lesson here because at the time i built the largest part of those maps, those parameters were of free use. Also, when you design a map for polymost, you can´t map on classic because many things dont work like models, skyboxes, etc.

Can you confirm r_usenewshading, r_usetileshades and r_shadescale commands are locked on the console? Is there a way I can ship a mod which overrides the default values?

[Forge]

Is it because the port is being used for a commercial game, so now everything has to be locked up ala DNF 2011?

[Danukem]

Gambini, on 24 March 2018 - 07:58 AM, said:

Sure. The problem is that since i have been using models, i run only polymost with r_usetileshades 2 and those shading parameters i posted as my autoexec.cfg.

There is sadly no such thing as a magic mapster32 script which may adjust all parameters involved on restoring what i have achieved after a lot of fine tuning.

Your fine tuning would stay largely intact. The idea is that we figure out a formula that when applied to the current maps, makes the shading and visibility on them look correct in the current Polymost build. The changes between builds surely weren't random, there must have been some rules that were followed governing the changes; therefore it seems reasonable to assume that a script which globally changes shade and visibility settings according to a reverse-engineered formula could at least closely approximate what is needed to make the maps look correct. If you were to, say, fix a small area in one map, and you noticed a pattern in the changes you were making, I could probably make a script that applied that pattern of changes globally. At that point we test it out -- probably it will be wrong in certain ways for other map areas. Then we make some adjustments and try an improved formula. The whole process would probably take a few hours before it was correct, but it would still be a fraction of the time needed to redo all the maps.

Forge, on 24 March 2018 - 08:16 AM, said:

Is it because the port is being used for a commercial game, so now everything has to be locked up ala DNF 2011?

Very unlikely. Ion Maiden evidently uses a somewhat different build where various things work differently (e.g. you have to hold shift and ~ to open the console), so if there was anything they wanted to lock up, it would make sense to do so only on the IM branch.

[Phredreeke]

Not to mention... eduke32 is open source, anything done to "lock it down" could be undone in the source code.