[TerminX]

They have a weapon flag set on them to change the autoaim behavior, unset the flag and they should act like regular weapons.

[Fox]

enum weaponflags_t {
    WEAPON_SPAWNTYPE1           = 0x00000000, // just spawn
    WEAPON_HOLSTER_CLEARS_CLIP  = 0x00000001, // 'holstering' clears the current clip
    WEAPON_GLOWS                = 0x00000002, // weapon 'glows' (shrinker and grower)
    WEAPON_AUTOMATIC            = 0x00000004, // automatic fire (continues while 'fire' is held down
    WEAPON_FIREEVERYOTHER       = 0x00000008, // during 'hold time' fire every frame
    WEAPON_FIREEVERYTHIRD       = 0x00000010, // during 'hold time' fire every third frame
    WEAPON_RANDOMRESTART        = 0x00000020, // restart for automatic is 'randomized' by RND 3
    WEAPON_AMMOPERSHOT          = 0x00000040, // uses ammo for each shot (for automatic)
    WEAPON_BOMB_TRIGGER         = 0x00000080, // weapon is the 'bomb' trigger
    WEAPON_NOVISIBLE            = 0x00000100, // weapon use does not cause user to become 'visible'
    WEAPON_THROWIT              = 0x00000200, // weapon 'throws' the 'shoots' item...
    WEAPON_CHECKATRELOAD        = 0x00000400, // check weapon availability at 'reload' time
    WEAPON_STANDSTILL           = 0x00000800, // player stops jumping before actual fire (like tripbomb in duke)
    WEAPON_SPAWNTYPE2           = 0x00001000, // spawn like shotgun shells
    WEAPON_SPAWNTYPE3           = 0x00002000, // spawn like chaingun shells
    WEAPON_SEMIAUTO             = 0x00004000, // cancel button press after each shot
    WEAPON_RELOAD_TIMING        = 0x00008000, // special casing for pistol reload sounds
    WEAPON_RESET                = 0x00010000  // cycle weapon back to frame 1 if fire is held, 0 if not
};

[Helixhorned]

Fox, on 04 January 2014 - 06:58 AM, said:

Is it possible to make the Pistol / Expander auto-aim accuracy adjustable with ANGRANGE or ZRANGE? Right now there is no way to modify that behavior.

What kind of modification do you have in mind? You can now have arbitrary values for these two, where formerly you were forced to used powers of two. How to disable spead follows from this commit message:

r3715 said:

Generalize ZRANGE and ANGRANGE to accept any nonnegative number.

Numbers 0 and 1 mean 'no spread', but the latter does one krand() call.
Negative numbers are reserved for potential future use.

It's the projectile flags that toggle this behavior: PROJECTILE_ACCURATE has to be unset to enable spreading.

If you want to research this in detail yourself, player.c:P_PreFireHitscan() is a good starting point.

[Helixhorned]

Hendricks266, on 03 January 2014 - 08:14 AM, said:

I extracted the .pal from this image using IrfanView, and I used bsuite to insert it into a PALETTE.DAT. http://hendricks266....ke3d_unk_proto/

Doesn't look as if it's been extracted properly. Open it with a hex editor -- you'll only see values 0xC, 0xD and 0xE.

I'm done with attempting to recreate the base shade table for now though. My guess is that maybe the software they did the art with had that capability in some form.

[DavoX]

This question has nothing to do with anything but is it possible to keep a single zip file for all the necesary items to run eduke32 and mapster32 on the synthesis page? I've recently checked and mapster32 is on one file and eduke32 is on another... it's pretty confusing now.

[Fox]

Helixhorned, on 05 January 2014 - 05:53 AM, said:

What kind of modification do you have in mind?

To be specific, I want to remove Eduke32 specific behavior regarding the Pistol / Expander accuracy when auto-aim is off for Duke 64. But it's not that important (since I probably would make it an option anyway).

[Fox]

Would it be asking too much to disable that unfinished 2 player split screen code for now?

