odamex / odamex Goto Github PK

Although I don't find problems, in general, to load different pwads, it happens that wos.wad (Whispers of Satan, boom-compatible pwad) cannot be loaded, the port crashes when I try it. This happens in the latest release of the port (0.9.0), running in MacOS Big Sur.

I don't know why it happens, I have loaded it correctly and I have not had problems with other boom-compatible pwads, being that the pwad in question works correctly even in Boom 2.02 (the latest build of Boom in DOS).

The parameter used is the usual: odamex -iwad doom2.wad -file wos.wad.

The terminal indicates, after crashing: 42044 segmentation fault.

for more details I transcribe the crash report:

Signal number: 11
Errno: 0
Signal code: 1
Fault Address: 0xffffffffffffffec
0 odamex 0x0000000100f06dab _ZL17SigActionCallbackiP9__siginfoPv + 443
1 libsystem_platform.dylib 0x00007fff203d1d7d _sigtramp + 29
2 ??? 0x00007ffeeedd7260 0x0 + 140732905910880
3 odamex 0x0000000100e7cff1 _Z11HU_Shutdownv + 33
4 odamex 0x0000000100e692e0 _Z10D_Shutdownv + 96
5 odamex 0x0000000100ec9149 _Z10call_termsv + 89
6 odamex 0x0000000100ec96b8 main + 1240
7 libdyld.dylib 0x00007fff203a8621 start + 1

sv_waddownload cvar not working
Friend can't download wads from server with this is "1"

Bug 293
Posted By: griffiniic (Dr. Zin)
Posted On: Sun, 21 Jan 2007 18:56:25 GMT
Last updated Sun, 27 Jan 2019 06:34:48 GMT

There seem to be sporadic instances of ghost monsters in coop, except they occur in maps that do not contain archviles. Suspect monsters are spawned as ghosts.

Bug 574
Posted By: elykdav (Kyle)
Posted On: Thu, 18 Mar 2010 04:28:06 GMT
Last updated Mon, 18 Mar 2013 05:13:18 GMT

Allow clients to not receive messages from a specified person.

Pretty easy to replicate. Load up odasrv, put a breakpoint on a cvar with a callback, and set it to something. The callback will run twice, once from the expected location, twice from D_SendServerInfoChange. Not sure what's going on here.

Testing an issue

Bug 529
Posted By: doomgod (doomgod)
Posted On: Sun, 04 Jan 2009 04:02:31 GMT
Last updated Thu, 20 Mar 2014 05:21:21 GMT

A good example is Plutonia 2. It plays music from IWAD.

Bug 475
Posted By: Ralphis (Ralph Vickers)
Posted On: Sun, 01 Jun 2008 10:47:34 GMT
Last updated Fri, 13 Apr 2012 13:28:52 GMT

Servers should make sure that clients are using the exact same wad files as the server. As of revision 870, this is not the case.

I began modifying my odamex.wad to test out new flag sprites. I soon found out that even with a modified odamex.wad I could connect to any server.

Correct behavior is for server to check client's wad and make sure it matches exactly. If the wad doesn't match, player is booted from the server.

Bug 372
Posted By: alexmax2742 (Alexander Mayfield)
Posted On: Sun, 09 Sep 2007 07:16:52 GMT
Last updated Wed, 16 Jan 2019 15:33:32 GMT

Two new commands

• Timeout: Calls a timeout. All play is frozen.
• Timein: Calls a timein with a 3 second countdown (3..2...1...GO!)

One new server variable

• sv_timeout: How long the timeout lasts before automatically timing back in. Default to 120 seconds
• sv_timeouts: How many timeouts a particular player gets per match (or until we implement cpma-style matches and rounds per bug 238, per map)

Can you port to PlayStation 2? Like the Xbox version :D

Also check this
https://github.com/cosmito/ps2doom
https://github.com/ps2dev/ps2sdk

Please answer, this is a very easy or bad idea?
This is is will be cool + also with PS2's DEV9 (Network play)

Bug 634
Posted By: ijgjgr (Amateur Spammer)
Posted On: Sat, 11 Sep 2010 12:03:41 GMT
Last updated Thu, 16 Jun 2011 03:07:37 GMT

Launcher queries servers too quickly, causing exaggerated pings. (I checked by refresing individual servers ).

