Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
baja blast rd.

*** The "ask a miscellaneous editing question" thread ***

Recommended Posts

Do maps in Boom format have some sort of height limit? I'm asking because i've read somewhere that if you make a map that goes higher than 512 or lower than -512, then you're going to have some sort of glitches. I can't remember the thread where i've read about that and i'm not sure if the one who said that was talking about Boom or Vanilla format.
I'm working on a map that will possibly go lower than -2000 in height and it's in Boom format.

(Also, this is my 666th post, give me my 'Evil Member' title, quick! Do it!)

Share this post


Link to post
ChekaAgent said:

I can't remember the thread where i've read about that

It might have been this very thread: https://www.doomworld.com/vb/post/1573747

ChekaAgent said:

and i'm not sure if the one who said that was talking about Boom or Vanilla format.

It's not about format, it's about the engine that you play with. The limit existed in vanilla Doom engine, and most ports since Boom have removed the limit. PrBoom-plus launched with vanilla complevel will actually emulate the limit.

ChekaAgent said:

Do maps in Boom format have some sort of height limit?

Only limit given by the map format: Minimum height is -32768, maximum is 32767. I'm not sure what exactly happens when you make floors/ceilings at the very borders of these limits, it might even be different in different ports, but certainly nothing good.

Share this post


Link to post
scifista42 said:

Only limit given by the map format: Minimum height is -32768, maximum is 32767. I'm not sure what exactly happens when you make floors/ceilings at the very borders of these limits, it might even be different in different ports, but certainly nothing good.

bigbox_v3.zip works in ZDoom, GZDoom, and Zandronum. If you fly up to the ceiling, you can pass right through and you will rise through the floor.

Share this post


Link to post

I fixed my code I had issues with before!

actor AmbientDaemon 16001
{	
	-SOLID
	-Shootable
	-NoPain
	-NoBlood
	+LOOKALLAROUND
	+Float
	Speed 0
	radius 16
	height 40
	States
	{
		Spawn:
			EGGY A 5
			EGGY A 1 Thing_Hate(0, 1000, 4)
			EGGY A 1
			EGGY A 5
			Goto See
		See:
			EGGY A 1
			EGGY A 2 Fast A_Chase
			EGGY A 1 A_NoBlocking
			EGGY A 1 A_JumpifCloser(512, "Check") // Checks if the player is within 512
			//  Ignore me // EGGY A 5 A_JumpifInTargetLOS("Daemon", 0, JLOSF_DEADNOJUMP | JLOSF_CLOSENOJUMP | JLOSF_NOSIGHT, 512, 256) //
			Loop
		Check:
			EGGY A 1 
			EGGY A 1 A_Log("Got to check phase") // Debug script to check if line 19 was triggered
			EGGY A 1 A_JumpifCloser(256, "See") //Aborts if player is in the minimum range, 256
			EGGY A 1 A_JumpIfInTargetLOS("See", 0, JLOSF_DEADNOJUMP, 512) // Aborts if player is in eyeshot
			goto Spawner
		Spawner:
			EGGY A 1 A_Log("Got to spawn daemon") // Debug script to check if lines 25 and 26 were NOT triggered.
			EGGY A 400
			Goto see
		Pain:
			EGGY A 1 A_Pain
			Goto Spawn
		Death:
			TNT1 A 0 A_SpawnItemEx("XenSplatter",random(-16,16),random(-16,16),random(-16,16),random(0,0.1),random(0,0.1),random(-1,1),random(0,359))
			TNT1 A 0 A_SpawnItemEx("XenSplatter",random(-16,16),random(-16,16),random(-16,16),random(0,0.1),random(0,0.1),random(-1,1),random(0,359))
			TNT1 A 0 A_SpawnItemEx("XenSplatter",random(-16,16),random(-16,16),random(-16,16),random(0,0.1),random(0,0.1),random(-1,1),random(0,359))
			TNT1 A 0 A_SpawnItemEx("XenSplatter",random(-16,16),random(-16,16),random(-16,16),random(0,0.1),random(0,0.1),random(-1,1),random(0,359))
			TNT1 A 0 A_Scream
			EGGD ABC 6 A_NoBlocking
			EGGD C -1
			Stop
	}
}
Its a bit sloppy, but it turns out that Thing_Hate and targetting only take effect if the monster is in its A_Chase state! To keep it stationary, I merely set its speed to 0.

