PrBoom said: No SKY3 found

[CrazyDoomguy]

On my PrBoom said, there are error:

 

R_TextureNumForName: SKY3 not found.

 

I had add SKY3, but next error ist SKY1. I had add SKY1 and for safety SKY2, but this programm said "No SKY1". Wtf!? What should I do? Please explain on easy english...

[leodoom85]

If it's for textures then it's RSKY1, 2 and 3 (at least in vanilla)

[CrazyDoomguy]

5 minutes ago, leodoom85 said:

If it's for textures then it's RSKY1, 2 and 3 (at least in vanilla)

Dont work with RSKY1,2,3. Said same error "no SKY3"

[Nine Inch Heels]

I am still confident that this is actually an issue related to mapping format, rather than missing assets, because I could run the map in question in GZDoom, and it didn't show me anything related to missing textures.

 

If I were to make an uneducated guess, the map you were working with was made in a format that allows the use of (wall)textures as (floor/ceiling)flats, which is something that does not work for boom.

[CrazyDoomguy]

20 minutes ago, Nine Inch Heels said:

I am still confident that this is actually an issue related to mapping format, rather than missing assets, because I could run the map in question in GZDoom, and it didn't show me anything related to missing textures.

 

If I were to make an uneducated guess, the map you were working with was made in a format that allows the use of (wall)textures as (floor/ceiling)flats, which is something that does not work for boom.

Ok, but what should I do, that this works on boom?

[SaladBadger]

You are absolutely sure that SKY3 is defined anywhere within your WAD's TEXTUREX lumps, right? PRBoom seems to want to have all sky textures properly defined any time it loads any map from my testing, which is a bit odd (Vanilla handles it as long as you don't go to a map that has SKY3edit: only chocolate doom handles it). ZDoom handles it without issue since it can combine TEXTUREX lumps from multiple wads so it grabs the SKY3 from your IWAD, but PRBoom uses the vanilla logic of only using the last TEXTUREX lump loaded.

 

EDIT: Testing the four ports I typically use with a wad that has the IWAD TEXTURE1 lump with SKY3 deleted, [G]ZD and spawn load the texture from the IWAD if its missing, Chocolate crashes out as expected if you load maps > 20, but you can load any other map, Eternity lets you load any map, replacing SKY3 with a missing texture graphic, and PRBoom+ doesn't let you load any map at all.

Edited July 15, 2017 by InsanityBringer : chocolate is actually lying heh

[Phade102]

Hi Crazydoomguy. If you feel comfortable with doing so, upload your wad to doomworld here, in this topic (It needs to be in a zip file) and let some people take a look at it. That will be the best way to solve it, it could be something simple, but we can't help without getting a proper look.

[BigDickBzzrak]

It's something simple, I'm sure of that.

Does your WAD have all texture definitions from the IWAD? Are you loading with the right IWAD?

We've solved that particular issue, like, millions of times, the search bar exists for a reason.

[CrazyDoomguy]

1 hour ago, Phade102 said:

Hi Crazydoomguy. If you feel comfortable with doing so, upload your wad to doomworld here, in this topic (It needs to be in a zip file) and let some people take a look at it. That will be the best way to solve it, it could be something simple, but we can't help without getting a proper look.

Here please. I tried, but no succes...
https://www.dropbox.com/s/hbd5dzxhw8lrqo2/New.zip?dl=0

[Graf Zahl]

PrBoom is indeed stupid. Note that this stupidity was inherited from vanilla.
 

  else if (gamemode == commercial)
    // || gamemode == pack_tnt   //jff 3/27/98 sorry guys pack_tnt,pack_plut
    // || gamemode == pack_plut) //aren't gamemodes, this was matching retail
    {
      skytexture = R_TextureNumForName ("SKY3");
      if (gamemap < 12)
        skytexture = R_TextureNumForName ("SKY1");
      else
        if (gamemap < 21)
          skytexture = R_TextureNumForName ("SKY2");
    }

 

Strange that Chocolate Doom fixes this particular vanilla oddity (actually, the entire function was totally rewritten and this weird trait removed...)

 

[CrazyDoomguy]

21 minutes ago, Graf Zahl said:

PrBoom is indeed stupid. Note that this stupidity was inherited from vanilla.
 

 

  else if (gamemode == commercial)
    // || gamemode == pack_tnt   //jff 3/27/98 sorry guys pack_tnt,pack_plut
    // || gamemode == pack_plut) //aren't gamemodes, this was matching retail
    {
      skytexture = R_TextureNumForName ("SKY3");
      if (gamemap < 12)
        skytexture = R_TextureNumForName ("SKY1");
      else
        if (gamemap < 21)
          skytexture = R_TextureNumForName ("SKY2");
    }

 

 

Strange that Chocolate Doom fixes this particular vanilla oddity (actually, the entire function was totally rewritten and this weird trait removed...)

 

