why do I always get the message backup past 0 in one place in my map? AguirRe's engine, -developer 1 option.

And I get monster in wall message when monsters spawn high over ground (to avoid accident telefragging them).

Can anyone explain? AguirRe? 

i think the droptofloor doesn't drop monsters if they are too high above a floor, this means that when the monster is checked to see if it can walk or not (ie: stuck in the floor or not on the ground) it will return false, and thus give the error message.

this used to happen in quoth for spawning monsters from func_hordespawn, because i chose to not make spawning monsters droptofloor (in case you used flying monsters) but the error check would come back that they couldn't move (because quake physics hadn't started on them yet and made them fall to the floor). 

Backup past 0: I don't know, it happens occasionally without any obvious problems.

Monster in wall: I also don't know, if the monster behaves as desired, ignore the warning.

I think both things can be QC issues as well. 

The monster in wall check is just like necros said, it's a QC side thing, in the function walkmonster_start_go. The way the QC tests for a monster stuck in a wall is to call walkmove(0,0), the function for walking monsters on the ground. This function returns a float value of 1 if the movement was successful and 0 if it wasn't. If the movement fails then the error message "walkmonster in wall at: " is printed.

The problem is that walkmove can fail(return 0) for three reasons. One is that the monster is stuck in a wall, which is the behaviour the code assumes. The second is if the monster can't physically move that far, like when there is a wall in the way. This cannot happen in this case though, as we are walking the monster 0 units. So you only end up in a wall if you started in one.

The third reason it can fail is if the monster isn't on the ground, as walkmove is only for monsters that are walking on a surface(surprisingly enough). So if the monster is spawned in the air it's going to fail this check. Usually the preceding line of code in walkmonster_start_go drops the monster to the floor first, but if your monster is too high to drop(more than 256 units above a surface) then it won't work.

Since you mentioned avoiding telefragging as the reason the monster is so high, there is another possibility why droptofloor isn't happening. I'm guessing that you're using some kind of spawnflag teleporting, rather than the ID setup of info_telport_destination and teleporters outside the level. Some code(mine included) modify walkmonster_start_go to ignore the droptofloor call - precisely for the reason you're giving, so that the monster teleports in from where they are placed, which is allowed to be in the sky. Of course, then the code should really skip the "monster in wall" check too, as it'll always fail even when the monsters are not stuck. I guess I should contact inside3d about correcting my teleport flag code then... 

for some reason remove_skip doesn't work on my map. it always stops after saying "bsp is version 29" without removing any faces. could this be related to fact that i'm very close to hitting the marksurfaces limit and have exceeded clipnodes by 10k? compiler is treeqbsp-bjp by the way. 

skippy tends to trash the bsp and cause all many of problems. 

i changed the object in question to a health trigger. thx 

...I have just added 20+ monsters without making any changes to brushwork. Marksurfaces have risen from 31065 to 31665.

If marksurfaces are created as a result of the way the brushes are split in the qbsp stage, does it mean that monsters can cause a different split? And if so, is there a benefit to keeping monsters off of the ground in the mapping stage.

I ask because I have at least another 80 monsters to go and am in danger of exceeding the marksurface limit, and I want my map to be playable in FitzQuake.

(I am probably getting too tired/old to adhere to the critical technical disciplines of Quake mapping these days) 

Compile the map one with all the monster entities in it and let it exceed marksurfaces. Use adquedit or similar to export the entity list to a .ent file. Compile the map again in it's current state(ie. with enough point entities stripped out to compile with marksurfaces under the limit). Then just import the ent file into that copy of the bsp. Equivalently you could do an -onlyents compile to add the monsters back in, and this might be a little easier to set up with batch files. 

monsters have no effect on the bsp tree :)

As for what caused your increase in marksurfaces, I have no idea. Are you sure you didn't do anything?

Also, I've heard rumors which I find very hard to believe that things like vis results are actually different based on the speed of your CPU and stuff... I really have a hard time accepting that the compiles are non-deterministic. But, I don't know everything, so :P 

