[PsychoGoatee]

I posted in the wrong thread, so I'll say well, Duke on!

[Fox]

Trooper Dan, on 03 June 2018 - 02:25 PM, said:

Anyways, I thought to try EVENT_DISPLAYCAMERAOSD, which of course isn't documented.

It's used to display CAMCORNER and CAMLIGHT when viewing through a security camera.

[Mark]

I have brought this issue up a few times over the years and I don't remember what the replies were or why it has never been resolved.

Flickering of wall sprites under polymer. When a sprite is placed on a wall, Mapster offsets it a tiny little bit away from the wall when looking at it in 2D mode. That makes it a 50/50 chance that it will flicker in game using Polymer. My solution has been to turn off grid locking and manually drag the sprite a tiny bit further from the wall. Flickering problem solved. But seeing as how I have had to do this many 100's, maybe more than a 1,000 times over the years in all my projects it sure would be nice to have Mapster automatically place new sprites further away.

My suggestion is double the number that is used in that calculation right now. My pic shows the default placement on the left and where I manually drag it to on the right. Just that tiny bit of placement makes the problem go away. For reference in the pic, mapster is set for the smallest grid square.

Attached thumbnail(s)

• 

[Mark]

No response? I'm guessing the problem may be an issue with the Polymer renderer. But since messing with that isn't very feasible I thought getting the fix through Mapster would be the hot ticket. Any foreseen problems with the Mapster fix?

[Danukem]

Mark., on 13 June 2018 - 10:47 AM, said:

No response? I'm guessing the problem may be an issue with the Polymer renderer. But since messing with that isn't very feasible I thought getting the fix through Mapster would be the hot ticket. Any foreseen problems with the Mapster fix?

I'm pretty sure they don't want to make mapster changes based on Polymer glitches. But you could strengthen your case if you could show that the old default distance used in the original maps was larger and did not cause the issue.

Also, I don't have time to do this right now, but one could make a mapster script that would adjust the distances for the entire map all at once so you wouldn't have to do it manually.

[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