Sounds like a plan. Muff1n get to work!

Added the lighting information to the readme, and fixed a small documentation error with the "particles / noparticles" commands.

Awaiting the gpl version of end.bsp so I can add it.

Who is working on it?

Pretty much just awaiting a link. Since it's not compatible with the original, someone has to have made it and tested it, right?

It can easily be made compatible, else what is the point?

Oh?

The point is that a GPL end would be free? If distributed with e.g. nQuakesv, it could easily be played by anyone.

http://www.quakeworld.nu/forum/topic/5789/page/2#92069

I uploaded a quick recompiled version with flat textures. External textures will work fine. the map itself is unmoddified, there's an extra room with a giant teleporter in it. I can also post the .wad file i made of the flat textures if someone wants. If this isnt exactly what you want, i can edit the map also, to make it more what you want.

Sputnik, do you think you could, with a BSP editor, remove the exit room completely from the GPL end.map? We could then compile, with Baker5's simple.wad, a truly compatible GPL replacement for end.bsp.

Baker already did this i guess...

http://www.quake-1.com/files/maps/end-map-plus-simple-wad2-plus-endmapsource.zip
unless his map has wrong texture names so they dont work with the external textures... UGH. Ill have to check

NO IT SEEMS that it uses the correct texture names... So, I havent really followed the thread long enough, i just saw a post about wating for a gpl end map, thought if I made my own textures and recompiled that it would be all good.

So u just want me to remove the room and ceal up that wall and compile with the simple.wad??
--------------------------------------------------------------------------------------------------------
EDIT:
ok i removed the wall and recompiled with simple.wad
I noticed one of the spike shooters up near the tele doesnt shoot correctly in the normal end map, i fixed this too.
Should they even be there for DM?

What Baker did is change spawnflags on the func_wall at the entrance into the exit room, so that the wall would be there in all game modes and not just single player/coop. However, when you use his map with ezQuake to connect to a server running vanilla end, the wall is gone (obviously the server doesn't send updates for an entity it has no idea about) and you can peek (but not walk into) the room. The one correct solution to this is to remove the room altogether, so that the map looks and feels exactly like the vanilla one.

I must say I don't like the idea of fixing spikeshooter bugs or any other entity bugs. The vast majority of servers will have the vanilla end.bsp after all, so if you want to fix a particular bug, the way to do it is update KTX so that it corrects things after loading the map, be it vanilla or GPL.

May I see your new version?

Hey empezar, thanks a lot for this package, it's great being able to install an play QW in just a few minutes.

Just posting to say there's a minor error in the graphics help:

alias _graphics_echo_8 "echo ^p^a^r^t^i^c^l^e^s$x20$x20$x20$x20$x20 - turns off eyecandy particles"
alias _graphics_echo_9 "echo ^n^o^p^a^r^t^i^c^l^e^s$x20$x20$x20 - turns on eyecandy particles"

Should be the other way around: first one turns particles on, second one turns them off.

Also, something that I think should be really helpful are aliases to set conwidth/conheight for typical aspect ratios (640x380 or 853x480 for 16:9, etc) and probably aliases for the most common resolutions nowadays too (1280x720, 1366x768, 1440x900, 1600x900, 1920x1080 and 1920x1200).

Is there a way for ezQuake to detect the desktop resolution?

Cheers.

http://www.quakeone.com/qrack/maps/end2.bsp

I fixed the particles messages just a few days ago.

I could create a consize alias. It's a great idea. Dunno about 1600x900 though.

I ust downloaded the last versionm of nQuake
and I was quite impressed. its very nice and theres minimal to config
good job.

one note, the arrow pointer needs a shadow

I'm gonna start the process of adding extensive credits to nQuake.

If you feel you had anything to do with nQuake, add your name to this wiki

http://wiki.quakeworld.nu/NQuake_credits

It's a mess currently (mostly a copy of fQuake credits), so add your name at the top and I'll move it into the credits list later.

There's a lot of credits to remove since fQuake included a lot more stuff than nQuake does.

Spirit for being an annoying nit-picker about map readme text files.

A quakeworld newcomer friend of mine downloaded nQuake recently, and a couple of things confused/escaped him which might be considered for alteration in the default config.

1) The default conwidth/height seems to be set to 640*480 leading to deformed geometry in the vast majority of people's setups with no suggestion that anything is wrong. Perhaps a better default would be 640*400, or change vid_wideaspect to 1? Is 16:10 still the most common desktop monitor aspect ratio? This seems like a difficult problem to address from nQuake's perspective.

2) The "r_enemyskincolor" and "r_teamskincolor" variables are both set, but they do not appear to be obviously available in the options menu. This causes attempts to change enemy colours and skins to be met with confusing and frustrating results where fullbright skin colours end up combined with the overlaid r_enemyskincolor (eg. assigning a green skin to the red-coloured enemies results in fullbright yellow enemies). In contrast, the skin-changing system seems transparent and simple. Perhaps the r_*skincolor variables should be removed from the default config?

