[Helixhorned]

Trooper Dan, on 15 March 2013 - 01:07 PM, said:

Uh yeah, I should have checked the log, it works now. Since the per-player gamevar declaration was partially working, I didn't consider the possibility that it was invalid.

What was probably happening is that the Gv_GetVar() call returned -1, which is often used as a "error condition" marker in C code and that value got interpreted as the logo flags. Of course, -1 has all bits set...
The broader issue though is that the CON parser/interpreter permits a lot of sloppiness on the user side when it should give decent error messages or warn instead. This case is rather benign.

Fox, on 15 March 2013 - 01:32 PM, said:

I suppose that during some instances of the game, such as while checking if it should display the Shareware or Ten screens, the player doesn't exist, not even as a placeholder, so it fails to make the check if LOGO_FLAGS is a per-player variable.

What exactly LOGO_FLAG_STOPANIMSOUNDS does? I tested it, but I couldn't figure it out.

Hendricks266, in r3545, said:

Make stopping of all sounds after completion of LOGO.ANM conditional on the newly introduced (LOGO_FLAGS & LOGO_STOPANIMSOUNDS). Modifies r3217.

[Diaz]

I'm not sure if I have asked this before, but are stayput actors hard-coded to have more strength? One of my stayput enemies (which replaces the PigCop) takes two rockets to die, while the non-stayput version takes just one.

[Micky C]

