In addition to the "frame specific" options, I forgot to mention the desire to tie separate bmodels to certain keys' values or spawnflags. In particular, the health kits, which use separate .bsp models for the normal health, rotten health, and Megahealth settings inside of the item_health entity. I don't see a way to do that, currently.

I've also just stumbled over what I think is a bug: when an entity has multiple copies of the same key, but with different data types, the two keys are presented to the user in the Object Properties dialog as separate options, but have their values tied together.

In my case, the light entity used by Quoth is proving troublesome. The FGD I've been working on, as well as just the basic Quoth 2 FGD from Preach's site, have the base class Target defining a key called 'delay' that's of type "string", which allows Quoth entities to offer a delay before triggering their target entity. The Light class, which derives from Target (among others), defines another 'delay' that's of type "choices". Both show up in the Object Properties, which seems sensible since they're different data types and I imagine there should be no conflict (Quoth supports them both, if I understand correctly), but changing the value of one changes the value of the other. This behavior also prevents the "choices" version of delay, which is used to select lighting attenuation, from providing the dropdown list of options with user-friendly names.

I'd suspect it was my messing around with the FGDs that caused this, but since the standard quoth2.fgd shows the same behavior I'm led to believe it's a bug. Is this something that's possible to fix? 

I don't have a strong opinion on where to go with this but I can share some thoughts. First is why delay is a string in the Quoth fgd - which seems strange when you realise that it's actually a numerical field in-game. The reason is that you might want to set a non-integer delay like "0.5" or "2.3". In some map editors, your options for field types are "integer", "pick-list" or "string", and only one of those lets you put the decimal place in.

The other is who "owns" the delay field. It's actually a standard field in vanilla Quake which just got inherited into Quoth - although I might have added it to the Target class for consistency. It's best practice for fields which mean something to a compiler tool to be prefixed with an underscore (which avoids conflicts with QuakeC), but the use of delay like this does date back a long time. So tough call.

Perhaps a good fix would be to remove the Target class from lights, and just add the "target" field to the Light class instead? Lights don't actually have fully fledged targeting, they only use the field at compile time for directional lighting with an info_null, so the Target class is overkill and perhaps not appropriate. Yeah, that sounds alright actually... 

is very unfortunate.

I believe they were named that way because of compiler restrictions. If only people knew that prefixing with an "_" back in the day would have solved this little problem. delay, wait etc are daft names for the functions they carry out. 

Your idea sounds alright to me! I can't offer any intelligent commentary here, frankly, but if it works for you it works for me.

I only assumed the current class hierarchy was explicitly meant to work as is, and Jack was expected to provide users with both versions of the key. If the Target class is in fact overkill, removing it from Light and simply adding the target field by hand is easy enough, and would solve the problem in this case.

I'd still wonder if it's something Jack should allow in case of future conflicts, but I suppose now it's more of an academic question. If you decide to go with stripping the Target class from Light, I'll follow along with my own FGD and the point will be moot. 

 

I went ahead and tried out your idea, Preach, and after testing it a little it seems to work just fine. Target works to let people define their spotlight target, and Attenuation has the nice dropdown menu.

Thanks for the advice! I'd never have figured out how to handle this otherwise. 

Export wad file pathnames to .map using forward slashes only, e.g. C:/QUAKE/wads instead of C:\QUAKE\wads to prevent compiler mistaking for escape characters. 

I've been wanting there to be a more user friendly way to make Quake levels closer to the spirit of Mario Maker. Something that includes the standard assets, models, like base doors that are hard to make, selectable attributes instead of using complicated integer flags while keeping the ability to manipulate, adding the compilers, places custom music and graphics and creates folders for you etc. Then, maybe an updated and more simple guide. Basically just try to think how easy Mario Maker is, but allow people to go further than that and do advanced brushwork. There may even be some basic low hanging fruit in QuakeC settings that could be built into the Quake Maker.

We could create a much bigger community of level makers if we could make things easier to understand and a tool that integrates the features. I'd like to focus more on level design instead of trying to break through the technical hurdles.