3) r_dynamic is set to 0 by default, and that's quite an important one when it comes to detecting powerups. Is this off for reasons of performance enhancement? Is that still necessary?

4) +jump appears to be bound to 3 separate keys; Space, mouse2, and shift. It's not exactly a high-priority problem, but it seems quite wasteful, especially on shift.

I was under the impression that changes were made in ezQuake (on my request?) that ezquake's default resolution would match your native windows resolution. I guess if you have no settings in config for resolution or console resolution it would "auto fit" somehow.



I requested this from Empezar a while back, to simply use enemyskin / teamskin but he said r_enemyskincolor etc. was better. I still think simply using teamskin/enemyskin is best and simplest. It could be both are ok, but just that almost noone uses this setting in the scene, so its hard for current players to help newbies since they are not familiar with the default nQuake setup. Using "advanced" setup is not only bad for the newbie, its also bad for the players introducing the new players, that have to "research" nquake config to figure out whats going on. Ultra simple binds are used for weapons though which is good and easy, confined to Q E R CTRL (don't like CTRL, hard to reach)



I reckon this is for performance. r_dynamic with radeon takes a huge performance hit, even on medium to high end pc setups.



SPACE/MOUSE2 i can understand since they are both very common and probably covers like 90+% of all players' choice. I agree SHIFT is not good for jumping and should be used for a default weapon bind. maybe move grenade from CTRL, which is a hard to reach button?

It looks like they implemented that, but without a similar feature for conheight. I guess this is a problem that should be reported to the ezquake developers rather than an nquake issue? Do ezquake developers still exist?


It's far too obfuscated a command when neither newcomers who browse through the menu, nor old players intimately familiar with most commands can figure out how to change enemy colours, and I don't see how it confers any advantage over the traditional /enemyskin approach, while /enemyskin is transparent to newcomers and old players alike.

I'll change the enemy/teamskin thing, and look into that conheight default.

I can change the shift bind too. I use shift to jump. I didn't realise I was the only one.

This is a sneak peak of the latest development of nQuake.

Kudos to hifi.

[url=http://nquake.com/online[/url]

(Edited 2012-12-29, 13:28)

God damn that is fantastic. Great job!

Btw. That launcher is meant as a complement to nQuake. By no means is it a replacement.

But it's kinda neat to be able to install and launch QuakeWorld in under a minute.

The launcher does not only install, it also updates when an update comes out so your mini nQuake will stay up-to-date with the latest trends.

I'm also adding that it's a very toned down version of nQuake and doesn't have all the goodies the full version does. We did it on purpose to keep it clearly separated from the actual nQuake installer and to have the fastest loading times possible. Instant Quake at work, anyone?

It also runs on Linux x86 and x86_64. Adding support for other platforms is trivial, it only requires more ezQuake binaries as long as the target system has working Java installation. The browser does not need a Java plugin for it to work, .jnlp files are associated to javaws binary which runs the launcher.

At any rate, if you have any problems with launching, please try to update to latest Java version. On Linux, OpenJDK with IcedTea-Web runs it with some minor problems, Oracle Java probably works better.

I am vastly impressed by the launcher - It's incredible that the game can be downloaded and run so fast!

By the way - where does the launcher download the game? Where is it located?

C:\Users\Patrol1985\AppData\Local\.nqonline

I will put together a FAQ for these questions.

By the way, the package is confirmed to work with nQuakesv ktx and ktx ctf.

Awesome except you can't see whether someone has quad

Fixed that.

Also, nQonline now works for OS X (Intel macs).

Edit: Nevermind. It doesn't work for OS X. Unless someone with OS X downloads NQonline and tells me what is wrong, it will probably never work.

I get two errors. At first it says "cannot create shortcut". This seems to trigger on first run only. The second is "unsupported system: Mac OS x64".

net.sourceforge.jnlp.LaunchException: Fatal: Read Error: Could not read or parse the JNLP file.
at net.sourceforge.jnlp.Launcher.fromUrl(Launcher.java:491)
at net.sourceforge.jnlp.Launcher.launch(Launcher.java:283)
at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:202)
at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:51)
at java.security.AccessController.doPrivileged(Native Method)
at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:168)
Caused by: net.sourceforge.jnlp.ParseException: Only one application descriptor element allowed per JNLPFile.
at net.sourceforge.jnlp.Parser.getLauncher(Parser.java:643)
at net.sourceforge.jnlp.JNLPFile.parse(JNLPFile.java:694)
at net.sourceforge.jnlp.JNLPFile.<init>(JNLPFile.java:207)
at net.sourceforge.jnlp.JNLPFile.<init>(JNLPFile.java:190)
at net.sourceforge.jnlp.JNLPFile.<init>(JNLPFile.java:175)
at net.sourceforge.jnlp.JNLPFile.<init>(JNLPFile.java:161)
at net.sourceforge.jnlp.Launcher.fromUrl(Launcher.java:477)
... 5 more