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

5 hours ago, AJOgames said:

DEVG D 1 A_JumpIfInventory("WildRocketOnecheck",0,"Reload")

This doesn't do what you think it does.

https://zdoom.org/wiki/A_JumpIfInventory

My advice would be to rework your counter system so as to count up instead of down. In fact, you could probably just get away with using A_CheckForReload(50, "Reload") instead of using dummy items. Call A_ResetReloadCounter in the Reload state sequence.

Thank you @Gez this is much simpler to implement compared to the the dummy inventory tactic I used earlier,

 

Also, there's another thing I was wondering...

 

I wanted a specific action to happen when trying to use "Altfire", 

 

When you see Atfire in the decorate code I posted eariler, you will see these two actions I put befre the actual A_FireCustomMissile function occurs,

 

it looks like this:

DEVG A 0 A_JumpIfInventory("WildRocketOnecheck",2,"MustReload")
DEVG A 0 A_JumpIfInventory("WildRocketOnecheck",1,"MustReload2")

(now obviously, this isn't the ideal way to do this sort of thing, but i didn't know any better at the time)

 

since that post, I have modified the code to actually include the custom actions "MustReload" and "MustReload2", they look like this:

 

 MustReload:
      DEVG AB 1
      DEVG A 0 A_Playsound ("TRR/MustReload")
      DEVG A 1 ????? "You do not have enough ammo to use the alternative fire mode."
      goto Ready
  MustReload2:
      DEVG AB 1
      DEVG A 0 A_Playsound ("TRR/MustReload")
      DEVG A 1 ????? "You only have enough ammo to use the normal fire mode."
      goto fire

 

Now the idea of the Altfire was when you press the alternate Fire button, the weapon will quickly check to see if there is enough ammo to use the Altfire,  (the Altfire requires at least 3 rockets in your ammocount to fire.) if there are only two rockets in your ammocount, it would go to "MustReload" and say that you don't have enough ammo to use this mode, before going to "Ready", 

 

If the player only has one rocket left in their ammocount when they try to use the alternative fire, it would go to "MustReload2" which is almost the same as MustReoad, but tells you that you only have enough ammo for the normal fire mode, after that, it will automatically go to the "Fire" action, instead of "Ready".

 

Problem is, I don't know what action can send a message to the player, (sort of like the "Obituary" used by Monster actors or the PickUpMessage used by a weapon/powerup/other pickups.)

 

The "?????" you see is just a placeholder.

This is a handy page to have bookmarked. Scroll down to Print actions.

https://zdoom.org/wiki/Action_functions

4 minutes ago, Empyre said:

This is a handy page to have bookmarked. Scroll down to Print actions.

https://zdoom.org/wiki/Action_functions

Thank you so Much!

Given how A_JumpIfInventory will jump if the player has at least as many of the inventory item in question, your checks for 1 or 2 will always trigger when the player has enough ammo to use the alt-fire mode; and will only not jump when the player has zero.

 

Oh, and you should check the ammo type directly, of course.

 

A simpler approach would be this pseudocode:

AltFire:
	A_JumpIfInventory("ActualAmmoType", 3, "AltFireOkay")
	A_Log("You do not have enough ammo to use alt-fire")
	Goto Ready
AltFireOkay:
	<insert shooty code here>

Note also that you can let ZDoom do the ammo check for you by using the Weapon.AmmoUse2 property...

Which Boom port should I use? I see there is Boom, PRBoom, and glBoom. Also, what editor should I use to map in Boom format and is it ok to use GZDoombuilder in Boom format or should I use a different one, like DoomBuilder. Any advice/recommendations appreciated.

4 minutes ago, Payload4367 said:

Which Boom port should I use? I see there is Boom, PRBoom, and glBoom. Also, what editor should I use to map in Boom format and is it ok to use GZDoombuilder in Boom format or should I use a different one, like DoomBuilder. Any advice/recommendations appreciated.

Prboom+ as whole includes prboom+ and glboom+ branches, so you can use both for testing, one runs on software mode and second one is opengl related. I use gzdoom builder for my boom maps, so you can use that freely, without any problems, besides changing node builder in zdbsp with zero reject.

Thank you @Misty. Is the node builder change a personal preference or are there problems with zdbsp. I'll admit ignorance on the whole node builder topic.

8 minutes ago, Payload4367 said:

Thank you @Misty. Is the node builder change a personal preference or are there problems with zdbsp. I'll admit ignorance on the whole node builder topic.

Well, zdbsp can handle big boom maps without any problems and minimal slimetrails. I use it, because my maps are getting bigger and more advanced with each map. It's what I wanted to say :""")

2 hours ago, Payload4367 said:

Thank you @Misty. Is the node builder change a personal preference or are there problems with zdbsp. I'll admit ignorance on the whole node builder topic.

 

The default node-builder is ZenNode, and generally when starting out Doom mapping you don't need to worry about changing the node-builder.  When play testing your map if you start to see some really weird things happening (like walls disappearing, falling through the floor, rooms not appearing, or just not loading at all), then it might be worth playing with the other node builders (or just asking on here), but you'll be probably quite an experienced mapper and be making maps that do pretty advanced things before you start to run into issues like these.

