[Hendricks266]

That was a feature specifically requested by Cage Diaz. Any reason why I should revert it or make it conditional?

[Gambini]

Well, that sound always set me in the mood of playing the game, been listening to it for (you know how many years). I don´t know the reasons of why Cage asked for it, but if they are speficic to his project, I indeed would consider it as optional.

[Player Lin]

Hendricks266, on 29 January 2013 - 02:55 PM, said:

That was a feature specifically requested by Cage. Any reason why I should revert it or make it conditional?

No, it actually requested by Diaz, in this topic too,...last year.
(After trying to find Cage's all 90 posts in whole Duke4.net forum, and then I think it's not by him. )

http://forums.duke4....798#entry141798


It's only weird if you skip the default/short intro in original/mods' LOGO.ANM, otherwise it just minor problem.
(Maybe it's better make it "optional" for maps/mods/TCs needed it.)

[Diaz]

Making it optional somehow seems fair.

[Player Lin]

Player Lin, on 26 January 2013 - 06:56 AM, said:

I tried the latest one synthesis build of eduke32 (r3433), I noticed two small glitches/bugs happened...

1. ALT-TAB out from eduke32 and go back to it will cause it forced to switching to window mode, only happens on 16/32bit OpenGL renderer, software one is fine.

2. The sector light level that player's direction of facing(or something related the light level of sector) will affected AutoMap's "light level" too, if I faced/stand on a room where it's very dark, when I actives AutoMap and it will looks very dark too, again it only happens on OpenGL renderer too, classic software just working fine as hell.

Sorry to say again, with current r3458, the two problems still exist on my end...but the second one just a bit less happened but I'm not sure, still... some of dark area made totally dark when I using Automap with polymost...

[Gambini]

I´m gonna post this bug as a Murphy´s law:

Stayput enemies are not.

I have a hunch that this is related to sprites updating their sectnum when coming too close to the boundaries. Maybe it has been intentionally added to prevent glitches with sprites being in the wrong sector. The problem is noticeable when you put enemies on a subway sector. When they see the player they will try to walk towards him and as soon as they hit the wall, they fall off the subway. This isnt the original behavior AFAIK. I remember my making traffic full of enemies on board and they´d never get off their transport.

[Gambini]

Yeah who cares...

[OpenMaw]

Gambini, on 06 February 2013 - 04:41 PM, said:

Yeah who cares...

I care.

Just can't code!

[TerminX]

What revision did this behavior change in?

[Gambini]

Mmmmh interesting question. Last time I used a similar effect, it was 1997 and I was running Build.exe. That´s like 800 weeks ago.

I´m gonna do a research and come back to you with a result as accurate as possible.

[TerminX]

Thanks! I know it can be a pain to download and test a bunch of old builds, but it really helps us immensely when tracking issues like these down.

[Gambini]

Well, I started with one of my favourite builds (5-14-2006, one of the last versions with that sofware polymost) and noticed that while it seems to take them much more time to fall, they eventually fall too. Just to be sure I tested it in jonof and the behaviour is similar than with the formerly mentioned build.

So while not entirely something broken, it is indeed worse than before. In my tests I had to chase these cars half their itinerary in order to make the liztroops fall off (eduke 2006 and Jonof). While as with the newer builds (two with a few months of difference) the enemies get down the car ten times faster.

I know I should narrow down the exact snapshot where this changed, but seeing how that could take years considering the seemingly subtle difference. I´d end in a point of not noticing the difference.

Here´s the example map attached I´m talking about. Try to walk following these cars -any of them- and watch how the liztroop gets down the car. It is interesting that the player, when riding them is also like pushed outwards as longer the trip is. But I have no idea if that´s new or old.

In any case if both things could be improved/completely fixed. I´d be quite happy. This is an isolated and cleaned part of an actual map, so any success on improving that thing in this map will directly translate to make the actual mpa work better.

Attached File(s)

•  stayput.rar (5.97K)
  Number of downloads: 178

[Kyanos]

I wasn't sure where to post this, but anyways...
I made a fence, maskwall, using a transparent sprite. I made a sliver of a section in front of it, with blocking walls to set the height of my fence. I then raised the height of the sectors in front of that and behind the fence for walls to align correctly at a functional game height.

Now here comes my minor annoyance, in software as expected the fence is as high as I set the sector in front of it, as intended. However, in polymer the fence is the height of the sector behind, a non accessible sector just for background.

[Plagman]

Any chance you can make a small test map that shows the difference when switching between classic and polymer? This ought to be easily fixable. If you link the map there there's more chance I'll remember to check it out, too:

http://wiki.eduke32....er_Deficiencies

[Awakened]

I got a nice 120hz monitor awhile back, but I can't get eduke to run at that refresh rate fullscreen. It always automatically switches to 60hz, even with MaxRefreshFreq set to 120. It does stay 120hz if I run in windowed mode though.

Edit:
Found a way around this. Setting ScreenMode to 2, border-less fullscreen, leaves my monitor running at the default desktop 120hz.

[Mike Norvak]

Gambini, on 06 February 2013 - 06:50 PM, said:

Well, I started with one of my favourite builds (5-14-2006, one of the last versions with that sofware polymost) and noticed that while it seems to take them much more time to fall, they eventually fall too. Just to be sure I tested it in jonof and the behaviour is similar than with the formerly mentioned build.

So while not entirely something broken, it is indeed worse than before. In my tests I had to chase these cars half their itinerary in order to make the liztroops fall off (eduke 2006 and Jonof). While as with the newer builds (two with a few months of difference) the enemies get down the car ten times faster.

I know I should narrow down the exact snapshot where this changed, but seeing how that could take years considering the seemingly subtle difference. I´d end in a point of not noticing the difference.

Here´s the example map attached I´m talking about. Try to walk following these cars -any of them- and watch how the liztroop gets down the car. It is interesting that the player, when riding them is also like pushed outwards as longer the trip is. But I have no idea if that´s new or old.

In any case if both things could be improved/completely fixed. I´d be quite happy. This is an isolated and cleaned part of an actual map, so any success on improving that thing in this map will directly translate to make the actual mpa work better.

Okay, I tested the map and I found that behavior was introduced in r3317 (being 3314 the latest without it) and I'm pretty sure it has something to do with this:

Quote

r3316 | helixhorned | 2012-12-23 11:24:21 -0800 (Sun, 23 Dec 2012) | 7 lines

Fix rotation-fixed useractors (those having usertype bit 4 set).

Rotation-fixing happens for a couple of hard-coded statnums that presumably
never move (DEFAULT, STANDABLE, FX, FALLER, LIGHT), but for actors it wouldn't
make sense since the common case is that they do move. For this reason, bit 4
was introduced in r1934. The position of such useractors will not diverge
due to error roundoff accumulation in rotating sectors (SE0, train).

Now let's get to work!!!!

[Gambini]

Thanks Mike! Unfortunately I sense the bugs I report are deliberately ignored. So next time i find something gruesome, i will just shut the fuck up so it gets a chance to be fixed.

Quote

Now here comes my minor annoyance, in software as expected the fence is as high as I set the sector in front of it, as intended. However, in polymer the fence is the height of the sector behind, a non accessible sector just for background.

I reported that issue a thousand years ago, it even got a track in the svn and a testing map, will see if i can find it.

[Plagman]

Sorry... most of the time when read reports I'm doing something else (eg. at work) so I can't really do anything about it immediately, and then it just falls off the radar. I'm sure it's like that most of the time with everyone including helix, etc, so don't hesitate to nag about small issues if you think they dropped off the radar.

[Gambini]

double post, attached it is a map file showing the maskwall issue. it´s the same old map so ignore the other things.

Here´s also the tracker that Plagman did for the bug, created in 2009.

http://sourceforge.n...duke32/bugs/25/

Plagman: didnt see your message. Ok, as you suggest, here´s my nagging

Attached File(s)

•  Buuuugs!.rar (810bytes)
  Number of downloads: 181

[Danukem]

The quake CON command seems to be broken. Try putting this in the player actor code:

ifhitspace quake 300

The quake will only last for 2 seconds, not 300 tics.

[TerminX]

The parameter in question is an unsigned 8-bit int, when 300 is cast to that type you would end up with a value of 44 (since an unsigned 8-bit int is 0-255, 256 would be 0, 257 would be 1, etc) or about a second and a half.

[Helixhorned]

 Gambini, on 06 February 2013 - 06:50 PM, said:

Well, I started with one of my favourite builds (5-14-2006, one of the last versions with that sofware polymost) and noticed that while it seems to take them much more time to fall, they eventually fall too. Just to be sure I tested it in jonof and the behaviour is similar than with the formerly mentioned build.

So while not entirely something broken, it is indeed worse than before. In my tests I had to chase these cars half their itinerary in order to make the liztroops fall off (eduke 2006 and Jonof). While as with the newer builds (two with a few months of difference) the enemies get down the car ten times faster.

(...)

Here´s the example map attached I´m talking about. Try to walk following these cars -any of them- and watch how the liztroop gets down the car. It is interesting that the player, when riding them is also like pushed outwards as longer the trip is. But I have no idea if that´s new or old.

I tested the map in Duke3D 1.5 running under DosBox and for me, it took maybe twice as long as current EDuke32 for the liztroop to fall from the subway. But since I did that only once, it's hard to say whether it was due to chance or not.

 Norvak, on 10 February 2013 - 12:06 PM, said:

Okay, I tested the map and I found that behavior was introduced in r3317 (being 3314 the latest without it) and I'm pretty sure it has something to do with this:

This makes sense, but that was rather a bug fixed. In r3102, TX refactored some code but accidentally made the "rotation-fixed useractor" behavior apply to enemies. This made them stay at exactly the same point with respect to the pivot on rotating sectors, assuming they were spawned into such a sector from premap. Making enemies stayput is supposed to make them stay in their sector but letting them free to roam it. However, it doesn't really work when that sector moves under their feet.

So either
1) Duke3D and EDuke32 really differ in this respect, but the change was introduced prior to r3102, or
2) there's no difference, but that should be tested with more runs of the "train-chasing" experiment.

