[Jblade]

Any chance of a flag for walls being added that lets us hide it from the map-screen? Or sectors, if not that? There's something similar in Zdoom and it would be a handy feature to have to hide secrets, or signatures, or effect sectors if we wanted to add an auto-map pickup for example.

[Danukem]

 James, on 04 April 2013 - 03:49 AM, said:

Any chance of a flag for walls being added that lets us hide it from the map-screen? Or sectors, if not that? There's something similar in Zdoom and it would be a handy feature to have to hide secrets, or signatures, or effect sectors if we wanted to add an auto-map pickup for example.

Either that or exposing to CON the array which determines which sectors have been automapped, so that it can be manipulated directly.

[Fox]

I fear it may be not so simply to add it in CON. It seems the values stored are per-sector per-player, something unprecedented in current CON code.



I suppose a work-around would be to convert the player id to a bitfield, since it is only for a true or false check. If the sector is visible for player n, add 2ⁿ to the sector structure or array.

===//===//===

Is it possible to add a display respawn toggle in Mapster?

[Helixhorned]

 Fox, on 04 April 2013 - 09:39 AM, said:

IIs it possible to add a display respawn toggle in Mapster?

It's already there, coded in a.m32, but you have to "lock" onto the RESPAWN sprite with SPACE unless you set the showrespawn_always gamevar to 1. Also, it sometimes doesn't work due to an m32-script interpreter bug.

[Spirrwell]

 Hendricks266, on 29 March 2013 - 02:05 PM, said:

I felt like building a new 64-bit build so I did. Helix fixed the bugs with CON gamearrays about a month ago.

http://hendricks266....est_20130329.7z

Yeah, it runs far faster for me as well with Polymer. It's about a 75% increase for me in a steady frame rate... It'd be cool to have 64 bit Windows binaries in the synthesis. It seems according to the wiki that a 64 bit binary can be compiled with MinGW-w64, is this right?

[TerminX]

Yeah, that's correct, but the 64-bit Windows builds aren't really stable yet and still have a few problems that aren't present in the 32-bit builds (though they're mostly corrected now).

[TerminX]

Committed r3654 a few minutes ago... should be of interest to a few people.

[Mateos]

Thank you very much! Installed!

[Skulldog]

 TerminX, on 08 April 2013 - 10:35 AM, said:

Committed r3654 a few minutes ago... should be of interest to a few people.

Nice update TX.

[Micky C]

I remember replacing the duke3d.exe from megaton with eduke32, then when I fired it up, the mouse wasn't working. I remember the Commander also had some control issues.

[Gambini]

Helixhorned, on 05 April 2013 - 08:18 AM, said:

It's already there, coded in a.m32, but you have to "lock" onto the RESPAWN sprite with SPACE unless you set the showrespawn_always gamevar to 1. Also, it sometimes doesn't work due to an m32-script interpreter bug.

I remember suggesting that idea and being happy to know it was implemented. But I never managed to make it work.

Just tried with "include a" in the console but nothing happened. Tried that showrespawn 1 but nothing happened. Tried pressing space on a respawn but nothing agian.

Would you give detailed instructions to make it work?

[Helixhorned]

Gambini, on 08 April 2013 - 08:31 PM, said:

Just tried with "include a" in the console but nothing happened.

What did the log say after that? It should report which "states" were defined and so on, or bail with an error, for example if names.h couldn't be found. After loading it, the given instructions apply. It could of course be that the m32-interpreter bug is a BAD BUG (C undefined behavior), in which case I merely had "luck" that it worked at all in some cases.

[Mark]

I don't remember if I put the a.m32 file in the samples folder or if that is where it normally resides. I brought it out to my main directory otherwise it won't run when you type "include a" in the console.

BTW, it shows "4 warnings" in the console when run, but since it enables the recently added player SE light thats all I care about for now.

[Jblade]

The newer snapshots hang on the finding game data part - this is related to this snapshot I believe. I guess it's because I'm running it in a directory without a Duke3D.grp, but the mod I'm playing is standalone and worked perfectly fine before this change.

[TerminX]

Where/how does it hang exactly? I'll look into it today.

[Jblade]

TerminX, on 10 April 2013 - 08:35 AM, said:

Where/how does it hang exactly? I'll look into it today.

Pretty much at this part:

EDuke32 2.0.0devel r3636 
Compiled Apr  3 2013 10:31:08
Application parameters: /gAMCTC.grp /map test.map 
Using C:/AMCTHETC/ for game data
Windows 7 Service Pack 1 (build 6.1.7601)
Initialized nedmalloc
Initializing DirectDraw...
Searching for game data...

I thought it was megaton related so I deleted that but it didn't change anything. I've set the def files to load the AMCTC grp so it shouldn't really matter since it has everything it needs to run.

EDIT: that log is from a version that runs, but the point is that it gets to 'Searching for game data...' and then stops going any further on the latest snapshot.

[TerminX]

I committed a fix for that in r3661, by the way.

I've also got another modification of the startup window game selector coming up that allows arbitrary GRPs to be added to the selector (finally!).

It's already programmed, but I want to play with it a bit before I commit it to make sure it doesn't screw anything up. Currently, it scans the root dir for any file with a "grpinfo" extension and loads as many additional entries from that as are defined in the file, in this format:

Quote

"fuuuu" 418389083 22213819 GAMEFLAG_ADDON DUKE15_CRC "fuuuu.con"