Share this post


Link to post

Can somebody help me out with this skin I'm working on? I've checked other player skins and looked at various S_SKIN lumps and even read a tutorial online and for whatever reason it's not working the way it's intended to; as neither the sprites or sounds appear but the HUD face does change at least. Not sure what I'm doing wrong here.

Share this post


Link to post

The order of lumps matters: First should be the sounds (and HUD graphics), then the S_SKIN lump, then the sprites (and do NOT put the sprites between sprite markers). The sounds also might not play because the source port you're using doesn't support MP2 audio format.

Share this post


Link to post

That's certainly odd - I didn't find anything that indicated otherwise that it mattered, but after going through the WAD file again with those suggestions it seems to work fine now. Thanks!

Share this post


Link to post

The "RSKY1 patch replacing" method of replacing skies only works if the sky consists of a single patch which has the exact same dimensions as the respective IWAD sky patch (and texture), but CC4's SKY2 patch/texture is wider and taller than Doom2's RSKY1 patch / SKY1 texture, so you must redefine the actual TEXTURE1 entry of the sky to make the engine recognize its new size.

Share this post


Link to post

Is there a way to orient a large map in the 65^2 grid in order to avoid that issue where things no-clip through impassable lines? Or a way to build nodes, maybe? I had a map that took up 28*22 before some repositioning of areas, but it really seems like that isn't quite "ginormous" yet, and I was really surprised to find that the map was already getting spacious enough for me to hit whatever limits I hit.

Share this post


Link to post
rdwpa said:

Is there a way to orient a large map in the 65^2 grid

Move it so that its center would be as close to the [0,0] coordinate as possible.

rdwpa said:

Or a way to build nodes, maybe?

Change your node builder to ZDBSP to generate ZDoom extended nodes. (PrBoom-plus actually supports ZDoom extended nodes.)

rdwpa said:

I had a map that took up 28*22

28*22 of what?

Share this post


Link to post

Thousands of map units of space -- difference between most extreme +x and -x coordinate of a vertex in the map, and likewise for y.

Which ZDBSP option should I use? Of the non-UDMF options there are "compress nodes", "normal (no reject)", and "normal (zero reject)" (lolwut at the last two).

Share this post


Link to post

Try "compress nodes". Also, "no reject" means that the map will be saved with an empty (0-sized) REJECT lump (or maybe without a REJECT lump at all, I'm not sure), and "zero reject" means that the map will be saved with a REJECT lump filled with an appropriate number of bytes with 0x00 value, for compatibility with vanilla and ports that would crash upon loading a map that doesn't have REJECT lump at all or have a 0-sized or inappropriately sized one.

Share this post


Link to post

Reject tables can get pretty huge (i.e. wad file size) for large maps, but they definitely offer notable performance improvements in certain types of levels (lots of sectors + lots of mobs + groups of mobs tend to be sectioned off from eachother in some way). I remember when making m30 of SF12 that I could only play it at a decent fps when I busted out a command line version of zennode to build the reject table (the one baked into db2 failed if the map had > 2^15 lines), if zdbsp was capable of doing it all along then I guess I could've just used that, but ohwell.

Share this post


Link to post

I'm sorry if this has been asked before but... You know there are some new stuff in GZDoom Builder like a visual mode that shows you 3D floors and having the ability to align floor and ceiling textures and setting up colored lighting without using any scripts and having key numbers to everything and the like? How much of that actually works with normal Zdoom without OpenGL?

Share this post


Link to post

GZDoom Builder is just an editor. Its editing features, no matter what you create with them, do not affect compatibility with ports. The examples of features you've described are all ZDoom-compatible features of the UDMF format, nothing to do with GZDoom Builder in particular. If you're asking about GZDoom (not Builder) features that do not work in software renderer, go here.

Share this post


Link to post

Ah sorry about that I was talking about GZDoom. Though the link you posted was helpful, it didn't answer my question of what works in GZDoom but not ZDoom. Because I've played wads with 3D Floors, Slopes, translucent lines and colored lighting with software rendered Zdoom.

Share this post


Link to post

-Software renderer cannot display sloped 3D floors. It can display non-sloped 3D floors and non-3D-floor slopes, though.
-Translucent lines are OK for software renderer.
-Sector based colored lighting is uglier in software renderer due to being limited to the game's 256-color palette, but basically works.

Also, whatever (G)ZDoom feature that does NOT have an explicit OpenGL compatibility warning on its own zdoom wiki page, should be ZDoom compatible. Most of those features are listed here or here.

Share this post


Link to post

Ah thanks. This helped clear up all confusion.
It also explains why I was able to see slopes, 3D floors and colored lights in ZDoom.

Share this post


Link to post

So, for the 2D movement of my player I used this code in the 'see' state:

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_SIDEMOVE, AAPTR_PLAYER1) < 0, "MovingLeft")
I opted for using the DECORATE function over ACS, since I assumed this would be more efficient. Though I have to admit, the sprite-action still isn't very direct. I know I'm being a perfectionist here, but I would love to have the player sprite change instantly (or close to it) whenever the player presses the button.