once I noticed the same thing as Mike did. I exceeded the marksurfaces limit when placing monsters (no brush changes). Wise people told me that monsters don't affect marksurfaces, so I believed them.

Anyway, some maps with exceeded marksufaces limit can still be playable in fitzquake (and all the other engines I think). When I got the crash problem the first time I started making small changes to the map and tried it in the engine each time. After n attempts map started to load without problems. Though I still have no idea what was the case of the problem and solution.

It's kinda Quake mysticism. 

I always get a message when I test my map on skill 2 (-developer 1 option, aguire's engine):

TH_STAND CALLED
WALKMONSTER_START_GO WORKED

WTF is this? And why it appears only when I play on hard skill? I suppose that's because of a big ammount of monsters (>200), but I don't get it on skill 1 where monsters are only about 20-30 less. This message dissappears only closer to the end of the map after I kill about 150-170 monsters. 

th_stand is the standing animation for all monsters, and walkmonster_start_go is the function that gets called everytime a new monster is made to set up common stuff between all walking monsters...

but i've never seen error code like that in the qc, so it must be an engine thing... 

I doesn't cause any problems (at least I didn't notice them so far). It is just annoying message at the top of the screen. I just wanted to get some ideas of how can I get rid of it. 

Are you using a custom mod for this map, perhaps with a custom monster that only appears on hard skill? Those messages sound like the kind of thing I'd add to a monster when diagnosing a bug and trying to pin down where it occurs. 

It happens in my map that you've seen (beta1). But I think all custom monsters appear in all skills. So no new custom monsters on skill 2 that weren't on skill 1 

Didn't we discuss (and solve) this issue five months ago? It's a bug in the Arcane progs that I later sent you an update for. 

thought you were talking about stock id progs :)

yep, that'd certainly explain it. 

indeed, I forgot about it.

The thing is that I found another bug in progs and asked Preach to fix it, but I forgot that I was using your fixed version.

So I have two versions of arcane progs atm: the first - your version without crashing bug but with version with ammo bug and the second - Preach's version without ammo bug but with crashing bug.

I think you should contact with each other and make an ultimate version. 

Are lights with "style" toggleable? And if not, has some clever person devised a 'hack' to make them so.

I am sure I remember this cropping up quite recently but I can't seem to find anything. 

but no way to do with in stock progs, afaik.

toggleable lights have a unique style for every different toggle light (set by the light.exe), which is set to a single light level and only goes from on to off in the progs. 

How I suggested to do this last time it came up can be found on the following page:

http://www.celephais.net/board/view_thread.php?id=4&start=4458&end=4482

But yeah, you need a custom progs to do it. 

Thanks. 

Hub-style level transitions.



cool, you're still reading.

For a real useful implementation you'd (I'd) want:
o persistent entity states upon returning to a map
o a set of global flags for triggering things across maps
o the final exit trigger to display the intermission with stats for all levels totaled (or even broken down)


What would be necessary for such a thing? There's a lot to do in QC, of course. But QC doesn't have control over saves IIRC - so you would be required to mess around with the engine, no? And if you're messing with the engine, why not just up the limits to allow the whole map in one huge BSP instead?

(the answer to that being, of course, compile time on the map, and ease of messing with savegame code vs. difficulty of raising all internal limits).

So assuming one is not above including an .exe with his maps, what's involved?

I would think the following but go ahead and argue with me cuz I'm dumb:
o Bunch of stuff stuck into the player struct for preserving cross-level trigger flags, and filenames of temp saves used to track recently visited bsp's
o Bunch of additions to endlevel trigger to handle preserving vs. dropping cross-level information, and stashing away level state in a savegame file
o Bunch of additions to player spawning functions to handle preservation of keys and stuff, and correct location within the map based on previous exit trigger 

i'm interested in this issue too.
some old rpg/adventure-style mod (don't remember the title) had some sort of hub code even back in 1997 or so. but i think it didn't have a 'final intermission' summarizing the stats of all maps...