Quakeone.com Modding Bonanza

[Spike]

using a tool that can easily pull up documentation on builtins or whatever is never a bad idea. it will save time in the long run.
encouraging people to use notepad right from the start is like encouraging them to write code one handed and with one eye covered - awkward and uncomfortable.
jumping in at the deep end will indeed make people learn, but only if they miraculously stick at it.

now, I'd like to pimp fteqccgui as the best tool ever... but I cba to polish+package it properly. :s
on the plus side, I have finally stopped using notepad for QC, hurrah!

[R00k]

Spike can you be bothered to make fteqcc built into the engine so we can code in immediate mode like a commodore64 and just type RUN in the console?

That's on my todo, that and a built-in screenshot previewer!

[golden_boy]

A word about warez: Files produced by, say, a warezed 3dsMax might contain things that betray their warezy origin. Another reason to use free tools. Clean conscience + never worry.

[Dutch]

My personal experience in learning QC is actually a combo of what Gypsy and GB are saying.

I started with the unclean, uncut version of Quake 1.06 source. I made a few changes, pissed around with some things, learned a little bit on my own and a lot online when the need arose.

Doing all this kept me curious and wanting to dig deeper. That's when I did what GB is saying. I picked up the Scratch tutorial on Inside3d and built QC from the ground up (the basics, that is). To further my understanding, I poured over other people's code (FrikBot was a big one).

Having a little bit of background, I then re-visited the unclean version of 1.06 and went through EVERY single line of code, re-organizing it into separate files that made sense all while adding my own, understanding every little bit of code that I could. A few things are still unclear to me (for example, just the other day Spike gave me a little lesson on the relationship between FindRadius and while loops for locating more than one entity), but if there's something I don't fully understand, at least I know where to find it within the code, how it relates to portions of code I do understand, and what questions to ask to find a solution.

So where you start depends on where you want to end up in my opinion. Do you want to touch up small areas of Quake, heavily modify Quake, or make a whole new game? That's probably the first question you should ask yourself if you're just starting out.

It's also never bad to have more than one project, which you can then combine them later on down the road. Implementing several different projects into one will really increase your understanding, at least that's how it's been for me.

[golden_boy]

Spike can you be bothered to make fteqcc built into the engine so we can code in immediate mode like a commodore64 and just type RUN in the console?

I'm pretty sure it does that already. Just type "compile" in the console.

[RL Clown]

Thanks again G_B, I commend your efforts here. You rock! I wasn't sure what to expect from your first News article but holy shiet. If I expected bologna on two slices of bread, I ended up with a T-Bone steak slathered in A1 sauce,and for that I thank you again. Now to find a fork and steak knife

That's a great way to put it! Thank you for your answers (people)! From my understanding, modding is an adventure. I can't wait to pack my bags and start hiking!

[ArrrCee]

We have discussed this before MG. We'll have to agree to disagree.

Programming and housebuilding are not compareable. It is entirely possible to write an entire Quake mod in notepad without any trouble.

I get that you want people to use your software, but there is really no point in starting this discussion again.

Well sure, Notepad is fine and dandy and can get you there but I would also suggest downloading sublimetext or Notepad++ to start with if for nothing else, the styles! Setting colors for all of your code is so useful it's hard to go back once you use it!

Plus, Notepad++ is free so why not use it?

Good post btw Golden_Boy, don't think I'm picking on you -- just one coder to another. =)

[MadGypsy]

Programming and housebuilding are not comparable

Sure they are. Both require knowledge, skill and tools. The tools are the focus here and notepad is a handsaw...or maybe even a stone tied to a stick, attempting to be a hammer. In either situation you want the best tools you can get your hands on but at the same time you don't want to have to assemble the tools. That's what radiant and QC become, an adventure in assembling tools. I personally believe that the assembly part is where most people say "fuck it".

I get that you want people to use your software