Did you by any chance define your stay put enemies by having an alternate pal? Recently eduke32 was changed so that enemies with alternate pals have double strength (although I would hope this doesn't apply to mods).

[Jblade]

Trooper Mick, on 20 March 2013 - 02:08 PM, said:

Did you by any chance define your stay put enemies by having an alternate pal? Recently eduke32 was changed so that enemies with alternate pals have double strength (although I would hope this doesn't apply to mods).

It does - I remember I brought up some time ago that pigcops with a different pal had twice as much health in v1.3D, somebody confirmed it and then it was added back into Eduke32. For them to add it back in must mean it was supposed to still happen in Atomic edition but was broke for some reason since I know they normally shy away from gameplay effecting bugs (Like for instance, not fixing the fact that respawns don't respect pal colour, since there's several Liztroop respawns ingame that are supposed to spawn captains)

[Fox]

I don't agree with that decision. That was just an ugly hack to increase the hit points of the Assault Captain, which accidentally extended to other enemies (and was fixed in Atomic Edition).

If anything, Eduke32 should apply this behavior only to version 1.3. I suppose a safe way to get the game version is to check the number of gamestartup entries in user.con.

James, on 20 March 2013 - 02:15 PM, said:

For them to add it back in must mean it was supposed to still happen in Atomic edition

Not really, in Atomic Edition the Assault Captain hit points is changed via CON, and nothing was changed about the other actors.

James, on 20 March 2013 - 02:15 PM, said:

Like for instance, not fixing the fact that respawns don't respect pal colour, since there's several Liztroop respawns ingame that are supposed to spawn captains

They are not supposed to. It is just in some specific cases which the source makes some actors take the respawn pal (Boss1 for example), but they forget to give it to the Liztroop.

[Jblade]

Fox, on 20 March 2013 - 02:16 PM, said:

I don't agree with that decision. That was just an ugly hack to increase the hit points of the Assault Captain, which accidentally extended to other enemies (and was fixed in Atomic Edition).

It was hard-coded? Well bug or not, I think that V1.3D maps should have the strength change respected, but is it worth coding in a way to check if a map's v1.3D or not?

[Diaz]

My stayput enemy doesn't have a different palette, just different tilenum (what would be PIGCOPSTAYPUT).

[Fox]

James, on 20 March 2013 - 02:19 PM, said:

It was hard-coded? Well bug or not, I think that V1.3D maps should have the strength change respected, but is it worth coding in a way to check if a map's v1.3D or not?

Do it matters whenever it is a 1.3d map or not? Eduke32 is based on Atomic Edition version. It is not like Eduke32 is making a gameplay change, it is something that 3DRealms already did on their own.

[Jblade]

Fox, on 21 March 2013 - 11:49 AM, said:

Do it matters whenever it is a 1.3d map or not? Eduke32 is based on Atomic Edition version. It is not like Eduke32 is making a gameplay change, it is something that 3DRealms already did on their own.

If someone makes a map for 1.3D that uses a bug to change it's gameplay, and then a new version of the game fixes that bug so it messes up the gameplay of earlier user levels, having an option to re-enable that bug so that the map can be played as the author intended is only fair.

[Fox]

What if someone added a palette to an enemy and didn't wanted it to have double strength...? Probably most of the mappers were not aware of this behavior.

And it wouldn't work if you played with the Atomic Edition executable, for example. So it was something that 3DRealms fixed.

[Danukem]

Fox, on 21 March 2013 - 12:35 PM, said:

What if someone added a palette to an enemy and didn't wanted it to have double strength...?

Then the map will be harder than intended. There are many user maps released for Atomic over the years with paletted enemies where this could be an issue.

[Jblade]

Fox, on 21 March 2013 - 12:35 PM, said:

What if someone added a palette to an enemy and didn't wanted it to have double strength...? Probably most of the mappers were not aware of this behavior.

It's incredibly obvious when a pigcop takes 4 shots instead of 2 from a shotgun.

Quote

And it wouldn't work if you played with the Atomic Edition executable, for example. So it was something that 3DRealms fixed.

You still don't understand. Wherether they fixed it in atomic or not doesn't matter, since the behaviour existed in v1.3D and that's what some people mapped for.

There's no real point in this discussion regardless, I think it should be a compatability option but the number of atomic maps outnumber 1.3D maps so it would be best to remove the feature if a toggle isn't added.

[Fox]

James, on 21 March 2013 - 01:01 PM, said:

It's incredibly obvious when a pigcop takes 4 shots instead of 2 from a shotgun.

No it is not. If it was obvious it wouldn't be wrong about it. It takes only 3 shots with the Shotgun to kill a Pig Cop with twice the hit points.

[Jblade]

Fox, on 21 March 2013 - 01:26 PM, said:

No it is not. If it was obvious it wouldn't be wrong about it. It takes only 3 shots with the Shotgun to kill a Pig Cop with twice the hit points.

come on man, semantics How many more ultimately doesn't matter. Let's just drop this discussion since neither of us are going to budge on our viewpoints, before it gets ugly or drags out.

[Danukem]

Fox, on 20 March 2013 - 02:16 PM, said:

I don't agree with that decision.

referring to the decision to double hit points on paletted enemies

James, on 21 March 2013 - 01:01 PM, said:

the number of atomic maps outnumber 1.3D maps so it would be best to remove the feature if a toggle isn't added.

So everyone (myself included) who has offered an opinion agrees that it would be best to remove the feature. Then you guys got confused about each other's positions and thought you were having an argument o_O

[Jblade]

well I was arguing that it shouldn't be seen as a bug even if it was due to the fact it essentially gave map authors a slightly beefed up pigcop to use in levels, but like I said atomic edition is considered the defacto version and more maps are for that so it's best to maintain compatability with that than the old version. Bear in mind of course that v1.3D was the first version I ever played so to me having them double strength feels more 'correct' whereas I'm sure you guys played atomic first so you'd differ on that

[Diaz]

Grrrr. Turns out at some point (and I don't remember when and why I did it) I replaced all of the PIGCOPSTAYPUT's by PIGCOP's with pal 10, then coded that pal to be a stayput actor :/

So yeah, the behavior in my mod is due to paletted pigcops. I just fixed it with a line of code....

[Micky C]

As a mapper and non-coder, I think it would be useful to have the option to double enemy strength (just to clarify, is it every pal except pal 0 that does this?) although I more strongly believe that compatibility should be kept with the thousands of maps already out there and the feature should be removed. Although a toggle would be best. Maybe one day, features such as this could be set within map files...

Trooper Mick, on 20 March 2013 - 02:08 PM, said:

Did you by any chance define your stay put enemies by having an alternate pal? Recently eduke32 was changed so that enemies with alternate pals have double strength (although I would hope this doesn't apply to mods).

Diaz, on 21 March 2013 - 02:39 PM, said:

Grrrr. Turns out at some point (and I don't remember when and why I did it) I replaced all of the PIGCOPSTAYPUT's by PIGCOP's with pal 10, then coded that pal to be a stayput actor :/

So yeah, the behavior in my mod is due to paletted pigcops. I just fixed it with a line of code....

Called it

[Fox]

Trooper Mick, on 21 March 2013 - 09:16 PM, said:

just to clarify, is it every pal except pal 0 that does this?

Yes.

[sedition]

Is it possible that every map in an episode has a different loading screen?
I know how to change the loading screen in general with

onevent EVENT_GETLOADTILE
 setvar RETURN 3281
endevent

but I want to have a specific one for every map within an episode like
E1l1 --> image1.jpg (or tileXX)
E1L2 --> image2.jpg (or tileYX)
... and so on.

Is there a chance to do this?

[Fox]

onevent EVENT_GETLOADTILE
  ifvare VOLUME 0
  {
    ifvare LEVEL 0
      setvar RETURN <e1l1>
    ifvare LEVEL 1
      setvar RETURN <e1l2>
  }
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN <e2l1>
    ifvare LEVEL 1
      setvar RETURN <e2l2>
  }
endevent

[sedition]

Fox, on 22 March 2013 - 11:46 AM, said:

onevent EVENT_GETLOADTILE
  ifvare VOLUME 0
  {
    ifvare LEVEL 0
      setvar RETURN <e1l1>
    ifvare LEVEL 1
      setvar RETURN <e1l2>
  }
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN <e2l1>
    ifvare LEVEL 1
      setvar RETURN <e2l2>
  }
endevent

Thanks for your reply, Fox.

<e1l1>

are the tile numbers?

Sorry, but I have absolutely no knowledge of all the CON stuff and copied the code I posted from the wiki, IIRC.

[Hendricks266]

Yes.

[Fox]

Yeah, whatever is the tile you choose to replace it.

===//===//===

Is it possible to make the shoot command and EVENT_DOFIRE spawn a regular actor?

[sedition]

Thanks, Fox and Hendricks.

Another thing I forgot to ask for:
Is there a way to have another tile for the loading bar on that screen? After I replaced textures I have always a wall texture for the loading bar.
And can I turn of the xxx / xxx textures message on the screen?

[Hendricks266]

sedition, on 23 March 2013 - 01:43 AM, said:

Is there a way to have another tile for the loading bar on that screen? After I replaced textures I have always a wall texture for the loading bar.
And can I turn of the xxx / xxx textures message on the screen?

Try "addvar RETURN 16384" to the bottom of your event. IIRC it should disable the "LOADING" text completely.

onevent EVENT_GETLOADTILE
  ifvare VOLUME 0
  {
    ifvare LEVEL 0
      setvar RETURN <e1l1>
    ifvare LEVEL 1
      setvar RETURN <e1l2>
  }
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN <e2l1>
    ifvare LEVEL 1
      setvar RETURN <e2l2>
  }

  addvar RETURN 16384
endevent

As for more complicated replacement of the loading screen, I have thought about using the variables LOTAG and HITAG to store the current and total textures values so modders could completely make their own screen using EVENT_GETLOADTILE or an EVENT_DISPLAYLOADING. edit: The variable TEXTURE might be acceptable to change the loading bar texture.

Fox, on 22 March 2013 - 04:35 PM, said:

Is it possible to make the shoot command and EVENT_DOFIRE spawn a regular actor?

Would "eshoot FOOBAR" followed by "changespritestat RETURN 1" work?

[Fox]

Thanks, that worked.

[sedition]

Hendricks266, on 23 March 2013 - 02:15 AM, said:

Try "addvar RETURN 16384" to the bottom of your event. IIRC it should disable the "LOADING" text completely.

onevent EVENT_GETLOADTILE
  ifvare VOLUME 0
  {
    ifvare LEVEL 0
      setvar RETURN <e1l1>
    ifvare LEVEL 1
      setvar RETURN <e1l2>
  }
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN <e2l1>
    ifvare LEVEL 1
      setvar RETURN <e2l2>
  }

  addvar RETURN 16384
endevent

As for more complicated replacement of the loading screen, I have thought about using the variables LOTAG and HITAG to store the current and total textures values so modders could completely make their own screen using EVENT_GETLOADTILE or an EVENT_DISPLAYLOADING. edit: The variable TEXTURE might be acceptable to change the loading bar texture.


Would "eshoot FOOBAR" followed by "changespritestat RETURN 1" work?

Thank zou Hendricks and Fox,
I tried this, but all I get is a black background. And the loading text is also there.
Did I do something wrong with it?

Here´s the con code:

//Thanks to Fox and Hendricks266

onevent EVENT_GETLOADTILE
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN 4030	// replace <xxxx> with the tile no. to display
    ifvare LEVEL 1
      setvar RETURN 4031
  }

  addvar RETURN 16384	// deletes the loading text