Bug 269
Posted By: ryan (Ryan Nematollahi)
Posted On: Fri, 19 Jan 2007 03:51:51 GMT
Last updated Sun, 30 Mar 2014 21:20:15 GMT

Sometimes when the player runs out of ammo and autoswitches weapons, the weapon he switches to will fire the rounds of the previous ammo (ex. player runs out of rocket launcher ammo, autoswitches to super shotgun, supershotgun shoots rockets). Its quite difficult to reproduce.

Bug 309
Posted By: lemonzest (Lemonzest)
Posted On: Fri, 26 Jan 2007 17:01:03 GMT
Last updated Thu, 20 Mar 2014 05:23:59 GMT

would be nice if you could get help for odemex/odasrv from the cline with for example /? or -help printing a list of available command line options/arguments.

Bug 419
Posted By: mike (Mike Lightner)
Posted On: Sat, 19 Apr 2008 20:35:43 GMT
Last updated Thu, 20 Mar 2014 05:23:58 GMT

In order to support Rich Internet Application (RIA) interaction, it is necessary to have some method of instantiating odamex application services. One convenient way to do this is via a URI.

Currently, when one launches odamex via this URI method, odamex receives one argument that ends up being the entire URI itself, i.e.:

odamex://odamex.org:10666/?+fullscreen=0

The above becomes argv[0] and argc is 1. Odamex should parse these into a form it can digest. Likewise this could be done with launching odasrv:

odasrv:///?+hostname=abc def&port=10669 (third slash after colon to match above where location would be).

Bug 194
Posted By: denis (Denis Lukianov)
Posted On: Fri, 14 Apr 2006 00:12:57 GMT
Last updated Thu, 12 Apr 2012 16:31:11 GMT

would be nice

Bug 664
Posted By: mwoodj (Mike Wood)
Posted On: Sun, 03 Oct 2010 04:20:04 GMT
Last updated Sun, 03 Oct 2010 04:49:55 GMT

This is caused by the fact that the main window does not register as having focus when the application starts even though cycling the focused widget cycles widgets on the main window as if it were the focused window. Making a cursor selection (pressing A) anywhere in the window registers the window focus. Explicitly calling the focus function in the main window constructor with the main window as the function parameter does not seem to resolve the issue. This issue does not affect interaction with the interface using the cursor at all.

Bug 327
Posted By: gmakermaniac (Albert Brown)
Posted On: Sun, 01 Apr 2007 00:44:12 GMT
Last updated Thu, 20 Mar 2014 05:21:20 GMT

The voodoo doll bug is a bug from vanilla doom where dummy players would be spawned which can be used to cause damage to the player it represents. Though the benefits of this glitch are low, there is one very amazing thing it can be used for: it can (and has been) used to implement logic circuits by having a doll placed on a conveyor which crosses over lines. Also it has been used for the ""instant suicide effect"" featured in tnt.was map30.

Voodoo dolls dont seem to work at all in the current svn release of odamex. The player spawning code for cooperative should try to mimick the code of vanilla, including trying to spawn player instances at every spawn point in coop. Some additional system may need to be implemented to make maps like tnt.wad map30 work completely (die every time you cross the line and telefrag yourself, not only once)

This may not be too hard to fix, I'll consider doing it myself.

Bug 629
Posted By: Ralphis (Ralph Vickers)
Posted On: Sat, 04 Sep 2010 23:41:57 GMT
Last updated Tue, 15 Nov 2016 06:14:31 GMT

Most coop maps are only designed for 4 players (since vanilla Doom only have 4 player starts). Of course, Odamex supports much more than 4 players. A problem arises when 5 or more players enter the next level because some players will be telefragged and lose all of their stuff.

Skulltag solves this by just allowing players to keep telefragging each other but having them keep their weapons until they move off the spawn spots. I personally find this method very sloppy and think that Odamex can do it better. Perhaps something like our current sv_unblockplayers except it would only take effect on players when they spawn (and they'd become solid again once they've cleared each other)?

Bug 649
Posted By: alexmax2742 (Alexander Mayfield)
Posted On: Tue, 21 Sep 2010 06:48:45 GMT
Last updated Tue, 21 Sep 2010 06:48:45 GMT

Right now, wad downloading is rather slow. I think it would be a lot nicer if Odamex could download WAD's from any HTTP source.

