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. 
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.