[Stabs]

iam cleaning it up, textures get tiles, fogging is getting a massive overhaul and its all not that hard

so ill post work by work posts to let people gauge how it runs / spot little texture errors

anyway all you need is the latest HRP and Eduke and just dump it in there.


Very Tight kinda ready version 4 of the beta


DOWNLOAD

2.0 "polish patch" features

- LAUNCHER FOR 65-BIT / 32 - BIT WITH GFX SETTINGS
- SECRET LEVEL
- TONS OF TEXTURE TWEAKS AND FIXES / HUGE FPS INCREASES / MORE SECRETS
- TROR IMPLEMENTATION WHERE FEASIBLE
- GLOVES
- DIFFICULTY NOW WORKS ON DMG TAKEN VS DMG DONE
- BETTER SCRIPT WRITTEN BY HENDRICKS
- DP FIXES FOR LATEST EDUKE VERSION
- BETTER LOOKING FOG
- SPEC / HEIGHT MAPS FOR DNE TEXTURE ASSETS (NOT IMPLEMENTED YET)

[Stabs]

UPDATE

so ran the script over ALL the maps

major changes are proper TROR water in DNE02, real water on the hotel roof, also inside the hotels water feature has real water now

lots of other tweaks and changes

should have a version of DNE04 up soon with real water in the sewer section

 PATCH WORK02.zip (2.9MB)
Number of downloads: 224

BTW in DNE04 it periodically makes a large white flash which slows the game, think it could be a dukeplus related error

[Danukem]

Are you using the latest DP from the site, or the version that was packed with DNE? There haven't been a lot of updates since then, but there have been a few.

[Stabs]

yup got the latest version, great couch and sandbag models BTW very useful

but as mentioned, it could be eduke or dukeplus but flashing lights can just flash really BIG now for some reason and really bomb the frame rate

it looks like lightning is striking in DNE04 when it happens

[Danukem]

I haven't looked into it and I have no idea what the problem might be. Are the flashing lights the ones I coded, such as the cop car lights? They used to work perfectly. If you have time you could put one of them in a simple map by itself and see how it behaves, maybe change the values on it that control frequency and radius etc. (hell it's been so long I don't even remember which values you could set on that effect).

[Stabs]

cop cars seem to be fine hard coded stuff, its just se49 i place myself can just light up a whole map, sounds like its this SIN thing from the other thread

[Helixhorned]

I plan into looking into the huge Polymer light issue when I have set up DNE + patches. For reference, this is what I downloaded so far:

From the moddb page,
* Duke Nukem Eternity 1.3d ZIP
* Duke Nukem 1.3D Performance Patch
* Duke Nukem 1.3D Performance Patch v2 (does this one supersede the first one, or is it an addition?)

From here,
* PATCH WORK.zip
* PATCH WORK02.zip

From Fissile Materials,
* DukePlus. I think the version is 2.35, date 20130105. The md5sum is
4aa2e4df4e645f7787a7c745d61bf96c DUKEPLUS_2.35.zip

Phew. That's a lot of manual effort just to set up a development version of a mod. Have you (DanM and DT) considered asking Plagman about an SVN repository?

[Stabs]

shouldnt even need my DNE resources dude, just dukeplus and the map

run DNE04 and look for the lightning like effect

were ok without an SVN, i just map and request code now and then. amazingly with DP the trophy system runs purely out of map code and a few quotes , there is no con, and same with how the level ends and shows you what trophys you have found and how many civs rescued

edit : ya defeintly the flashing lights, as you leave the alley at the start of DNE04 turn 90 degrees right the big white building has a broken light, keep it on your screen and keep walking and backwards and forwards toward it and it will make a huge flash randomly

[The Commander]

As DT said DanM, have you tested this in a simple test map to make sure nothing else is causing the issue as well.
I've noticed you have ignored a couple of requests to test stuff the past few days and insist it's something else.

[Stabs]

 The Commander, on 23 February 2014 - 05:45 AM, said:

As DT said DanM, have you tested this in a simple test map to make sure nothing else is causing the issue as well.
I've noticed you have ignored a couple of requests to test stuff the past few days and insist it's something else.

its pretty obvious dukeplus needs tweaking to its flashing light system, i turn on dukeplus it happens, run DNE04 through stock game and it dosn't happen

run at a flashing light backwards and forwards in dukeplus and you can make the effect happen more and more

