[Micky C]

Just tried out the latest commit, and well done Helix! The transition to dark in polymost looks a lot smoother and less sudden. I could run towards a wall from a distance and watch it slowly get darker. I can't remember exactly how it was before, but this feels much better.

Also congradutaions on your first commit hendricks, even if you did have to go back and fix it
That's some nice work with the BROKEHYDROPLANT and REACTOR2 sprites.

[Daniel]

Micky C, on 24 July 2011 - 06:55 PM, said:

Just tried out the latest commit, and well done Helix! The transition to dark in polymost looks a lot smoother and less sudden. I could run towards a wall from a distance and watch it slowly get darker. I can't remember exactly how it was before, but this feels much better.

Also congradutaions on your first commit hendricks, even if you did have to go back and fix it
That's some nice work with the BROKEHYDROPLANT and REACTOR2 sprites.

im very glad Helix fix this issue, it takes lots of emails with my cr*p English so i draw him pictures how shading should look like and what was wrong with it

pre-1940 builds code:





Proposed version:



1943+ Builds:



i tried contact TerminX in first place but seemed he dont cared about my issue with shading

[TerminX]

It's not a matter of not caring, it's a matter of having 20 million things to do every day and very very little time to spend on EDuke32 anymore currently.

Helixhorned did do a nice job of tweaking my crappy shading algorithm, though.

[Fox]

Hmm, I assume there really isn't a perfect way of doing that, since it's not a question of a mathematic formula for the shading, but it is based on a lookup table that is more artistic.

[TerminX]

You assume correctly. The whole implementation of sector visibility in Polymost and Polymer is just a bullshit hack I came up with that alters the GL fog depth for every object or surface drawn to approximate the results of that lookup table you mentioned. It still looks a LOT better than the original Polymost from JFDuke3D though!

[Tea Monster]

That is so cool

[DavoX]

Awesome!!!

[Daedolon]

It's finally fixed? That's great news.

[Roma Loom]

Is it possible to implement a feature in mapster32 where you can highlight a sector by entering it's Number?

[Helixhorned]

You can already do that by entering

do sethighlightsector <sectnum> <set?>

in the OSD ('do' can be omitted if 'osdtryscript' is set to 1 in mapster32.cfg).

[Roma Loom]

Great, it really works Thanks.

[Hendricks266]

 Micky C, on 24 July 2011 - 06:55 PM, said:

Also congradutaions on your first commit hendricks, even if you did have to go back and fix it

I made the commit but I forgot to make the announcement!

New Feature: CON/DEF Modules

This is a gradual step towards my goal of a much more user-friendly method to mix and match mods, packs, and generally anything distributed for EDuke32.

CON and DEF modules are individual, stand-alone files that are in effect included after, or from the end of the previous file, whether it's the default root file or another module.

This should make life easier for creators of small gameplay mods, as well as mappers who want to add only small things to the con files (such as an episode listing or some new sprite code) but don't want to restrict use to only a certain set of base cons.

Internally, a dynamic array stores the file names of modules, so there is no limit on the amount you can use other than available RAM.

Here's an example of the syntax: eduke32 -xgame.con -mx module1.con -mx module2.con -hduke3d.def -mh module.def

Disclosure: I used the term "module" rather than "mutator" because in the discussion in IRC channel, there were some strong opinions that mutators should not be added unless the names of gamevars were mangled by the executable to prevent conflicts. I think that's unnecessary, and there are times when you might want to change the value of a gamevar used elsewhere. Regardless, you're free to refer to them as mutators.

[Plagman]

Hendricks266, on 28 July 2011 - 07:28 AM, said:

Disclosure: I used the term "module" rather than "mutator" because in the discussion in IRC channel, there were some strong opinions that mutators should not be added unless the names of gamevars were mangled by the executable to prevent conflicts. I think that's unnecessary, and there are times when you might want to change the value of a gamevar used elsewhere. Regardless, you're free to refer to them as mutators.

There should probably be a "best practices" document that explains this and advises future coders to namespace their identifiers. I can't imagine how many problems we'll have about people wondering what's up with their "TEST" gamevar unless this is made very clear.

[Hendricks266]

That's a good idea for the wiki. It's pretty deficient in terms of a "How To Package Your Mod" guide. I'm not going to work on one for a while because it could quickly become obsolete, and I don't have a lot of cross-platform experience.

[Master Fibbles]

This is random and maybe someone has already said something about it or it is just me:
When editing I might get a crash or something in Mapster32 and then I load up either autosave (I maybe even reloaded the map I was working on) and there are no sprites in the map. I can't remember exactly how it went down, but I was editing and then there were no sprites in my map; and I had some complicated explosion stuff in there already set up.

I'd see if I could reproduce it, but I'd rather not.

[Mike Norvak]