New variable:
sv_httpwaddownload

If true, the client will attempt to open a normal HTTP connection to the URL listed in sv_website + the wad name in question. If found, it will download the file over HTTP. If not, it will then continue on with attempting to download via sv_waddownload like normal. Note that it will not try to reimplement wadseeker by searching for the wad anywhere, merely try the URL in sv_website and if it's not there give up.

Bonus feature:
Attempt to also find any file with .zip or other archive and extract the wad from the archive.

Version: 0.9.0 (compiled from sources)
OS: Debian GNU/Linux 10 (buster) x86_64

Situation 1:
Server is fine working. But on other restart now server can't load a wads

[03:04:49] Could not resolve resource file "BTSX_E1A_OCF.WAD".
[03:04:49] Could not resolve resource file "BTSX_E1B_OCF.WAD".
[03:04:49] Could not resolve resource file "D4V2_OCF.WAD".
[03:04:49] Could not resolve resource file "BTSX1D4V_OCF.WAD".
[03:04:49] Could not resolve patch file "D4V2.DEH".

("OCF"(Odamex Compatible Fix) is temporary sub-naming, because hash checks failed)

Server config from preset.
Start config:

../server_data/odasrv -config ../configs/d4v2_btsx1.cfg +logfile ../server_data/logs/d4v2_btsx1.log -port 29100 -file ../pwads/btsx_e1a_ocf.wad ../pwads/btsx_e1b_ocf.wad ../pwads/d4v2_ocf.wad ../pwads/btsx1d4v_ocf.wad ../pwads/d4v2.deh 

Also tried this thing: e.g. "-file 1.wad 2.wad 3.wad" and this: "-file 1.wad -file 2.wad -file 3.wad" but nothing
Start config contains in home folder (e.g. /home/someusername/anotherfolder/... © Captain Obvious)

Situation 2:
All is identical, but:

[02:41:32] DOOM 2: Hell on Earth
[02:41:32] adding /home/dartpower/Servers/Odamex/server_data/odamex.wad
[02:41:32]  (240 lumps)
[02:41:32] adding /home/dartpower/Servers/Odamex/pwads/vacav15_ocf.wad
[02:41:32]  (907 lumps)
W_GetNumForName: STDISK not found!
(checked in: ODAMEX.WAD, VACAV15_OCF.WAD)

What im doing wrong? Or this is a bug? o_O

And another bug also:
Files in lower-cased named.
Also have bug with downloading wads, if this not lower-cased, this is cant downloaded from sites (Windows client)
e.g. in folder: BBBB.wad, in game (if font dont touch my eyes) BBBB.wad, but can't found
And if in folder: bbbb.wad and on file server also this. Downloading is normal.
(Sorry for my bad english XD)

Bug 254
Posted By: denis (Denis Lukianov)
Posted On: Mon, 13 Nov 2006 10:13:14 GMT
Last updated Thu, 20 Mar 2014 05:23:59 GMT

because i'm not lazy, i get to post this on the bug tracker

this is not an easy problem

Bug 369
Posted By: doomgod (doomgod)
Posted On: Tue, 04 Sep 2007 19:53:12 GMT
Last updated Thu, 20 Mar 2014 05:23:58 GMT

They look not symmetrically on 1024*768 and more, like on this screenshot: http://screens.doomgod.msk.ru/cross.bmp

would be nice someday

Bug accepted.

Bug 186
Posted By: denis (Denis Lukianov)
Posted On: Sun, 02 Apr 2006 20:26:27 GMT
Last updated Thu, 20 Mar 2014 05:24:00 GMT

Need a volunteer to organise the tranlsation effort. All menus, console text, etc. You do not need to know lots of languages, just lead the effort. Set up a status page on the wiki and find people to translate. Keep organised lists of strings. When there's at least one complete-ish language, we'll integrate it into the source.

Attached are CTF and Duel/FFA mockups for caster-friendly, spectator-only huds, which I will break down the changes and enhancements proposed from each:

First of all is an upscaled, and easier to read timer in the bottom. The reasoning for this is addressed in the second addition.

Second is changing the flags/frags obtained, flag/fraglimit, and the spread to large numbers. This is a direct response to Take The Crown feedback from spectators on QuakeCon's Twitch who found the numbers difficult to read through the stream due to their small size. In the case of CTF, the flag indicators were moved up slightly to accomidate.