None of it is my software. Your method of teaching radiant involved attempting to explain a bash compile script that circumvents the allegedly broken build menu. My method simply fixed the build menu. When I release a gamepack I'm essentially just giving you a working Q1 build/run map environment. The extras aren't all that extra - for instance, I usually include some engine and I also include pretty much every compiler. The build menu is tied to the compilers so there is no way around that. The engine I include is more like a highlight of "this is where you put the engine". Past that I included a couple of wads of flat colors and grids.

The only thing "ready made" is your ability to start mapping, not to mention that there is no actual documentation on how to write build menus or customize radiant. A trip through my gamepack can provide a lot of answers. On top of that, I know damn near everything there is to know about any file that is externally editable in Radiant. In that, you get pro code/settings. Even you know less about that than I do (I am speaking specifically of the backside of radiant). I could make radiant work with any game that has some kind of .map compiler, I don't care what game it is.

[Mindf!3ldzX]

do you include catools?

[Mindf!3ldzX]

CA+/CAx multiplayer mod tool that is, catool

[golden_boy]

@MG: no.

Using a script to compile maps in a terminal has actual advantages, such as seeing the compiler output in realtime in its natural environment. And a terminal offers a bunch of goodies on top of that. I STILL prefer compiling with a bash script. It's a lot more than just circumventing a broken build menu.

And it has another side to it: Learning to not fix what ain't broken and knowing when to not bother about some issue and just do it another way are important skills in game development. There are many roads that lead to Rome. No need to bust a leg when there is an easy way to get the same result. While you were writing build menus, I was compiling maps. I'd wager that's a more efficient use of time.

Give a man a whale, and he'll never know what fish tastes like.

[MadGypsy]

@GB - I agree with you in many ways. I just also disagree with you disagreeing with me

@such as seeing the compiler output in realtime in its natural environment

I can see all that stuff too. You maybe forget that the build menu is nothing but an xml command line and for Q1 mapping I have build process monitoring off. This means that the build menu for my packages is the same thing as your bash script. I can rewrite any bash script you create identical in the build menu and get the same results. Really the build menu does 6 things that your bash script can't.

1) Selecting customize allows you to change specific elements of specific builds without having to open a bash and find the line(s) you want to modify.
2) The build can be run straight from radiant menu
3) You = 30 maps - 30 bash / ME = infinite maps - 1 build menu
4) Multiple builds can be defined and selected specifically with nothing but a press of the LMB. These are all in one menu as opposed to misc bash files stored in random locations.
5) If you customize the build menu from the radiant menu the customized version gets saved to another location and the pointer to the default build menu is automatically changed. This means it is impossible to destroy your build menu because your original never gets touched.
6) Your bash script works on linux. The build menu works on anything that will run radiant.

For Q3 mapping build process monitoring is left on and you still get all of the specific map information because radiant is designed to report Q3map2 statistics. There is no gain from using a bash apart from learning how to write a bash/bat. Doing it the build menu way will have you modifying the same switches that you would have to in a bat. Meaning, a person still has to learn how to initiate the compilers and engine with the proper switches for their needs.

You're like an advocate for the caveman way when it has no advantages over the intended way. What if you found an old map but lost it's compile script? You'd have to spin a new script and could potentially forget what switches were used. All I'd have to do is open it in radiant and select a build. Chances are, whatever build I used is stored in the menu, ready to go.

While you were writing build menus, I was compiling maps. I'd wager that's a more efficient use of time.

Nope. Cause you are a mapper and I was a radiant modder. Your work led to maps. My work led to the ability to create them without having to fix the tool you are going to build them with. Your bash scripts help anyone using a linux machine. My build menus help everybody period.

The point here isn't for you to agree that the build menu is the way to go...it's to stop trying to pretend that it's broken or inferior to your bash method. There is nothing you can do in a bash that I can't do cleaner in the build menu cause they are essentially the same thing. The build menu is genius. These guys figured out an xml way to universalize commands over various operating systems. That's the difference here, man. Your way only works with one OS and if you collaborated with someone that isn't using linux they're gonna have a bunch of crap to do just to start, which can also lead to mistakes/oversights/errors as they convert your bash to bat.

