PrBoom-Plus, ver. 2.5.1.4

VinceDSS said:

I want to make doom maps, not Serious Sam / modern games wannabes :)
There are much much better and modern engines to do such things without losing your time.

That's ok, but your idea about forcing all (popular) ports to implement some new features you need is absolutely crazy :) Even just for unlimited frames table you need to ask authors of Whacked, PrBoom/+, (G)ZDoom, Edge, Vavoom, DoomsDay, Chocolate-Doom to implement it.

forcing? I am merely suggesting and thinking out loud at that point :)

I believe greatness is achieved through cooperation not by doing things in your corner alone.

VinceDSS said:

mapping and item/monster editing are two completely different things to me.

So? Where's the problem. It's quite obvious that you want more than the conservative ports but at the same time map for the lowest common denominator available.

I'm sorry but this is not possible. If you can settle for MBF and use the added frames it has to offer to Dehacked it's the farthest you will get.

If that's not enough you'll have to choose - and at the moment the only realistic choices are ZDoom and Eternity. With a little effort you might even be able to create something that works with both.

I want to make doom maps, not Serious Sam / modern games wannabes :)
There are much much better and modern engines to do such things without losing your time.

Again, what's the problem? There are tons of ZDoom maps out there that don't go any further than to make a Doom map with a few added features. There's no need to use scripting or slopes or whatever else the engine provides that you don't need.

Truly unlimited frames is crazy, but a big-ass amount of extra frames is very easy. Likewise for extra actors. It would be quite simple to just add like 50 dummy actors and 5000 dummy frames. People could then build brand-new stuff in DeHackEd without having to cannibalize existing actors. That's the approach taken by the aforementioned Fusion port.

Support in Eternity and ZDoom wouldn't be hard, since they both have ways to add extra frames and actors available to DeHackEd. I'm sure it wouldn't be a problem in the others. (Well. Chocolate Doom, of course, would not support it at all since it would be contrary to its mission statement.)

That said, DeHackEd is more a crutch than anything else. Seniority is the only reason it has near-universal support.

VinceDSS said:

I believe greatness is achieved through cooperation not by doing things in your corner alone.

... but that's how many things have developed in the Doom world...


Of course you are correct but it's really too late for this now.
There's far too many people involved and far too many egos to satisfy and you can be sure that one will always block such an effort. And let's be honest: If Doom engine progress were decided by committee we'd still be stuck at Boom. You won't get progress unless people can do their thing - even at the risk of breaking away from the flock.

If you make a Doom 1 project, you have the freedom to add all-new monsters.

I'm not particularly fond of adding new power to PrBoom editing, other than fixing some MBF incompatibilities that might arise. While I was among the group that criticized the "Limitations breed innovation" thread, I was more against not using any new content. With MBF yes, you still have to destroy some existing monsters to give room. But you're free from the pressure of total freedom, and know when to stop monster-editing, in order to move farther. But probably if you're a good author, this need for limitation wouldn't help anyway.

If I map something for PrBoom using MBF features, I wouldn't count on ZDoom adding support for it. While some features are indeed emulated in ZDoom (Mushroom, RandomJump/A_Jump, Spawn, PlaySound, TOUCHY) others are very specific and deeply coded (FRIEND, BOUNCES), and would join an already large population of similar flags that use classic ZDoom, Hexen or Strife behavior.

I always thought per-map dehacked would be a nice feature. That is, the ability to use a different dehacked file for each map. That way, inside each map, you would only be using things allowed by Doom2.exe/Boom/MBF/whatever, but you could have very different behaviour (weapons, monsters, sounds, code pointers, bosses, etc.) in individual maps without it impacting or restricting what you can do in other maps. I've no idea how feasible that is though, or if dehacked stuff can only be loaded at program start and there is absolutely no way around that (short of a huge rewrite).

Just thinking aloud. Not a feature request!

myk said:

No.

Speaking of not supporting OPTIONS lumps, is there any particular reason not to?

OPTIONS doesn't overwrite user's settings, it only is in effect while the WAD containing it is being played.

Also, having Yes or No on several compatibility options may critically affect the gameplay. It's good to be able to control which settings are allowed in a WAD relying heavily on advanced features.

For example, if you allow the Boomism of objects being pushable off ledges, you'd be able to make objects and monsters on a conveyor fall off. This is critical if the objects are items.

It's better of the end-player not to need to bother with compatibility settings before playing a wad with stuff.

2.5.0.7.test from the change log page contains details_test.wad. Do these custom details work correctly for everybody? You should use GL renderer for testing and "Options\General\Allow Details Textures" must be enabled.

Works fine on my machine. 8800GT with latest drivers.

entryway said:

2.5.0.7.test from the change log page contains details_test.wad. Do these custom details work correctly for everybody? You should use GL renderer for testing and "Options\General\Allow Details Textures" must be enabled.

Apologies for the possibly dumb question, but is the music supposed to change from map01's music to map31's music when you cross the farthestmost set of columns? Because that happens to me every time.

emailking said:

Apologies for the possibly dumb question, but is the music supposed to change from map01's music to map31's music when you cross the farthestmost set of columns?

MUSINFO lump + special thing (14101-14164) in sector (from Risen3D).

I've been bedevilled lately by random lockups on exit which leave me with a mouse pointer on a black screen and an unresponsive keyboard. The last entry in stdout.txt is I_ShutdownSound: - is this an SDL issue?

GreyGhost said:

I've been bedevilled lately by random lockups on exit which leave me with a mouse pointer on a black screen and an unresponsive keyboard. The last entry in stdout.txt is I_ShutdownSound: - is this an SDL issue?

