News | Forum | People | FAQ | Links | Register | Log in
Q1SP Arcane Dimensions Dev Kit
All the Download Links are on this page!

I don't want Arcane Dimensions to be constantly updated anymore, it will just end up being a complete mess if everyone keeps patching stuff. I would prefer if everyone downloaded the dev kit and just make their own MOD instead!

So here is the Arcane Dimensions Dev Kit in super trimmed down (@14Mb) format! The assets have been split into 3 flavours, Vanilla (Just id monsters), AD+ (New+Quoth+RRP) and Hexen2 (Copyright nightmare). The links are all on the above web page link.

I do plan to keep this QC base up to date every couple of months with a new zip file. If anyone has any bugs, problems or feature request then please explain yourself (fully with examples) in this thread.

PS. All proxy server trolls will be ignored!
An Idea 
If you plan to keep the QC updated, maybe it would be useful to set up a repository at github that people can fork and submit pull requests to? 
+1 For Repository 
 
Damn, Maybe I Should've Waited... 
..for this to be released before i started borrowing code from 1.50 for my own mod

Thanks Sock, great Christmas present! 
I Wanted To Ask For Quite Some Time 
What about the license? Aren't you supposed to include COPYING for something licensed under GPL? 
Good Call Sock. 
 
Github 
If you plan to keep the QC updated, maybe it would be useful to set up a repository at github that people can fork and submit pull requests to?
I can understand this being useful for coders, but this devkit is really aimed at level designers, who just want to download something in a zip, create a new MOD directory and load maps.

I don't mind helping out with updates to the devkit, I would prefer this to everyone trying to patch AD. I really want everyone to move away from AD and now explore their own MOD ideas. 
GPL License 
What about the license? Aren't you supposed to include COPYING for something licensed under GPL?
Anyone who uses the AD QC for their own MOD has to release their source, its a GPL license. I have specified this at the bottom of every readme file of AD and devkit.

The QC files in this MOD are based on 1.06 source files by ID Software. These files are released under the terms of GNU General Public License v2 or later. You may use the source files as a base to build your own MODs as long as you release them under the same license and make the source available. Please also give proper credit. Check http://www.gnu.org for details. 
Melee Golem Bug 
Golem Crashing QS - http://imgur.com/iH98UpB

The QC crash reports are not easy to understand. That screenshot is saying a function was called and nothing was defined for it. This is because one of the melee attacks (golem_knock) is trying to a combo attack (quickly go into range).

The fix is for line 270.
if (self.enemy.health > 1 && !(self.spawnflags & MON_GOLEM_MELEEONLY))

The devkit has this fix in the progs. If you have any other issues, post in this thread. Also I highly recommend you move away from AD directory, download the devkit and create your own MOD directory instead. 
Player.qc Bug 
Single-shot weapons (like SSG) have been broken for a very long time. Symptoms: if you release the trigger at the wrong time, the weapon's animation will loop again without actually firing; during continuous shooting the muzzle flash frame comes too early.

I see what you mean, its not an easy bug to find as you really have to hit the reload at the right frame. Also harder to spot on QS because of the gun position. I will do some more testing and if this does not break anything I will add this to the progs.

Thanks for the qc and explanation, it certainly makes it easier to understand the bug. 
Megahealth 
I was recently pretty surprised to discover that the "picking up two or more megahealth packs in a row" bug is still present in AD.

Can you give more details? 
Maybe I'm Overlooking Something 
But don't we need the AD WADs? There are no WADs included in the kit. And maybe I'm just spoiled by Source engine FGD's, but when I use the AD patch 2 FGD in JACK, most of the entities are represented by colored bounding boxes instead of a model or icon. Is this just how it is for Quake mapping? I'm used to virtually all entities having their own model or icon to represent them. 
Respawning Megahealth 
Is this intented to be this way. If I place respawning megahealth somewhere, it doesn't start counting to becomes pickable again, until player's hp is 100? In my scenario I wanted to keep player's health higher than 200 and also if it start counting these numbers just after HP is back to 100, it might change the way I designed one fight to be, player eventually takes some damage, and I wanted to balance that situation by giving megahealth just enough to keep HIM alive and not to die on couple mistakes right away. 
Megahealth 
Can you give more details?

When you pick up a megahealth, you receive an inventory item that will gradually "rot" you health back to 100. Then it is removed.