Hey Helixhorned it could be possible you make a method to draw guide lines in mapster?, it could be put just like the regular lines for sectors but these lines serves as reference porpuses, and the mapper could draw and crossing sectors over them, exactly as the background grid...

[Helixhorned]

Mr.Flibble, on 29 July 2011 - 06:40 AM, said:

This is random and maybe someone has already said something about it or it is just me:
When editing I might get a crash or something in Mapster32 and then I load up either autosave (I maybe even reloaded the map I was working on) and there are no sprites in the map. I can't remember exactly how it went down, but I was editing and then there were no sprites in my map; and I had some complicated explosion stuff in there already set up.

I'd see if I could reproduce it, but I'd rather not.

That's unfortunate. The best thing would be crashlog, or if you don't mind, the map before and after the corruption (you did make backups, right?)

Norvak, on 29 July 2011 - 03:20 PM, said:

Hey Helixhorned it could be possible you make a method to draw guide lines in mapster?, it could be put just like the regular lines for sectors but these lines serves as reference porpuses, and the mapper could draw and crossing sectors over them, exactly as the background grid...

So you should be able to draw lines that, instead of being walls, simply add reference points in the XY plane which further wall drawing snaps to? What's the use case for that of you already can make the grid very finely meshed?

[Master Fibbles]

Helixhorned, on 30 July 2011 - 12:26 AM, said:

That's unfortunate. The best thing would be crashlog, or if you don't mind, the map before and after the corruption (you did make backups, right?)

Sadly, I don't think I have any of those. I've messed with it since. The crash comes from alt-tabing to Notepad to look at the MapFAQ or something like that. I'll see if I can reproduce it with a more crash oriented mode on a map that is backed up.

EDIT: Actually, I figured it out.
The problem is from using the undo feature. At some point while undoing it erased all of the sprites in the map. I must have only noticed it when I reloaded after a crash. That would explain why I didn't have a back up of the level with sprites.

Attached File(s)

•  newboard-error.zip (16.88K)
  Number of downloads: 642

[Hendricks266]

Mr.Flibble, on 30 July 2011 - 06:24 AM, said:

The problem is from using the undo feature. At some point while undoing it erased all of the sprites in the map.

I've had that happen to me before, but I just chalked it up to "use the undo feature at your own risk".

[Mike Norvak]

Helixhorned, on 30 July 2011 - 12:26 AM, said:

So you should be able to draw lines that, instead of being walls, simply add reference points in the XY plane which further wall drawing snaps to? What's the use case for that of you already can make the grid very finely meshed?

Well I ended up doing it with the regular white lines as reference, what i needed was to make diagonal lines with no common angles to make circles, I used them to make an sloped spiral, so i think my request isn't really necesary we can always use other alternative methods

[Hendricks266]

Feel free to add to this list of Polymer deficiencies.

[Radar]

Hendricks266, on 09 August 2011 - 01:15 PM, said:

Feel free to add to this list of Polymer deficiencies.

"not hooked up to TX's Sector Effector-based ROR"

TX's? Don't you mean Helixhorn's? Or is this some other type of ROR I'm not aware of...

[TerminX]

No, he's talking about the ROR system I wrote before Helixhorned added the map based ROR.

[Hendricks266]

No, I mean TX's. TX wrote an ROR implementation using sector effectors (i.e. only applicable to Duke 3D) some time ago and it works well in classic and Polymost, but he left it up to Plagman to support it in Polymer. Later, Helixhorned added TROR (T for "true") because the ROR is actually stored in the map and it's implemented into EDuke32's BUILD engine code.

[DavoX]

Is there a way to use TX's version of ROR in polymer for people that find it really hard to juggle between all the lines?

[Hendricks266]

That's why it's on the list of deficiencies, it doesn't work in Polymer yet. You can use it in your maps but it won't work in Polymer for the time being.

[Micky C]

I tried using it once. It seemed buggy, and there isnt a good way to actually move between the TROR rooms as far as I can tell. I was under the impression it's unfinished.

[Hendricks266]

It works fine. For example, try NWL5 of NW+.

[Danukem]

Starting with r1957, view warping no longer occurs when the player changes size. This is due to Helixhorned making r_usenewaspect on by default (turning that off makes it work fine again).

[Jblade]

DeeperThought, on 10 August 2011 - 01:10 AM, said:

Starting with r1957, view warping no longer occurs when the player changes size. This is due to Helixhorned making r_usenewaspect on by default (turning that off makes it work fine again).

Just testing 1961, I think this part is fixed but the screen goes back to the old aspect if the player's view is rotated.

edit edit: actually it does look much better!

edit2: Ok - when I'm playing in fullscreen the aspect or whatever is fine when rotscrnang is changed. but If I play in windowed mode the aspect goes all weird when rotscrnang is used.