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

[OpenMaw]

I have a bit of a pickle right now, and hopefully someone knows the answer.

I've got this code. It works just fine. Basically its just boxes. I'm stacking boxes.

Now, for no apparent reason, some of the boxes just decide to fall through the other boxes. (The code is very simple. If you get shot by a rocket, you blow up, if not, sit there and be a box.) There only code outside of the ifwasweapon stuff is "fall." It mostly works, but, again, some of them just decide to fall through the others, and they're all exactly in the same position relative to each other (The same number of units higher, evenly spaced.) so it's not sloppy map placement or anything. They just choose to be asses.

So am I to assume this means there is a set limit to the number of objects that can be stacked? If so, that's disheartening. I was hoping to build some mine-craft esque locales that I could have areas where you blow structures up that are made out of blocks.

[Mblackwell]

Does the actor's xvel change at all? Because if it moved even one build unit it could cause the sprite to no longer be considered the "floor" and it would fall through (depending on a few different factors). Also try increasing clipdist... go with something like say 84.

[zazo]

I enconuter an annoying thing: the rendering of shaded walls and floor is not the same between eduke( in game) and MAPSTER: when i test the map in mapster, the walls are darker in eduke for high shaded walls (somes turns to totaly black), but the shading of sprites are good ...
very annoying to work on dark places in a map.
some configurations to fix that ? thanks

[OpenMaw]

Mblackwell, on 09 January 2013 - 05:21 PM, said:

Does the actor's xvel change at all? Because if it moved even one build unit it could cause the sprite to no longer be considered the "floor" and it would fall through (depending on a few different factors). Also try increasing clipdist... go with something like say 84.

Not that i'm aware of. At least, i'm not fiddling with the sprites xvel. They start out stationary/stacked, so.... Blah. I tried adding clipdist to the code, and it made no discernable difference.

I did make a clipshape for the block, but I don't see why that would be the problem, since some of the blocks do end up stacking properly and others just fall through... Ugh...

Here's the code:

define BLOKBREK 19

action BLOKSTAY 0
action BLOKBREKNO 0

useractor notenemy BLOKBREK

clipdist 84
fall

ifaction BLOKBREKNO
{
	ifactioncount 16
	{
	strength 0
	action BLOKSTAY
        break
	}
}
else
	ifhitweapon
{
ifwasweapon RADIUSEXPLOSION
 {
            debris SCRAP1 8
      debris SCRAP2 4
      debris SCRAP3 7
killit   
    }
else
	action BLOKBREKNO
}
enda

Here's what the stack looks like in Mapster.


Here's what it looks like in game.




...The heck? To my knowledge they're all identical.

Now, over the edge of the platform I am on, they go all the way down to the bottom floor. So it's not something that stupid. I started with it at ground level, and made the raised platform to be able to see the top of the stack.

[Helixhorned]

[I moved this from the "What are you working on" thread since it's more of a CON coding question than a show-off post.]

Commando Nukem, on 09 January 2013 - 10:48 AM, said:

I have a bit of a pickle right now, and hopefully someone knows the answer.

I've got this code. It works just fine. Basically its just boxes. I'm stacking boxes.

Now, for no apparent reason, some of the boxes just decide to fall through the other boxes.

If you raise the boxes a little so that they have a gap in between, they stay on each other. Unfortunately, game code is littered with "magic" z displacements everywhere. A suggestion at a workaround is to make the box model (I assume you will be making models since flat boxes are a little nonsensical, right?) bigger than its tile which is used for collision computations.

Commando Nukem, on 10 January 2013 - 06:19 AM, said:

I tried adding clipdist to the code, and it made no discernable difference.

Clipdist is only used for clipmove, that is, horizontal movement. For BUILD, horizontal and vertical movement are two different concepts.

[Helixhorned]

zazo, on 10 January 2013 - 06:10 AM, said:

I enconuter an annoying thing: the rendering of shaded walls and floor is not the same between eduke( in game) and MAPSTER: when i test the map in mapster, the walls are darker in eduke for high shaded walls (somes turns to totaly black), but the shading of sprites are good ...
very annoying to work on dark places in a map.
some configurations to fix that ? thanks

The following cvars are relevant:

• r_usenewshading: selects between three fog computation modes.
  
• r_shadescale: specifies a factor applied to the shade. This is currently 1.3 by default, so it may darken very dark objects to the point of being black. However, there's
  
• r_shadescale_unbounded, which prevents objects becoming plain black if set to 0 (the default).

Check that these are the same for the game and editor. They're not synchronized automatically.

[zazo]

Helixhorned, on 10 January 2013 - 12:31 PM, said:

The following cvars are relevant:

• r_usenewshading: selects between three fog computation modes.
  
• r_shadescale: specifies a factor applied to the shade. This is currently 1.3 by default, so it may darken very dark objects to the point of being black. However, there's
  
• r_shadescale_unbounded, which prevents objects becoming plain black if set to 0 (the default).

Check that these are the same for the game and editor. They're not synchronized automatically.

in mapster32.cfg and eduke32.cfg files ???

[zazo]

in mapster when i load a old map, what means the message in the top of the window: "map corrupt (level 4): 64 errors ?"
scray !!!

[OpenMaw]

Helixhorned, on 10 January 2013 - 12:25 PM, said:

[I moved this from the "What are you working on" thread since it's more of a CON coding question than a show-off post.]


If you raise the boxes a little so that they have a gap in between, they stay on each other. Unfortunately, game code is littered with "magic" z displacements everywhere. A suggestion at a workaround is to make the box model (I assume you will be making models since flat boxes are a little nonsensical, right?) bigger than its tile which is used for collision computations.


Clipdist is only used for clipmove, that is, horizontal movement. For BUILD, horizontal and vertical movement are two different concepts.

Ah, man... That's what I figured. Thanks for the info. That kinda blows. Basically what i'm wanting to do is build a minecraftian map. Certain structures would have walls that would be blastable with explosives, so you can build alternate paths through the environment. That means the player would need direct interaction with the objects (jumping over them, etc.)