[Player Lin]

If it's a Duke3D/Duke Nukem theme mod then Regenerating Health system just sucks ass, you know why...

If not a Duke3D mod, just a TC or totally different FPS game with eduke32 and Build...hmm, whatever.
But, really, when a lot of modern FPSs are overusing the Regenerating Health/CoD:MW style health system, I feel this one is just bad idea on FPS games, but maybe someone seems health pack/pickup system is bad idea too. Just pointless to argue about this...

[Reaper_Man]

I think the way that 40k Space Marine handled "regenerating" health was particularly great. They got rid of the chore of hunting for health items without making you essentially invulnerable.

Mblackwell, on 05 November 2012 - 01:40 PM, said:

That's why I prefer inventory based health packs/medkits. A good compromise though is thresholds of health.

Yeah or this. I don't see many games doing it though.

[Mblackwell]

The only games I can think of off of the top of my head (besides something like Deus Ex/Fallout) are the FEAR series and Bioshock. I'm sure there are others though.

I've never played 40k Space Marine... how does it handle it? Does it do "no regeneration during encounters"?

[Micky C]

Max Payne's health works by picking up bottles of pills that you can use at any time to restore some health.

[RichardStorm]

I think the modern regeneration system as seen in DNF and COD series it's a bit idiot... i suggest a slow regeneration ala Borderlands, which is the right key between combat and "calm", to avoid hunt for medpacks in the level.
I prefer medkits stored in the inventory, i think it's the most realistic thing but it needs the right balance. A slow regeneration could mean a portable regeneration system, an auto-repair feature or whatever you want.

However i think that the right method to recover health depends on the game, for example if it has an arcade/classic gameplay or its more realistic.

[High Treason]

Survival Horror games often rely solely on inventory items and, on rare occasions, certain interactions with the environment, it can be fun when there's a limited number in the game, makes it harder. While I like this system, moving it to an FPS game would probably only work if the game was nonlinear and encouraged you to explore, otherwise it makes the system seem like a chore.

I feel Duke3D's system was fine, but I do like the hybrid system in F.E.A.R whereby it regenerates to 25% slowly, but beyond that, you need to find First Aid Kits. Unfortunately the game isn't the best possible implementation of such a system in my opinion, but it has potential, I could, for example, see it working in a Duke Nukem game.

[Daedolon]

Health regeneration always takes you out of the game experience as you will have to wait before you can interact with the aspects of combat or exploration as you're vulnerable and you know that's the only thing you can do at the given time.

Health packs are great, especially for nonlinear games, as you can always flee from the combat zone and partake in exploration based gameplay as you hunt for more health. It also gives the game a more tactical aspect as you profit from learning the item placement in areas you previously visited.

[Kyanos]

Remember in link to the past catching fairies with the bug net. One of the most unique health systems, yet simple and suited to the game.

[wesley025]

I want to load my episode and it already shows the name of the episode in the and the first level but after that, it starts the L.A hollywood episode and starts with Hollywood Hollocaust.

Any help with this

[Darkus]

I wish to know how to make the monsters appear in the automap? I've seen that in some mods, but I have not found how to do it...

[Daedolon]

Darkus, on 14 November 2012 - 11:47 AM, said:

I wish to know how to make the monsters appear in the automap? I've seen that in some mods, but I have not found how to do it...

Display them as floor aligned sprites when the map is visible.

[Darkus]

Daedolon, on 14 November 2012 - 01:58 PM, said:

Display them as floor aligned sprites when the map is visible.

It does not work very well, the sprites a screwed up in map.
Anyway this is not very important, I am creating an experimental pathfinding AI, that's why I wanted to see if the monsters are moving properly in some places.

This is what what I mean: As you can see, the Pigcops are going to climb the slope to reach you.


As you can see, the sprites at the map are a little scrambled, but it is not too serious as long I can see them moving. Beware, they're coming.

[Danukem]

Do they looked scrambled in the 32 bit modes?

[XThX2]

Darkus, on 15 November 2012 - 06:44 AM, said:

It does not work very well, the sprites a screwed up in map.
Anyway this is not very important, I am creating an experimental pathfinding AI, that's why I wanted to see if the monsters are moving properly in some places.

This is what what I mean: As you can see, the Pigcops are going to climb the slope to reach you.

As you can see, the sprites at the map are a little scrambled, but it is not too serious as long I can see them moving. Beware, they're coming.