When you pick up a second megahealth while the first one is still active (health > 100), you receive a second inventory item that will also "rot" you health back to 100. The result it that your health will degrade twice as fast. The more megahealth packs you collect, the faster your health will degrade, all the way back to 100.

The fix is somewhat complicated by the behavior Newhouse mentioned - megahealth is supposed to respawn when its "last user" drops to 100, so all the inventory items need to be in check. 
@sock 
Thank you for implementing the melee only Golem.

I almost have the "storyboard" level(area) finished that will use this for the start of the episode.

Also I highly recommend you move away from AD directory

Will do.

Again thanks... for everything. 
Mh 
mh respawn times is considered a feature in quakeworld - every now and then he pops up and gives d3d advice.. err.. wait... *cough*.
but yeah, players having control over when the mh respawns so they can try and time it to respawn at the same time as other items on areowalk is a thing.

but yeah, vanilla mh logic:
ongrab = {
other.health += 100;
while (other.health > 100) {
other.health -= 1;
sleep(1);
}
sleep(20);
regeneratenow();
};
so the respawn time depends upon how long the player can keep their health above 100. and if you get 3 or 4 megahealths then it starts to rot away really really quickly.

on the other hand, if you're designing a fight where the player is sure to be taking sustained damage then its imho more interesting if the player has to wait for his health to drop below a certain threshold before he/she grabs the next mh in order to avoid dying due to having no health while there's no mh powerups thanks to them all being on cooldown ater rotting away really fast.
but yes, the (vanilla) mechanics do seem a little buggy. 
This Is Awesome 
And also a great idea to split the devkit assets into different tiers.

I was dreading having to stomach a bunch of "unofficial community patches" of the main AD mod, but this will neatly avoid that. 
@dwere 
More details:

Player is on top of mountain, wizards shoots fire balls at him, and player needs to dodge a lot while trying to kill them all. But since I know not every player is as skilled, some people take more damage than the others. That is why I thought it would be a great idea to place there respawning mh, but wasn't sure how it actually works.

Now thinking about it, this is actually a lot more interesting that you have to wait so your hp goes back to 100, after that mh (starts counting) respawns after some time. So those seconds will be extra intense. 
 
To be honest I'm not sure I understand the purpose of "everyone [moving] away from AD" to the devkit. For a level that just uses AD entities without adding anything new, working from the AD directory seems ideal for both player and mapper because, like Quoth, you're just dealing with one mod directory. If I'm understanding this right, it seems like you're saying it's better for mappers who want to use AD content to pick what they want, and repackage it in their own mod directory for their map? Honestly this seems like an unnecessary hassle and a bit of a waste, if we're going to end up with the same assets spread over many different folders.

As for "community patches," you say yourself you plan to keep the devkit updated, so I'm pretty confused there. Couldn't the same stuff be included in official patches for AD itself?

Maybe I'm dense so help me out here! 
 
If I'm understanding this right, it seems like you're saying it's better for mappers who want to use AD content to pick what they want, and repackage it in their own mod directory for their map?
It's not how I read it. I think it was more addressed to people like OTP who released an unofficial patch for AD. That said, I understand Sock's motivation (not allowing a mess of forks) but AD still needs a few things patched. 
Missing Wads 
don't we need the AD WADs? There are no WADs included in the kit

The WAD files are textures only, these are something you have to sort out yourself because it depends on what texture theme you want.

I recommend you download the wads from Quaddicted. There is even a preview images for most of the texture sets. If you want textures from the AD maps, then you will need to use TexMex to extract them yourself and save them as new wad files.

And maybe I'm just spoiled by Source engine FGD's, but when I use the AD patch 2 FGD in JACK, most of the entities are represented by colored bounding boxes instead of a model or icon. Is this just how it is for Quake mapping?

You need to setup JACK to point to your mod directory where you are developing your stuff. All the paths in the FGD point to the progs directory which must exist under your mod directory. 
MH By Design 
If I place respawning megahealth somewhere, it doesn't start counting to becomes pickable again, until player's hp is 100? In my scenario I wanted to keep player's health higher than 200 and also if it start counting these numbers just after HP is back to 100

