RiftQuake

[Dutch]

Well, FitzQuake and RiftQuake don't agree too well. Had to do some narrowing down to find the culprit. Apparently I'm tripping a model precache limit somewhere. RiftQuake uses an insane amount of custom models that DarkPlaces doesn't seem to mind in the least. I'll need to look into this further.

Going to try Quakespasm now.

EDIT: And Quakspasm was a success. A little tweaking in my code and translating my custom stereo sound effects over to mono and it was rocking as good as DP. From my understanding, QuakeSpasm is a derivation of FitzQuake with a few extra features and raised limits, so this made the difference.

However, I'm still having problems with two things:

1) QuakeSpasm does not like my custom .BSP ammo and health models. It's a bit weird. I know the models are precaching and loading just fine. The textures are being recognized from the .BSPs. However, only the fullbrights in the .BSP model textures show up (other colors are flat black) UNLESS the entire map has no light compilation (meaning fullbright everywhere). In this case, the .BSP models appear as normal. Anyone ever deal with this? It's just not adding up. DP doesn't have this problem so I'm looking through the extension QC right now to see if I can figure something out.

2) Quakespasm won't load Player HealthBar pics (like the mini-weapon pics telling you which firearm is currently equipped). I know what the problem is here. I don't have the custom textures packaged within an updated gfx wad. DP doesn't mind this, QuakeSpasm does. I use TexMex for wad editing, and it doesn't like modifying the gfx wad, even with correct picture dimensioning....add this to the list of "here we go again" fixes. Lol.

EDIT2: I narrowed down the .BSP issue to the .BSP files themselves. I loaded both the original id model of the rotten health box as well as the one used in Soul of Evil just to see what would happen. Both loaded fine into the mod. So, I'm wondering what it is about the way my .BSP file compiled that DarkPlaces is ok with and QuakeSpasm is not.

EDIT3: Sorry I keep rambling on. Whenever I hit a bump in the road I obsess over fixing it. Just my nature. Anyway...since I'm dealing with the .BSP problem, I'm thinking I might just kill 2 birds with 1 stone. One feature I wanted to add to RiftQuake was realistic lighting on the ammo/health pick-ups (nothing screams 'fake' like glow-in-the-dark boxes). After I get off work tonight I'm going to see if I can find a way to convert .BSPs over to .MDLs, since .MDLs are not rendered fullbright all around. This would be the easy way. The hard way would be reconstructing .MDLs in Blender and applying the correct textures. One way or another I'll get it done.

@Spike if you're reading this, FTE looks pretty slick. I'm going to add that to the list of engines I want RiftQuake to run smoothly on. Testing/tweaking starts tonight.

So far, the list of target engines is DarkPlaces, QuakeSpasm, and FTE. I would like to get a few more 'faithful' vanilla engines on the list, but due to the increased detail and model calls in RiftQuake, this may prove challenging.

[vegetous]

I had a dream last night!

It involved riftquake + smc and Cthulhu!

I would call it "a complete new Quake episode".

Just think about it for a few moments!

[Seven]

Hello Dutch,

Spike will sure help you with most of your mentioned points.
Until then, let me direct you to the start/home page of quakeone.com.
Scroll down a little and you will find links to 2 more very famous engines: Qrack and DirectQ. They are without a doubt also 'advanced engines', so they should have no problem in running your mod. Please try them.
DirectQ is focused on a faithful look and is even recommended by Spirit on quaddicted.
Please click on that link and read. You will learn a lot about Quake engines.
Once you are there, be sure to also navigate through the other pages of quaddicted (if you didnt already).
It has the biggest archive of maps and mods, tools, files, ect for Quake.
Spirit also recommends reQuiem, which might fullfill your needs as well.

Regarding your issue with replacement textures (like your mentioned sbar/ibar), you must know that some engines support external replacement files, while other do not and therefore you have to edit the original wad file.

The same goes for replacement models (like your mentioned ammo boxes). DP swallows a lot of model formats, if the ending is renamed to the original ending, without complaining.

And there we hit the biggest issue:
Once you decide to use external replacement files, you will have to decide for an engine of your choice, as most advanced engines expect special/different places (= subfolder) or namings of these files. There is no standard for all replacement-supporting-engines unfortunately.
So, best way to avoid this specific issue, is to bake the textures into .mdl and use vanilla file formats. Watch out for the limits though.