Yes, problem is, that on this Prboom is TAS and nice graphic looking. If TAS on Zdoom, all would forgett prboom soon

[Scotty]

When you create a new texture1 set in Slade you must be sure to select "Import from Base Resource Archive" (make sure you have Doom2.wad set as the base resource archive) instead of create new, then it seems to always work (for me anyway):

 

 

 

Here's a link to a working version for you. I basically just removed all the textures and flats and readded them, using this method.

 

https://www.dropbox.com/s/y8neloiwgidof72/crazydoomguy.wad?dl=1

[CrazyDoomguy]

10 minutes ago, Scotty said:

When you create a new texture1 set in Slade you must be sure to select "Import from Base Resource Archive" (make sure you have Doom2.wad set as the base resource archive) instead of create new, then it seems to always work (for me anyway):

 

 

 

Here's a link to a working version for you. I basically just removed all the textures and flats and readded them, using this method.

 

https://www.dropbox.com/s/y8neloiwgidof72/crazydoomguy.wad?dl=1

AWERSOME!!! Thank you!!!! Didnt knew this function!

[Nine Inch Heels]

10 minutes ago, CrazyDoomguy said:

Yes, problem is, that on this Prboom is TAS and nice graphic looking. If TAS on Zdoom, all would forgett prboom soon

The problem is that ZDoom shat on demo-compat time after time, which made it so people would design TAS-programs for PrBoom+, because that did not mess up demo-compat all the time.

 

I record all my demos in PrBoom+ if possible, and none of them are TASed, for that matter. If you think TASing is the only reason PrBoom exists you're a bit off the road.

[Graf Zahl]

8 hours ago, Nine Inch Heels said:

The problem is that ZDoom shat on demo-compat time after time

 

Let's put this right: ZDoom decided that demo compatibility was not worth keeping because it's simply too much work. The way you phrase it makes it sound that it would be an easy task to do so. Have you ever looked at the convoluted mess of code PrBoom developed into in order to keep it?

 

So, please reduce your use of expletives.

 

[Edward850]

14 minutes ago, Graf Zahl said:

Have you ever looked at the convoluted mess of code PrBoom developed into in order to keep it?

PRBoom's "convoluted mess" is because its demo compatibility handles memory overflows for historical archival of complex speedruns, not just v1.9 demos in general. Memory overflow emulation is not something people typically expect when they ask for demo compatibility.

Edited July 15, 2017 by Edward850

[Graf Zahl]

Yes, this is definitely done for memory overflows...

 

  if (comp[comp_dropoff])
    {
      // e6y
      // Fix demosync bug in mbf compatibility mode
      // There is no more desync on v2-2822.lmp/vrack2.wad
      // -force_no_dropoff command-line switch is for mbf_compatibility demos
      // recorded with prboom 2.2.2 - 2.4.7
      // Links:
      // http://competn.doom2.net/pub/sda/t-z/v2-2822.zip
      // http://www.doomworld.com/idgames/index.php?id=11138
      if ((compatibility || !dropoff
            || (!prboom_comp[PC_NO_DROPOFF].state && mbf_features && compatibility_level <= prboom_2_compatibility))
          && (tmfloorz - tmdropoffz > 24*FRACUNIT))
        return false;                      // don't stand over a dropoff
    }

[Edward850]

I'm not sure what you are showing me that's supposed to be convoluted. That could certainly be written cleaner, but it's hardly convoluted.

That's also MBF compat, not v1.9.

[Graf Zahl]

It is convoluted because the entire code is littered with constructs like that, making it hard to read overall.

This was just a particularly obtuse check with 5 different conditions being relevant on demo-specific behavior.

 

 

[Edward850]

 

[Grazza]

https://sourceforge.net/p/prboom-plus/bugs/57/

 

Ah, good times. Thanks for drawing attention to the massive amount of time and effort that was put into demo compatibility.

[Danfun64]

So...what compatibility related bugs does PrBoom-Plus keep that Chocolate lacks...and vice versa?

[Grazza]

Prboom-plus can emulate about 20 different exes* in terms of demo compatibility (that is the reason for most of all the compatibility mazes; well, that and the fact that regular Prboom development around 2000-2002 was haphazard and introduced some problems and incompatibilities). Chocolate emulates only the vanilla ones.

 

For vanilla demo compatibility, there is very little to choose between them: in both cases, there is something like 1 in 10000 demos that either will fail to play back correctly. (Number not plucked out of thin air; I recall a demo or two where Choc succeeds due to more faithful memory management, and some few where Prboom-plus's on-the-fly error fixing avoids a crash without also causing a desync.) But basically you can use either and never expect a problem. Of course, someone could deliberately manufacture wads and demos that are problematic for one port or the other, if they wished for some reason.

 

* Yes, more than the number of complevels, as there are some fixes that are version-specific within complevels, such as for Boom 2.01.