You should also make them shoot the player if they can see him and if he's near the edge; otherwise it'd look stupid like "Oh let's all go climb up the slope why not, he can kill us on the way too!". I think you can just create batches of pigcops, randomly given tags and behave uniquely, those with a certain tag guard the outside and shoot the player if he's on edge while the rest climb up and meanwhile also shoot the player at given opportunity. I think this is easily doable but I've been away from CON for so long, I don't remember much.

About the sprites being scrambled, that's how they are rendered. I think it is different in polymost/polymer. If that doesn't work, you can change the way they are shown in minimap with I think tsprite or something, that should be it.

[Diaz]

Trying to add a sprint feature to my mod, but things aren't working as expected. The following code:

            getplayer[THISACTOR].posxv XVELZ
            mulvar XVELZ 2
            getplayer[THISACTOR].posyv YVELZ
            mulvar YVELZ 2

            setplayer[THISACTOR].posxv XVELZ
            setplayer[THISACTOR].posyv YVELZ  

obviously causes the player's speed to increase exponentially, until it's way too fast. What strikes me is that dividing the variables instead of multiplying them succesfully makes the player speed slower, without exponentially doing so

[Daedolon]

Darkus, on 15 November 2012 - 06:44 AM, said:

It does not work very well, the sprites a screwed up in map.

Looks like the sprites aren't dividable by two. I know they should be but who knows.

[Darkus]

 XThX2, on 15 November 2012 - 07:33 AM, said:

You should also make them shoot the player if they can see him and if he's near the edge; otherwise it'd look stupid like "Oh let's all go climb up the slope why not, he can kill us on the way too!". I think you can just create batches of pigcops, randomly given tags and behave uniquely, those with a certain tag guard the outside and shoot the player if he's on edge while the rest climb up and meanwhile also shoot the player at given opportunity. I think this is easily doable but I've been away from CON for so long, I don't remember much.

This is for the moment a test, I wanted to see if they were able to reach the player depending on his position. I can very well make them shoot on sight, but for now, I'll try to make them do interesting things, like opening doors properly, activating switches, taking elevators...

 Trooper Dan, on 15 November 2012 - 07:29 AM, said:

Do they looked scrambled in the 32 bit modes?

In polymost/mer, they do not look scrambled anymore.

But now they are cut in half...

Spoiler

I also thought to use the 2061 tile, but I think I'll have the same result...

[Danukem]

 Diaz, on 15 November 2012 - 08:59 AM, said:

Trying to add a sprint feature to my mod, but things aren't working as expected. The following code:

            getplayer[THISACTOR].posxv XVELZ
            mulvar XVELZ 2
            getplayer[THISACTOR].posyv YVELZ
            mulvar YVELZ 2

            setplayer[THISACTOR].posxv XVELZ
            setplayer[THISACTOR].posyv YVELZ  

obviously causes the player's speed to increase exponentially, until it's way too fast. What strikes me is that dividing the variables instead of multiplying them succesfully makes the player speed slower, without exponentially doing so />

Dividing seems to work for you because large amounts are constantly being added to those velocities as the player accelerates, preventing the numbers from getting near zero.

Instead of messing with the velocities directly, you might try manipulating player.runspeed instead.

[CruX]

...In both CrackDown and BLiGHT, I had this reoccurring problem with weapon-switching, where when the player switched from one weapon to another, the new weapon would pop up, lower down, and then raise back up. This shit seriously plagued me, I couldn't figure out what I was doing to cause it, and in the case of BLiGHT, I coded this big, elaborate workaround to fix it that probably wound up creating more problems than it solved. And then this morning I decided to change one little bit of my display code from this...

ifvare PWEAPON 1 {  // my own variable
setvar RETURN -1
state displaypistol 
}

to this

ifvare currentweapon 1 {  // a constantly updated variable
setvar RETURN -1
state displaypistol 
}

