A productive day

[randi]

Today, I had a chance to sit down and spend much more time with ZDoom than I have in some time. Here is today's entry from my log:

• Fixed: Using the MDK cheat always flung the dead things at you. Related, the maximum thrust to have something fall forward on death is now 10 units/tic.
• Fixed: ClearInventory always crashed because using GiveInventory to give a weapon afterward would not bring the weapon up, so the player's ready weapon would be left as something that doesn't exist.
• Fixed: The overlayed automap showed statistics when not viewing through a player's eyes.
• Increased MISSILERANGE to 20480 (was 2048).
• Changed the massacre code so that it sets the shootable bit for any monsters that have it cleared (such as Serpents, usually), so they die too.
• Fixed: Masked midtextures beneath a fake floor (or above a fake ceiling) only inheritted their light level and not their light color from the control sector.
• Added code so that when a map thing is spawned directly on a line, it will be moved 1/4 unit in toward the middle of the subsector so that it will be clipped reliably by the renderer. See the torch right in front of the player at the start of Heretic E1M1 for an example of this bad practice.
• Changed: MF2_FLOATBOB actors no longer splash on liquids.
• Fixed: P_AimLineAttack() clamped the player's vrange to 1 degree maximum instead of 1 degree minimum, so it would not aim past any two-sided lines if you were using 0 autoaim because the toppitch and bottompitch would be the same before even entering PTR_AimTraverse. This was the cause of the chainsaw not always pulling you in and melee weapons sometimes missing monsters that were clearly in range.
• Fixed: P_SpawnPuff() used linetarget instead of its hitthing parameter to determine if it should play the puff's SeeSound or AttackSound.
• Improved(?) the Bloodscourge so that its initial target search only looks in front of the player.
• Fixed: MStaffSpawn used linetarget, but P_AimLineAttack was never called to set it.
• Fixed: P_CheckMissileSpawn would destroy ripping missiles if they spawned inside something.
• Fixed: Dark servants could not be morphed in Hexen.
• Fixed: MageWandSmoke was not translucent.
• Combined all the WeaponPrefs list for each game into a single list.
• Added text skipping for the Hexen chess ending.
• Fixed: The chessboard finale drawer looked at userinfo.PlayerClass instead of CurrentPlayerClass to decide which chess piece to draw, so random players would always appear as the fighter.
• Fixed: When V_BreakLines() inserted newlines for word wraps, the default text color was restored for the new lines. Now it adds color escape sequences after any soft line breaks, but it leaves hard line breaks alone.
• Added support for marking scripts that are "safe for multiplayer". To do this, add net after the script header but before the script body. e.g.:

  Code: Select all

  script 1 (void) net { ... }
  script 1 open net { ... }
  script 1 enter net { ... }
  ...etc...

• Added the sethudsize ACS command. It takes three parameters: sethudsize (width, height, statusbar). The width and height is the size of the screen that hudmessage thinks it's drawing on. If this is different from the real screen size, the hudmessage will be scaled to make it fit. If statusbar is 1, then the height parameter covers the status bar and you can draw on top of the status bar. If it is 0, then the hud message will be stretched differently depending on whether the status bar is visible or not, because the height available to draw in is shorter when the status bar is visible. (However, a value of 0 will still let you draw on the status bar if the hud message extends below the height you specified.)
  
  After using sethudsize, hudmessage coordinates also behave differently. You now need to specify actual pixel coordinates and not numbers in the [0.0, 1.0] range. However, they are still fixed point, so you need to keep the decimal point. e.g. If you used SetHudSize (320, 200, 1); and want to draw a hudmessage at the center of the screen, you should pass it the coordinates (160.0, 100.0) and not (0.5, 0.5).
  
  The fractional part of the coordinates effect what part of the hud message you are positioning:
  
  For x:
  .0 = positions center of box
  .1 = positions left edge of box
  .2 = positions right edge of box
  .4 = centers text inside box
  .4 can also be added to either .1 or .2 to get .5 or .6
  
  For y:
  .0 = positions center of box
  .1 = positions top edge of box
  .2 = positions bottom edge of box
  
  e.g. If you used SetHudSize (320, 200, 1);, then the coordinates (160.1, 100.1) will position the upper-left corner of the hud message. The coordinates (160.2, 100.2) will position its lower-right corner instead.
  
  To make hudmessage behave as normal, use SetHudSize (0, 0, 0);.
  
  In summary, use sethudsize for hud messages that are really graphics, and don't use it for text (unless you want your text to appear the same size at all resolutions, such as a title with a special font or something).
