[Hendricks266]

Why would you simply disable a feature of the original game?

[icecoldduke]

TerminX, on 04 June 2017 - 05:40 PM, said:

If you're going to do that, you need to let the user type the old cheats directly into the console.

Fair enough, so for all commands I'm going to have both the original command and the more standardized command. So to turn on and off god mode, it would either be "god" or "swchan". That is now in my depot.

Hendricks266, on 04 June 2017 - 05:46 PM, said:

Why would you simply disable a feature of the original game?

Having less redundant systems in the codebase always makes things easier to maintain in the long run. In the short term, that system has a nasty bug in it, that I haven't been able to track down.

[icecoldduke]

Another question for you guys, I have been tracking down a issue in Polymer were "drawroomstotile" is not working correctly. When investigating I found that function to be really slow, and I tracked the issue down to setviewtotile where the engine temporally switches to the software renderer for render to texture. It gets reset to Polymer/Polymost in setviewback. So in Polymer and Polymost security cameras have always been using the software renderer for rendering. Would you guys mind if I switched that logic over to FBO's?

[TerminX]

If you can get it to work with Polymost too, go for it.

[Lunick]

icecoldduke, on 04 June 2017 - 05:29 PM, said:

• changelevel <level id> - changes level
  
• screenshot - takes a screenshot

Does anyone have a issue using the console instead of the old cheat text input mechanism?

Um, who would ever type screenshot into the console? Also the level change command should be "map" rather than "changelevel".

[Danukem]

icecoldduke, on 04 June 2017 - 05:59 PM, said:

Another question for you guys, I have been tracking down a issue in Polymer were "drawroomstotile" is not working correctly.

Upvoted because anything you can do to make polymer run better without fucking things up is good in my book.

[TerminX]

Lunick, on 04 June 2017 - 06:08 PM, said:

Um, who would ever type screenshot into the console? Also the level change command should be "map" rather than "changelevel".

There's a screenshot console command so you can bind it to keys. "map" usually starts a new game on a given filename, whereas "changelevel" continues the current game on a different level. They do different things.

[icecoldduke]

NEW BINARY RELEASE:

!!PLEASE DELETE ALL YOUR SAVED GAME DATA BEFORE PLAYING THIS PATCH!!!

NEW PATCH HERE:
https://forums.duke4...post__p__279012

WHATS NEW:

• POLYMER: Transparent water and FAF sectors now render correctly.
  
• POLYMER: Disabled remote camera rendering, doesn't work yet and caused performance issue. Will re-enable when fixed.
  
• Added new console commands for various cheat(developer) commands and disabled legacy command input system.
  
• MAPSTER: Sectornum will now be displayed for sprites/floors/ceilings.
  
• Added new fortune cookie text.
  
• Added more of Drek's hipal work.
  
• Deprecated BGL* system and replaced it with glew.

[icecoldduke]

TerminX, on 04 June 2017 - 06:05 PM, said:

If you can get it to work with Polymost too, go for it.

Yes this will work for both Polymost and Polymer.

[Hendricks266]

icecoldduke, on 04 June 2017 - 08:22 PM, said:

Added new fortune cookie text.

???

That's not in the job description of a source port.

[TerminX]

Hendricks266, on 04 June 2017 - 08:33 PM, said:

???

That's not in the job description of a source port.

Ugh, reminds me of my facepalm politicized multiplayer death messages in certain older versions of EDuke32.

[icecoldduke]

I'll put them back in a few patches, I'm testing a couple things for my third episode mod (which is the title of this topic ). Small shit like this will come and go in various patches until I branch off from this branch.

[Forge]

neato.
I hope this mod also includes proper shadows, enemies that actually drop ammo items, no random crashes, and full mouse support.

[icecoldduke]

Forge, on 04 June 2017 - 08:57 PM, said:

neato.
I hope this mod also includes proper shadows, enemies that actually drop ammo items, no random crashes, and full mouse support.

I assume your talking about the existing bugs in the game. I've been looking over your bug reports, did I miss one where you brought up the enemies aren't dropping items?

[icecoldduke]

Has anyone been using the new mapster thats included in the patch? If you guys can try it out because i'd like to get some insight on any potential fuckage in the editor. I've been able to make a few things but I haven't had the time to stress test it as much as I should.

[Mark]

I noticed 2 things with Mapster. The first one is minor. I'm used to having the game's map list show up as default instead of like now where you have to press Ctrl F to bring them up. Second thing is Mapster crashes to desktop as soon as the cursor hovers over an ST1 sprite in 3D mode. No error in the log. Does it with or without Polymer box ticked. I'll avoid those sprites for now and do some more testing.

[icecoldduke]

Mark., on 05 June 2017 - 08:00 AM, said:

I noticed 2 things with Mapster. The first one is minor. I'm used to having the game's map list show up as default instead of like now where you have to press Ctrl F to bring them up. Second thing is Mapster crashes to desktop as soon as the cursor hovers over an ST1 sprite in 3D mode. No error in the log. Does it with or without Polymer box ticked. I'll avoid those sprites for now and do some more testing.