Third is the SITREP proposed in this form, above the health and armor of the player. In CTF, spectators would see the status of all possible team players. This would include a small flag held indicator on the left side of the player's name, coupled with right-justified health indicator, and a way to indicate armor status. I used hash marks for this, but a custom shield symbol might be a good unique indicator as well. In Duel, this would server to allow spectators to instantly see the other player's status.

In addition to this, trunication might be required for long names or too many players. In the event of too long names, two trunication methods occurred to me. The first being to auto-remove team tags inside brackets from rendering. So "[SUC]Ralphis" would just be "Ralphis". The second being to have an arbitrary limit of characters, and then display a "..." after. For too many players, the top (10?) players could be shown, like a mini scoreboard. This would also ease casting large events without having to tap the scoreboard key a lot to get a status of the game.

Third and a half is adjusting the blue color to a more readable range of blue in the doom palette. The default ZDoom blue is very hard to read at a glance and during streams the bitrates might mulch the darker blues together.

Fourth applies solely to the Duel/FFA HUD but could be adapted to CTF as well. Yet due to the importance of powerup control in FFA or Duel I recommend it for these. They are item timers, showing the respawning powerups like armors or spheres in the map, with a dash for indicating currently up and ready to be taken, and a timer for when it is taken and a respawn is underway.

In certain wads that contains a mapinfo lump, this cannot be loaded in the port, e.g. duelpack.wad load even in vanilla or chocolate-doom, but in Odamex when is loaded the engine crashes, the problem dissapear when the mapinfo lump is deleted of the wad file.

The bug occurs in the latest build of the engine (0.9.0) running in MacOS Big Sur.

Bug 557
Posted By: mdvulture (HeX_Vulture)
Posted On: Mon, 04 Jan 2010 07:20:02 GMT
Last updated Wed, 10 Feb 2010 01:26:03 GMT

TEAMINFO is a wad lump introduced into ZDoom that allows one to create new teams. The teams can have a specific name and use specific color combinations to allow several options for team customizations.

I imagine that if TEAMINFO were to get introduced into Odamex it should take a similar approach to Skulltag's implementation to remain compatible with Skulltag and ZDoom. It is very simple to set up, an example for the Blue team can be seen here:

Team ""Blue""
{
PlayerColor ""00 00 BF""
TextColor ""Blue""

FlagItem ""BlueFlag""
PlayerStartThingNumber 5080

}

Note: This would be how the Blue team would be implemented into odamex.wad in the TEAMINFO lump if it were to be implemented.

However some additional things will probably have to be implemented to support the right flag icons in the HUD(SmallFlagHUDIcon/LargeFlagHUDIcon support too?).

When people usually want to use translations, they use either green or gray. (Green being what Doom originally used for changing player colors, and gray because it has the largest color range.) I would recommend putting a gray flag in odamex.wad, remove the red/blue/gold ones, and simply translate from there.

More info here: http://zdoom.org/wiki/TEAMINFO

Bug 587
Posted By: ghostlydeath (GhostlyDeath)
Posted On: Tue, 18 May 2010 04:06:35 GMT
Last updated Sat, 15 Dec 2012 04:57:41 GMT

On some servers, you have multiple IP Addresses, and in that case the socket library may decide what it really wants to use.

Would basically be this in i_net.cpp in the function BindToLocalPort

netadr_t na;

if -bind command line parameter exists
{
NET_StringToAdr(""<-bind address>"", &na);
NetadrToSockadr(&na, &address);
}
else // Any address
address.sin_addr.s_addr = INADDR_ANY;

Bug 666
Posted By: mwoodj (Mike Wood)
Posted On: Sun, 03 Oct 2010 04:37:19 GMT
Last updated Mon, 25 Nov 2013 23:53:56 GMT

This is for anyone using a joystick including Xbox or other console users. The keyboard should be displayed when a menu option is selected that requires keyboard input such as player name or save name. It should also be displayed when a user needs to enter text in-game such as when entering text in the chat line. It should also be able to be displayed using a bind so that a user can bring it up and enter cheat codes while in-game. There should be a menu option to enabled/disable the feature and it should be defaulted to off with the exception of game consoles where it should be defaulted to on.