I don't know everything that is possible because I'm not an expert builder familiar with everything, but I think talking to some of those people, creating a list and then outlining a project would be the solution. I would then want it to get done and maybe we would have to create a fund to pay some open source developers to make it happen.

I see J.A.C.K supports windows and linux, but not MacOS, so I hope that MacOS is added and maybe the creator will be interested in pursuing the sort of vision I describe here. Trenchbroom is also an option, but I don't know who may be interested in doing this. I like the option to manipulate in 3D with Trenchbroom. 

And your evidence that there is a ton of people chomping at the bit to make quake levels, but put off because existing level editors are too difficult to use is.... 

Kinn,

I'm thinking of myself first and I'm already using the current editors and see a lot opportunity to add features to make the program more user friendly. So, even people of my interest and knowledge level it would help me a lot. I imagine that it would also open Quake up to a lot more people if such a program already exists and it introduced to them. 

So, you are basically asking to turn the editor into SnapMap/Deathmatch maker for the target audience of you. 

MaxED,

No, I don't think that would describe my vision.

I actually haven't used the SnapMap editor, but I did use Deathmatch Maker 2 for Quake 2 a long time ago and I have a good idea of what SnapMap is probably like.

The only Quake editor I have been able to get to work is TrenchBroom. It is possible that some of the features I would like are in other editors.

I would like drag and drop assets of the objects that are standard in the game though. It is possible a file could accomplish this if somebody has a map file with lots of these in there that could be copied and pasted out. Examples like base doors which I find hard to make because the way they split down the middle and line up with the texture and other common assets.

Some of the low hanging fruit is with the flags on objects, descriptions and compilers. It would be much easier to have drop down options instead of having to look up integers and set values and some prefabs to get people started that don't have the objects from previous projects would be helpful. Having EricW's light program linked along with the compiler would make the workflow much easier. Perhaps even getting people setup with creating pak files and game folders for custom sounds and graphics would be helpful so all that can be done behind the scenes and create a final distribution.

I don't want to have any limitations to edit brushes and do anything advanced, I just want to use a more user friendly program.

I might have to use J.A.C.K, so I hope J.A.C.K will release a MacOS version soon. 

You do realise you can just maintain a "prefabs" map file and just copy n paste bits over into your working map as required, right? 

Oh just read your post where you say the same actually. 

You can submit your ideas as feature requests for TrenchBroom on github and I'll consider them. I'm always open for ideas on how to make it easier to use as long as they don't get in the way of power users. 

Kinn,

Yes, I've thought of doing that, but I don't have such a file. I've thought of asking around if somebody has one or could make one for me. Also, I've had a lot or problems with TrenchBroom crashing when I try to open two map files. I think TrenchBroom is great though because it supports MacOS and lets you manipulate things in the 3D view window. 

SleepwalkR,

That is very kind, thank you. I have some ideas. I also suspect I could come up with a better understanding of what is possible by talking with an advanced mapper to generate more ideas. 

"Jackhammer has been renamed to J.A.C.K. because of copyright issues"
Seriously? Isn't jackhammer a common noun, like car or refrigerator? And isn't J.A.C.K. trademarked by Monolith, you know, as in Contract J.A.C.K., the game set in the No One Lives Forever universe? 

Jack Hammer aka J.A.C.K. was greenlit on Steam. I guess they asked XaeroX politely to rename it, to avoid misunderstanding what is Valve's Hammer and what is Jack Hammer. 

So to avoid copyright issues they're creating a new one? Boy, that's rich! While they're at it, why don't Valve ask the world politely to find new words for hammers, valves and steam altogether? 

 

...but the saddest thing about it is that you're most probably right. 

Anyway it would be a trademark thing, not a copyright thing 

Copyright, trademark... it's basically the same thing under a different guise. 

Suggestion: In camera mode you can use pgup/pgdn to cycle between multiple cameras. I can't see any reason for why the same keys shouldn't cycle through cameras outside camera mode as well. I don't think they're bound to anything else.