Inside3D!
     

Engine standards for mod compatibility
Goto page Previous  1, 2, 3 ... 11, 12, 13, 14, 15, 16  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Thu Jan 14, 2010 8:44 pm    Post subject: Reply with quote

Baker wrote:
origin brushes available (revolving doors instead of doors that must slide open)

Just as a side-note: rotating doors are possible in Quake, using a combination of rotate_object for the door, and targeting an info_target. info_target in this case has the same effect as origin brushes. It could be an info_null as well (or anything you like for that matter), if you want it removed on load in regular Quake, as it's not needed after compiling the map. rotate_object is the entity recognized by the map compiler, and anything it targets will act as its origin. It's supposed to work as is, but there might be a bug in the available compilers concerning collision. LordHavoc recently fixed this in his compiler, as seen in this thread here.
_________________
Look out for Twigboy


Last edited by Urre on Thu Jan 14, 2010 8:48 pm; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website
Team Xlink



Joined: 25 Jun 2009
Posts: 320

PostPosted: Thu Jan 14, 2010 8:46 pm    Post subject: Reply with quote

FPS Display (Tutorial on Quakesrc)
CMDLIST (Tutorial on Quakesrc)
CVARLIST (Tutorial on Quakesrc)


Those three should be a standard already, they are dead easy with the tutorials on Quakesrc.

These ideas just came to me:

Mh's Chasecam code found in the tutorial section (The whole thread worth not just the first post).

That is non operating system specific and is really useful particularly to modders because instead of coding a chasecam the modder can just stuffcmd to chase_active 1 Which would be fully fixed with his tutorial.

Fixed Bounding Box's
That is something I have found very useful to modders. Solitude had a problem with the weapons falling through the floor when you would drop them, I fixed it by fixing the bounding box using the tutorial on quakesrc.

Here are some links to tutorials on some good features that I think should be in the standards.

http://www.quake-1.com/docs/quakesrc.org/71.html
http://www.quake-1.com/docs/quakesrc.org/80.html
http://www.quake-1.com/docs/quakesrc.org/87.html
http://www.quake-1.com/docs/quakesrc.org/119.html
http://www.quake-1.com/docs/quakesrc.org/124.html
http://www.quake-1.com/docs/quakesrc.org/143.html
http://www.quake-1.com/docs/quakesrc.org/145.html
_________________
Anonymous wrote:
if it works, it works. if it doesn't, HAHAHA!
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Thu Jan 14, 2010 10:57 pm    Post subject: Reply with quote

Team Xlink wrote:
the modder can just stuffcmd to chase_active 1

Modding Standards for Engine Compatability - don't use stuffcmd, there is already a perfectly good builtin to set cvars. Wink Laughing

Actually I'd like to see stuffcmd die. It might be useful if modders could suggest things that they've had to fall back on stuffcmd for, and how a proposed engine builtin could help here.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Thu Jan 14, 2010 11:19 pm    Post subject: Reply with quote

What about network protocol? I think I mentioned earlier, that some raised limits require altering the protocol, which in my mind would require some form of standard for that as well. Spike mentioned the fact that there could be singleplayer-only engines, which would get excluded if there was a protocol requirement. This, to me, is simply fixed by letting a singleplayer-only engine freely upping the limits to match that of the multiplayer-capable ones, while the multiplayer-capable engines have the additional requirement of supporting a common network protocol, to make sure they're all able to play online with eachother. I don't see it being an unreasonable thing to ask. As a modder you'd expect all the engines within the same standard to be able to run your multiplayer mod between eachother. Otherwise it's not much of a standard, is it?

Is Protocol 666 (FitzQuake) a reasonable suggestion? I'm not entirely sure on the boundaries of its limits, it didn't seem like the readme had all the details, I might not have looked hard enough though. It'd be great if someone could provide a detailed list of what Protocol 666 requires.

The main thing that absolutely needs to be bumped, and I suspect it does affect the protocol, is the amount of entities you're able to have on the server. One of the most common things I've heard modders worry about is saving in on entities, constantly, worrying about spawning an extra entity for something which might make their life easier or the feature they're developing a bit better. This is one of the main reasons I've been modding exclusively for the DarkPlaces engine, because it allows virtually unlimited entities. I've never reached any limit anyway, and I've had huge maps filled with over 4000 waypoints, on top of the regular entities used by the actual game. Ofcourse, the limit doesn't have to be insane, but reasonably larger than Quakes. A modder shouldn't have to worry about wasting entities just because the amount is limited. The question wether they can all be visible at the same time or not is a different one. That I guess is more of a packet-overflow kind of discussion, which also affects the network protocol.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Thu Jan 14, 2010 11:44 pm    Post subject: Reply with quote

