ZDoom

Zippy wrote:An ammo-pool system is cakewalk with a simple mix of ACS and DECORATE.

(snip)

ACS is not needed to ensure proper reloading anymore- if the magazine ammo types contain +ignoreskill they will always work as intended.

DoomRater wrote:ACS is not needed to ensure proper reloading anymore- if the magazine ammo types contain +ignoreskill they will always work as intended.

Gack! Thanks for pointing that out, because it could've caused some problems down the line. I'll be sure to flag the ammo types when I work on the WAD tonight.

Anyhow, the weapons are all working, and DECORATE lets me do some cool stuff that ACS could never do (like having the M1 bolt lock back until reloaded).

This is fantastic news.

I just noticed this thread and would like to echo the sentiments already posted by most (all?) other people - this is fantastic news. CaH should have been a great mod and, although I enjoyed playing it, the issues you are addressing severely held it back. I'm really glad you are working on it and fixing the problems. I hope CaH will soon be the mod it always promised to be.

I'm trying to remember... there was something that bothered me about the sprites in CaH. Were some of them unfeasably large or something? They can be easily scaled down and kept hi-res if you think that might be suitable. Or maybe the sprites are meant to be large - IIRC it was in a "trippy" bit of the mod.


And, what's more, you've got a cool avatar.

"Damn fine coffee! And hot!"

DoomRater wrote:ACS is not needed to ensure proper reloading anymore- if the magazine ammo types contain +ignoreskill they will always work as intended.

I'm well aware. I personally use ACS in a personal wad I have with a variety of weapons because it allows more flexibility for how I want things to reload.

Besides, the code I posted doesn't contain any catches for avoiding the ammo doubling. It's expecting +IGNORESKILL to be used, so that whole point is kind of moot.

What kind of reloading tricks can you do with ACS that you cannot with DECORATE?

It's not always about cans and cannots. Sometimes it's also about convenience and flexibility.

But long story short, reloading based on some global variables.

Enjay wrote:I just noticed this thread and would like to echo the sentiments already posted by most (all?) other people - this is fantastic news. CaH should have been a great mod and, although I enjoyed playing it, the issues you are addressing severely held it back. I'm really glad you are working on it and fixing the problems. I hope CaH will soon be the mod it always promised to be.

Well, so far things look promising. The new weapons setup really helps things - it's smooth in a way the ACS-based system never was, and now actually works. I booted up the first playable level with the fixes, and everything flows better.

Part of the problem is I think I went a little overboard with stuff I thought was neat (ahem... snow... chairs) and didn't do enough playtesting. There were some pretty epic (IMHO, of course) moments towards the end of the WAD, but by that point most people were lagging so badly it didn't even matter.

I'm trying to remember... there was something that bothered me about the sprites in CaH. Were some of them unfeasably large or something? They can be easily scaled down and kept hi-res if you think that might be suitable. Or maybe the sprites are meant to be large - IIRC it was in a "trippy" bit of the mod.

Hmm... I'll take a look at it. Most of the sprites are standard Doom-scale. The only exception is at the end, where the final boss is a more realistic scale and therefore looks large and drawn out in the Doom world. That was intentional, but I'll check the scaling out to see if anything can be improved.

And, what's more, you've got a cool avatar.

"Damn fine coffee! And hot!"

Yes!

Well I sure am a hyper-genius... I think I found a way to limit the impact of the snow on framerate without making it look like ass:

A_JumpIfCloser

Figure I'll set it something fairly large so the player has the visual effect of snowfall, but set the snow object to destroy itself immediately if it's outside the range. Any thoughts on how well this would work?

I was thinking about creating a custom MAPSPOT with similar behavior. Would using THING_DEACTIVATE without a tid (or with a tid of 0) deactive the DECORATE object calling the action special only, or would it, say, stop all instances of the same object type?

The other option would be to make a custom MAPSPOT that drops snow objects only when the player is nearby. Obviously this wouldn't give me nearly as much flexibility in terms of snow intensity. I suppose this could be circumvented with some clever use of fake inventory items and A_SpawnItemEx's "chance" parameter. Does random(x,y) work in DECORATE?

It should deactivate itself... though that would then probably make it so that it couldn't reactivate itself - so I think you'd be better off having a looping A_JumpIfCloser part, which is it's closer goes to the snow-spawning bit, and if not just wait a few tics and goes back round the loop again.

Phobus wrote:It should deactivate itself... though that would then probably make it so that it couldn't reactivate itself - so I think you'd be better off having a looping A_JumpIfCloser part, which is it's closer goes to the snow-spawning bit, and if not just wait a few tics and goes back round the loop again.

Good point, I hadn't considered whether the thing would be able to turn itself back on.

I'll mess around with it tonight and see what I can make it do.

EDIT: What about the Inactive state? (see http://zdoom.org/wiki/Creating_decorati ... 9activated) Any idea if having another A_JumpIfCloser bit in there to wake the MAPSPOT up again would do it?

Here's how I'd make the snowflake spawner actors on the board: use the Nointeraction flag and have it spawn nointeraction snowflakes (that remove themselves after falling a certain distance) if the player is closer than a certain distance (I'd say anything just outside where the player can run to and see snow NOT falling). The nointeraction flag should ease much of the snow slowdown already, so you might not need to send snow based on where the player is, but basically it just skips the snow spawning section of the code if the player isn't close enough. No need for deactivation or reactivation that I can see.

DoomRater wrote:Here's how I'd make the snowflake spawner actors on the board: use the Nointeraction flag and have it spawn nointeraction snowflakes (that remove themselves after falling a certain distance) if the player is closer than a certain distance (I'd say anything just outside where the player can run to and see snow NOT falling). The nointeraction flag should ease much of the snow slowdown already, so you might not need to send snow based on where the player is, but basically it just skips the snow spawning section of the code if the player isn't close enough. No need for deactivation or reactivation that I can see.

That's a good idea, but will DECORATE allow the use of the "random" command to randomize x and y movement?

The only reason I mention deactivation and reactivation is that it will plug into the existing ACS code.

You can use thrustthing and thrustthingz on actors even when they have the nointeraction flag set, and even from within themselves! Those use the random() function just fine.

But if you already have ACS written and working, no sense in changing it all around just to please a DECORATE purist.

DoomRater wrote:You can use thrustthing and thrustthingz on actors even when they have the nointeraction flag set, and even from within themselves! Those use the random() function just fine.

But if you already have ACS written and working, no sense in changing it all around just to please a DECORATE purist.

Like I said, I'll mess around with it tonight. It may turn out that the DECORATE-only (er... mostly?) solution is the best one. At least Doom Builder makes selecting and changing huge numbers of MAPSPOTs with specific tids easy to do.