endevent

/* OLD ONE - NOT NECESSARY
// Background on Map´s load

onevent EVENT_GETLOADTILE
 setvar RETURN 3281
endevent
*/

And the lines in my textures.def:

dummytilerange 4030 4031 128 96
texture 4030 {
   pal 0 { file "highres/textures/bf/bf4030.jpg" }
}
texture 4031 {
   pal 0 { file "highres/textures/bf/bf4031.jpg" }
}

Maybe I did it wrong, but I can´t figure out what.

[Hendricks266]

It looks like the "add 16384" functionality was removed. Since no one has noticed until now, it should stay removed. There is code to compensate if the tile number is over MAXTILES (which has since been increased to 30720) but nothing to disable the loading screen text. (For the feature to be safe we would need to expose the value MAXTILES to CON as is done in M32script but it would still be hackish.)

If anything it should be done with other variables like TEXTURE. If the idea is approved I will add a way to disable the parts.

Try removing the "addvar RETURN 16384" for now. At least your custom tile should be displayed correctly.

Another thing, to cover the whole screen your dummytilerange should use the values 320 200 instead of 128 96.

[Mblackwell]

Hendricks266, on 25 March 2013 - 07:25 PM, said:

It looks like the "add 16384" functionality was removed. Since no one has noticed until now, it should stay removed. There is code to compensate if the tile number is over MAXTILES (which has since been increased to 30720) but nothing to disable the loading screen text. (For the feature to be safe we would need to expose the value MAXTILES to CON as is done in M32script but it would still be hackish.)

If anything it should be done with other variables like TEXTURE. If the idea is approved I will add a way to disable the parts.

Try removing the "addvar RETURN 16384" for now. At least your custom tile should be displayed correctly.

Another thing, to cover the whole screen your dummytilerange should use the values 320 200 instead of 128 96.

Actually I've noticed there seems to be an off-by-one error when using 320x200. You'll get a thin line on (I believe) the top and left of uncovered screen.