It's a lot more than just circumventing a broken build menu

It's not broken and never was. Build Process Monitoring = false was the only thing necessary to make Q1 maps compile. This stops radiant from trying to delegate the build and allows the XML to run everything natively. That's it. That's the big secret. no BPM = regular ole compile. I can even tell you every single place you can set that var:

1) games/yourgame.game - no_bsp_monitor = "1" ~this is where you would set it if you have never started your gamepack
2) settings/1.5.0/yourgame.game/local.pref - false ~ this is where you would set it by hand after a first start on your gamepack
3) edit/preferences/build - enable build process monitoring [uncheck] - this is where you would set it within radiant

I know too much about this to continue to argue it, brother. Your way is not superior or even comparable for that matter.

@ca tools
Should I include that?

[Mindf!3ldzX]

I would want it included for the sake of multiplayer Q1 rests in the hands of r00k, a excellent multiplayer mod author. He can whip together a proof of concept in no time, thats nothing to sneeze at.

Mappers/other Stuff's that make 'new content arousal' for multiplayer quake are thin at best non existent at least?or is it the other way around?

I can't stand show and tell, I know it drives a lot of the community here but I'm to put it bluntly, ready for a new multiplayer social climate. the atmosphere is stale in multiplayer.

everything inside the atmosphere has to go except for out of box support for q1 servers (the maps being GPL'd ensure even a custom mapset with texture support thats legal is a starting point. a legal Quake is what I most desire to spend my time on and theres a niche group that suffers huge neglect thats multiplayer. r00k is Atlas, and he's tired of endlessly being forced to shoulder the globe that is Multiplayer Q1.

He's surrounded by phenomenal talent in every department, but instead we have 'read your own book' club. Everyone here has a passion for Q1, its time in my opinion we had a opensource Quakeone.com project that aimed for a common goal. While everyone still has the 'doin shit in Q1' steam, utilizing that steam rather than it just being an infinite number of individual projects, I can't imagine what kind of monstrosity of a behemoth project when propped up by the talents here @ Quakeone.com could achieve. The people here could author the next massive hit in opensource gaming, but we'd never know it until everyone wore a shirt saying 'I'm standing next to Talent,let's copulate our talents' themes and it became obviously apparent.

I was so stoked for RMQ, and the possibility it could inject a modern interest in Quake1.

Darkplaces caters strictly to a singleplayer crowd it seems rarely to benefit outside mp coop / RQ Coop.

CATOOLS.exe builds custom map-menu's for CA+ and CAx , as far as I know r00k uses CATOOLS for CAx and that is a modern supported by author multiplayer MOD.

It is infinitely important that multiplayer catch a slice of anyones attention anywhere they are willing to devote some attention TO it. I the lowly multiplayer Quaker humbly beg any modern badass of modding Q1 do that exact thing. Rally the troops, stop the flexing and taunting and rally the troops.

[dr_mabuse1981]

idk if you guys know Jackhammer:

Jackhammer: My Favorite Level Editor group - Mod DB

It already supports Quake 1 and 2, Halflife and soon Q3BSP too
Its based on VHE and also has a few Radiant features.

Plus it can show your models (MDL, MD2, HLMDL) in the editor which is
awesome.

[R00k]

CATOOLS.exe builds custom map-menu's for CA+ and CAx , as far as I know r00k uses CATOOLS for CAx and that is a modern supported by author multiplayer MOD.

Um, Thanks for the props Mindz, BUT, catools is basically a single purpose hex editor, specifically for CAx.
It searches the progs.dat for a string of characters ("lt!g") and includes upto 8 padded spaces to overwrite map names. This allows admins to add custom maps to the warplist. It only does that, no mapping. It is not a mapping tool.