• Added the getcvar ACS command. It returns the value of a cvar as an int, so scripts can alter their behavior based on cvars.
• Added the strlen ACS command. It behaves just like its C counterpart.
• Added support for loading compressed GL nodes when regular nodes are unavailable.
• Fixed: You could pick up items above your head because P_CheckPosition() added an extra 24 units of height to detect when you might step up inside another actor. It still does, but now PIT_CheckThing() takes this into consideration before touching it.

Sorry, I want to get through more of the bugs before releasing anything.

[Cyb]

wow, that's a lot of stuff

[Eevee]

alright, now everyone stop finding bugs until 2.0.48 is out...

[Sphagne]

Great news Randy, Hope it would coume out soon!

P.S. have you thought about that "Monster Sight Calculation" suggestion of mine?

[Hirogen2]

[*]Added code so that when a map thing is spawned directly on a line, it will be moved 1/4 unit in toward the middle of the subsector so that it will be clipped reliably by the renderer. See the torch right in front of the player at the start of Heretic E1M1 for an example of this bad practice.

I hope this only holds true for 1-sided linedefs!

[*]Added the getcvar ACS command. It returns the value of a cvar as an int, so scripts can alter their behavior based on cvars.

Could you give an example for what this might be used? setcvar(int) and setcvar(str) would be needed to, probably.

[*]Added support for loading compressed GL nodes when regular nodes are unavailable.

How can the software renderer profit from GL nodes or vice-versa?

[Graf Zahl]

How can the software renderer profit from GL nodes or vice-versa?

Why shouldn't the software renderer profit from GL nodes? One definite advantage I can see is that GL nodes store their vertices as fixed point numbers not shorts. That alone should be reason enough to support them.
Last time I checked the format of GL nodes was similar enough to the one normal nodes to be of use in the software renderer.

[HotWax]

In other words, if someone makes a map and only build GL nodes, because their game of choice is ZDoomGL, ZDoom would previously have to build regular nodes for it every time someone played it with ZDoom. Now, it makes use the GL nodes, which I presume are similar enough as to make no difference.

[Hirogen2]

So there is no need to build plain-nodes anymore?

[HotWax]

So there is no need to build plain-nodes anymore?

Depends on whether or not you want your level to be playable via Doom, Boom, and any number of non-ZDoom/GL ports.

[Hirogen2]

Right, is there a possibility to turn off building of normal-nodes? That would save some space for ZDoom levels.
BTW, if a map has a name longer than 5 charactes (i.e. nothing like ExMy or MAPxy), what will the GL map identifier be called? MAPNAME => GL_MAPNA I presume... would ZDoom then find the GL nodes for maps? Probably no.

[randi]

Please note the word in bold:

Added support for loading compressed GL nodes when regular nodes are unavailable.

The next version of ZDBSP will be able to save compressed nodes (GL or normal). The advantages of compressed nodes are:

• Less space used in the wad
• Full precision vertices even for non-GL nodes
• More than 64k segs
• More than 32k subsectors
• More than 32k nodes

The last two probably aren't much of an advantage, since those limits are very hard to reach.

ZDoom still does not load uncompressed GL nodes.

How can the software renderer profit from GL nodes or vice-versa?

The only appreciable difference between GL nodes and regular nodes is that GL nodes have minisegs and a specific seg ordering inside each subsector. It's not a matter of the software engine "profiting" from them; it just means you don't need to build two sets of nodes if you want to have nodes built for ZDoomGL in your wad (once ZDoomGL supports compressed nodes).

Could you give an example for what this might be used?

Code: Select all

getcvar ("con_scaletext")

setcvar(int) and setcvar(str) would be needed to, probably.

No.

Right, is there a possibility to turn off building of normal-nodes?

You will with ZDBSP 1.5, otherwise I wouldn't have bothered with this feature.

BTW, if a map has a name longer than 5 charactes (i.e. nothing like ExMy or MAPxy), what will the GL map identifier be called? MAPNAME => GL_MAPNA I presume... would ZDoom then find the GL nodes for maps? Probably no.

If you don't have any other maps that begin with the letters "MAPNA", I don't see a problem with it. But since ZDoom doesn't look for those anyway, it's not a problem for me. Compressed GL nodes and compressed normal nodes can coexist in the space used by uncompressed normal nodes, so there isn't any need for extra lumps when using them.

[Anonymous]

heh! that's super!!!
and Randy gotta 25 bugs to fix

[Hirogen2]

Count down to 0.

[Zell]

so, randy, why dont you make a bug list and fix one each a day like those little candy chocaltes that you buy, and you eat one each day closer to christmas. Hell, sometimes i eat two

[Anonymous]

Randy will be too fat