What ports do YOU use?

A big difference is that stairbuilding is a standard editing feature used on several vanilla maps, whereas ghost monsters are not. It is therefore a lot more likely that some little-known map was created that needs the original stairbuilding method than a map that requires monsters failing all collision checks.

Share this post


Link to post
myk said:

Ah, I see, you need to edit compatibility.txt in zdoom.pk3 and add the corresponding hash values and levels to the section on ghost monsters. Rather awkward, but the option is there.

You called it a "serious bug", but that's really up to the user to decide in this case.



It's a 'serious bug' because unintentionally creating ghosts can easily ruin playing a map that's not designed for it.

Also, no map in existence is utterly dependent on this. Normally the worst that can happen is to make the player's task a bit easier.

Share this post


Link to post

It's not a serious bug. Only you think it is. While you are a pretty good programmer, you're not someone who's opinion is regarded when it comes to the matter of good game play.

Share this post


Link to post

What do unintentionally created ghosts have to do with gameplay?

Answer: nothing at all. They are an engine bug that really can screw you over if you are unlucky. Ever experienced a ghost Revenant following you everywhere on a large map and you can't kill it because you don't have the rocket launcher? Better get your latest savegame and start again because you'd be screwed otherwise. So yes, if ghosts are created unintentionally I consider them a serious bug on the same level as a door or lift no longer working properly.

Intentionally created ghosts, despite being annoying as shit, are different.

Share this post


Link to post

I don't see how a monster failing all collision checks can be considered not a serious bug.

Share this post


Link to post
kristus said:

Hate using Doomsday though because of it's launcher.


I hate launchers too, but why you cant use it without launcher? Just by jHeretic.exe

You using later versions than 1.8.6 ?

Share this post


Link to post

PRBoom or DosBox for watch demos

GZDoom for play Strife (because there is not a jStrife now)

ZDoom for some tests (if need). For example fast and agressive (skill 5 mode) monsters tests.

ZDaemon for internet play

DosBox for create original opl soundblaster 220 music packs. Maybe I will use Chocolate Doom for this, when he will support correct OPL emulation.

Doomsday for Singleplayer.

In DoomsDay I use my own original opl soundblaster 220 music packs for jHeretic and jHexen, remastered music by DJ RedLight for JDoom, and edited versions of other packs: for example I deleted 3d models that I dont like and left 3d models I like and so on. 3d Models, Particles, Textures, Halos and Lights - turned ON. In jHexen I use "ambient light level = 255" because I like bright version of Hexen:)

Share this post


Link to post
theleo_ua said:

Why you cant use it without launcher? Just by jHeretic.exe

You using later versions than 1.8.6 ?

Do you think a guy who is the best mapper for heretic and who has 8000+ posts here do not know something about heretic? ;)

Share this post


Link to post
entryway said:

Do you think a guy who is the best mapper for heretic and who has 8000+ posts here do not know something about heretic? ;)


I dont think anything about any guys on this forum, but I really want to know - why he need launcher, because I never used launcher before.

The only reason, I think, to use launcher, is higher versions than 1.8.6 (if they doesnt support "launcher=off" mode)

Share this post


Link to post
entryway said:

Do you think a guy who is the best mapper for heretic and who has 8000+ posts here do not know something about heretic? ;)


What does Heretic it'self have to do with how a port launches the games.

Also, what does it matter if someone does or doesn't like how port X launches the games.

Share this post


Link to post

Me? I always liked having a launcher in handy. Especially when it was time for custom wads.

Share this post


Link to post

I've always just made separate batch files for each custom wad that I want to permanently have quick access to.

Share this post


Link to post
Mike.Reiner said:

I've always just made separate batch files for each custom wad that I want to permanently have quick access to.


Me 2

Share this post


Link to post

I will try Chocolate Doom for OPL music issues, when he will support correct OPL emulation.

Maybe I will use it instead of DosBox

Share this post


Link to post
theleo_ua said:

I really want to know - why he need launcher, because I never used launcher before.

jDoom.exe does not work if current dir is not jDoom.exe dir. Also it does not recognize %DOOMWADDIR%.

I do not want to have another copy of all my wads in doomsday folder and I do not want to have all DoomsDay's files and folders in my common DOOM dir which contains all wads I need and I do not want to RTFM for trivial things.

.\Doc\Example.bat (fixed with full path) also does not work if I start it from my DOOM folder in this way: example -iwad doom2.wad

Also it annoys me a little, when after each attempt I get error message twice: with MessageBox and with notepad.

I know it's possible to start jdoom heh, but I do not want to use any kind of launchers and I do not like to fuck with 250kb of documentation just for starting Doom and I do not want to try to recollect all this magic again in future.

Generally, when I need to start jdoom with minimal tortures I do it in this way:
jDoom.exe -iwad D:\games\Doom2\DOOM2.WAD -file D:\games\Doom2\MM.WAD D:\games\Doom2\MMMUS.WAD

Not really hard from file manager, but would be much better for me if DoomsDay will have only jDoom.exe\jHeretic.exe\jHexen.exe in its main folder and all the internal stuff in single DoomsDayData folder

Share this post


Link to post

You do realize that jdoom.exe/jheretic.exe/jhexen.exe are nothing more than glorified shortcuts? They aren't even included in newer releases because the command line they forward is no longer valid.

You would be better calling doomsday.exe directly and specifying the game you want via the command line e.g.:

doomsday.exe -game jdoom

