[Mark]

IIRC It does cause the flicker in vanilla maps. This has been happening for years. I thought I would bring it up again in case someone wanted to try what I thought would be a good compromise fix. I'll just continue my workaround for another few hundred times. Its not a mod breaker.

[TerminX]

Polymer still has issues with z buffer fighting regarding wall oriented sprites, yeah. Changing the editor to place sprites further away from the walls is just a band-aid "fix" and isn't really acceptable--the issue will have to be addressed in Polymer itself if/when it enters active development in the future.

[Mark]

sigh

[Tea Monster]

If your name were Jim, I could tell you something.

[Mark]

Huh?

Attached thumbnail(s)

• 

[Mark]

TerminX, on 13 June 2018 - 05:08 PM, said:

Polymer still has issues with z buffer fighting regarding wall oriented sprites, yeah. Changing the editor to place sprites further away from the walls is just a band-aid "fix" and isn't really acceptable--the issue will have to be addressed in Polymer itself if/when it enters active development in the future.

I determined the band-aid fix to be acceptable and asked someone to apply it to Mapster32 for me. It works great. I know, if I want to continue using this feature I have to stay with this revision. I don't want to keep bugging this guy every couple of months to apply the band-aid to the latest revision. But right now its a decent tradeoff.

[Micky C]

Couldn’t you just add a mapster script solution?

[Mark]

I'm sure its possible. But wouldn't the script be run from the console after the sprites are placed? In the mean time they would flicker and sometimes be hard to select and pan/resize.

Or would the script automatically run at Mapster startup and place the sprites away from the wall by default like my version does?

[Kyanos]

Micky C, on 24 June 2018 - 06:10 AM, said:

Couldn’t you just add a mapster script solution?

Hmmm, how would you determine which sprites to move and when to move them. Just sorting for wall aligned sprites isn't enough, you would need to check if they are close to a wall. It's not so complex for trig, but a fair bit complex for m32 script.



Eg) Rooftop E1L1, the fence;
These sprites are all pretty close to a wall, so the script should move them, but then the corners will open up (more than they already are.)
Also these sprites are above the wall and don't actually z-fight with anything because there is nothing behind them... so maybe they shouldn't move after all but now that's a hell of a lot of extra scripting, and what is that checking for, the height of the floor on the other side of a red wall if the sprite is even against a red wall, it may be a white wall and be empty back there...

[Danukem]

But if the script is written to apply to alt-selected sectors, then he could just decide which ones to include, whether its the whole map or a specific part. His maps may not even contain any situations similar to the fence area in E1L1.

[Mark]

That sounds like I would move the sprites with the script long after they are placed in the map. I much prefer to have them away from the wall at the time they are placed. I can't tell you how many times I was changing sprite size or height by holding down a key, the sprite flickers out and the wall behind it now changes. Or if the sprite has flickered completely out I have to move to get it back in view to mess with it. I don't find changing them with script after the fact as the prefered band-aid fix.

Also, the extra time and effort to zoom in all over the map to find and alt-select the proper sprites to run the script on would be a hassle. In my opinion, hacked Mapster32 is the best solution for me at this time.

If a Mapster script can be autoran at startup and perform the same sprite placement away from the wall at the time it is placed there I would say go for it. But right now it doesn't look to be that way. Until then it will be hard to talk me out of hacked mapster which does exactly what I wanted.

[Danukem]

Mark., on 24 June 2018 - 10:50 AM, said:

That sounds like I would move the sprites with the script long after they are placed in the map. I much prefer to have them away from the wall at the time they are placed.

Well I don't know how I would make a mapster script intercept and adjust the sprite placement as it happens. The only way I know how to do it is when the user deliberately runs the script.

[Mark]

Sorry. I hit refresh and your post did not display so I added on to mine. So that just confirms in my mind I made the right choice for a band-aid until a Polymer fix happens, if ever.

[Kyanos]

Trooper Dan, on 24 June 2018 - 10:53 AM, said:

Well I don't know how I would make a mapster script intercept and adjust the sprite placement as it happens. The only way I know how to do it is when the user deliberately runs the script.

m32 script is many things, undocumented and surprising being just two of them.

onevent EVENT_INSERTSPRITE3D
    set k I
    for i spritesofsector .sectnum
    {
        ife i k
        {
            set .lotag 10
        }
    }
endevent

I read about EVENT_INSERTSPRITE2D in a.m32 so I just tried to do something random using event insert sprite 3d and it works. Maybe a script solution is feasible.

[Mark]

Once again Drek has...

Attached thumbnail(s)

• 

[Kyanos]

This has gone far beyond my level of caring lol, but I do have a m32 that sort of accomplishes this, most of the time, doesn't seem to like 45 degree angle walls for some reason I'm far to tired to look into at this point.

////////// MOVE SPRITE ORNAMENTED (TESTING-6/24/2018) //////////

gamevar mso_i 0 0
gamevar mso_j 0 0
gamevar mso_k 0 0