That is how the MH works, the MH entity is the thing that counts down, it cannot respawn because its busy counting down the player health. If you have multiple MH then you have multiple entities taking the player HP down! If you want to give the player health use the trigger_heal entity. You can reset if you want more health. 
Double Rot Time 
When you pick up a second megahealth while the first one is still active (health > 100), you receive a second inventory item that will also "rot" you health back to 100. The result it that your health will degrade twice as fast. The more megahealth packs you collect, the faster your health will degrade, all the way back to 100.

It sounds like you want the megasphere from Doom and that is fine, but then you should design a new item, not change the existing one.

I know some mappers do the multiple MH thing in a row, but not many. I don't want to make the MH overly complex, I like the id design, is fine for 99% of mappers. There is also the trigger_heal if mappers want to keep players topped up during combats and there is also re-spawn on all standard health packs. 
Slow Changes 
Thank you for implementing the melee only Golem. I almost have the "storyboard" level(area) finished that will use this for the start of the episode.
Email me if you have other requests, it will be quicker than waiting for replies on forums. 
Dependancy 
To be honest I'm not sure I understand the purpose of "everyone [moving] away from AD" to the devkit. For a level that just uses AD entities without adding anything new, working from the AD directory seems ideal for both player and mapper because, like Quoth, you're just dealing with one mod directory

If you are just creating a map and not wanting to change anything about AD then indeed it is fine, just release your map as a dependent of AD. The devkit is aimed at people who want to change the mod for their projects and feel the need to patch AD for the community!

I am trying to avoid community patches, lack of testing and broken setups because everyone is going in opposite directions. The AD team did a crazy amount of testing of all maps and I don't want to see their hard work broken by unofficial patches.

As for "community patches," you say yourself you plan to keep the devkit updated, so I'm pretty confused there. Couldn't the same stuff be included in official patches for AD itself?

Unless there is a critical bug then AD should be left alone. I am patching the devkit for people who want extra features or minor fixes. Ultimately mappers should be taking this opportunity to get into modding themselves. Just like Rubicon2 and RRP, make your own vision! 
Megasphere From Doom 
Megasphere doesn't rot, among other differences. So I'm not sure why this particular comparison.

Regardless - this is your creation, all I can do is suggest. 
Critical Forks 
I understand Sock's motivation (not allowing a mess of forks)
People can fork or create their own mods using AD as a base as much as they like. I have no issues with that, as I said I just want the original AD mod to be left alone. Either make maps for it or create your own mod, its all setup ready to go with the devkit.

AD still needs a few things patched
like what critical stuff are you talking about? 
 
Thanks for the clarification, sock! I am indeed dense hehe. 
 
Nothing critical, just stuff like the statue gibs being bloody, for example. It would have also been nice to make some parameters user-controlled. I'm notably thinking about some particle effects like the grenade explosions that prevent the player from seeing the action or the footstep volume that you reduced slightly too much IMHO. 
 
The statues are squishy on the inside deliberately. 
 
Think of them like Pyura Chilensis (google it, but trigger warning: gross), which is a million times Quakier than some Harry Potter-esque magical rock monster 
Trigger_sky 
Would it be cool for longer maps to have a trigger_sky entity, similar to trigger_fog, that could dynamically change the skybox during the level?

Kind of give a sense of day and night time passing. Could be neat if implemented correctly? 
Stuffcmd 
Maybe?

I think it could be done but not sure if different engines use different commands to change skies 
 
I think it could be done but not sure if different engines use different commands to change skies

quakespasm uses 'sky foo' as a console command that persists only for that map, fte+ezquake+fuhquake+etc uses r_skybox as a cvar, dp has a loadsky command, markv has a cl_sky cvar (which only works on level changes), while the fitzquake protocol has a svc_skybox thing that will crash any clients that don't support it.

so yeah, good luck with that. :P 
#33 
lmao 
Although 
I suppose you could stuffcmd all of those commands to cover all engines and then follow with the "clear" command so the player doesn't see all the "unknown command" messages. Ugly as all hell, but we ain't going to get a standard on this across engines. 
Sure You Could Do That 
And then the engine takes a shit on player immersion by hanging for several seconds when loading the heavy TGA files. 
#36 
Load up AD, then drop the console and type bind: bind j "sky moonhigh_", load up a map and walk around, while doing so hit J ;)