Mr Fitz himself kindly wrote up a description of that, and I'm pretty certain it's lurking somewhere on the wiki.

I think it's a good suggestion, although currently I think only FitzQuake and DirectQ support it (and I'm not 100% certain on how well - or not! - I've implemented it Laughing ) It would also be popular with mappers and modders, which can only help.

I would however extend it to add some more granularity to origin and angles. I don't see much reason why origin can't be transmitted using the original float, and all angles (not just the client) should - at worst - be extended to 16 bit quantization (full float would be preferable though).

This would require a bigger buffer, hence larger transmissions, but for MP games it would only matter if the server was running the same protocol.

For SP games I would advocate bypassing the protocol and network layer entirely and just writing/reading the data direct, but I haven't researched this enough to know how much work would be involved (quite a lot I suspect).
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Thu Jan 14, 2010 11:48 pm    Post subject: Reply with quote

Concerning graphical features, seeing as they're both controversial and kind of silly to keep consistent between software and hardware accelerated rendering, I'm going to attempt finding some form of middleground which means different requirements depending on what rendering your engine supports, and for atleast one case, a completely new solution, which is kind of going against the core idea of this standard (standardize existing features), but I'm feeling it's justified for this specific case... You're all welcome to whine about it in the other thread once I've updated the QSB entry in the wiki Smile

How does this sound though, theoretically speaking? Do you feel it's okay to have different requirements?
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Thu Jan 14, 2010 11:50 pm    Post subject: Reply with quote

mh wrote:
Mr Fitz himself kindly wrote up a description of that, and I'm pretty certain it's lurking somewhere on the wiki.

Ooh, nice, thanks for the heads up, found it!
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Thu Jan 14, 2010 11:53 pm    Post subject: Reply with quote

Urre wrote:
Is Protocol 666 (FitzQuake) a reasonable suggestion? I'm not entirely sure on the boundaries of its limits, it didn't seem like the readme had all the details, I might not have looked hard enough though. It'd be great if someone could provide a detailed list of what Protocol 666 requires.

Documented here: http://quakery.quakedev.com/qwiki/index.php/Fitzquake_Protocol

As for whether the standard should require a specific protocol, I think we would be better off saying "we don't care as long as the required limits are supported." If the goal is to have an easy-to-name target spec for mappers and modders, the limits and capabilities are all that we should be including in that spec. The network protocol is an implementation detail.

I certainly think engines having a common protocol is beneficial; for multiplayer and coop obviously it matters to players. But maybe outside the scope of this standard?
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Thu Jan 14, 2010 11:57 pm    Post subject: Reply with quote

Urre wrote:
Concerning graphical features, seeing as they're both controversial and kind of silly to keep consistent between software and hardware accelerated rendering, I'm going to attempt finding some form of middleground which means different requirements depending on what rendering your engine supports, and for atleast one case, a completely new solution, which is kind of going against the core idea of this standard (standardize existing features), but I'm feeling it's justified for this specific case... You're all welcome to whine about it in the other thread once I've updated the QSB entry in the wiki Smile

How does this sound though, theoretically speaking? Do you feel it's okay to have different requirements?

Depends on what the requirements are really. Something like alpha support for all model types might seem reasonable enough until you realise that we're back in protocol-land. I'd also like to see some discussion regarding implementation. How does alpha support on a brushmodel that contains water surfs interact with your r_wateralpha value? What about if the brushmodel contains sky surfs?

These are just examples of one such hypothetical requirement that sprouts tentacles if you dig a little at it.

Otherwise I think differing requirements for software and hardware are fine. Above all any lowmark for the standard that comes out of this should be achievable, and I'd hate to see an otherwise perfectly good software engine fall down because the author lacks the necessary 31337 h4xx0rz sk1Llz to implement 32-bit linear filtered mipmaps in software.

_________________________

By the way, I forgot to give you credit for taking this on and putting some momentum behind it! Buy yourself a very large beer! Very Happy
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Fri Jan 15, 2010 12:03 am    Post subject: Reply with quote

Urre wrote:
How does this sound though, theoretically speaking? Do you feel it's okay to have different requirements?

It might work to identify two levels of support for the standard:

1. doesn't crash and lets you play the content, and implements the features as well as is reasonable. (or: as well as necessary for gameplay to work)
2. implements all features correctly, can be said to deliver the "intended experience" of the content developer.

Then a software engine can be in the first category at least. Perhaps we can even define that partial support in a rigorous way, such as:

Alpha
1. 0 = invisible, 1 = opaque, in between values must be visible and somewhat transparent
2. correct alpha blending math using close to the alpha value specified (i.e. within a percent of the right value)
Back to top
View user's profile Send private message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Fri Jan 15, 2010 12:09 am    Post subject: Reply with quote

metlslime wrote:
I certainly think engines having a common protocol is beneficial; for multiplayer and coop obviously it matters to players. But maybe outside the scope of this standard?

If you're making a multiplayer mod, what use is there to follow a standard if you know your players need to use one single engine anyway, to be able to play together?

Is adding a new protocol hard? Why is it generally frowned upon by engine devs? I have no clue really Smile

mh: Thanks! I'm quite enjoying myself actually, this is awesome fun. Who knew standardizing could be entertaining and feel meaningful Smile
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Fri Jan 15, 2010 12:14 am    Post subject: Reply with quote

metlslime wrote:
It might work to identify two levels of support for the standard:

1. doesn't crash and lets you play the content, and implements the features as well as is reasonable. (or: as well as necessary for gameplay to work)
2. implements all features correctly, can be said to deliver the "intended experience" of the content developer.

Then a software engine can be in the first category at least. Perhaps we can even define that partial support in a rigorous way, such as:

Alpha
1. 0 = invisible, 1 = opaque, in between values must be visible and somewhat transparent
2. correct alpha blending math using close to the alpha value specified (i.e. within a percent of the right value)

Exactly, I'm starting to lean towards this one a bit, although I was against it at first. Well, I was against optional features as suggested by LH, but this isn't really the same thing. It's features within limits of capability. I'd require full support for the feature if it's a hardware accelerated renderer, but only reasonable support if it's a software renderer. Still with clear requirements, just not fullblown like the hardware one. Nothing optional in that.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Fri Jan 15, 2010 12:24 am    Post subject: Reply with quote

Sounds good to me too. Very Happy

Adding a new protocol isn't that difficult, and even easier if you decide to replace protocol 15 outright. It's just kinda messy the first time you add one. Having more than 1 protocol supported can involve quite a bit of juggling in your code too.

I guess it's not really frowned upon, it just doesn't have quite the same sex appeal as a particle system or whatnot. Me, I enjoy tinkering with stuff on the level of the file system or the memory manager (it helps that I'm also rubbish at particle systems), so I'll cheerfully add as many protocols as are reasonably documented.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Fri Jan 15, 2010 1:39 am    Post subject: Reply with quote

Urre wrote:
metlslime wrote:
I certainly think engines having a common protocol is beneficial; for multiplayer and coop obviously it matters to players. But maybe outside the scope of this standard?

If you're making a multiplayer mod, what use is there to follow a standard if you know your players need to use one single engine anyway, to be able to play together?


Well yeah, and also for players the interoperability is pretty important. I don't know, I guess i'm willing to include a protocol in the standard if it's not to hard to agree on one. And obviously 666 would be easy for me since it's already implemented on my end Smile

If we do go with 666, maybe we need to retro-actively add svc_skybox and svc_fog to it so that we can have correct server-side sky and fog control. (already implemented in fitzquake but not DirectQ afaik)

Or just bump to 667 and add whatever additional features are needed for this standard. (high precision entity angles and coordinates have already been suggested, but we'd need to solve this in a way that doesn't bloat packet size too much.)
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Fri Jan 15, 2010 3:08 am    Post subject: Reply with quote

metlslime wrote:

If we do go with 666, maybe we need to retro-actively add svc_skybox and svc_fog to it so that we can have correct server-side sky and fog control. (already implemented in fitzquake but not DirectQ afaik)

Or just bump to 667 and add whatever additional features are needed for this standard. (high precision entity angles and coordinates have already been suggested, but we'd need to solve this in a way that doesn't bloat packet size too much.)


I'd vote in the second option. If we are going to another protocol, then that's the moment to improve things. And I believe we should not worry about compatibility with vanilla Quake at this point, but instead with other QSB 1.0 compliant engines only.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Goto page Previous  1, 2, 3 ... 11, 12, 13, 14, 15, 16  Next
Page 12 of 16

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group