The first field is the GRP's friendly name, the second field is the CRC (take it from grpfiles.cache, it's the last field there), the third is the filesize of the GRP, the fourth defines what type of GRP it is (currently just GAMETYPE_DUKE or GAMETYPE_ADDON), the fifth is the CRC of the main GRP an add-on GRP requires to operate (current predefined values are DUKE15_CRC, DUKE13_CRC, and DUKEDC_CRC/DUKECB_CRC/DUKENW_CRC representing the GRPs distributed with the Megaton Edition), and the sixth field is of course the name of the CON file the GRP needs to load to function. I plan on adding an additional field for the DEF file name before I commit this, so the syntax will change a little bit, but that should be enough information to give everyone an idea of how it works and how simple it is to use.

[Jblade]

That works, thanks - that feature definitly sounds pretty useful, looking forward to getting to try it out.

[supergoofy]

What about a separate 64-bit binary repository ? Where there will be 64-bit binaries hosted, (somewhat) regularly.

Personally, I haven't encountered any major issues with the 64bit binary that Hendricks266 posted. I haven't played though with the HRP. I only played the Attrition mod v1.50 beta 2.

[Helixhorned]

Player Lin, on 18 February 2013 - 04:41 AM, said:

I can only get that glitch happens on that position, other points are just looking fine as well. I may try again later...

EDIT: OK, I found two other one, both are still above the TROR sector so maybe still not useful too? The -4 one don't needed jetpack but jump on the shelf.

About this TROR problem in Polymost. When I tried running that map on the AMD/AMD system again, I couldn't reproduce the wild flickering any more (both synthesis and self-compiled builds). However, the no-draw issue seen in the first screenshot of Player Lin's post can be easily reproduced in Mapster32, where it will appear as black area instead. Since I have no intention of improving TROR rendering on Polymost, I guess this issue is closed then?

[Player Lin]

I just disappointed a little when the Polymer still runs like shit on my machine...

Hope TROR will not over-using by mappers before I buy new one.

[Diaz]

Alright, so I thought it'd be rather interesting for other Polymer modders if I share what I've just found out.

Some time ago I posted about a bug that was bothering me quite a bit. It looked as if there was some sort of memory leak in Polymer that caused performance to degrade exponentially with time, until it reached an unplayable state and a restartvid was needed.

Well, today I've coded a small flame burst actor that happens to have twenty frames of animation, all of them defined with a glow map in the .def.

I placed a lot of these actors in a big lava area and.. BOOM! performance started degrading like a bitch. So I thought something weird was going on. I went ahead and deleted the glow map definitions and instead set the shade manually to -127 on the actor code. Guess what... performance increased again!

So there you have it. The exponential performance degradation was due to animated, glow mapped sprites. I deleted all animated glow map definitions from my .def files and instead set the actors to have a constant fullbright shade, and performance has increased dramatically, specially after running the game for some time. Not sure if it's related to the sprites being animated or being transparent, which they all were. But it works. I FUCKING FOUND IT AT LAST. Seriously, this thing was driving me nuts.

So, beware of glow maps.

[Plagman]

So you're saying that when looking at your scene with lots of glow maps and doing nothing, perf was visibly going down?

[Diaz]

Yes. It's not a sudden performance drop (like what would happen if looking at a very detailed scene), but rather the frame rate counter descends as time passes - even if looking at the same point all the time.

[Helixhorned]

Helixhorned, on 05 April 2013 - 08:18 AM, said:

It's already there, coded in a.m32, but you have to "lock" onto the RESPAWN sprite with SPACE unless you set the showrespawn_always gamevar to 1. Also, it sometimes doesn't work due to an m32-script interpreter bug.

OK, that interpreter bug has been fixed. What it did was to wrongly clamp all set tsprite z values to [-524288 .. 524288], so it's no wonder that the RESPAWN preview didn't work as expected when those sprites were outside that range.

[High Treason]

I'm wondering if there's any chance of Mapster32 getting a "Sprite Counter" implemented?

What I mean is, something like the frame-rate counter but it displays how many sprites are onscreen? I think it would be useful for complex sprite work as I often worry that I'm going to go past the drawing limit.

Don't know if there'd be much call for such a thing or how easy it would be to implement if at all possible, it's just a suggestion and I can work without it.

[Fox]

Actually it would be relatively easy, even if just with CON.

[Jblade]

Right now ANGRANGE and ZRANGE only take values with a power of 2, meaning there's only a very small selection of usable accuracy ranges. Is there any way to change or maybe add some more precise variants, so we can have better control over bullet weapon accuracy?

[Danukem]

James, on 25 April 2013 - 03:43 AM, said:

Right now ANGRANGE and ZRANGE only take values with a power of 2, meaning there's only a very small selection of usable accuracy ranges. Is there any way to change or maybe add some more precise variants, so we can have better control over bullet weapon accuracy?

That's a good question. And on a related note, I wonder if there is a simple way to disable the pistol's ability to hit any enemy under the crosshair regardless of range.

[Diaz]

Is there a problem with the ifp prunning and prunningback checks?

I swear I've run hundreds of times through my APLAYER code, comparing it with my old Fusion APLAYER code, and with the newer one, the running animations for the player don't work. They do on the older code, which is identical.

To debug, I've tried to print different quotes depending on whether the player is pwalking, pwalkingback, prunning and prunningback - only pwalking and prunning display the quote. Yet, "ifp prunning action PRUN" doesn't work - it doesn't switch to the PRUN action, but rather keeps the previous action. Weird.

This is driving me nuts...