Why do you expect to be able to use the same command line options for Doomsday as you would the original game executables? Yes some of the available options are the same for user convenience but expecting it to work exactly the same is asking too much don't you think?

Share this post


Link to post

When the core option set is the same across all ports, then it is a lot more convenient for automated launchers that assume they can just change the name of the exe on the pre-built command line. This includes frontends such as ZDL, but also the test mode of editors such as DB2.-

Share this post


Link to post

Yes but consider why that is possible - none of the other ports use the same architecture as Doomsday where the game code is not in the main executable.

Share this post


Link to post
DaniJ said:

You do realize that jdoom.exe/jheretic.exe/jhexen.exe are nothing more than glorified shortcuts?

Yes of course, but they make sense for me just for forcing "-game jdoom"

DaniJ said:

You would be better calling doomsday.exe directly and specifying the game you want via the command line e.g.:

doomsday.exe -game jdoom

It does not work if current dir is not DoomsDay dir:

D:\games\Doom2>D:\games\Doom2\DoomsDay186\Bin\Doomsday.exe -game jdoom -file mm.wad

doom2.wad and mm.wad are in D:\games\Doom2

DaniJ said:

Why do you expect to be able to use the same command line options for Doomsday as you would the original game executables?

Because I think it's still Doom port.

Share this post


Link to post
entryway said:

Because I think it's still Doom port.

Nnnnnnnnot precisely... :)

Share this post


Link to post
DaniJ said:

Yes but consider why that is possible - none of the other ports use the same architecture as Doomsday where the game code is not in the main executable.

The code that identifies the IWAD (so that it can tell whether it's Doom or Doom 2, etc.) could very well be used as well to automatically determine which game DLL to load. "This is Doom II, therefore load jdoom.dll." Would make the architecture difference irrelevant to the end user.

As for the question of finding files, if they're not specified with a path, then it should check current working directory, program directory, and %DOOMWADDIR% (in that order IMO).

Share this post


Link to post
entryway said:

It does not work if current dir is not DoomsDay dir:

D:\games\Doom2>D:\games\Doom2\DoomsDay186\Bin\Doomsday.exe -game jdoom -file mm.wad

No it won't because it thinks the runtime and base directories are the location in which doomsday.exe resides. You need to specify them (see here: http://dengine.net/dew/index.php?title=Command_line_option_reference#-userdir_P_.28-ud.29


Because I think it's still Doom port.

Whether you think its still a DOOM port or not does not alter the reality of it being very different.

Share this post


Link to post
Gez said:

The code that identifies the IWAD (so that it can tell whether it's Doom or Doom 2, etc.) could very well be used as well to automatically determine which game DLL to load. "This is Doom II, therefore load jdoom.dll." Would make the architecture difference irrelevant to the end user.

Think about that suggestion. In order to implement it would require altering the core engine whenever a new game is supported, adding the logic necessary to detect the game from the loaded resources. Rather defeats the point of having plugin game modules no?


As for the question of finding files, if they're not specified with a path, then it should check current working directory, program directory, and %DOOMWADDIR% (in that order IMO).

This is precisely what happens (with the exception that there is no support for %DOOMWADDIR%).

Share this post


Link to post
DaniJ said:

Think about that suggestion. In order to implement it would require altering the core engine whenever a new game is supported, adding the logic necessary to detect the game from the loaded resources. Rather defeats the point of having plugin game modules no?

I don't really see it this way because the detection code is just checking for a few specific lump names. The only game-specific part of it is which lump names it looks for. The technical part of scanning a wad for its lumps is standard code that would be quite needlessly duplicated in plugins. And it's not like new supported games are added every other week; plus nothing prevents even then from using the -game parameter.

Share this post


Link to post

Correct, but then there's not enough abstraction which seems to be the primary goal here.


If you want to keep it abstract have each plugin implement an identification function and let that decide if the provided file is valid. Who cares if multiple plugins each waste 0.05 seconds on this? Nobody will ever notice.

Share this post


Link to post

Indeed that is how it is done in the 2.0 architecture. It couldn't be done in earlier releases (1.8.x based) because they did not allow for dynamic changing of the game whilst running and/or loading multiple game modules. In 2.0 the user is presented with a game selection GUI with which they can also change the currently loaded game at any time.

Gez said:

I don't really see it this way because the detection code is just checking for a few specific lump names. The only game-specific part of it is which lump names it looks for. The technical part of scanning a wad for its lumps is standard code that would be quite needlessly duplicated in plugins.

You are assuming that all supported games use WAD and the lump-game-selection logic applies.

And it's not like new supported games are added every other week

That is irrelevant. It is/should be possible for anyone to create a new game plugin using just the SDK without recompiling the engine.

...plus nothing prevents even then from using the -game parameter.

True. Although it would result in a much less elegant design architecturally speaking.

Share this post


Link to post

Then the identification data can be put in the configuration file; this way it's abstracted out of the main exe has well. Can do away with the lump name thing and have the user directly associate IWAD names with games in the ini.

Share this post


Link to post

Yes but then that means:
A) The engine must include generic version of the lump-game-selection logic and then interface that with the config files.
B) Assumes this logic makes sense for all supported games which may not even support WAD.

The engine should not be involved in the identification process at all. It is much cleaner to ask the game module whether it recognises a game logic it can provide the engine from the available resources.

Share this post


Link to post
Gez said:

Can do away with the lump name thing and have the user directly associate IWAD names with games in the ini.

Share this post


Link to post
This topic is now closed to further replies.