Regarding the high amount of models, why not try to simply extend the animation frames ?
Example: Shalrath�s new animations can be added to the end of the her original animations frames. This might save you some models. But there are frame limits for .mdl as well.

Just like Spike said:
Quake limits everywhere....
But with the above mentioned engines you should be good to go, as these have limit extensions.

Best of luck,
Seven

[Dutch]

@Seven

Thank you big time for the link and the info, this is great to know. I will check out the engines you mentioned for sure. I've been to quaddicted a few times but never fully explored it. I'm still at work so I will look into all of these tonight. Just to clarify based on what you've told me, it sounds like I can solve the issue by properly packing sbar textures in the original gfx wad and by utilizing .mdl models for the health/ammo. One more quick question: what kind of file types can I get away with for the sbar pics within the gfx wad for vanilla engines? Currently I have jpegs, which I'm fairly certain were never used by id originally. I was having difficulty determining what format the currently existing sbar pics are. I imagine they are MIPS.

Thanks again seven, this is a huge help. I will read up on those links tonight.

EDIT: oh and all of the monsters use the existing model for custom animations except for the player model, which calls on custom models for the gibs so as not to exceed frame limits. Also, the player model seemed to get stuck in frame1 whenever I called on a new animation within the original file (something to do with client-server relationship?). A vast majority of the custom models are from entity-specific gibbed body parts (shambler claws, vore legs, fiend blades, and all manner of respective arms/legs).

[Trickle]

Very good work sir!

I'd have to agree, this certainly has an awesome Brutal Doom like style. All the images and videos have been impressive thus far. I look forward to watching more of your progress!

P.S.

Nice job on the vweps

[Syluxguy28O3]

man this looks really good. excited to see more.

[MadGypsy]

@learn radiant or worldcraft

This is just my opinion - fuck worldcraft. I know some excellent maps have been made in it, and that's great and all but, fuck worldcraft. I will personally teach you everything you could ever want to know about Radiant, as it applies to Q1 mapping, if you like.

Why do I hate worldcraft? I don't. It's great if you are a beginner. I'm not a beginner. I remember picking up Worldcraft and mastering it's interface in like 1 hour. I also remember golden_boy challenging me about my worldcraftness and instigating me to pick up radiant. I also remember never looking back after that. I spent months picking apart the meaning of every line of every file that is configurable in Radiant. In those same months I started tackling the major problems that most people have with radiant.

1) Q1 compilers are completely external and you are just expected to know how to set it up. (SOLVED)
2) You couldn't run your Q1 map after a compile. I mean in the sense that you couldn't compile and expect Radiant to start the map when the compile was done. (SOLVED)
3) multiple file types (image and model) that are acceptable in Q1 today were not even allowed in the "stock" config (SOLVED)
4) The original config (in NetRadiant) was set-up to actually crash if you tried to compile a Q1 map (SOLVED)
5) No build menu for q1 even existed. How could it, no compilers were included (SOLVED)

There were other things but the bottom line is, all this "solved" is what every user would have had to solve just to use it. I just solved it all and made it a gamepack. I went as far as to write example build menus for every compiler and I even included a compass in the build menu for the sunmangle features in BJ's compiler.

There was another thing to consider about all of this "solved". Radiant is simply way more customizable than Worldcraft will ever be. You have practically unlimited control over every little nuance of your setup. This realization led me to categorize Worldcraft as the Walmart version of mapping tools. It's pretty good, just not good enough.

This of course is just my opinion, but there is one thing that isn't my opinion. Worldcraft does not make authentic Quake1 BSP's. I believe the filetype is called Valve220 (I may have the name wrong but the main fact is true)

______

Your rooms look really good

[Dutch]

@Trickle and syluxman2803: Thanks guys! More updates soon hopefully. Working out some bugs for the time being. I'm glad you like what you see.

@Gypsy: Well that just about did it. Sign me up. This sounds like the hot setup. Is there a place where you have the gamepack linked for download? I'd like to start checking this out real soon. I appreciate it buddy. It's time I stepped up my mapping a bit and quit playing in the sandbox.

[MadGypsy]

@Dutch - I will have a copy for you tomorrow. Even if you find a copy, don't use it. I promise you I have a better one.