Just curious what resolution are you running at? As a hunch can you try 1980x1200?

[Mark]

No crash if I choose full screen and my monitor's native 1920 x 1080. I noticed in 2D mode that some lines and sprites will slowly flash as normal and others will flicker when the mouse hovers over them.

Also, I love the instant switch back and forth between 2D and 3D. Although I don't know if thats your programming skills or this is normal for vanilla maps and 8bit assets. ( which I haven't used in my projects )

[icecoldduke]

Mark., on 05 June 2017 - 08:11 AM, said:

No crash if I choose full screen and my monitor's native 1920 x 1080. I noticed in 2D mode that some lines and sprites will slowly flash as normal and others will flicker when the mouse hovers over them

I think whats happening is this. I added more info for SW to the mouse hover ui box. I think there is some array that I missed that is allocating some array that has a limit on the number of lines it can display, and this is causing the crash. I'll fix this crash as soon as I can, in the mean time please run your editor at 1920x1080 or higher. I do this by default because I have a 4k monitor at home, which is how I missed this.

Mark., on 05 June 2017 - 08:11 AM, said:

Also, I love the instant switch back and forth between 2D and 3D. Although I don't know if thats your programming skills or this is normal for vanilla maps and 8bit assets. ( which I haven't used in my projects )

In Duke3D mapster, the instant switch also happens when the 2d and 3d resolutions match up. In sw mapster the 2d/3d screen resolutions are the same(set by the resolution you select on startup). Does anyone need the resolution for 2d and 3d mode to ever be different?

[Mark]

The reason I ran in a lower than fullscreen res is because that messes with my ability to "tab out" of Mapster with my windows key and properly navigate my desktop. But for testing purposes I can deal with it.

What sprite do I tag to make a Polymer light?

[icecoldduke]

Mark., on 05 June 2017 - 08:35 AM, said:

The reason I ran in a lower than fullscreen res is because that messes with my ability to "tab out" of Mapster with my windows key and properly navigate my desktop. But for testing purposes I can deal with it.

I will try and get this fixed asap, but it might be a couple days. Thanks for testing this out .

[icecoldduke]

Mark., on 05 June 2017 - 08:35 AM, said:

What sprite do I tag to make a Polymer light?

ST1:
HiTag 597
TAG13=ZOffset
TAG6=LightRange
TAG7=Red Color(0-255)
TAG8=Green Color(0-255)
TAG9=Blue Color(0-255)
TAG10=Priority

[Mark]

Thanks. I guess that answers my other question about the need for those 2 long lines of tagging info. Its an SW thang.

Before posting I tried ST1 but I used the regular Mapster way of F8 and filling in the blanks with the values I'm used to. I'll have to get used to the SW way of doing things. I'll see if I can find my ancient SW FAQ I printed out years ago.

[icecoldduke]

Mark., on 05 June 2017 - 08:41 AM, said:

Before posting I tried ST1 but I used the regular Mapster way of F8 and filling in the blanks with the values I'm used to. I'll have to get used to the SW way of doing things.

Yeah you can't do that, in the next build I'll remove that from swmapster. You have to use the tags .

[Mark]

When I tried it i was hoping that inserting values like normal into the x,y,zvel would correspond to the higher tag numbers used in SW. No such luck.

[icecoldduke]

Mark., on 05 June 2017 - 08:53 AM, said:

When I tried it i was hoping that inserting values like normal into the x,y,zvel would correspond to the higher tag numbers used in SW. No such luck.

While SW tags use xvel, yvel, etc the tags piggy back multiple tags on xvel, yvel, etc via bit modifications, which is why you have to use the tagging system .

[Kyanos]

How did you implement tagging buttons? Is it like sw build? shift : #

Also I may as well ask here, can anyone recommend a good hex editor with copy paste? It's for the last few lookup.dat slots that I can't edit in openglbt.

Another also, just tested the editor and I'm getting the same crash as Mark, I can report this is definitely new behavior.

[icecoldduke]

The work around for the swmapster crash is to run the editor at 1920x1080 or higher. I will get a patch out as soon as I can.

I don't have the button layout in front of me, but the button combos for editing tags is the same as the dos editor.

[Kyanos]

Umm I'm on a 4:3 monitor. It's all good though I can also report that it worked for me at 1152xsomething windowed, the highest one it defaulted to when I clicked off fullscreen.

I'd prefer to edit them in 3dmode... I'd also prefer the editor to default to windowed and 32bpp.

[Mark]

I'm pretty sure this came up in the past but I have forgotten the answer. Are you going to add an option to offset player height in Mapster to make it a match for height in the game? The scale being so far off is a deal breaker for me in using SWMapster.
In a map I walked up to a counter and the top was at eye level. Wall switches are above the player's head