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

[Helixhorned]

Fox, on 23 December 2013 - 08:26 AM, said:

It has been suggested before for Eduke32 to automatically load MYMAP.CON and MYMAP015.art, and if save files can store the con I suppose it can be loaded with a user map.

Per-map ART files are in with r4257. If you're like me, you'll want to replay user maps that come with custom ART, since I usually avoided them for the inconvenience of installation. I wonder if the usual map review sites allow searching for / selecting only such maps. Is any of them actually backed by a database?

[Fox]

DNR do actually, but it has not been updated since 2011: http://dukerepository.com/maps.php

[Helixhorned]

James, on 13 January 2014 - 05:24 AM, said:

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.

Well, TROR transitions between a bottom air sector and a top water sector aren't really a supported feature. I don't think there's anything analogous in vanilla Duke3D, so right now it merely "works" by the engine's mercy. The usual air/water transitions have a couple of effects added, such as stopping currently playing sounds, starting a "gasp" sound, spawning a water splash sprite, and last but not least changing the base palette. The "inverted" transition doesn't get recognized as such by the respective game code, and consequently doesn't exhibit these effects.

If you have a particular behavior in mind for this transition, you're invited to look at everything around P_Emerge(), P_Submerge() and P_FinishWaterChange() in actors.c and suggest what you feel is a natural extension.

Is the map you need this for just surrealistic or does it have a "physical" explanation? Like... a water tank in space and a force field that lets everything except water pass (you'd only pass that one once ).

[Helixhorned]

Fox, on 13 January 2014 - 01:11 PM, said:

DNR do actually, but it has not been updated since 2011: http://dukerepository.com/maps.php

Sweet, that's what I was looking for!

[Jblade]

Quote

Is the map you need this for just surrealistic or does it have a "physical" explanation? Like... a water tank in space and a force field that lets everything except water pass (you'd only pass that one once ).

Heh, it's set in a place where logic does not apply What you said makes sense, it's a lot of work for something that would only see use probably once or twice. It's an easy thing to fix with a bit of CON code (screen palette transition wise) I just wondered if there was something in the engine or whatever. Thanks for the detailed reply.

[Helixhorned]

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

The reality of the situation is that userdef is a hodgepodge of shit that doesn't belong in the same struct.

TerminX, on 11 January 2014 - 04:33 AM, said:

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.

Yes! It's like you two were speaking right out of my mind!

Fox, on 11 January 2014 - 08:43 AM, said:

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?

VOLUME and LEVEL are merely read-only aliases to the respective userdefs members. The general pattern is that you want to set these to affect commands that behave conditionally on them. So the real solution is to make the commands (in Lunatic: functions, for example in 'gv' if there's no better place for them) accept these conditioning values as arguments. For example, the Lunatic interface could (and probably will) look like that:

gv.currentLevel()  -- will be one-based, I think. It's just more natural that way because it's how everyone thinks of these
gv.currentEpisode()
gv.currentMapName([ep, lev])  -- this one returns the current map name if passed no args, or that of E<ep>L<lev>