[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.

[Fox]

I have a question about the precache command:

Quote

0 - Precaches <tile0>-<tile1> only if <tile0> is in the map
1 - Precaches <tile0>-<tile1> always

How can I make it so that tile 0020 is loaded if 0010 is in the map, but not include tiles 0011-0019?

[Hendricks266]

The precache command isn't set up for instructions of that complexity. Search for CON_PRECACHE in gamedef.c and tiledata_t (the type that g_tile[] is) in actors.h.

Is it really necessary? Either bite the bullet and load #20 always, or ignore it and let the game takes its chances with automatic loading (which ideally should make this a non-issue).

[Fox]

Is it necessary? Not really, I don't care much about precache. But since it's there, it wouldn't hurt to also add it.

To be more specific, this is the projectile of the Grenade Launcher from Duke Nukem 64 I am talking about. There is about 200 tiles beetween some frames of the projectile.

[Hendricks266]

It would hurt to add it, in the implementation details.

On the other hand, anything related to weapons the player uses should always be precached, so your use case is moot. In fact, the precache extension as you intend might not actually kick in because none of the projectiles might be in the map in the first place.

[Fox]

But isn't that how the source code works? I looked at it and the projectiles frames are precached if they are spawned. It is odd for precache command to not work in the same way.

(And to think about it now, the source code includes the frames from the RPG angles, or FREEZEBLAST animation, etc. Shouldn't it automatically check for animations in the .art files (or using animtilerange), and for all frames of the <action> from actor or useractor commands?)