[Hendricks266]

Fox, on 05 January 2014 - 02:21 PM, said:

Would it be asking too much to disable that unfinished 2 player split screen code for now?

What specifically do you need changed? Any hacks in the code that make life easier for splitscr.con while making life harder for normal mods should be chainsawed. I personally would rather see proper splitscreen done internally (which is a tall order), but I don't mind hacking around some things as long as it's transparent.

IIRC there was something about co-opting the fake multiplayer mode specifically for splitscr.con. That's no good.

[Fox]

I don't know, it's just that a second HUD and weapon is displayed by default with another player, even if I am not using splitscr.con.

[Helixhorned]

Fox, on 05 January 2014 - 03:32 PM, said:

I don't know, it's just that a second HUD and weapon is displayed by default with another player, even if I am not using splitscr.con.

Isn't that conditional on the use of the -q (fake multimode) flag? I assumed that it's not useful for anything than splitscreen at this moment, but I can see how it's in the way of coding your own Duke bots.

[Fox]

I don't know, I am just using bots to test some features.

Based on the name, I assume DISPLAYREST is called when all in-game screen code is done, right? Is it possible to include an event that does the opposite, i.e. is called before any in-game screen code? DISPLAYROOMS is not far doing that, but it doesn't run it some cases (i.e. with automap).

[Helixhorned]

Fox, on 06 January 2014 - 07:43 AM, said:

Based on the name, I assume DISPLAYREST is called when all in-game screen code is done, right? Is it possible to include an event that does the opposite, i.e. is called before any in-game screen code? DISPLAYROOMS is not far doing that, but it doesn't run it some cases (i.e. with automap).

What exactly are you trying to achieve? Wouldn't an event that's called before any hard-coded drawing be useless unless the latter is suppressed (e.g. by assigning 1 to RETURN before EVENT_DISPLAYROOMS is left)? I guess a thinkable use case is a custom portal system assuming that a frame may not always fill the whole frame buffer, but that assumption shouldn't be relied on.

[Fox]

Typically if I want to change some sector / wall / player / userdef structure "temporarily" (like with tsprite), I change it during DISPLAYROOMS and set it back in DISPLAYREST. Some examples include the changing the sector pal, or making a custom palfrom code. But the problem is that it doesn't work with automap, so that leaves a hole on it.

[Scott_AW]

Found out my game will most likely never be able to run on Polymer or Polymost without a complete rehaul, and making custom models. I'm not even going to bring up the framerate differences, as that can be overcome on better systems, but there's this.



Maybe I missed something about mirror, but even if I were to do a project involving polymer can one get mirrors to work properly?

Other issues I noticed is that my windows, single pixel diagonal lines seem to have doubled, even when just a flat texture. I don't turn on any texture blending. I'm sure this isn't an issue with high-res textures.

[Micky C]

Mirrors should always work fine in polymer. If you're using any TROR that will most definitely break mirrors in polymost (classic seems slightly more resilient).

[Fox]

I know multiplayer is unsupported, but I had like to report some problems with multiplayer not related to net code.

• Parts of the dukematch intermission screen are too dark (picture);
  
• The player name is not being displayed in messages or screens (picture above) until you change it, every time you run the game.
  
• As mentioned earlier, some incomplete split screen code with fake multiplayer (picture) despite splitscr.con not being used.

Additionally, the multiplayer support for mods is very limited due to it being impossible to change the current userdef being accessed.

[NNC]

I'm not sure if it had been mentioned, but the Tank and the Newbeast enemy with higher skill setting appears inactive on screen when lowe skill setting is played (ie. skill 3 Tanks/Newbeast appear inactive with Let's Rock skill). Check Area 51 or other E4 map to see that.

Also, the Liztroop, Pigcop and Battlelord stayput version give recognise sounds when used as a respawn. Check LA Rumble for example. Enforcers are fine.

[Hendricks266]

Fox, on 11 January 2014 - 12:54 AM, said:

Additionally, the multiplayer support for mods is very limited due to it being impossible to change the current userdef being accessed.

Userdef isn't transmitted over the network. It stays local to the current machine. If there's anything you need to transmit, you'll have to roll your own playervars and/or signal system. Also keep in mind that client-server architecture means that only the server has an actual copy of the game logic running, while the clients just have visuals.

I'll take a look at the rest of the stuff.

[TerminX]

Fox, on 11 January 2014 - 12:54 AM, said:

I know multiplayer is unsupported, but I had like to report some problems with multiplayer not related to net code.

• Parts of the dukematch intermission screen are too dark (picture);
  
• The player name is not being displayed in messages or screens (picture above) until you change it, every time you run the game.
  
• As mentioned earlier, some incomplete split screen code with fake multiplayer (picture) despite splitscr.con not being used.

Additionally, the multiplayer support for mods is very limited due to it being impossible to change the current userdef being accessed.

Not being able to overwrite local preferences (a horrible idea anyway) for players which aren't even local could in no way be called "very limited" support for mods.

If you are relying on setuserdef functionality to make mods work, I'm sorry, but you're doing it wrong. Setuserdef was not supported in EDuke 2.0 and will in the future generally no longer be supported with Lunatic either, so you had better get used to the idea of players being able to set options in the menu and keep them that way without some poorly thought out mod functionality coming by and changing them to different values.

In fact, the only reason there's a "setuserdef" that does anything at all is because EDuke32 started out as a way for me to personally continue an old EDuke mod on Windows, and in my inexperience at the time, I wanted to do things the wrong way myself. It was a poor decision. At no point should allowing a mod to take a menu option the player set and immediately change it back to something else EVER be a good idea. Mods must work with and cater to the player, not force them into potentially unwanted settings.

Nancsi, on 11 January 2014 - 02:04 AM, said:

I'm not sure if it had been mentioned, but the Tank and the Newbeast enemy with higher skill setting appears inactive on screen when lowe skill setting is played (ie. skill 3 Tanks/Newbeast appear inactive with Let's Rock skill). Check Area 51 or other E4 map to see that.

Unable to reproduce.

Quote

Also, the Liztroop, Pigcop and Battlelord stayput version give recognise sounds when used as a respawn. Check LA Rumble for example. Enforcers are fine.

I'm not positive, but that may be caused by the game originally having a bug where the stayput versions of those enemies were omitted from an internal list of enemy sprites. If I'm remembering that correctly, I'm guessing they play the sounds now because the bug was fixed.

[Hendricks266]

TerminX, on 11 January 2014 - 03:16 AM, said:

you had better get used to the idea of players being able to set options in the menu and keep them that way without some poorly thought out mod functionality coming by and changing them to different values.

While I agree with the letter of this statement, unfortunately, it's not so clear-cut. The reality of the situation is that userdef is a hodgepodge of shit that doesn't belong in the same struct. Here's a grep of the Duke 64 mod for "setuserdef":

DISPLAY.CON:    setuserdef[THISACTOR].const_visibility DEFAULTVISIBILITY
DISPLAY.CON:    setuserdef[THISACTOR].const_visibility DEFAULTVISIBILITY
DISPLAY.CON:    setuserdef[THISACTOR].const_visibility DEFAULTVISIBILITY
GAME2.CON:        setuserdef[THISACTOR].eog 1
GAME2.CON:    setuserdef[THISACTOR].volume_number LASTVOLUME
GAME2.CON:    setuserdef[THISACTOR].level_number LASTLEVEL
GAME2.CON:      setuserdef[THISACTOR].eog 0
GAME2.CON:    setuserdef[THISACTOR].volume_number 7
GAME2.CON:    setuserdef[THISACTOR].volume_number TEMP
GAME2.CON:      setuserdef[THISACTOR].volume_number MUSICVOLUME
GAME2.CON:      setuserdef[THISACTOR].volume_number TEMP
HUD.CON:      setuserdef[THISACTOR].screen_size 3
HUD.CON:      setuserdef[THISACTOR].screen_size 3
HUD.CON:      setuserdef[THISACTOR].screen_size 4
SCREENS.CON:    setuserdef[THISACTOR].volume_number NEXTVOLUME
SCREENS.CON:    setuserdef[THISACTOR].level_number NEXTLEVEL
SCREENS.CON:    setuserdef[THISACTOR].volume_number TEMP2
SCREENS.CON:    setuserdef[THISACTOR].level_number TEMP3