How do you change starting textures (STARTAN2, FLOOR0_1, CEIL1_1) in GZDoom Builder? Seeing those ugly textures all the time just makes me not want to map at all.

Quick question: I have a lift made out of 5 sectors, via sector_setlink. Is it possible to use a walkover line trigger for lifts made out of several sectors? If I change to a switch it works, but if I want to use a walkover trigger the lift and my hopes to ever make a decent map fall apart.

22 hours ago, elend said:

Quick question: I have a lift made out of 5 sectors, via sector_setlink. Is it possible to use a walkover line trigger for lifts made out of several sectors? If I change to a switch it works, but if I want to use a walkover trigger the lift and my hopes to ever make a decent map fall apart.

You aren't trying to use the same line for sector_setlink and for the walkover trigger line, are you?

Yeah, it's not the same line. Trigger is actually the outer line of the lift, with the little linedef peg facing to the direction the player is coming from. Whereas the sector setlink is one unused line within the lift.

Are you putting the correct tag on walkover trigger, the one for the lift and not the one for the sector_setlink?  I am just trying to think of things that might make it not work.

At first I didn't use a control sector. This worked fine with a lift controlled by a switch. But a walkover trigger didn't work.

Now I am trying to figure out, how to use a control sector, but I have a real hard time understanding this. See those images attached, what am I doing wrong? The lift should be attached to the control sector, right? The control sector is moving up, like the lift is supposed to be. But once I trigger the control sector with the walkover line, nothing happens. Yet, I hear the control sector going up. Additionally I have a hard time understanding that window with those flags.
 

 

 

 

The activation method shouldn't matter, if the sectors are linked they should stay linked.

 

Here's a simple example.

linkedlift.zip

@Gez Thank you so much for your effort! It finally worked. Turns out, in the sector set link I don't have to specify the control sector tag?! I also added another sector to the control sector, so that the lift has something to go up to, but I am not sure if this was necessary. Nevertheless, it works now. Thank you so much!

 

<3

.

Edited September 2, 2023 by Krull

What version? If it's GZDoom 3.7.0 or 3.7.1, try to upgrade to 3.7.2 and see if the problem doesn't just go away.

.

Edited September 2, 2023 by Krull

Hello again,

 

I've been trying to create a color palette based off of the original Doom palette, (but give it a more grittier look to it.) but I think I messed it up a bit.

 

Here's the thing, I tried taking aspects of other game palettes that I liked  and tried to insert them into the standard Doom palette.

But, being the first time I ever tried manually changing the palette (or indeed any palette for anything.) I of course messed up some things,

Some of the color palettes that I (tried) taking the colors from were from the following games.

 

Lameduke (1994 Duke3D beta) (this is the main color palette that I took some of the colors from. mainly the Dark and light blues, yellows, the greys the tan/flesh tones, and the reds)

Fate (1997, cancelled build engine game by Capstone,) (tried taking the flesh tones, Dark-Greens, Oranges, Browns, Aqua-type colors.)

 

There are some good things about the palette I created, the reds from the Lameduke palette were successfully brought over to the custom palette, and when playing Doom with GrittyPalette.wad put in, it really does names it look a bit more darker and gritter, but the problems with the graphics looking lightly messed up in places kind of ruins it a bit, giving it an unintentionally grainy look to it as well, which is what I want to fix.

 

but, just so you can follow along a bit easier, I'll post some pictures here to allow you to see what I'm talking about.

First here's my palette:

Okay, now here's the Lameduke palette.

 

(just to get things straight, in the Lamedukepalette picture above, "ReiPalette" was an earlier name for GrittyPalette, just throwing that out there.)

Now the red from Lameduke that I took is between the light green and the yellow, and the grey that I took is at the very top of the palette, the flesh tones I tried taking from is between the dark red and orange. and  speaking of dark red, that was also carried over to Grittypalette

 

The hard part for me was that fact that I had to manually change the RGB values of the reds in the Doom Palette to match the ones in the Lameduke palette. it worked for the red, not so much for the grey which I did rather sloppily, 

 

Now I wanted to change the greys in the Doom palette to the one seen in the Lameduke palette mainly because the greys in Doom, for me anyways, looked a bit to bright, Lameduke's greys look more dark and dirter, which is what I wanted to add to the Doom palette I was editing.

 

Now the palette I am editing, given the name "GrittyPalette" is obviously not finished, the yellows seen in the Lameduke palette have yet to be inserted into GrittyPalette, and the same can be said for most of the blues, greens, and some of the browns. 

 

Now here;s the Fate palette.

Now the colors I too from this palette and (tried) to put into Grittypalette are the light Grey and AquaBlue (seen here on the 2nd and 3rd row respectively, below the dark blue on the 1st row.) the ones I have yet to do are the Dark-green (14th row) Dark-Brown (13th row,) Now as for flesh tones, I didn't really know which one to pick, because there are technically three, (first one is 10th row, second one is 7th row, columns 1-8 and the third is 16th row, columns 1-8) so I'm kind of at a standstill with that one.

 