I'm not kidding when I said earlier that I have made a lot of stuff. An example of upgrades to the gamepack include stuff like wads of base color gridz and just base colors. I do not mean base as in a Quake Base map textures. I mean base as in rudimentary.

These make mapping easier in many ways. The textures with the grid right on them (accurate too) can help a lot if you want to work in perspective view, and they are invaluable for lining up textures in tricky geometry.. The solid color textures make it easy to see your geometry. They also take texture concerns out of the mix while you are laying brushes. You can go back when you are done an easily use radiants replace feature to switch to the proper texture.

That is one example of an upgrade. Those textures are included in the current gamepack. I went a step further though. The textures are in wad format, but if you just place the "high def" textures in the right folder Radiant will automatically load them instead of the quake palletted wad ones. So you can work in radiant with "high def" accurate gridz of the proper color...these are also included.

There is actually just a little more about these textures. They come in like 20 different colors, 3 or 4 different sizes and represent multiple grid units. I think 16, 32 and 64.

I know I put other stuff in the game pack but I can't remember what. It's like an SMC for radiant...lol.

----

I didn't include this in the gamepack but I rewrote entities.ent so you can see your models while you make your map. Like the player, monsters, etc... The one glitch with this is that none of the ammo boxes work and none of the light models do either. Weapons, monsters, pick ups...all work. I can give you a copy of this as well, if you like. Personally, I don't like to use it. It makes radiant slow down too much when my map gets big. Maybe you have a better computer and by maybe I mean probably.

[Dutch]

@Gypsy

The grid textures sound extremely convenient. This is starting to make me miss mapping something fierce. Can't wait to dig into this. And yes I'd like to check out the entities.ent. This would be familiar because Qoole, despite it's lack of many features, rendered models in 2d windows. But I absolutely doubt your PC is worse than mine. Mine's a dinosaur.

[Seven]

Just to clarify based on what you've told me, it sounds like I can solve the issue by properly packing sbar textures in the original gfx wad

Hello Dutch,

You can of course edit your own wad file inside your pak0.pak, but your aim is to release your mod one day and people would need your modified wad for that.
I never altered my wad, so I do not know if you can simply put it in a new pak0.pak inside your mod subfolder "riftquake" besides "id1" folder, and start your game with "-game riftquake" extension.
You must try this, if it works, go on. If it doesnt you have to find another way...
Because overwriting original id1 Quake files would not be a good idea for a mod.

One more quick question: what kind of file types can I get away with for the sbar pics within the gfx wad for vanilla engines? Currently I have jpegs, which I'm fairly certain were never used by id originally. I was having difficulty determining what format the currently existing sbar pics are. I imagine they are MIPS.

You said you are using TexMex for this. Did you read its readme.txt files ?
One of it says:

You can copy&paste between TexMex and most other graphics applications.#@#@All neccessary conversions are handled automatically.
Tex-Mex can read WAD2, WAD3 and BSP files.#@#@As well as WAL, BMP, PCX, JPG and TGA files as images.When you paste or load an image#@The item will automatically resize#@to accomodate the new image.
Pasted and loaded images are#@automatically remapped to use the#@Quake palette.
Auto-mip will scale the image#@to generate the three sub-mips#@that Quake requires for a texture.

oh and all of the monsters use the existing model for custom animations except for the player model, which calls on custom models for the gibs so as not to exceed frame limits. Also, the player model seemed to get stuck in frame1 whenever I called on a new animation within the original file (something to do with client-server relationship?).

It is hard to say what the issue might be without seeing the source.
I can only guess: In PutClientInServer() the player model is defined and modelindex_ is declared. Maybe you corrupt something when later on change the player model...
Or you did not use setsize when using setmodel ?
Which animations do you call when using new player model ?
Are their frame numbers in order compared to original model ?

I am suprised that you exceed the max. frame amount, as the original player model has around 150 frames, so you still have more than 100 left...
Do you really need more than 256 frames ? Please double check.




Regarding level editors for Quake:
You should at least look here once, before you decide which way to go.
Several new mapping tools have been released shortly. They already have the mentioned things included and a lot of people seem to like them very much. Many change over to one of these, as they are made for Quake and its requirements.
- TrenchBroom
- Jackhammer

But I am not a mapper. I only like to read things about it and they cought my attention due to their positive feedbacks from longtime Quake modders !


Best of luck,
Seven

[Dutch]