Does anyone have suggestions, or should I accept this for what it is and move on?

Share this post


Link to post
Agentbromsnor said:

I would love to have the player sprite change instantly (or close to it) whenever the player presses the button.

This will do it:

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
Or even this: (to react on pressing "turn left" button the same way as "strafe left" button)
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & (BT_LEFT | BT_MOVELEFT), "MovingLeft")

Share this post


Link to post

That works as well! Thanks. To make this work optimally, I'm going to use a dedicated left and right state.

I'm also going to use a user variable to determine which movement button the player last pressed, so I can determine the side of the "idle" animation (which should be facing to the left or right). I think user variables should be the way to go in this regard, no?

EDIT: I just created this code and GZDoom crashed about a second after I start it:

	states
	{
		Spawn:
			PROT A 3
		loop
		
		See:
			TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
			TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")
		Goto see
		
		MovingLeft:
			PROT E 3
			PROT F 3
			PROT G 3
			PROT H 3	
		Goto see
		
		MovingRight:
			PROT A 3
			PROT B 3
			PROT C 3
			PROT D 3
		Goto see
	}
There's probably something really obvious I'm missing here?

Share this post


Link to post
Agentbromsnor said:

See:
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")
Goto see
There's probably something really obvious I'm missing here?

Yes, there is. Hint: What will happen if the player doesn't press either left or right button?

Share this post


Link to post
scifista42 said:

Yes, there is. Hint: What will happen if the player doesn't press either left or right button?


Whoops... Yeah, I should have seen that coming.

I could use this to my advantage to make a "grinding" animation, for when the player grinds to a halt.

I'm just pondering though... I just changed the 'see' state to this:

		See:
			TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
			TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")
			PROT A 3
		Goto see
Which works well, but I can't help but feel that polluting the 'see' state with different frames will make the GetPlayerInput states less responsive. Is this not an issue?

Share this post


Link to post
Agentbromsnor said:

I can't help but feel that polluting the 'see' state with different frames will make the GetPlayerInput states less responsive. Is this not an issue?

No issue at all.

Agentbromsnor said:

I'm also going to use a user variable to determine which movement button the player last pressed, so I can determine the side of the "idle" animation (which should be facing to the left or right). I think user variables should be the way to go in this regard, no?

I would personally prefer the good old method of declaring a dummy inventory item with MaxAmount 1, using A_TakeInventory and A_GiveInventory among the player's animation states to give him this inventory item when he turns right, and take it from him when he turns left, and using A_CheckInventory for said inventory item to determine which animation was the last one entered (if the player has the item, it means he last turned right, and if he doesn't have it, it means he last turned left).

Share this post


Link to post

Thanks. Reassuring to know it's not an issue.

I've seen the dummy inventory item method used in a lot of different ZDoom mods, though they are usually combined with ACS. I couldn't find anything on the ZDoom wiki when searching for "A_CheckInventory". It did have this page though: http://zdoom.org/wiki/Classes:CustomInventory

Do I have to combine it with ACS? Because if that's the case, I'd rather use the user variables in DECORATE for the sake of consistency.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×