Now another thing you might've noticed about the Lameduke and Fate textures is the direction of the color depth, Both Lameduke and Fate are Build engine games, o the palettes for these games are handled differently, and if you look at both of the palettes from left to right, the colors go from dark to light, but on Doom engine games, the colors on the palette (looking from left to right) go from light to dark, which was yet another difficult thing I had to deal with when trying to take the colors from these palettes and put them in GrittyPalette.

 

I did see a post on ZDoom forums that interested me a bit, someone was editing the Doom palette in a certain way,and was getting some pretty good-looking results, but I have no idea what tactic/tool they're using here.

Heres a link to what I'm talking about: 

https://forum.zdoom.org/viewtopic.php?t=49301

 

Now I will include a zip file containing the wads for GrittyPalette, LamedukePalette, and FatePalette, but here's something I need to say, once you open either FatePalette.wad or LamedukePalette.wad, you might notice that "PLAYPAL"  is considered to be an unknown type, this is a simple fix, if Slade calls it an Unknown Type, just select PLAYPAL, press CTRL+2 to bring up the Command prompt, click the box you type in, and type "Type palette force" and you should be fine, close the command prompt, and the palette should look like the ones seen in the pictures posted here.

 

So what do I want help with? I want help with making GrittyPalette look better, no grainy sprites and textures, just a dark, gritty, grimy, and industrial look that can really give the game a different feel and atmosphere.

 

However, being new to this sort of thing means that I don't think I have the skills and knowledge necessary to do such a thing. if any of you know of someone who is way better at palette editing, please let them know, they might be able to help.

PaletteCollection_LAME.FATE_FRITY.zip

On jeudi 31 janvier 2019 at 6:23 AM, Krull said:

OK yeah, the very latest version doesn't reject randomjumps anymore. However, there is another problem. Objects summoned using MBF's spawn codepointer seem to be solid (as if their 'obstacle' property is flagged), and properties entered in their parameter boxes (e.g. distance from the ground) are ignored, so pain elemental-style enemies using that effect will not work correctly. Is there a compatiblity option for that?

 

Another thing I've noticed arises from the way ZDoom seems to bypass custom PLAYPAL files in some way: while it displays textures without any fuss, it doesn't correctly interpret effects that use dehacked's green-to-red-or-brown colour swap, if they depend on a custom pallette. Like this:

 

Please report any such oddities to the ZDoom bugs forum (registration is not required to post there) along with some quickly testable material. There shouldn't be any need for compatibility options, but there have been a lot of major overhauls ever since the move to ZScript so this kind of regression is to be expected, unfortunately.

40 minutes ago, AJOgames said:

Now another thing you might've noticed about the Lameduke and Fate textures is the direction of the color depth, Both Lameduke and Fate are Build engine games, o the palettes for these games are handled differently, and if you look at both of the palettes from left to right, the colors go from dark to light, but on Doom engine games, the colors on the palette (looking from left to right) go from light to dark, which was yet another difficult thing I had to deal with when trying to take the colors from these palettes and put them in GrittyPalette.

Technically, there's nothing engine-dependent here; it's just a question of how the developers arranged the palettes. In fact, for example, Heretic and Hexen use dark-to-light range progressions while Doom and Strife use light-to-dark. See the examples here.

I was playing ESP 2 today (Map 20), and I found out that, when I use GlBoom, sky transfers doesn't work correctly. When I use PrBoom and ZDoom-based sourceports, sky transfers work fine.

 

GlBoom:

 

PrBoom and other sourceports:

 

https://www.youtube.com/watch?v=pGSGrdxe6Rc&amp;t=258s

Timothy Brown played this map using GlBoom, and for some reason, it works fine for him.

 

I don't know what could be causing this problem. Help would be appreciated.

 

I encountered the same issues with GlBoom when testing / developing Eviternity. It also cannot handle multiple sky transfers. I'd suggest just playing in standard PrBoom, or using GZDoom, Eternity or another GL enabled port if the GL-look is a must have.

Edited February 5, 2019 by Dragonfly

2 hours ago, Dragonfly said:

Eternity

Eternity Engine is a software only renderer, but it does support freelook.

GLBoom can have multiple sky transfers, but they bug out if mouselook is enabled. The result is both bizarre and interesting.

To force GLBoom to render its skies properly, you need to disable mouselook entirely, which will cause it to render the sky the same way PRBoom would, as a texture, whereas mouselook forces it to render the sky like GZDoom does, like a barrel.

2 hours ago, Aquila Chrysaetos said:

GLBoom can have multiple sky transfers, but they bug out if mouselook is enabled.

 

not if you change gl_skymode. If you set it to 2 (I have no idea, I just experimented with values) instead of 0 you can have gl graphics and multiple sky transfers look fine both with and without mouselook.

 

 

Disclaimer: I have no idea what that option actually does, or if there are negative side effects to doing this.

It worked! Thanks Ribbiks!

.

Edited September 2, 2023 by Krull