Currently on Odamex 0.9, the HELP lump (f1 help screen in-game) scales the image to a 4:3 aspect ratio screen like the original doom2.exe

My feature request would be to open up the possibility of using 16:9 (or other aspect ratios) in the HELP lump/screen to allow players that play on 16:9 without any scaling/stretching/collapsing. Additionally, allowing transparency in these lumps/images would open up even greater possibilities for design and presentation of all types of WADs :-)

Here is a video to compare all of the multiplayer Doom ports' handling of the HELP lump/image. Something like ZDaemon's implementation is what my feature request aims to replicate (with a solid transparent color in place of any teal/see-through colors in the image itself):

https://streamable.com/z9c3e4

PS: The HELP lump image on this WAD has a native resolution of 1920x1080. All 3 ports had the resolution set at 1920x1080.

Describe the bug
Currently, when vanilla sound is enabled (co_zdoomsound = 0), sounds are played globally at full volume like they are in EXM8 of UDoom. Over the past week, I've joined in games and players really seem to hate this happening.

Build that the bug occurred in
0.9 Stable

To Reproduce
Make sure "co_zdoomsound = 0", go to Doom 2 Map08, listen to any sound.

Expected behavior
Make exception only apply to EXM8? There is some argument as to whether or not this is one of the intentional "tricks" of the map.

Screenshots, NetDemos, & Crash Dumps
N/A

Additional context
N/A

Describe the bug
In survival mode (g_lives > 0), you will automatically go into spectator mode once you run out of lives. After this happens, you can only move through spynext with F12.

Build that the bug occurred in
Odamex 0.9

To Reproduce
See bug description.

Expected behavior
Mwheel should scroll through available views as it does as a normal spectator.

Bug 597
Posted By: spleen.the.bloody (Spleen)
Posted On: Sat, 24 Jul 2010 04:16:15 GMT
Last updated Fri, 14 Oct 2016 21:24:25 GMT

Monsters seem to randomly desync in coop online, even when testing on a LAN and with sufficient rate/sv_maxrate variables set. For example, cyberdemons will sometimes show their firing sprites while moving around (a state desync, in this case).

Bug 219
Posted By: denis (Denis Lukianov)
Posted On: Tue, 26 Sep 2006 23:16:55 GMT
Last updated Sat, 12 Nov 2016 02:20:27 GMT

This bug is here to track progress with the OpenGL renderer. I know some people hate the idea, but everyone seems to be happy with it as an option.

Currently, a basic walls-only SDL-OpenGL proof-of-concept is located in branches/ogl_hack.

I think that unless we get more good coders with spare time on their hands (or maybe even then), the OpenGL renderer is the only way to fix bug 42, bug 143, and bug 188.

On Singleplayer, whenever the Doomguy is hit, he will turn his face left or right, depending on the angle of the attacker.

However on multiplayer, it will always face straight, and never turn his face around.

It looks like that on the client, the attacker is never declared, triggering this bug.

However, it looks like it will require a protocol change to fix this.

*** Bug 168 has been marked as a duplicate of this bug. ***

Bug 133 originally posted by denis (Denis Lukianov) on Sun, 26 Feb 2006 15:27:00 GMT and last updated Thu, 20 Mar 2014 05:24:00 GMT

Has been talked about, many people agree would be nice. There have been voices against, mainly because of poor implementation in other ports. Also solves the cross-platformness of launcher.

Not related to bug 99
Not directly related to bug 118

In some rare instances the status bar / mug might not draw the green textures while in widescreen. One reliable way to reproduce the bug:

1. join an online game with widescreen enabled as a spectator with the Doom hud on
2. switch to single player with ""new game""
3. game draws no hud texture border

(Bug 43)

Reassigned temporarily to Nes. If he doesn't find anything of usefulness to do we'll make a decision about this bug at that time.

Bug 221
Posted By: denis (Denis Lukianov)
Posted On: Thu, 28 Sep 2006 14:42:42 GMT
Last updated Sat, 12 Nov 2016 01:57:47 GMT

Pretty separate application to login to servers and do rcon. Because server GUI should not be linked to the server implementation.

Bug 167
Posted By: typone (Tom J.)
Posted On: Sun, 19 Mar 2006 16:01:57 GMT
Last updated Sun, 30 Mar 2014 21:19:13 GMT