Just here we can see some different use cases.

const_visibility is effectively changing a gamestartup value during gameplay. I think everything in gamestartup should be modifiable. Most is, such as smaxammo, but not everything. I'm looking at QSIZE.

eog is a "game state" that works around hardcoded behavior, completely transparently to a player. (It's not a choice of any sort.)

level_number and volume_number are used to work around the inadequacies of qgetsysstr (with STR_MAPNAME) and starttrack, among other things.

Manipulating screen_size is pretty much necessary to build a custom HUD. As with all of the above, there should be a better way.

It definitely needs cleaning up for Lunatic.

TerminX, on 11 January 2014 - 03:16 AM, said:

I'm not positive, but that may be caused by the game originally having a bug where the stayput versions of those enemies were omitted from an internal list of enemy sprites. If I'm remembering that correctly, I'm guessing they play the sounds now because the bug was fixed.

I'm too lazy to check but I may have fixed STAYPUTs at Fox's request along with the minibosses, and perhaps NEWBEAST too.

[TerminX]

That right there is the problem with just exposing internal structures en masse without any sort of thought into a sane interface. The bits you've pointed out are good use cases (except for screen_size... more on that in a minute), but moreover they're things that probably don't belong in userdef in the first place. There's zero logic in having user preferences controlled by menu options right there next to internal variables that control game states and level progression. My issue isn't with access to stuff that controls the game state, it's with the ability to contradict and override (and confuse and piss off) the user. It's regrettable that EDuke 2.0 exposed these internal structures without having cleaned them up or organized them beforehand, and it's even more regrettable that I added the ability to overwrite all of them...

Anyway, about screen_size, I don't think it should be necessary to overwrite that preference to do a custom HUD. If EDuke32 currently doesn't allow you to cancel drawing the HUD through a display event at any value of screen_size, then that's a separate issue which should be addressed. I understand that some may want to disable the ability to shrink the screen size entirely, in which case instead of overriding user preferences what we really need are menus that can at least be somewhat cutomized in terms of enabling/disabling options and setting the acceptable range of values for said options.

[Fox]

Hendricks266, on 11 January 2014 - 03:37 AM, said:

I'm too lazy to check but I may have fixed STAYPUTs at Fox's request along with the minibosses,

I actually didn't requested that, I was adressing some inconsistencies beetween the bosses in regards of making miniboss 2 and 3 work. I wouldn't ask that because otherwise the Protector Drone or Tank missing recog sounds should also be fixed.

Hendricks266, on 11 January 2014 - 03:37 AM, said:

While I agree with the letter of this statement, unfortunately, it's not so clear-cut. The reality of the situation is that userdef is a hodgepodge of shit that doesn't belong in the same struct. Here's a grep of the Duke 64 mod for "setuserdef":

Actually I realized how unreliably it was to mess up with userdefs by using getuserdef, not setuserdef. More specifically, I have some code to make the player invulnerable to the Shrinker if God Mode is on, however I figured out dukebots would never return god true despite cheat codes working for all players.

There are some userdef structures that I need to check or even set outside of unsynchronized events:
- player_skill
- god
- eog
- volume_number
- level_number
- noexits

Going by TerminX explanation a code that uses this would never work out in a real connection. The solution would be to add non-userdef alternatives like there are VOLUME or LEVEL variables?

I guess it's not necessary to explain how player_skill, god or noexits would eventually need to be checked. The volume_numer, level_number and eog ones need to be changed in order to replace the current end of level code without writting everything from scratch (this perhaps would need to be replaced with an event). Additionally I use eog in conjunction with startlevel to end the episode.

[NNC]

TerminX, on 11 January 2014 - 03:16 AM, said:

Unable to reproduce.

So that means I have a bug somewhere in the folder or what? Play Area 51 for example on Let's Rock, and visit the main area. You will see two tanks, one will work properly, the other is just facing you, and do nothing. It's blocked and invulnerable. Later on you will see Newbeasts in the same way. If not, there is something wrong with my cons, etc., don't know where.

Quote

I'm not positive, but that may be caused by the game originally having a bug where the stayput versions of those enemies were omitted from an internal list of enemy sprites. If I'm remembering that correctly, I'm guessing they play the sounds now because the bug was fixed.

I'm not sure.... The Octabrains and the Commanders indeed give sounds when stayput (the commanders also give the attack sound at the same time, so you can clearly hear it's the stayput version, like in XXX Stacy), the rest are silent. The normal, non respawning versions of the others are still silent, and the respawning Enforcers are silent too... I'm not sure why, but I think it's better when they are silent. Maybe I just used to it during the years, but it also gives those guys some sneaky tactic advantage.