If rotation-fixing if desired for enemies, it could be made to be controlled by a per-sprite bit from CON. Currently, it is a per-tile setting.

[Gambini]

In the old times (like a month ago) maps became fully visible when you shoot, in Duke. Now, it fucking blinks white! what the hell is that? I have also been told that it tears the screen if you aern´t using v-sync. Something that seems to happen only in Polymost?

[Plagman]

Yes, the screen tears if you're not using V-Sync; it's always been like that and will always be more noticeable when the whole screen changes suddenly such as a flash. That's a general rule of life that applies to everything, not just EDuke32.

What do you mean about the screen blinking white, though?

[Gambini]

It´s like before the whole map turned into vis 240 when you were shooting. Now it looks like the whole map becomes white while you are shooting. I´ve been told of this, because I dont use polymost too much. But I tested and it is indeed quite annoying, it kind of hurts your eyes if you have a Ten Feet Screen like mine

Well, these days I use to include screenshots to go with my reports, but this is, as you can imagine, a hard one.

[Fox]

I remember that the errors with water surface sectors have been there for quite some time.

Projectile hit the paralaxed sky in lo-tag 1 sectors:

Spoiler

Actors (that are not moving?) do not submerge:

Spoiler

Actor clickers in and out of water:



This became an issue when I was specifically trying to predict how an actor would submerge...

[Fox]

How weird, I just realized that the shading in polymodes for sprites on the screen is different from that of the level.



As you can see above, the dropped Pipebomb is similar to the weapon in 8-bit mode, while in polymost it is completely different.

[Fox]

Is it possible to fix the bug which sprites offset doesn't flip with it in Polymodes?

[Gambini]

Second that! It´s an important thing.

[Plagman]

Can you post this map?