I found myself not motivated or even urged to replay this and I wonder why since I by all means think it is fantastic. does anyone else share this? any idea why?

I think I would like some treasures and gold and stuff. a more roguelike setup in a way. or story driven missions. here "reach the end of the level" is boring for me. it feels void of purpose. playing usually is filled with small frustrations (waking up monsters, having to retreat), maybe that is why I need a purpose here (compared to a quake map where I do not miss that (though it can be the icing on the atmosphere czage)).

--------

for the public you definitely need a "run this exe and you are set" setup. having to point it to the quake directory is ok, having to fuck with the commandline is not. quake is so damn user un-friendly by modern standards.

the remaining "hardcore" quake community is missing people who advertise stuff outside our little inbred circle jerk. the majority of those who do and the majority of happy recipients seem to want just quake with blingbling. I did some publicity forum threads for new q1sp releases but it was not rewarding so I stopped. I am now poster for the big quake group on Facebook so that's where I will focus from now on. that IS rewarding like 10 years ago. but the same applies, if it is not consumable/hooking after a second the fallout(?) is massive.

for getting bigger sites interested I think it is great to have progression threads at sites like tigsource or polycount. where people get hyped and hype themselves. if I was an editor I would probably have many things already on my Todo list or things I myself want to check out (just like I do with that certain quake website). if someone sends me a mail about his "awesome mod" I would not feel too interested if I never heard about it before. if I would see some massive public interest however, sure, I should check it out. hen and egg problem... :( on the other hand pc gamer featured that particular "cinematic" quake re-sound mod so sometimes it happens. maybe one has to play contacts. :((

seeing the awesome webgl port I am thinking that I will probably try to host that for more supported maps/mods. we need more DOers. imagine sending people to something like that instead of a zip (ugh!) with a readme (ugh ugh!) in it. 

@nitin, thousands and it is not possible with the current size of the Quake community.

@ijed, It will probably be a large zip file of stuff. I can't imagine anyone here will find much use for it because I re-wrote most of the QC (new file structure and layout) and the maps are in GTK format. (I got the impression most people here are WC)

@scampie, thanks for the support but this is the final nail in the coffin for this project. Quake is indeed dead memories, hardly anyone owns the game anymore and new players certainly don't want to buy it. (you can hardly blame anyone for that either)

@spirit, that is an interesting point, the more I changed of the game the more people expected of it. Quake is a old game at heart and the appeal is mostly about the simple pleasures of raw combat. 

thats much more than I was thinking.

One question, and I cant comment since I havent really had time to get to it yet, what happened to your thoughts around distributing with an exe and content so that it could be standalone?

Not sure it will get you what you were after in terms of a Kickstarter but surely more interest? 

@nitin, I tried the idea of using the shareware quake to create a independent version of the game but the shareware license is strict, no custom content can be run with the shareware assets.

I plan to do my final release (couple of weeks time) and include a custom engine for people to run it with. Hopefully it will be the MarkV because it is the easiest to run and install. The latest version also works perfectly with the shareware version of Quake but I am not going to get involved with distributing the shareware version.

Also if anyone has a steam account, please go to the steam page below and give a rating, it will help with the visibility on the Quake portal page on steam.

http://steamcommunity.com/sharedfiles/filedetails/?id=128234918 

We've got the name and legacy code left and for ease of testing right now we've removed any dependency on the Quake folder itself and run standalone.

This made me go "eep, eep, eep" because of Beth/Z C&D possibility that I estimate to be very real. IMO that is a dangerous road.

Why don't you (and Sock) go the way of Scout's Journey (or Nexuiz/Xonotic)? Properly remove all dependancies by going 100% original / GPL content. This means textures, models, sounds etc. from scratch of course, no more modified / remade Quake assets.

I know Sock can make his own assets, and so can the Schism team. I guess the problem then becomes "it's not Quake" though, because your new assets cannot look too much like Quake assets to avoid C&D.

SJ is lucky in that it doesn't need to be Quake. If your project is meant to visually resemble Quake, then IMHO you can't be standalone.

So yeah, there's the dilemma with having to require Quake for legal reasons but on the other hand no one owning the damn game or giving enough of a shit to buy it.

Quake mods live between a rock and a hard place. 

Just finish it as a noncommercial project, no matter how long it takes. I mean other people here are also doing mods without kickstarters. It is good and deserves to live. I'd hate to see a product of good craftsmanship die. And I can appreciate craftsmanship even if I don't really love Quake anymore. 

He said somewhere that he wants it to be in the Quake universe (I3D probably).

Recreating all the content on a high quality level and consistent style would require massive funding. No idea about Scout's Journey but Xonotic is a visual mess and at least to me not appealing. I cannot think of any free standalone fan-made FPS with great visuals at the moment. :(

Not to mention having to come up with amazing designs like the fiend, vore or shambler in the first place. 

Quake mods live between a rock and a hard place.

I totally agree with statement, at times I feel like I have gone down the same road as RMQ and hit exactly the same hurdles trying to get people interested in something I have created.

I honestly thought the shareware version would be a cool way to get people back to Quake and interested enough to buy the game but the shareware game is license locked, no custom content allowed.

A friend of mine told me I should find my target audience and suggested I look at the Quake Steam page because apparently it is extremely popular when on sale. I bought steam quake a while ago but rarely use it because it is extremely difficult to run with any custom content! This does make me laugh, one of the founding fathers of mod games Quake on steam and it does not work with mods, how ironic! :)

If anything I have learnt one very valuable lesson from this, understand what the target audience is and find a way to contact them. If the target audience is too small or not interested then move on. 

Good luck Sock, with whatever you do. 

at times I feel like I have gone down the same road as RMQ

Don't beat yourself down like that! 

It's just the code (and only a small part of it) that's still legacy - all other assets are either replaced or going to be.

If we wanted to be dishonest then we could just not mention about its origins and slap a price tag on it, in theory.

Interesting that Steam isn't enabling Q1 mods. There are also sanctioned mods for Source (Gary's mod comes to mind) that users pay for.

Have you tried emailing Valve Sock? You never know, maybe they'll be open to suggestions.

Not sure where id would stand - but you've already got a line of communication with Carmack.

Maybe worth a shot?

RMQ was a full sized game with a full sized team - and nobody being paid. So yeah, it's evolution and eventual stalling were an atypical tale.

Won't stop us from making Schism though, we've learned a lot from the mistakes there. And have a ton of content left over as well, which helps. 

Hey so I played through this before using Fitzquake Mark V, some version before the poison infighting tutorial was added (I think).

Since you recommended DarkPlaces in the Steam guide I thought I would give that a try. Fresh setup, started a new game on Hard. When I got to the poison infighting tutorial the scrag & hell knight would not attack each other.

Ran back through to get a demo: http://dl.dropbox.com/u/11690738/temp/nojoy.zip 

@JL, Not sure what is going wrong there, I will have to test it more. The Wizard and HKnight certainly don't want to attack each other, but poison infighting does work, I did a run through of S1M1.

I have other bugs with DP, original Quake skies don't work, noclip will not fly up or down, have to use swim up/down. 

I have other bugs with DP, original Quake skies don't work, noclip will not fly up or down, have to use swim up/down.

given how advanced DP is in almost all other departments i'm amazed LH hasn't fixed this yet 

I was really looking forward to the main maps.
Regardless - what's been done so far is awesome in every way and certainly one of the highlights of custom Quake. Just most unfortunate that you became a victim of false expectations - indeed, there simply isn't such a big player base for Quake stuff, but this shouldn't have come as a surprise. I do think there are more people than one would imagine (judging from the download numbers at Quaddicted), but for the most part they are a silent majority who never comment. Even here and in the other established "community" forums, often half of everybody can't be bothered to give feedback including regulars even if they've played the maps.
Not sure about this whole accessiblity thing and if it would really make that much of a difference. Something to make it easier like the Quake Injector is neat, except I doubt it can have any revolutionary or rejuvenating effects in the long run. Not to mention the people running the show are slowly but steadily losing interest unfortunately.

Admittedly, the kickstarter idea was pretty naive given this context, but even without knowing the current state of things, I think there's no way such a project would have succeeded anyway. After all, it's "just a mod" for a "17 year-old game", not something big and prestigeous like Black Mesa Source or the like.

Personally, I feel I maybe could have done more to support your course. I did mention ITS in a Quaddicted news post and also in the Q1SP thread in the Steam forums, but not as exclusive (individual threads) as it would have been possible. I even tried to contact Badboy to tell him to post about on quake.de, but on IRC and not email. The release did reach the usual places, just not farther beyond.

At any rate, it's a great work despite everything and it was fun testing it. I hope there's still a chance that some day you'll feel an itch to do some Quake work again, and reconsider doing one or both of the main maps as a hobby sideproject.

As for the bugs in DP, I assume by "skies don't work" you mean that it doesn't remove the shots? That's something I kind of made LH aware of not long ago and it may be fixed already - try the latest autobuild. The noclip behavior is the same as standard Quake - only Fitzquake and forks feature 'free' noclip movement. I prefer the latter myself, it's more user-(well, developer-)friendly, but it's not something in need of fixing per se. 

I looked at the beginning of S1M1 a few times in DP, and the sky was either a solid gray or a solid purple.

http://dl.dropbox.com/u/11690738/temp/shadows20130221155413-00.jpg

I was assuming that's what sock was talking about. 

@JL, yeah that is the skybox bug with DP. I suspect I need to download the latest (experimental) build. I don't enjoy developing with the DP engine and I plan to keep using Fitz/MarkV instead. The Steam guide is offline until I update it for a different engine.
@negke, sorry for the disappointment. 

Perhaps the sky is hidden by the fog? You can use the fog end distance to add a cutoff, otherwise it will increase to infinity, and thus solid color sky.

Try the fog command and set more parameters, then put that same set of parameters in the "fog" key in worldspawn and it will take effect, you can also do this in a .ent file (sv_saveentfile and then edit it to taste). 

Yep removing the fog ("fog 0 0 0 0") revealed the sky. 

to go standalone game. But then you would need a team to make all-new content and much more time. 

How did you go about your particle field controls in ITS?

I've got an emission system implemented that can throw sprites, bsps and models, but was wondering about better particle controls.

The main thing I'm wondering about is movement - I can just attach particles to an otherwise invisible emission, but was wondering what method you used, and if it'd be cheaper / better / faster.

I have a function which spawns a particle emitter (from QC or map entities) which is controlled via field values. Once the particle style is something I like I convert it to a prefab so it can be re-used easily.

Particles in my mod are essentially start position, movement direction and time. Here is a list of parameters I use:

STYLE : Prefab Particle style number
NOISE1,2,3 : Particle sprite file location/name
HEIGHT : Particle frames to use
VIEW_OFS : Spawning particle offset (vector)
COUNT : Maximum particle count
HEALTH : Lifespan (seconds)
ANGLES : Velocity Direction (X/Y/Z)
MANGLE : Volume - Random range from center to spawn (positive value)
YAW_SPEED : Velocity rotation (Y Axis only)
TARGET : Entity to spawn particles around (STARTING POINT)
NOISE4 : Entity to spawn particles toward (END POINT)
FIXANGLE : 1 = random 2 = circular movement 3 = rotation
V_ANGLE : extra velocity range (need FIXANGLE to work)
SPEED : Particle movement type (8=NOCLIP, 6=GRAVITY, 10=BOUNCE)
IDEALPITCH : Working distance (checks players)
DELAY : Particle Spawn time
WAIT : Particle spawn time (randomness)
PAUSETIME : When not in range of player, use this think timer

All the particles going through one function which deals with where the particles start from (can be different than the emitter), how it moves (XYZ direction) and how long it lives.

The problem with my current implementation is the constant turn over of new particles being spawned. My next version will work from a limited bank of particles (using chain field) that are setup initially and are constantly re-used. This will allow for the mod to limit the maximum amount of particles used for slower systems.

I highly recommend any particle emitter checks for the player location and adjust particle spawn rate. There is no point having active particle emitters if the player is not around to see them. 

That's interesting stuff. Essentially I need to extend my current 'effects' field to use a selection of particle types.

Most likely I'll make it two fields, one for colour and the other for size, with the additional controls of speed and so on being managed by the emission controls that already exist.

Currently I have point and volume emitter types, with additional volume 'effectors' which allow me to change the relative values of a given emission (gravity, velocity etc) or just remove them.

I can see the value of a target entity though. It's easy to see how that could be used to produce some cool looking effects, like particles being sucked into a teleport volume.

I'm using the extras mod particles as a base.

Pausetime looks useful as well - there are instances where the particle field is visible but far away.

In terms of a control to allow such expensive effects to run on low end machines or laptops without crippling the FPS I was considering a 'budget' system.

Having a single pool of total particles as you mention sounds tricky, for me at least. I'm not a particularly good coder so have to use more simplistic approaches.

The one I've been thinking of is to detect the FPS, and if it drops below 30 (or whatever is the desired value) then all particle systems would halve their output. For lower FPS's they'd lower the output further, checking once per second or so to not slow things down further.

It'll be a pretty rough and ready way of doing things, an improvement could be setting a priority for different particle effects, with purely decorative or far from any client effects being more aggressively optimised as FPS is affected. So eliminating unseen but used particles as you suggest.

Right now I'm thinking of some custom weapon and monster attack effects, presets for certain effect types like teleporters, torch smoke, force fields and a few others.

I liked the methods you used in ITS a lot for leading the player eye and highlighting important items. I see these as custom map elements as opposed to global presets, so will have a think on how best to implement them.

Probably the emission system I've already got with the improved particle controls will do the trick. 

I recommend you limit the particles from demo files by marking them in some way that your engine ignores them. Particle movement/creation bloats demo files really bad, which is a shame because they are handy for highlighting events and making the world feel more alive.

I tried to use particles to lead the player especially if there is an items that I want the player to notice. (example s1m2 - YA) It is really tempting to add loads of particles to everything but sometimes less is more visually like for example torches.

Initially I experimented with particles changing vector/direction during their life time but you can get better effects with particles in linear lines with variable time instead.

I recommend you create a good base of particle sprites (colour/shape/size) because they can be mixed together to create interesting effects.

Here is an example of torch effect I used:
else if (self.style == PARTICLE_STYLE_TORCH) {
self.noise = PART_TORCH1; // Embers - Red/Yellow
self.noise1 = PART_DOTSML_GOLD;
self.noise2 = PART_DOTSML_GREY;
self.cnt = 3; // Total particle types
self.height = 1; // All
self.view_ofs = '0 0 0'; // Bottom of flame
self.count = 8; // Should be active when close
self.health = 2; // Short Life
self.angles = '0 0 10'; // Fly up
self.mangle = '1 1 0'; // Volume (X/Y/Z)
self.v_angle = '4 4 0'; // Slight wobble
self.idealpitch = 384; // Close range distance
self.speed = MOVETYPE_NOCLIP; // No world interaction
self.delay = 0.25; // Frequent (runs all the time)
self.wait = 0.25; // Spawn rate randomness
self.pausetime = 8; // High timer
}

Probably the most important part is the pausetime and idealpitch fields because this makes sure that the particle emitter is not producing particles unless close to the player. In a medium sized map that can make a big difference and only checking the emitter every 8s + random offset, will not strain combat. Plus if a player is in an area longer than 8s then they are looking for something and they are more likely to notice the particles. 

fitz 085 is the recommended engine? 

actually it's better with baker's mk5, otherwise centerprint messages get cut off.