I (think) I understand:
~WorldCraft.
~Qoole.
~TexMex.
~Pak Explorer.
~IrfranView.
~QuakeViewer.*
~Quark.*
- Still a lot I don't know about these tools.*
I don't understand (at all):
~BSP.
~ED3D.
~BreezeDesigner.
~MilkShape3D.
~QuakeC.
I've mispent quite a lot of energy recently trying to bring together code-spec's, tutorials and software to be able to make a decent contribution to r.siska's Mod (gotta work out the copyrights/lefts and workout a finalised look and feel for the Mod yet) I'm not happy with 2 things at present I was expecting neither to be quite such hard work learning how to do: stop a portal/gate from being able to stick to a brush given certain values & to make the portal_gun itself a little easier on the eyes. I've seen the code but couldn't understand what values to use, tried everything I could think of and got no-where. I tried to re-write the code ...no good, so I tried my hand at re-texturing the gun ...grabbed the texture ...made it pretty ...then realised I was using colours outside Quake's pallet, aquired the Quake pallet and will try again on another date. Right now I am very tired and stressed.
zzzzzzz
>using colours outside Quake's palette
You could try an advanced engine like darkplaces - override textures eliminate the palette limit issues.
Darkplaces does this with .tga files. The file should be a copy of the skin (or made first then copied over an exported .bmp of the skin and imported back into the mdl.)
If you have:
progs/portalgun.mdl
The override skin is named:
progs/portalgun.0_mdl.tga
"0" is for skin 0, the first skin. For a model with more than one skin, you increment the number to match the skin.
The tricky part of this is having the override match the original skin in such a way as to make the model look good with it.
What I like to do for a new custom skin is use quake model editor to paint the skin vertex & lines onto a temp skin, export it to .bmp, make a 32 bit tga from that, scale it up somewhere to 2x or 4x, create the fancy skin for the override, then shrink that back to the bitmap res., paste it onto the .bmp and re-import it into the model. This way the skin in the model and its override match.
For the standard maps and models there are many re-texture resources.
Without overrides, there are two palette tricks:
You can either, take the custom skin (open in gimp or whatever), convert it to a 8 bit indexed color map (if not already there) and load the quake palette on to that. You might have to run a search for the palette file. I have one called quake.pal.
Or - if that is not favorable,
Open the model (in something like quake model editor) export the skin to bmp, open that in gimp or some such and cut and paste the custom skin over the exported bmp.
Both methods convert colors slightly differently in my experience and one probably looks better. I usually use the second because its faster / easier, and since I'm using an override the native skin doesnt matter as much.
>stop a portal/gate from being able to stick to a brush given certain values
Would this happen to be things like doors & plats that move, or maybe monsters?
This can easily be handled by traceline() builtin and I have that example - I recently redid the original q1 portal gun from '97.
Or are you trying to stick / not stick depending on brush surface?
This can also be done with a darkplaces builtin.
I'm just helping R.Siska however I can, made half of an opening level which at this point he's only seen with original quake textures; I want a campaign at least as long as the shareware version of Quake.
Is the portal gun code the same thing; evolved from KQP to you to R.S?
I've been trying to find a list of the patents and copyright protections on Valves Portal to see how we can at least try to cover our butts. This has been a fruitless excersise. All I can think to do is re-name the whole project "Gategun" and aviod words like "testing" ....but if this is based on the code from KQP then valve can get stuffed as far as functionality
goes, then its just a matter of models, textures and maps.
I was hoping I would be able to take a brush (a wall for example) and tie that brush to an entity, change that entity from 'func_door' to the custom entitys name by just typing that in and setting a value of either 'portalproof' or 'ass_portalproof' but working with anything customised other than maps and textures using Qoole, WorldCraft and TexMex is completly alien to me.
Siska's been clear with people over at inside3D that he wants it to be able to run on DosQuake; I've been testing/tweaking lighting and texture alignment in winQuake out of conveinience. The portals themselfs have a graphical error in GLquake, I don't really understand why though.
Question: Should I use a C development suite ...I've just been looking at (and failing to re-code) files in notepad++ as I would mySQL, PHP etc'.
>campaign at least as long as the shareware version of Quake
Unless you are planning on some very basic levels - this will take some time. Theres a reason games these days are built by teams...I miss the days when one person could develop a game in a few months.
I might offer a level once I understand the overall project. I can bang out levels pretty quick.
>'func_door' to the custom entitys name by just typing that in and setting a value of either 'portalproof' or 'ass_portalproof
Doors are one way. There are a few ways to do this. I would try a touchable custom trigger field - start the portal and if it touches the trigger field, the fields quake c shuts it down. That would be a breeze as long as the startup portal has a touchable entity (i.e. has a model assigned to it.)
A trigger field with custom qc to close the portal is the easiest way I can think of - could be placed anywhere in a map you want to block portals.
>Is the portal gun code the same thing; evolved from KQP to you to R.S?
This is a video of the original quake 1 portal gun: Moddb.com
from this resource: Gamers.org - portal10.zip 01-Apr-1997 16:00 225k
download: Gamers.org
I can verify that too - I made a quake compilation cd back in 97/98 and that was on it!
I used that for my mod and added a few flavors.
The original there just targets a wall and tries to "bore" a tunnel to the other side - if it finds open space it opens a 2 way portal.
I've added the 2 part portal and some other cool modes.
When I've got the feature videos for the alpha release done, I'll make sure you get an update.
>patents and copyright protections
Since that portal is documented from 1997, I dont think valve would have much of a case against it. Not sure what they might say if you add functionality like theirs. Though, I have yet to play portal (got it when it was free) so I feel pretty confident about my code. And the fact that not many companies (besides iD who own it) are really interested in what you do with a 16 year old game system...
>DosQuake
I guess to run on older hardware? I was trying to stay operational under glquake, but I've recently given up - been seduced by all the fancy features in darkplaces.
>C development suite
I have a customized scite package I made myself. There is also this:
Freewebs.com
If you linux, I could send you my custom scite properties, handles qc really well. You might be able to just plug them in.
Single-player length: I'm hoping that between people that come on board; once the functionality is there that folks would converge on the design aspect and pul together to make a campaign as long as Quake's shareware, otherwise I'd just do a mini-campaign of four or more levels with 4 'test-chambers' in each.
'func_door' is the part I was trying to replace with 'portalproof' with a value of 'ass_portalproof' (and visa-versa, neither worked).
-Also want to make a 'splash-screen' or 'console-background' for the mod, no idea how to do that.
ATM the portals are blue and orange ...that will have to change.
Darkplaces hates my computer, I can run GLQuake but DP gives me 1 frame every other second ...seriously.
I have Ubuntu on a USB drive but I'm very new to it and got far more interested in QC than learning a new OS, didn't want Ubuntu ..wanted any GNU/Linux but Ubuntu as the hardcore Linux boys hate it for x, y and z reasons and I figured ...lets give the other cats a download first ...Fedora wouldn't install and openSUSE crashed on install, I wish people were still working on DamnSmallLinux being that a 50MB OS is a beautiful thing to behold but sadly I had many problems using it; so I got Ubuntu ...at least I got the CompizCube working. :)
~I've been off the coding and mapping for a few days as my headspace is a bit of a mess ATM, not sleeping etc' but I have every intention of seeing this mod through. :)
>Darkplaces hates my computer, I can run GLQuake but DP gives me 1 frame every other second
It isnt darkplaces. This is your video hardware and its driver.
If I had to guess I'd say your hardware accelerated video is being emulated by software. Thats the most frequent cause of < 15 fps.
Could be a mismanaged driver, not having the native card driver (windows likes to install generics - at least it used to), or (if not nvidia or ati card) you dont have the hardware accel support in the card.
If your card is recent-ish and supports hardware accel, darkplaces should run. Have you tried and older version?
And also darkplaces has tons of config options for all kinds of hardware based stuff (the stuff that made tenebrae engine the bane of powerful video cards [at the time] all over...)
>Also want to make a 'splash-screen' or 'console-background' for the mod
The file you want to setup / replace is:
gfx/conback.lmp
(the native one is under quake/id1/gfx/ once un-packed.)
The new engines make it easy to replace, but for the old stuff, you will need the lmp manipulation tools. And...none of the tools I have installed seem to do that.
Gamers.org
I suspect you want the lmp2pcx & p2lmp stuff.
Those will be dos tools - dosbox will and wine (should) run them if you dont win.
And as with the skins, I'd either convert the native conback.lmp to pcx (prob. the best option) and edit that, or make sure the pcx you have already has the quake palette on it.
And graphics manipulation software to edit the pcx too.
Be aware of dos loaders like CWSDPMI.EXE - one txt file mentions including it. Lots of old dos tools wont run without one of those loaders.
> many linux issues.
Yep, its a very mixed bag and for lots of hardware can be a real mess.
I also lament the lack of a serious distro without uber bloat.
11 years ago it was Morphix - < 400 Mb on the original install. One of everything and a thing of beauty. Sadly, they never kept up with it.
I ran it for 11 years tho! Damn proprietary nvidia drivers finally scuppered it - couldnt get the newer 64 bit driver to install for anything. And it sucks running under 32 bit and only being able to use 1G out of 4G of mem. Was sad, had all my tools setup, everything. The worst thing was, I had 4 monitors. 2 off an nvidia card and 2 off an MVP-pro dual chip riva 128 that can driver 4 monitors! I cant get the 4x card to work with the nvidia with the new OS drivers. GRR.
As for the tiny OS type linux - rarely are they ever geared for typical uses.
Like running hardware accel video apps.
I like debian - because of how easy apps can be installed with apt-get. I've thought of trying gentoo (installs everything from source) but like you dont feel like spending 3 months of spare time working into a new OS.
I'm using crunch bang. #! - I wont recommend it tho. Most config has to be done in txt files, not for linux neophytes at all.
If you ever do look around, this is a good site:
Distrowatch.com
You can run custom searches.
Don't really understand the advantages of using Qcide over Notepad++, could you elucidate?
>advantages of using Qcide over Notepad++
If notepad++ highlights c syntax and shows you the .qc files in the file select dialog maybe not much.
I know that scite hightlights a lot of programming syntax and allows you to "fold" (collapse) between matching braces. Though I never use the fold option.
If that qcide was done right (and I've only used it once or twice so I dont remember) it should have syntax highlight for qc commands. (Which may not differ from c syntax at all - just remove the extras qc doesnt have...)
I've thought a few times of adding the quake engine builtins to the syntax hightlight list, but like you I'd rather work on the mod than tools.
The big deal with the qcide & scite is being able to run the compile tools from the editor. Though I also dont use that feature either. I have a custom compile script that copies progs.dat to the run dir and the package build dir.
I find it nice that scite allows you to use regular expressions in search & replace dialog. And things like \n \t. Dont know if notepad++ does that, though I suspect you might not use regex very much. Kind of an old school unix admin type of thing.
Whew, final reply...
>func_door' is the part I was trying to replace with 'portalproof' with a value of 'ass_portalproof' (and visa-versa, neither worked).
I suspected you were doing that.
Because func_door is a map spawn function. This what it means:
If you open a .map file in a text editor and go to the bottom past all the map brushes - you will see a bunch of:
{
"classname" "item_health"
"origin" "1056 1104 70"
"angle" "0"
}
For any entry like that the game engine takes the classname string and searches for a matching function in quake-c. "func_door" is in doors.qc and item_health is in items.qc.
When (if) it finds that function it assigns the other values (along with the classname) to a new quake entity and calls the function with the self pointer set to the new entity. That is how all the stuff (like health boxes) are loaded on the map by the engine, and how quake-c allows you to control what appears on a map.
So to make the thing you want you need in your quake-c somewhere:
void() portalproof =
{
};
But there are a few caveats for this! Doors, plats, func_illusionary, etc. are all bsp models. This means the map brush assigned to them (open a map with a func_door, and find one - the sub-entity has [should if you want to see & interact with it] map brushes in it) must be linked into the world on map load. The func_door code does this. And it is deceptively simple.
self.solid = SOLID_BSP;
self.movetype = MOVETYPE_PUSH;
setorigin (self,self.origin);
setmodel (self,self.model);
That is how the door turns its map spawn entity brushes into a solid movable surface.
You really dont need all that - just a way to detect if a portal is being opened in front of a given world brush. It is more of a trigger situation.
Yeah, its sounds simple when said like that.
Triggers are invisible and call a touch function when a model touches them.
There are a few tricks to using them too. (Like everything on a map...)
I point this out because the existing triggers probably wont react to a portal opening model (they are geared for players & monsters) without some massaging. A custom trigger would have to be coded for this.
Another thing about doors, etc. is the tricky way map editors respond to them - allowing a brush set to be loaded into the sub entity. And this is controlled by the QUAKED description the editor references.
That will also affect your portalproof in allowing you to give it map brushes like doors.
OK, so I'll want to hold on to Qcide for if I want to edit progs.dat, but given that I can change the colour syntax parsing and have green/orange/grey/red text on a black background really saves on eye strain.
Thanks so much for helping me understand how Quake deals with moveable brushes, thats quite an eye opener.
ATM I've woken upin the middle of the night, so when I feel less crappy I'll have another crack.
Thanks again. :)