You'll see your post is nonsense. And I'm not using my SSD for Quake. It's only the slightest of hiccups. Defintely not several seconds and easily hideable in a level. 
@37 - That's An Example Fail 
if (strcmp(skybox_name, name) == 0)
return; //no change


If you reload the same skybox that is already in effect, the engine doesn't reload it.

It is, in fact, quite slow ... and you can experience this for yourself as follows ...

With Arcane Dimensions

Do bind j "sky interstellar_"
Do bind u "sky violent180_"

Alternately press j and u. It stutters pretty badly.

The reason your example doesn't cause a problem is that the skybox doesn't reload if the name is the same as the current one, hahaha ;-)


I'm not saying night and day transition wouldn't be cool, but some other method of achieving it would be preferred (darkening the sky? Fading in an alpha layer?)

Plus, the big thing: Why not change the lighting via QuakeC too. Would seem silly to have brightly lit outdoors with both sun and moon in the sky.

I'd like to see night and day transition. But the suggest method sucks donkey balls. 
It's Almost Instantaneous. 
When I use "loadsky moonhigh_" it's a snap of my fingers quick. That's on old WD Green drive and green is not known for going fast. 
..and That's Not On A Non-skybox Map. 
BUT like Baker expressed, not the best method suggested. 
Err.. I Meant Loaded Skybox On A Regular Quake Sky Map. 
DoH! 
@#38 
I'm not using the same sky man... c'mon! And I have the same experience as xaGe posted above. It's fast, really fast.

I've read enough of your posts not to doubt your technical knowledge in the slighest, but either something isn't right for you or we're just oddly lucky.

As far as lighting goes... if you mapped with this in mind, you would naturally create the lighting that was suitable for each area. Sky's are rendered fullbright perse right? Just like liquids? I don't see a problem. 
Dual Bind And Alternating... 
I see it now. It's a pretty hard hit and the sound stutters as well. Yeah, not good at all.

I guess since the 6 violent180_ .tga files weigh in at 21Mbs vs moonhigh_'s at 6Mbs I just got lucky with my selection. 
 
I would suggest you pursue your idea and then if others thinks it looks convincing ...

And you have a working prototype ...

Someone might come up with an idea of how to make it fast or a way to devise an awesome system for it.

Also: You might check out this https://quakewiki.org/wiki/lightstyle

metlslime once suggested a method for QuakeC based night/day transition for altering the lights.

Your idea has merit. And making a prototype IS the right thing to do.

If a decent prototype is made, even with a bit of stuttering, usually someone can look at the prototype and say "Here's how we can do this fast and make it easy on the mapper!" 
@Baker I Understand You Completely 
I almost have the "melee only" Golem prototype map finished ;)

Advice taken. 
 
Isn't it practically impossible to switch a light (for day/night transition, or otherwise) that covers a large area, unless it's almost the only light? I remember trying to do it in an unreleased map and it only took a few possible lighting combinations before I started getting lightmap bugs. 
 
There is a thin line between ...
1) "almost impossible"
2) "What do you mean it's impossible? My map already does that!"

Most of the elite mappers enjoy doing "almost impossible" things.

Probably for the same reasons QuakeC coders enjoy doing "almost impossible" things ... and that engine coders enjoy doing "almost impossible" things. 
 
four lightstyles per surface. big lights mean potentially more styles, means more surfaces will need more than 4 lightstyles, means more lightmap glitches.
the biggest issue with day/night cycles is getting the shadows to move properly (without rtlights anyway), but that's probably niche enough to not care about it.

lots of lightstyle changes might also result in stuttering.

whether an engine stutters or not when a skybox changes depends on that engine's caching, threading, tga performance, etc.
the more interesting issue is that you can only really change it when the player isn't staring at it, which should mean the engine also has a chance to spread the load over a number of frames to reduce stutter. 
 
Should I use this pack, if I only want to change some values? Like I think Pyro should have longer range like in Quoth mod. That is all I want to change at the moment, everything else seems just fine to work with. I'm too lazy to start "creating" bigger, and mostly just want to work with what you guys have already shared.

When I'm going to change couple values, and publish my maps/episode in the future. do I need to somehow patch modified files, it would be stupid to load entire ad mod in the same package? Is there way to point out, use this file instead, but when people play normal ad mod my files doesn't affect on those?