[Helixhorned]

 DanM, on 23 February 2014 - 03:11 AM, said:

shouldnt even need my DNE resources dude, just dukeplus and the map

run DNE04 and look for the lightning like effect

This is not how it works. I need to reproduce the same environment as you to be effectively handling bugs. I tried running dne01.map in stock DukePlus but couldn't even see a "lightning effect" or anything similar to what you mention. Maintaining DukePlus and DNE in their own repositories (with the latter preferably only keeping links to DukePlus revisions instead of duplicating DukePlus in the repo) would be a huge step towards being able to set up the mods quickly and painlessly. (And most importantly, not having dozens of old versions lying around on the hard drive.)
Seriously, source code editing not backed by a version control system is just plain unthinkable, and for data, having it in one place and the history "hidden" is a blessing.

I'll have to analyze how the files belong together then, looking at diffs etc. etc. This may obviously take some time. With SVN, all I'd have to do would be a

svn checkout http://address-of-the-dne-repo
svn checkout http://address-of-the-dukeplus-repo
cd dne
# create symlinks to DukePlus, ...
# set up config files
# enjoy a version that is consistent with what the developer sees

[Stabs]

i know for a fact i can reproduce this problem in DNE04 though



just run back and forth at that light just run dukeplus with dne04 from patchwork02, i know for a fact you can see it then

and yes i will set up a SVN if you can PM the details ill upload it all today

[Danukem]

 DanM, on 23 February 2014 - 01:28 PM, said:

its pretty obvious dukeplus needs tweaking to its flashing light system, i turn on dukeplus it happens, run DNE04 through stock game and it dosn't happen

run at a flashing light backwards and forwards in dukeplus and you can make the effect happen more and more

If you recall, I had added some code that was supposed to kill or dim lights depending on the framerate, light priority and distance from the player, in an attempt to get DNE running smoothly with polymer when it was released. It did help at the time, but I suspect that the code is not playing well with recent builds of eduke. I'm thinking I will disable it and see what happens. And I'll upload my latest CONs somewhere they can easily be accessed.

[Stabs]

yeah that sounds alright, it really runs much better now so we should be able to handle it

[Stabs]

well that's it tested a stack of version trying to find the one that made lightning and rev 3161 seems to introduce it i think its related to this

Quote

r3159 | terminx | 2012-11-14 15:32:43 -0800 (Wed, 14 Nov 2012) | 4 lines

Fix the warnings when building with C++, add MSVC C++ build support. This also changes the internal type of lotags, hitags and cstat type fields to uint16_t instead of int16_t to clean up some dubious behavior wherein the code was using a value of 32768 as a flag in these fields for certain types of things, like invisible sprites (using the value as if it was uint16_t) where it was elsewhere checking if the value was < 0 (using the value as if it was int16_t). This change may break a few specific effects if any part of the relevant code was missed when looking for areas that needed to be addressed.

I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)

[Danukem]

 DanM, on 25 February 2014 - 04:04 PM, said:

well that's it tested a stack of version trying to find the one that made lightning and rev 3161 seems to introduce it i think its related to this

Good job doing the research and narrowing it down. The next task is to figure out which specific lighting effect(s) are causing the flashes. It might be possible to prevent the flashing by avoiding certain tag values on the sprites and/or changing the CON code.

Here are the instructions for creating various SE49 effects in DukePlus:

Spoiler