onevent EVENT_INSERTSPRITE3D
    set mso_i -1
    set mso_j -1
    set mso_k 0
    
    ifaimingsprite nullop else
    ifaimingwall
    ife searchstat 0
    {                
            // j = wall[hitw].point2;
            // sprite[i].x -= ksgn(wall[j].y-wall[hitw].y);
            // sprite[i].y += ksgn(wall[j].x-wall[hitw].x);
        set mso_i -1
        set mso_j -1
        set mso_k 0
        setvarvar mso_j wall[searchwall].point2;
        
        setvarvar mso_i wall[mso_j].y 
        subvarvar mso_i wall[searchwall].y
        cos mso_k mso_i   
        divvar mso_k 512
        subvarvar .x mso_k;
        
        set mso_i -1
        set mso_k 0
        
        setvarvar mso_i wall[mso_j].x 
        subvarvar mso_i wall[searchwall].x
        sin mso_k mso_i   
        divvar mso_k 512
        subvarvar .y mso_k;
    }
endevent

[MatthewPatel]

Just a question if I may, that Duke UI spinning model, is it broken due to that new v5.1 hrp model that was added?

Because prior to that, it used a 3D spinning Duke model in the menu, now it's just the regular sprite.

Probably old, but just wanted to know.

[Hendricks266]

Do you mean the Duke in the Player Setup menu? I am confused because there is no "spinning Duke" in the menu anywhere.

[December Man]

Hey guys.

I've returned to Duke after a year, downloaded the newest version of eDuke32 and noticed some of my Cosmetic Duke code does not seem to work anymore i.e. specifically the casings on the Pistol and Shotgun. Funnily enough, the Chaingun casings and Pistol magazines (all of which are projectiles) work fine.

Mod:

https://www.mediafir...c8/CosmDuke.zip

I've tracked the specific version wherein the code stops working to 20170727-6388. It still works fine on 20170720-6372. I don't know whether this is a bug or some change I need to adjust my code to.

[darkprince227]

Just downloaded the latest eduke32 build. Not sure why but my AVG didn't seem to like it until I turned off CyberCapture.

Other than that, I can't see any problems. I'll let you guys know if anything comes up.

[TerminX]

darkprince227, on 26 July 2018 - 11:12 AM, said:

Just downloaded the latest eduke32 build. Not sure why but my AVG didn't seem to like it until I turned off CyberCapture.

Other than that, I can't see any problems. I'll let you guys know if anything comes up.

Did you download the 32-bit version or the 64-bit version?

[darkprince227]

TerminX, on 26 July 2018 - 01:25 PM, said:

Did you download the 32-bit version or the 64-bit version?

It was the 32-bit version now that I look at it. Don't know why though, I have a 64-bit machine.

i think I just really wanted to download and a lot of the time, when I try it says "Server busy or per-user connection limit exceeded." until I download something else on the page and THEN click on it.
AVG says the file is safe though.

EDIT: I turned CyberCapture back on and it seems to be working OK.

[Phredreeke]

TerminX, on 26 July 2018 - 01:25 PM, said:

Did you download the 32-bit version or the 64-bit version?

How about adding an alert (that can be optionally disabled) when you run the 32-bit version on a 64-bit OS?

[TerminX]

Phredreeke, on 27 July 2018 - 03:56 AM, said:

How about adding an alert (that can be optionally disabled) when you run the 32-bit version on a 64-bit OS?

It doesn't have anything to do with that... it has to do with the 32-bit version of the classic software renderer making somewhat extensive use of self-modifying code that Ken wrote by hand in x86 assembly. From the virus scanner's point of view, there is little to no distinction between this sort of thing and what certain kinds of nasty malware may do to try and obfuscate its behavior.

This is one of the reasons there is no 32-bit version of Ion Maiden.

[Phredreeke]

I know it won't help antivirus alerts, but it would help with people who unknowingly download the wrong version

[Player Lin]

Phredreeke, on 27 July 2018 - 12:03 PM, said:

I know it won't help antivirus alerts, but it would help with people who unknowingly download the wrong version

No, the real help is sent the exe file to those antivirus companies(whose AV program detected) and complain about these kind of false alerts to them I think...

Unless someone already did and they don't give a shit...

[Romulus]

I remember back in the olden days McAfee used to flag DUKE3D.GRP as a virus.

[Phredreeke]

Player Lin, on 27 July 2018 - 10:04 PM, said:

No, the real help is sent the exe file to those antivirus companies(whose AV program detected) and complain about these kind of false alerts to them I think...

Of course false positives are a problem. But even without them, running the 32-bit version on a 64-bit system is suboptimal. I did so myself for the longest time without realising it

[necroslut]

Player Lin, on 27 July 2018 - 10:04 PM, said:

No, the real help is sent the exe file to those antivirus companies(whose AV program detected) and complain about these kind of false alerts to them I think...

Unless someone already did and they don't give a shit...

But EDuke32 gets several new versions a week... wouldn't it just repeat with each new release?

[Player Lin]

necroslut, on 28 July 2018 - 07:21 AM, said:

But EDuke32 gets several new versions a week... wouldn't it just repeat with each new release?

Normally it should be fine just a verison of EDuke32 should work fine for analyzing, based what TX was said, but I'm not expert of AV so I'm not sure. I don't think those problematic code will keep changes on every version of EDuke32, if it does, then I can only suggest keep sent them the new files (still detected) or just change your AV software if it acting too sensitive. The world is already so sensitive I don't need my AV keeping to do the same shit to me so often.


Better keep bother the AV's support team/devs if still want using the AV and EDuke32 the same time if you ask me.