I'm not aware of technical stuff, and that is why I'm asking about it directly. Don't want to waste time on not knowing what is possible what is not.

Thank you for sharing this dev pack, if that is what I really need. 
No Patches! 
personally i would be prefer no patches and things like that
include the whole thing bundled
that can be an extra 36 MB if you decide to include the devkit patch1 & patch2 or 28mb if you don't use hexen II stuff 
Flame On! 
Should I use this pack, if I only want to change some values? Like I think Pyro should have longer range like in Quoth mod

If you want to change the pyro attack speed then you will require a different progs file, which means you should use the devkit.

The AD pyro is based on rubicon2 code, which is why it works different to Quoth. The speed/distance of the flames are linked to skill level (250=easy, 300=normal, 350=hard, 400=nm) and the debuff flame damage is skill based as well. Changing the pyro setup will have to be tested for all skill levels. 
Modern Day Bandwidth 
When I'm going to change couple values, and publish my maps/episode in the future. do I need to somehow patch modified files, it would be stupid to load entire ad mod in the same package? Is there way to point out, use this file instead, but when people play normal ad mod my files doesn't affect on those?

The AD devkit is all about freedom to mod however you want. its a base for you to play with and gives you a set of mapping tools to create maps easier and access to much more flexible functions.

This is essentially what Quake modding is all about, there are no closed source files, its like how rubicon2/rrp is done. You create your own mod package, it will install much easier with QA injector and only require one game directory. Worrying about download size is pointless nowadays, most people download gigabytes of data all the time.

Either work with the existing AD progs/assets or just do your own thing! Learning how to make a mod might inspire you to create your own mod from scratch one day! 
 
If you're really worried about your derivative mod's download size, I don't think it would be that hard to look at every asset you're using and then just remove all the ones you're not from your package. Depending on what that stuff is it could definitely cut down on file size. 
@sock 
Thank you very much. I will not worry about the size of my package then. I will start working on Pyro soon again, and also test it on all skill levels. 
 
What is the situation with models like misc_lightpost.mdl? Are they not included in AD's devkit because sock didn't have permission to?

I'm asking because I'm trying out tweaking the QC (I made a grunt with 3000hp, it took a minute and ten seconds to kill with the shotgun and axe!!) but I had to copy the missing models from the 1.50 release directory to my devkit directory to get my map to load. 
Minor Corrections 
Hi, just noticed a typo in the .def file - for func_breakable, the key to override the impact direction should be "angle", not "angles"

Even more minor, but the behaviour of the angle key for func_breakable is described in a paragraph, but it is omitted from the "Breakable entity details" key listing, so it might be missed by someone just skimming the key listings. 
#55 
Was about to ask the same question but with misc_smoke.mdl

The misc_smoke entity is in the documentation, but the model is not included in the devkit.

Is there a permissions problem with using misc_smoke.mdl, or was it just an oversight? 
Permissions 
The permissions on misc_smoke.mdl can be found at https://tomeofpreach.wordpress.com/about/

... offered without licence terms or conditions for use in Quake

So no problems there. 
Cool, Thanks 
 
Bare Bones 
What is the situation with models like misc_lightpost.mdl? Are they not included in AD's devkit because sock didn't have permission to?
I did not include many of the misc_ files because they are not required to run the MOD with minimum assets. Every version of the devkit has an example map which shows what assets it does support.

The dev kits are about showing what assets are required for a new mod to use the AD QC. Ideally as you use more assets in your project you will add them to your mod directory. The final AD mod included many maps which used special assets (lightpost.mdl) which are not essential.

I made a grunt with 3000hp, it took a minute and ten seconds to kill with the shotgun and axe!! I had to copy the missing models from the 1.50 release directory to my devkit directory to get my map to load
If you are copying stuff from the 1.5 directory for your map then its something to do with your map requiring unique assets. One example I can think of is the misc_smoke entity loading a special model. The devkits are really just the bare bones of AD with no bells and whistles! 
 
Yeah, my map does use some of the misc_ models, like the lightpost I mentioned. Hence me wondering if it was allowed for me to include them in something released based on the devkit - I remember you stating at points that it was tough to get permission for some of the things in AD, and I didn't want to end up using things I didn't have a right to.

Of course, if I actually want to release a mod using the devkit foundation, I probably ought to have more maps and models of my own anyway... 
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.