[Fox]

So you are not using the original CONs?

[Hendricks266]

Fox, on 11 January 2014 - 12:54 AM, said:

• Parts of the dukematch intermission screen are too dark (picture);
  
• The player name is not being displayed in messages or screens (picture above) until you change it, every time you run the game.
  
• As mentioned earlier, some incomplete split screen code with fake multiplayer (picture) despite splitscr.con not being used.

I've got these three things fixed.

[Jblade]

I've noticed that when you get over 32767 build units away from a flat sprite in classic mode, it's panning goes completely haywire. I swear it's never done this before, but I remember reading that x/ypanning support was added to Lunatic a while ago. If you move your view about, the sprite will pan with your view somewhat...it's bizarre but it's definitly a new thing.

[Helixhorned]

James, on 12 January 2014 - 03:42 AM, said:

I've noticed that when you get over 32767 build units away from a flat sprite in classic mode, it's panning goes completely haywire. I swear it's never done this before, (...). If you move your view about, the sprite will pan with your view somewhat...it's bizarre but it's definitly a new thing.

I can reproduce the odd panning for floor-aligned (what I assume you meant by "flat") sprites from a large distance in Duke3D 1.5, so it's a long-standing engine bug. In this incorrect case, the panning appears to be mostly a function of the player angle.

Quote

but I remember reading that x/ypanning support was added to Lunatic a while ago

You probably mean r4170:

r4170 said:

Classic: implement horiz. tex panning for sprites (spriteext[].xpanning).

Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be
assumed that this is only valid for wall-aligned sprites (currently, face
sprites also pan).

A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2
and only with the Lunatic build.

A few notes:
- it's only xpanning support, and only for wall-aligned sprites
- it's both CON (both implementations) and Lua

The advice to run the animatesprites.con test in the Lunatic build is because it crashes C-CON.

[Fox]

Hendricks266, on 12 January 2014 - 01:32 AM, said:

I've got these three things fixed.

Thanks. But there is a bug now which all players and player spawns die when the game starts.

Other issues I forgot to mention:
- You can't start a new game
- The menu freezes the multiplayer game, but if you close it the game abruptly jumps to where it should be if the game had been running.

[NNC]

Fox, on 11 January 2014 - 12:31 PM, said:

So you are not using the original CONs?

I think I found the bug and it happened in you basic bug fix EDuke.def file. The stayput sound changes also in there. I deleted these lines from my own version.

[Jblade]

Just a quick thing about TROR water sectors - the palette gets set properly if you swim up and out of a water sector, but if you can swim out of it from below (so above is water, below is air) than the palette remains as the water one. It can be fixed in code, but it's definitly a thing that should be fixed in the game's proper code as well.