Trying to compile my old q1 maps using Sleepy's Map Converter and a .bat, and while some maps compile fine, others get the following message, followed by none of the compile progs doing their jobs and a lot of nothing being accomplished:

Parsing file c:\quake\id1\maps\bleh.map...Exception EConvertError in Modul mapc
onv.exe bei 000077B6.
'' ist kein gⁿltiger Integerwert.

With any new maps I start, it will get up to the 'Parsing file c:\quake\id1\maps\bleh.map...' part, and just stick there. Again, it works fine with other old maps, so I'm thinking everything is set up to work. If anyone else has run into this and has some sort of workaround, I would very much appreciate some help. 

it is finding a floating point number in your map in a place where it expects an integer.

Biff, are you using quoole? Biff, is this true? 

I regret to inform you that this post is almost entirely worthless. The only thing I can say is that I remember getting that error two or three times, and each time it was 6-12 months apart so that I never remembered what the problem was when I encountered it. Since it's been about that length of time, and I don't use Sleepy's tool anymore, I don't remember exactly what the cause was. However, I do remember that each time it happened the problem was something trivial with the .map, and I would subsequently dopeslap myself before moving on.

Some things to check: is the map already in Q1 format? Are you giving the player a message that includes quotation marks? Do you have any crazy brushes with no volume, faces with no area, or other technical problems? (MapSpy could help determine the answer to this last problem.) Are you wearing sweatpants? 

1. No CZG, I am not using "quoole". I stay away from the hard stuff anymore.

2. RPG, what are you using instead of Sleepy's converter?

3. WTF is MapSpy (I'll prolly Google for it in a bit)...?

4. No sweatpants, but a pair of pajama bottoms my cousin and his wife gave me for Christmas. The weather here (as you may well know) has been too damned insane for consistent sweatgear wear. 

I don't know what RPG is using, but AguirRe's compile tools do the conversion for you, you just got to set the switch in you .bat or whatever 

At least the later versions of AguirRe's tools do. 

But I'm not too swift on this .bat stuff: Is it possible for me to stick AguiRe's stuff in a seperate dir than the .wads, and still be able to compile, or do I need to have it all in the /id1 folder (where GTK needs the textures)? 

wad and tools in maps folder
textures extracted (.jpg)in id1/textures/q1_biffs tex

batch file eg,
qbsp.exe -q2map -oldaxis -transwater biffs.map

-q2map being the conversion switcheroo

can you have things in a different dir, dunno, prolly not, but I don't know, I've always only done it the one way, come to think about it, that's prolly why my wife left me, hmmm 

if you put stuff in a different dir, you just need to specify the relative or full path to it in the bat file. Or, you use "cd" to switch to the qbsp dir. But, you might have to add the full or relative path to the map file in that case. 

GTKR 1.5 can save directly to Q1 .map format, which eliminates the need for a pre-compiler like Sleepy's. That's what I'm using.

MapSpy is a very cool program which was originally written to solve a Q2-specific game error, but has been expanded to help track down generic .map errors, such as brushes with no volume, brushes with infinite volume, faces with no area, etc. http://mapspy.gamedesign.net/ No matter how much I tell people to try it, no one seems to use it. I distinctly remember explicitly telling someone it would solve his specific problem, but he still refused to download it and try it for some stupid reason--I think it was because he thought it only worked for Q2 maps, which is simply not the case. When you run the program, just ignore the Q2-specific output and look for any QBSP errors it mentions.

Regarding compiler locations, I have maps, compilers, and maps in id1/maps, and the wads in id1/. From there, I reference the full path of the .wads from the map ("wad" "d:\quake\id1\metal.wad") and just run the .bat compiler from id1\. Here's what the .bat looks like:

set BASEPATH=D:\Quake\workingq

%BASEPATH%\maps\qbsp.exe -oldaxis %BASEPATH%\maps\%1.map

%BASEPATH%\maps\vis.exe -level 4 %BASEPATH%\maps\%1.bsp

%BASEPATH%\maps\tyrlite.exe -nocount -extra -nominlimit %BASEPATH%\maps\%1.bsp 

Got it sorted out, I think -- the .wads in /id1, along with the compile.bat, and the tools in a separate folder. One more question, tho: I'm using AguiRe's stuff, and dunno where along the line to use his Bspinfo prog...

Thanks RPG and the rest, though -- looks like I'll actually be doing some Quake mapping this weekend =D 

put it this way, use it when you need to use it ;) 

I was wondering how the skybox is used in Quake1 maps. Not the regular one, but the same as in Q2. 

Is your email working? 

Is there an easy way to allow monsters to use this: I do not want to use trigger_monsterjump? 

Monsters are effected by trigger_push by default.
They won't actively seek it out in any way, but when they touch it they will be sucked in. 

I'm dropping a spawned ogre onto a trigger_push and he just does his own thing?

If I go onto it, everything is fine... whoosh. But he just runs up and down the length of the trigger and even stops in the middle of it if I no_clip and hover above him.

Any ideas? 

:( 

Oh dear :( 

I'm guessing (wildly) that it might be a conflict of sorts between the movetype of monsters and the monster being on the ground.
Perhaps try throwing the monster into the trigger with a monsterjump?
Also, if the monsters starts inside the trigger, there is a minute chance (or any chance at all?) that the touch isn't registered. I doubt this though.

I remember the good old map grc4beta had a fiend traveling down a windtunnel early on in the map, but I'm not sure if the trigger_push was overlayed by a trigger_monsterjump there or something. 

but never an ogre.

I have only ever gotten a monster to jump with a trigger_monsterjump. In fact, the only other things I have ever successfully seen respond to a trigger_push (besides the player) are grenades.

Let me know if you get it working :) 

CZG - Whats your email?
I tried the one in czg07 readme . . . I�d post the message here but I�ve goofed before on spoilers.

Website - how do I review old threads? (ie. not on the main page)

Thanks 

Looking at the triggers.qc it seems as though this works by use of 'velocity', which is not how monsters move. Therefore, it does not affect monsters; therefore, there is no easy way to use it for monsters without writing some code. 

OK, I'm getting there. I can now get monsters using the trigger-push, but it now leads to another problem...

How does the 'angle' entered in the editor get converted to the self.angles vector used by the qc code? (I'm making this assumption because 'angle' is not seen in the code) 

The trigger_push uses the movedir vector for the direction that the velocity is added in. Movedir is set in the function SetMovedir() in subs.qc. SetMovedir() is always called by InitTrigger. The function setmovedir is quite self explanatory once you understand how .angles is set. Essentially the editor sets angles to '0 a 0' where a is the value of angle(note the absence of the s). This only allows you directions in the xy plane, so there's an extra hack added. If the angle is -1, Setmovedir converts this to a vertical vector pointing up. Similarly -2 produces an vector pointing down.

It's not a great way of doing it, since you can't have motion that's diagonally up and across. A good fix that would be backwards compatible would be to have a check before calling SetMovedir to see if movedir is already set. If it is, then normalise it but leave it otherwise unchanged. If it's not, call SetMovedir. That way you can choose to set the angle normally or override it with a custom movedir.