News | Forum | People | FAQ | Links | Search | Register | Log in
Progs.dat 2.0
Has anyone considered making an improved and standardized, engine-neutral progs.dat that would allow map makers to use a wide array of improvements without any QuakeC knowledge.

Sort of a progs.dat with support for

- Lunaran improved Zerstorer axemen / blue + red enforcers
- Hipnotic monsters + improvements
- Rogue monsters + improvements
- FC medieval characters like the crossbow enforcer

The progs, models/sounds could be rolled into a pak0 and maybe an entity definition file (.fgd) could be built.

This would let mappers with no QuakeC knowledge easily select from a wider array of features without having to learn anything.

One thing I have noticed that is lacking in Quake, is more custom light models.

We have a few torches, an ugly light globe, but no other custom lighting models (I am aware of) beyond that.

If something like this ever gets created, it would be nice to see beefed up server side thinking for better public server multiplayer (coop, vote-map, the exploit patches found in many multiplayer mods).

In particular I guess my thinking is that it would not only be nice to have this kind of thing for mappers, but it would be great if practical multiplayer servers could exist.

Mostly thinking out loud.

Really what needs to happen in addition to this is someone needs to finally take the Quakeworld map/model/sound download server side and client side code and get that added into several Quake engines.
Let Me Answer This Question Pictorially: 
There is a limit to progs.dat size. I dunno much about that tho and it might be completely unrelated.

This was already tried with custents. Not widely adopted.

If you're using custom stuff in your map, you're using custom stuff. Might as well release your own fucking progs.dat.

Kinn loves the cock. 
A Different Take 
I'd agree with the above posts about this, in that people are always gonna be better of making their own progs if they need custom stuff. To elaborate a bit on the size limit: the compilers have limits on how many variables, local variables, functions and things like that can be defined in a progs file. There is also a maximum file size for progs.dat. The last limit is the one you're most likely to hit, but the others could also be a problem. Plus the more you try to cram in, the more likely bugs are to arise, thing will conflict with one another, and the whole thing will run slower.

But something I was thinking of doing was to make a kinda mappers progs, not as the end of the custom progs, but rather as a better base than the ID one for mapping with today. They main thing would be optimisations to try and get round quake engine limits, trading it off against the better hardware available these days. Any custom stuff you wanted could then be added on top of that.

For example, the entity limit for quake is often a sticking point, so I'd put in alterations that would reduce the number of entities used wherever possible. Sometimes it would just be an all round improvement, like teleporting monsters that can just be triggered to teleport themselves, rather than wasting entities on a trigger_teleport, and info_teleport_destination and all that. Other optimisations would be tradeoffs to for example, reduce the number of used entities in exchange for an increased memory requirement. I'm sure everyone has enough memory to exceed the original '96 quake limits a bit, so it shouldn't be unplayable.

I posted a bit once upon a time about the entity management I was gonna put into the mod. It would basically keep track of entities that can be removed if need be, like corpses, explosion sprites, bubbles, fluff like that. Then when the entity limit is approached it starts to get rid of them. The behaviour of the corpse removal would be controlled from a value in worldspawn, so you could set whether corpses remain like they were, go static where possible, fade away, burst into dust/flames, sink, whatever. Extra features like kinn's group spawners would probably be handy to take advantage of entities freed up during the map, so they'd go in.

Another direction of improvement would be reducing the number of models the game uses, while changing the game as little as possible. Combining the silver and gold keys into a single model will use up a smidge more memory on maps that only have one key, but when people keep hitting the model limit I think it's a fair trade.

So is there demand for a mod like that? I'd like to think it'd be handy given the trend towards increasingly large maps, but if nobody really needs that kinda mileage out of good old glquake I'll save myself the effort. 
I Agree With Kinn. 
Baker, please collect all your recent so-called discussion topics, put them in one long post in the MAPPING HELP thread and get metl to delete them off here THANKS. 
Do you know what the file size limit for progs.dat is?

I wasn't aware that there was/is a limit and have been happily adding bits without regard for whether I will use them all or not. 
the Lost Chapters progs.dat has new monsters, monster spawning, mapmodels (new light entities and corpses), new powerups, etc...

as for file size, the current chapters build is about 860k. i can probably shave 60k off it though. 
Thanks. I'm nowhere near that size yet, so no worries. 
teleporting monsters that can just be triggered to teleport themselves, rather than wasting entities on a trigger_teleport, and info_teleport_destination and all that.

This is a brilliant idea. 
Re: Teleporting monsters

Zerstorer and Nehahra both have it. It's called trigger spawned monsters. They're not there until you trigger them (with or without the tfog). Easy to work into any mod. 
Teleporting Monsters 
Can we agree on a specific spawnflag for this, preferably something like 128, so that it is the same for all monsters (and items as well - now that's cool)

And also, can we use seperate entity names for the blue and red enforcers. This would make it more in line with the rest of the game. I would suggest monster_enforcer_blue or monster_me for the blue, and monster_enforcer_redfor the really tough bastard.

And while we are at it, find a use for monster_ogre_marksman, maybe as a weapon swap.

Btw, a note on entity replacement: If you decide to allow 2 entity names to mean the same thing (for backwards compatibility), then remember to change the classname, like this:

void() monster_me =
self.classname = "monster_enforcer_blue";

I can help code some small parts if you want. 
just looking for something in the archives and found this. I see the idea didn't go down to well, but I was thinking along similar lines recently.

However, since Quoth is so full featured (with a couple of minor omissions) and features really good new monsters and has a consistent feel, I am just going to use that in the future.

There is very little else that I have seen and really liked on the monster or weapon front, and Quoth has most of the new mapping features I want (except exploding walls, more shooter types and touchable triggers that don't use a model precache slot :)

Actually, I wouldn't mind a precache entity, that precaches a certain model or sound so that we don't have to load cthon or whatever just to have a ROAAR! noise in the level.

That's about all Quoth is missing*. If those things get added then that's probably enough.

*Zerstorer has a couple of really nice monsters and weapons though - but if I want them, I'll map for Zer. 
Precache Entity 
sounds interesting, although, you don't need it if all you want to do is play sounds. just give the file and path name of the id sound in the pak files for a play_sound_triggered entity and it will precache it itself.

speaking of zerstorer... anyone remember who made that big flying boss thing that kills you at the end? that model looked really cool... 
of course he was obviously a shambler with an upside-down shub as his lower body. Maybe with a cthon head? Can't remember. 
yeah, i know, but it's a cool mix, and it works well. :P

and yeah, i'm pretty sure his head looks like chthon. ^_^ 
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.