I do not know, because I do not have it.

Maybe I was just born unlucky. I'll try switching to an older SDL library to see if it's better behaved.

GreyGhost said:

Maybe I was just born unlucky. I'll try switching to an older SDL library to see if it's better behaved.

If you get it often, then you can try -nosound for checking. What OS do you use? I hope it is not Win98.

printz said:

I wasn't able to even run PrBoom, after I set it to 1280x1024 resolution and 5:4 ratio -- it quits because of Signal 11

I have made some changes in "aspect ratio" / "Status Bar and Menu Appearance" code. You can check it again.

Hmm. During demo playback, particularly with demos that span multiple levels, by default you could press 'end' to skip ahead to the next level, for some reason that wasn't working with the latest test release, it instead made the music restart.. but renaming my .cfg and creating a new one fixed that.. not really sure what I may have done to cause that.

entryway said:

If you get it often, then you can try -nosound for checking. What OS do you use? I hope it is not Win98.

I'll try that, if only for DoomBuilder testing since Doom without sound isn't the same game. I'm using XP Pro with service pack 3, does anyone here still use Win98 apart from myk?

-complevel makes mouse movement choppy in Linux while recording.

By choppy I mean the amount of mouse travel needed to move screen to a new angle. The extreme slightest nudge should move screen. But if I use -complevel while recording and move mouse very slowly, the screen wont move at all.

Also this showed up between r3475 and r3476. r3475 makes binaries, everything after doesnt. bootstrapped and re./configured for each test.

/usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../i486-slackware-linux/bin/ld: Warning: size of symbol `cheat' changed from 60 in d_deh.o to 2880 in m_cheat.o
r_demo.o: In function `G_ReadDemoFooter':
~/.prboom-plus/prboom2/src/r_demo.c:949: warning: the use of `mktemp' is dangerous, better use `mkstemp'
gl_sky.o: In function `gld_ParseSkybox':
~/.prboom-plus/prboom2/src/gl_sky.c:958: undefined reference to `strupr'

This sounds like a longtics/shorttics issue, and that it is working correctly.

Catoptromancy said:

The extreme slightest nudge should move screen.

Not if you are recording in any complevel such as Doom, Boom or MBF (or earlier PrBoom), when shorttics behaviour is applied by default (since this is the way Doom works). If you really don't want this, then add -longtics to your command line. But note that this records a demo that is not compatible with the exe that you are asking it to emulate.

Demos recorded on vanilla doom are just that much more impressive to me because of this, I can't stand the mouse when recording, it destroyed any motivation I had to record vanilla compatible demos.

Complevel 16 does this, complevel 17 doesnt. Shorttics and longtics makes a difference between prboom-plus 2.5.0.6 and 2.4.0?

Maybe I got used to recording another map without complevel so long. Then noticed it going back to -complevel 2. I think ill stick to complevel 16, instead of none to keep mouse consistent.

Catoptromancy said:

gl_sky.o: In function `gld_ParseSkybox':
~/.prboom-plus/prboom2/src/gl_sky.c:958: undefined reference to `strupr'

fixed

VinceDSS said:

The other, even better idea would be to extend dehacked to add your own ... code pointers.

I think Vavoom can do this.

Grazza said:
If you really don't want this, then add -longtics to your command line. But note that this records a demo that is not compatible with the exe that you are asking it to emulate.

The problem is with Boom and MBF, as no one's compiled or hacked them to do use long tics. For Doom, it's much like applying a DeHackEd patch, and maybe a bit better, since a demo recorded with a DeHackEd patch has no internal way to warn the user of the changes.

Catoptromancy said:
Complevel 16 does this, complevel 17 doesnt. Shorttics and longtics makes a difference between prboom-plus 2.5.0.6 and 2.4.0?

From PrBoom's NEWS.txt:

Changes from v2.4.0 to v2.4.1
- PrBoom demos are now recorded with high-precision turning (like the
  "Doom v1.91" hack that is floating around)

Maybe I got used to recording another map without complevel so long. Then noticed it going back to -complevel 2. I think ill stick to complevel 16, instead of none to keep mouse consistent.

I'd suggest using short tics anyway if you want to share a speed run, so your demo is like the ones most people record. If you're just recording for yourself or something less public, either way is fine, of course.

So a low complevel automatically uses shorttics?
I usually use a wad's txt file to choose a complevel or date of wad release.

Revision: 2366
Author: graf
Date: 11:47:38, 13 червня 2010 р.
Message:
- Added support for Risen3D/PrBoom+'s MUSINFO lump.

That's cool, but please, do not fail on unsupported stuff in GLDEFS lump

Script error, "details_test.wad:GLDEFS" line 11:
Error parsing defs. Unknown tag: Detail.

Also your implementation differs from Risen3d. Music should not change immediately.

entryway said:

That's cool, but please, do not fail on unsupported stuff in GLDEFS lump

To not fail I need to know about it because I need to skip it. So if you add your own stuff you need to notify me about it so that I can change my parser.

Also your implementation differs from Risen3d. Music should not change immediately.

When should it change?

Graf Zahl said:

When should it change?

After 30 gametics

Graf Zahl said:

To not fail I need to know about it because I need to skip it. So if you add your own stuff you need to notify me about it so that I can change my parser.

I think you must skip all unknown stuff:

unknown_stuff
{
...
}

Even if stuff is known, but you fail to parse it, then I suggest to skip it too instead of failing. GLDEFS is additional visual stuff. If you do not understand it - just skip it.