[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...

[Dr. Kylstein]

Trooper Dan, on 25 April 2013 - 09:04 AM, said:

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.

Perhaps not simple, but I have this:

/*
 * CON Mutator
 * Weapon range simulation
 * By Dr. Kylstein
 * 2013-01-27
 *
 * Makes accuracy decrease with range
 */

//generic variables
gamevar temp 0 0
gamevar temp2 0 0
gamevar xpos 0 0
gamevar ypos 0 0
gamevar zpos 0 0
gamevar xpos2 0 0
gamevar ypos2 0 0
gamevar zpos2 0 0
gamevar angle 0 0
gamevar angle2 0 0
gamevar sectorvar 0 0
gamevar sectorvar2 0 0
gamevar thatactor 0 0
gamevar wallvar 0 0

//distance to target
gamevar range_distance 0 1

//adjustment for scatter
gamevar range_pistol_divisor 12 0
gamevar range_shotgun_divisor 8 0
gamevar range_chaingun_divisor 12 0
gamevar range_railgun_divisor 128 0

//calculate distance between two points
state squarethreedistance // (xpos, ypos, zpos, xpos2, ypos2, zpos2) returns square of distance in temp
    subvarvar xpos xpos2
    subvarvar ypos ypos2
    subvarvar zpos zpos2
    divvar zpos 16 //16384z = 1024xy
    mulvarvar xpos xpos
    mulvarvar ypos ypos
    mulvarvar zpos zpos
    addvarvar xpos ypos
    addvarvar xpos zpos
    setvarvar temp xpos
ends

state threedistance
    state squarethreedistance
    sqrt temp temp
ends

//track distance to point aimed at
onevent EVENT_GAME
    ifactor APLAYER {
        getplayer[THISACTOR].posx xpos
        getplayer[THISACTOR].posy ypos
        getplayer[THISACTOR].posz zpos
        getplayer[THISACTOR].ang angle
        getplayer[THISACTOR].cursectnum sectorvar
        getplayer[THISACTOR].horiz angle2
        subvar angle2 100
        mulvar angle2 -2048
        cos temp angle
        sin temp2 angle
        hitscan xpos ypos zpos sectorvar temp temp2 angle2 sectorvar2 wallvar thatactor xpos2 ypos2 zpos2 0xFFFF0030
        state threedistance
        setvarvar range_distance temp
    }
endevent

//adjust scatter
onevent EVENT_GETSHOTRANGE
        setvarvar temp range_distance
    
        //different scaling factors for different guns
        getplayer[THISACTOR].curr_weapon temp2
        ifvare temp2 PISTOL_WEAPON {
            divvarvar temp range_pistol_divisor
        } else ifvare temp2 SHOTGUN_WEAPON {
            divvarvar temp range_shotgun_divisor
        } else ifvare temp2 CHAINGUN_WEAPON {
            divvarvar temp range_chaingun_divisor
        } else {
            divvarvar temp range_railgun_divisor
        }
        
        setvarvar ZRANGE temp
        divvar temp 8 // 128/16 the default ratio
        setvarvar ANGRANGE temp
endevent

[Mblackwell]

Diaz, on 25 April 2013 - 09:15 AM, said:

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...

Is another action overriding it later, perhaps? Usually it's a good idea to try isolating the call.

[Diaz]

I've actually replaced the whole APLAYER actor with the older one from Fusion Redux (which works correctly), yet actions do not change when prunning or prunningback...

[TerminX]

It sounds like you have other code somewhere that's manipulating the values that ifp checks.

Anyway, check out r3708 guys. I just committed the first version of the change that allows user-made GRP files to be displayed in the selection list in the startup window. The commit message contains information on what to do to use the feature. Thoughts?

[Diaz]

Sometimes, taking a break with coding helps.

I've just arrived home and soon found the cause for the strange behavior:

getinput[THISACTOR].bits PBITS
ifvarand PBITS 32 { ifvarg CANRUN 199 return } // Don't play step sounds when in sprint mode.

That return was f*cking everything up. It was in a completely different .CON, that's why I couldn't figure it out

[NightFright]

TerminX, on 25 April 2013 - 09:56 AM, said:

It sounds like you have other code somewhere that's manipulating the values that ifp checks.

Anyway, check out r3708 guys. I just committed the first version of the change that allows user-made GRP files to be displayed in the selection list in the startup window. The commit message contains information on what to do to use the feature. Thoughts?

Ingenious, TX! Even *I* got it working (with Last Reaction groupfile), and since I am a technical n00b, your change has earned the stamp "fool proof"! ^^ Excellent new feature!

I wonder if this already allowed me e.g. to play DukeDC with the HRP, either in a separate (sub)directory or in the EDuke32 root dir.

[Skulldog]

NightFright, on 25 April 2013 - 11:52 AM, said:

Ingenious, TX! Even *I* got it working (with Last Reaction groupfile), and since I am a technical n00b, your change has earned the stamp "fool proof"! ^^ Excellent new feature!

I wonder if this already allowed me e.g. to play DukeDC with the HRP, either in a separate (sub)directory or in the EDuke32 root dir.

What would it be for Duke Zone 2?

grpinfo
{
name "Duke Zone 2"
scriptname "DZ-GAME.CON"
defname "DZ-DEFS.CON"
size 42
dependency DUKE15_CRC
flags GAMEFLAG_ADDON
crc 44100411 854653276 2142638460
}

[NightFright]

Skulldog, on 25 April 2013 - 06:16 PM, said:

What would it be for Duke Zone 2?

grpinfo
{
name "Duke Zone 2"
scriptname "DZ-GAME.CON"
defname "DZ-DEFS.CON"
size 42
dependency DUKE15_CRC
flags GAMEFLAG_ADDON
crc 44100411 854653276 2142638460
}

Actually, I think in "crc", it's enough to use the last number from grpfiles.cache, you don't need all three. And the first one should be what you need as "size". It might still work like that, anyway, guess you just have to try.

[Fox]

I am not sure if I am happy with the grpinfo stuff. From the looks of it I can't define a "Game" based on a zip file or directory, it's all about grp files.

[Skulldog]

What would it be for Duke Zone 2?

grpinfo
{
name "Duke Zone 2"
scriptname "DZ-GAME.CON"
defname "DZ-DEFS.CON"
size 36 24 36
dependency DUKE15_CRC
flags GAMEFLAG_ADDON
crc 2142638460
}

[TerminX]

Fox, on 26 April 2013 - 12:06 AM, said:

I am not sure if I am happy with the grpinfo stuff. From the looks of it I can't define a "Game" based on a zip file or directory, it's all about grp files.

You could probably use a zip in place of a grp. I don't see any reason why it wouldn't work, though you would need to rename it to .grp since we obviously can't have EDuke32 running checksums on every random zip file that it might be able to find at startup.