And WHAM, problem instantly fixed. I'm happy, though I am slightly curious as to why it would make a difference. I remember I originally abandoned use of most constantly updated variables like currentweapon because I either couldn't use them in events or the APLAYER actor without getting a warning (it was a long time ago, my memory's kinda sketchy). In any event, I'm probably going to add a little caveat to the DISPLAY/DRAWWEAPON events in the wiki because while both entries are informative enough on their own, if you do arbitrary things like I do, you'll wind up with this problem, and if you're as dumb as I am, it'll take you years to figure out a solution

[Fox]

That's normal. To put it simply, you switch weapon the instant you press the key to select another, however the animation of your old weapon is still displayed until it is lowered. Note how the status bar change before you can see the new weapon.

So the player structure curr_weapon will holds the value for the selected weapon, while the variable currentweapon holds the value for the weapon that is being drawn.

And you really shouldn't currentweapon in the player actor, since it is used only to control what weapon will be drawn. In multiplayer, the game will assume that all players are using the same weapon as the player of the local machine.

[CruX]

 Fox, on 16 November 2012 - 06:37 AM, said:

And you really shouldn't currentweapon in the player actor, since it is used only to control what weapon will be drawn. In multiplayer, the game will assume that all players are using the same weapon as the player of the local machine.

I don't use it in the player actor. This was (probably) the reason I quit using currentweapon altogether, because back when I first started coding, I saw that it was causing a warning to pop up in the compiler, and decided it was safer to just pull the info from curr_weapon and use that for everything instead. I get what you're talking about insofar as the difference between the curr_weapon struct and currentweapon though, thanks for clearing that up.

[Danukem]

 EmericaSkater, on 16 November 2012 - 06:46 AM, said:

I don't use it in the player actor.

Don't use it anywhere except for display events, unless you really know what you are doing.

[Kyanos]

Spoiler

state onetimeonly

ifmultiplayer break
ifvarn rendmode 4 break
setvar currsect 0
whilevarvarn currsect NUMSECTORS {
	setsector[currsect].floorshade 25
	setsector[currsect].ceilingshade 25
	getsector[currsect].wallptr wallpoint
	getsector[currsect].wallnum numwalls
	setvar currwall 0
	whilevarvarn currwall numwalls
	{
		setwall[wallpoint].shade 25
		addvar wallpoint 1
		addvar currwall 1
	}
}
ends

I'm trying to run this code at map loading, just once per game. It just hangs up at the loading screen, before it begins to count textures. Any ideas?

[Danukem]

 Drek, on 24 November 2012 - 05:08 PM, said:

Spoiler

state onetimeonly

ifmultiplayer break
ifvarn rendmode 4 break
setvar currsect 0
whilevarvarn currsect NUMSECTORS {
	setsector[currsect].floorshade 25
	setsector[currsect].ceilingshade 25
	getsector[currsect].wallptr wallpoint
	getsector[currsect].wallnum numwalls
	setvar currwall 0
	whilevarvarn currwall numwalls
	{
		setwall[wallpoint].shade 25
		addvar wallpoint 1
		addvar currwall 1
	}
}
ends

I'm trying to run this code at map loading, just once per game. It just hangs up at the loading screen, before it begins to count textures. Any ideas?

you need to put "addvar currsect 1" after the whilevarvarn currwall numwalls loop.

[Kyanos]

Duhh! Oh well, gotta love easy fixes. Even if it means I made a dumb mistake

[Fox]

May I ask, what is the most performance-wise effective way of using temporary gamevars? Right now I use per-actors gamevars for actors, per-player gamevars for the player and display events, and global gamevars for menus and etc. I don't really know if it could possible be less CPU consuming to use only global gamevars.

[Helixhorned]

 Fox, on 17 December 2012 - 11:20 AM, said:

May I ask, what is the most performance-wise effective way of using temporary gamevars? Right now I use per-actors gamevars for actors, per-player gamevars for the player and display events, and global gamevars for menus and etc.

All CON code is executed in sequence, never concurrently or in parallel. So, lacking local variables in the language, there's no reason to use anything other than global gamevars for storing values temporarily.

Quote

I don't really know if it could possible be less CPU consuming to use only global gamevars.

One thing that's for sure is that it will consume less memory. A single per-actor gamevar takes 64KB or 128KB, depending on the "bitness" of the executable.

edit: the "storing variables temporarily" part should be more exact, of course. For example, you have to be careful if you're calling CON "states" in between the assignment and use of a variable, or an event is fired (e.g. by spawn --> EVENT_EGS).

[Kyanos]

I am curious about this;

volume_number

Specifically if I could use a switch or if commands to specify which .CON files are included depending upon which episode is played.

To be even more specific, say an upcoming WGR release has multiple episodes, some may use one CON while other episodes use another. Almost like two or more different mods in one.

I'll play around with it, maybe one of you guys here can help shed some light on it.

[Mark]

......shed some light on it.

Attached thumbnail(s)

• 

[Hendricks266]

 Drek, on 01 January 2013 - 06:39 AM, said:

I am curious about this;

volume_number

Specifically if I could use a switch or if commands to specify which .CON files are included depending upon which episode is played.

The include CON command only works at the top level, so you wouldn't be able to use separate files per se. However, it is very possible to have code conditional on VOLUME, and utilizing multiple instances of EVENT_GAME (or whatever other events are needed) and the "-mx" command you could keep the code modular.