When the PG / RL is fired, the plasma balls /rockets are displayed and audible after the ping returns, i.e. delayed. Which i think is the way it should work.

With any hitscan weapon (Pistol, CG, SG, SSG) the feedback is different. When any hitscan weapon is fired the sound is audible instantly without delay, whereas the visible feedback (the bullets hit something) is delayed by the ping. With the BFG the charging-up sound starts instantly after pulling the trigger but the plasma ball seems to be delayed as well.

I'd recommend making all of these weapon feedback events consistent (for instance every audible / visible feedback could be played delayed).

(Bug 112)

Cvar Overrides allow you to override certain cvars for certain maps, preventing
you from having to make one config criteria for your server.

I already wrote an implementation for ZDaemon, but would need to rewrite most of
it to make it snap into Odamex

For example... ( ZDaemon example, works with 1.07 and up )

add_cvaroverride map07 sv_infiniteammo true
add_cvaroverride map11 sv_respawnitems true

Whenever the server lands on map07, it'll temporarily override the
sv_infiniteammo cvar to true, and reset it to the server default when the map is
left.

add_cvaroverride map11 hostname ""Classic Map11 Deathmatch""

It allows for a lot of flexibity with minimal intrusion and thus should be
implemented for Odamex 1.0. Since I wrote the original implementation I will
take charge in writing this one.

Bug 299
Posted By: klaasedone (user'ok)
Posted On: Mon, 22 Jan 2007 15:41:41 GMT
Last updated Thu, 20 Mar 2014 05:24:00 GMT

would be good. when i go to quit menu or use a bind i must always switch from russian to english to make odamex understand my hotkey, that's not really handy.

Currently the internal jsoncpp and miniupnpc libraries are unconditionally built and statically linked. Respective USE_INTERNAL_JSONCPP and USE_INTERNAL_MINIUPNPC CMake build options should be implemented to enable users to link against their system-provided libraries.

Bug 585
Posted By: Ralphis (Ralph Vickers)
Posted On: Tue, 04 May 2010 11:10:48 GMT
Last updated Wed, 11 Sep 2019 19:32:28 GMT

Chocolate Doom recently implemented OPL Music Emulation. While it isn't perfect, it could potentially help Odamex for two reasons:

1. The cool reason. OPL Music is cool, sounds ""classic"", and is a great feature to have for a Doom engine. It also fits within Odamex's scope of providing an online experience relatively close to vanilla.

2. The practical reason. With all of the midi issues sdl_mixer causes for Windows Vista/7 users, offering the OPL alternative is a great solution that can be done without any changes to SDL_Mixer. The more people upgrade to the newer Windows that lack proper midi mapper support, the more complaints Odamex and other SDL Doom engines are going to hear. Offering OPL music would potentially fix a lot of these complaints.

When playing in an online environment, lifts and their respective switches are de-synced: the platform makes a sound and lowers first while the switch animation and sound follows after. I made a clip of this here (using the official/stable Odamex v0.9 build):

https://streamable.com/99mul7

Include guards are annoying to write and I cannot think of a C++ compiler we support that does not support the feature.

Here's the portability matrix:

https://en.wikipedia.org/wiki/Pragma_once#Portability

The most interesting compiler is GCC, which didn't support them "officially" until 3.4, though checking Bugzilla implies they supported it unofficially and intended to deprecate it much earlier.

Bug 565
Posted By: mike (Mike Lightner)
Posted On: Fri, 22 Jan 2010 01:26:15 GMT
Last updated Sat, 03 Apr 2010 19:47:46 GMT

This bug is for tracking support for Heretic and Hexen in the main engine. I would say ""return"" but quite frankly the previous code was more based on line specials and less on actually moving the progress forward in terms of loading things.

There is a branch called odaraven where this work will be done. As a result of this, we will be expanding gameinfo sets along with some new generalized functions and further code cleanup.

As of 1446 you can use a full heretic iwad and start the client. First steps are for the menus. You can see the menu, but you cannot start a new game completely until other lump loading issues are resolved. You can see episodes and skill levels though. This required adding in a general large text (fontb) drawer. Completing menu functionality will also require the sound tables to be set up as well, so it should help in getting things defined more generally.

Overall the first goal is to get the menu done, then to be able to load a map with no status bar, weapons or things loaded (just the map and textures and being able to move around).