Hi Seven,

As far as creating a custom gfx wad and placing it in the mod directory, this seems to be an acceptable thing even for vanilla engines, as Kell's Quoth mod does this (his recommended engine, I believe, is FitzQuake). I do recall reading the excerpt you provided from the TexMex readme. The problem is something else. Upon duplicating the original gfx wad, creating a new sbar icon to the exact dimensions as the previous one it is replacing, and inserting it into the wad, TexMex informs me that it needs to be re-sized, even though it is indeed the correct size. This, I suppose, could be any number of things and I will just need to figure a way around this. A little playing around with it and I should find a way.

As for the player animation problem, I was very careful in maintaining frame number relationship. I have heavily modified the model_index calls (there are now eight, one for each weapon), but the problem was present before any modification to the function. At any rate, calling 1 of 3 possible replacement partial gib models, so far, has operated flawlessly on enhanced and vanilla engines. I'm hesitant to change what already works.

The reason each player model has so many frames is because of the custom running and gunning animations. Four weapons are called in the player_shot functions, so as to maintain the original scenes in the .mdl file (thus side-stepping the afore-mentioned frame problem), and each running animation is coded, handled, and terminated/repeated separately for each weapon. This, of course, became a lengthy process that I'm sure has a cleaner way of executing, but nontheless it works well in both types of engines.

For example, the Scout Rifle, which is a slow-loading manually fed rifle, calls on 23 frames of player animation (depicting the player firing, opening the bolt of the rifle, reaching into his pocket for another cartridge, and loading it into the rifle). This is only for a player without motion. With motion, the same animation of the player's torso is called (slightly different, but still comprised of 23 frames) but his legs are in running motion. This weapon increased the player_shot scene from 6 to 46. The grenade/rocket launchers and assault rifle have similar (but shorter) frame calls. I believe each player model has a total of 197 frames. Still short of the max by 59, but with seven different possible partial gib animations, would likely exceed it.

As for level editors, I have tried TrenchBroom and really enjoyed it, but my PC does not agree with it. Maybe a future release will be more agreeable. A new map by Skacky called Conference of the Shamblers used TrenchBroom, and I was impressed at the detail the he turned out using the editor, despite how simple it's interface looks.

I like how JackHammer looks and will download and try it out. I want to dig into Radiant as a primary source of mapping and shy away from Qoole. I do like to have several editors available on my PC, as a collection of sorts I suppose.

Thank you for the input Seven. I will likely go back and determine the cause of the player model problem someday soon, but for now everything appears to be running smoothly.

[Dutch]

Did some custom modeling for the Health Box (25) using Blender, Wally for texturing, and qME for Quake size ratio determination. Thanks to MadGypsy for his pointers on properly unwrapping the UV. Made a HUGE difference.

EDIT: did some minor polishing since these pics to lessen the difference in color contrast.



Pic of it in the shadows. No more glow-in-the-dark .bsp model.



Blender render. Nothing fancy, still maintained a low poly count but gave the box some extra depth and angled geometry for detail. This is my first successful Blender created model for Quake.



On a side note, I'm slowly but surely ironing out the mod for vanilla engines. It runs great in QuakeSpasm.

[Seven]

Hello Dutch,

Due to the fact, that this thread is growing quickly, maybe post 2 or 3 clips and/or pics in your opening post.
I see that you linked your youtube channel and a screenshot page, but maybe add your personal favorites to that post would quickly tell the user what it is about.
People love to watch screenshots (they are too lazy to read text ).


Your health box doesnt seem to fit into your mod properly. It is very clean compared to the dirty, rough, harsh (I do not know the correct english word, as it is not my mother tongue) Quake world.
Especially your mod, which is gore-driven.
Try to make it look worn. Also blood splats would fit. Hopefully you know what I mean, hehe.


Good to hear that it runs robust in Quakespasm now.

Best wishes.

[talisa]

have to say i agree with seven about the ammo-boxes.

they look to bright and almost clinical-ish cuz of how bright they are and stand out to much in the world of quake, cuz quake is very dark and gritty.

im also getting a bit of a quake2 feeling with those ammo-boxes. they kinda look more like something that would fit into quake2 rather then quake1

what mainly looks to clean and clinical about your ammo-box is the white on top.
perhaps try making the box as a whole more darker and grittier looking and make the top another color?