POINT LIGHT = SE 49
This is a hardcoded SE that works without DukePlus. It only works with the Polymer renderer. Hitag is the distance the light will travel. XVEL/YVEL/ZVEL are the RGB values (0-255). In DP, point lights have additional features:
Oscillating light
This is similar to a CYCLER. Set HITAG to the brightness you want at the peak of the cycle. Extra will determine the length of the cycle, and must be > 0. Higher Extra = a faster cycle (64 is a good default value). Finally, the shade of the SE is a timing offset (1 tic per shade). You can have different cyclers oscillating at the same rate, but at different times. You can use this, for example, to make a an emergency light that switches between red and blue (you would put two SEs on the same spot, give them different colors, and give one a shade so that its light starts as the other's fades).
Flickering lights
Pal 1 is a broken light. When it blinks on, it will be at the full hitag brightness. How frequently it blinks on depends on the shade. The higher the shade, the more frequently it blinks. You may want to use this effect in conjunction with a light model that has a glow map, but in that case you don't want glow map to show unless the light is on. In your def file, define the model twice, on two different tile numbers, one with the glow map and one without. Place the non-glowing tile in the same sector as the SE 49, and give it an extra of 4911. Then set the model's hitag to the tile number of the glowing version. It will glow only when the light is on. Note: There is a small amount of lag between the light changing and the model changing which can't be prevented.
Pal 2 is a partially flickering light. Set Extra to the base brightness of the light. This value should be lower than hitag. The light brightness will randomly vary between the base brightness and the full brightness (hitag). You can leave extra at 0 for a completely random brightness, or set it closer to the hitag value for more of a flickering flame effect. Note that surfaces close to the light will tend to look fully lit even if the light is flickering, and I can't prevent that.
Making dynamic lights switch on or off
Place an SE150 in the same sector with the SE49 or SE50 that you want to be switchable. It only takes one SE150 per sector, and it work on all the lights in that sector, no matter how many there are. The HITAG of the SE150 will be the activation number for the light or lights. If you want the light(s) to start off instead of on, then give the SE150 an EXTRA of 1.

How to activate the lights: To make it work with a switch sprite, you tag the switch sprite with the activation number on both the LOTAG and the YVEL of the switch. If you set the YVEL on the switch, you do not need to place an ACTIVATOR. You can make the switch activate the light without setting YVEL, but in that case you must make the switch also do something else that works with an activator (like open a door). Lights can also be activated by dying monsters, DPTOUCHPLATE, and other DP effects that cause activations. Finally, they should work with other non-DP effects that use activators (but I have not tested them).
If you have an SE49 or SE50 that is set up to be switched ON/OFF (that is you have the corresponding SE150 in the sector), then you can also place a sprite tagged with Extra 4911 in that sector and it will be the linked model (e.g. a lamp or some other model representing the light source). As with the flickering effect, the Hitag on the Extra 4911 model will be the alternate glowmap picnum that gets switched to when the light is activated. For this effect, you can have the light start either off or on. It will be off by default, but if you want it to start as on, give the 4911 model a lotag of 1. Obviously, for this to work you must have a light source model and the same model with the glowmap defined in the defs on different tile numbers (picnums). There are some limitations. You can only have one 4911 tagged model per sector You could have more than one light linked to the model (simply by placing more than one SE49 or SE50 in that sector along with the SE150, but keep in mind that each SE that switches is going to flip the model. So if you have two lights that get switched off, each will flip the model and it will be like the model didn't flip. In other words, it should work if there is an odd number of lights in the sector.

I have been assuming that it's the oscillating light one that is causing the trouble. Can you confirm that?

[Stabs]

yup seems to be one pal 1 light per level, if you delete it just moves on to the next pal 1 light.

also i noticed light switches act a bit funny now, sometimes they work sometimes they do, and they usually just stop working

[Stabs]

The broken bridge in DNE04 is now a proper TROR Construction, if you miss the jump you can get back up, sorta, the duke bike has issues going through TROR layers

its not a pit of death too either, its a non essential side exploration area now

[Danukem]

I would like to check out the flashing light problem with as little time investment on my end as possible. Would you mind PMing me with a copy of a map that exhibits the problem near the player start location?

[Helixhorned]

 DanM, on 25 February 2014 - 04:04 PM, said:

well that's it tested a stack of version trying to find the one that made lightning and rev 3161 seems to introduce it i think its related to this

 Trooper Dan, on 25 February 2014 - 07:06 PM, said:

Good job doing the research and narrowing it down.

Indeed, that explain it all. r3159 changed the type of sprite[].hitag and .lotag to unsigned 16-bit integers. Whenever they are assigned negative values, the resulting number is the one that's obtained by re-interpreting the bit pattern as unsigned. E.g. -1 --> 65535.

A simple test case with an "cycling SE49" (extra >0) demonstrates this, since it cycles values around zero. However, a modification is necessary: in DUKEPLUS.CON,

                        setvarvar tempd timer
			addvarvar tempd initshade 
			mulvarvar tempd monstflags // frequency * time
			sin tempe tempd
			mulvarvar tempe hitag
			shiftvarr tempe 14
ifvare tempe 0 setvar tempe 1  // DEBUG; added to prevent disabling light
			setactor[THISACTOR].hitag tempe

when tempe results in the value 0, the SE may subsequently have bit SFLAG_NOLIGHT (256) set by "state lightsout", disabling the cycling SE from this point onward.

[Danukem]

I had already disabled state lightsout and uploaded the CONs, but I'll go ahead and make this change as well. But this is bad news from my standpoint, because I'm pretty sure there are several effects in DukePlus that use negative values on hitag and lotag.

[Helixhorned]

 Trooper Dan, on 26 February 2014 - 11:30 AM, said:

I had already disabled state lightsout and uploaded the CONs, but I'll go ahead and make this change as well.

Ah, in that case my change isn't necessary.

I'm interested into looking a bit deeper into the consequences of the signedness change of {lo,hi}tag myself, but I didn't apply the patches on top of the latest DukePlus from Fissile Materials since I'm waiting for the SVN repo.

[Danukem]

I'm keeping my latest DukePlus code here: http://fissile.duke4.net/dp/dpcons.zip

[Stabs]

now its an unplayable disco, every light has gone crazy

helix try this just with the latest DP, its a DNE map and .bat to start, i 100% guarantee you will see the problem, you dont need DNE resources either, its really all just art

 PATCH WORK.zip (222.22K)
Number of downloads: 171

with those latest cons its a disco

[Danukem]

That's strange. The only recent changes are a couple of checks in the pusing light code which should be harmless (preventing the light intensity from being zero or exceeding the initial max value), and the disabling of the lightout states (which again should be harmless). I could revert the changes or try some other stuff, but I'm too tired right now.

[Stabs]

Think this is eduke territory now isn't it?

i still have work to be done in the mean time.

[Danukem]

 DanM, on 26 February 2014 - 09:17 PM, said:

Think this is eduke territory now isn't it?

It should be a team effort. If there's a bug in eduke it's in our interest to make it as easy as possible to identify and fix. Also keep in mind that all of the CON code for manipulating polymer lights is essentially a set of hacks to add features to a WIP lighting system.

[Stabs]

version 3 of the alpha version of the patch, not quite beta yet

cool new TROR stuff in DNE04

- TROR Water
- TROR Office facilty
- TROR Broken Bridge
- Added a path and nuke button to get to the secret level ( hint : you need the bike to get there )
- Added secret level "Rapid Meat Roll" and DNE'ed it a bit
- Added egloves.zip and gloved weapons
- Tons of other texture tweaks and fixes in other levels
- ran error auto fix over all maps (each level had a level 1 wrap corruption, the fix seems to tweak slopes but no visible changes seem to be seen )

Hoping to change a lot of more hacky sprite based bridges into proper tror structures with the exception of the exterior of DNE05.

NOTE : Bike gets stuck under TROR sections that use 2 tic stairs in TROR

https://www.mediafir...dnfddqw2wyh0h9g

also use these dpcons from post #34 in my help me with a script thread, i dunno the proper link i have to use a web proxy duke4 is being a dick with my IP its static, might of flagged it as spam

[Helixhorned]

 Trooper Dan, on 26 February 2014 - 08:18 PM, said:

That's strange. The only recent changes are a couple of checks in the pusing light code which should be harmless (preventing the light intensity from being zero or exceeding the initial max value)

Posting what I think is the most recent version of the relevant code for reference:

Spoiler

		{
			// hitag the var is the max brightness
			// monstflags is the length of the cycle
			// initshade is the time offset on the cycle
				
			// tempe at a time = peak deviation from mid-intensity value * sin ( (frequency * time) + offset value )
			
			setvarvar tempd timer
			addvarvar tempd initshade 
			mulvarvar tempd monstflags // frequency * time
			sin tempe tempd
			mulvarvar tempe hitag
			shiftvarr tempe 14
			ifvarvarg tempe hitag setvarvar tempe hitag
			ifvare tempe 0 setvar tempe 1
			setactor[THISACTOR].hitag tempe
		}

The problem is not about exceedng the max value -- sin/cos should be perfectly fine and return values in [-16384 .. 16384]. It's that "small" negative hitag values will be converted to "large" positive ones on the C side. Hence, the correct fix is to bound 'tempe' below by 0. (Or by 1, if 'state lightsout' was not disabled.)

LunaCON now includes an option -ferror-negative-tag-write that may be useful for debugging this kind of issues. When I ran dne04.map on a still-not-updated DukePlus, the setactor[].hitag line from above was the only offender.

[Danukem]

oh thanks....I didn't realize that it was returning negative values