Problem compiling MenuQC

[Nash]

I extracted the MenuQC source files from the latest DarkPlaces mod in an attempt to understand and use it for my mod, but these errors come up when I try to compile it using frikqcc 2.6:

Code: Select all

error: mbuiltin.qc:50:"," is not a name
error: mbuiltin.qc:51:"," is not a name
error: mbuiltin.qc:52:"," is not a name
error: mbuiltin.qc:54:"," is not a name
error: mbuiltin.qc:55:"," is not a name
error: mbuiltin.qc:56:"," is not a name


If you have the DP mod, look the QC sources for the MenuQC source, but if you don't, here's the problem lines:

Code: Select all

entity   findstring(entity start, .string field, string match)     = #24;
entity   findfloat(entity start, .float field, float match)    = #25;
entity   findentity(entity start, .entity field, entity match)    = #25;

entity   findchainstring(.string field, string match)    = #26;
entity   findchainfloat(.float field, float match)    = #27;
entity   findchainentity(.entity field, entity match)   = #27;


Help please. :(

[Nash]

I am guessing that this is something the compiler I'm using doesn't support.

So what do I do? I tried switching to FTEQCC but it won't compile because the MenuQC code uses arrays and apparently FTEQCC doesn't support that.

[Sajt]

The menu code in DPMod is unused (I hope) and 3 years old - I think Black restarted it from scratch a few times since then.

Nexuiz is the only mod I know of which actually uses menu qc, and their code is up to date:

http://svn.icculus.org/nexuiz/trunk/data/qcsrc/menu/

[Nash]

Ah, okay then. I was aware that Nexuiz has working MenuQC but I decided to take the source from DP because it was apparently cleaner and hopefully easier for me to learn from.

Looks like I'm going to have to find some time to dissect that monster from Nexuiz then...

[leileilol]

MenuQC is a new untreaded, undocumented ground for most since it's so relatively new. I think you're diving into the unknown too early

[Nash]

Really? I wouldn't know.

[Nash]

Nexuiz's MenuQC also won't compile with FrikQCC 2.6:

Code: Select all

warning: msys.qc:1:unknown pragma flag
error: mbuiltin.qc:62:"," is not a name
error: mbuiltin.qc:63:"," is not a name
error: mbuiltin.qc:236:fopen redeclared (see previous declaration mbuiltin.qc(94))


Code: Select all

62: entity   findflags(entity start, .float field, float match) = #87;
63: entity   findchainflags(.float field, float match) = #88;

...

91: #ifdef FIXEDFOPEN
92: float    _fopen( string filename, float mode ) = #48;
93:  #else
94: float   fopen(string filename, float mode)  = #48;
    #endif

...

234: #ifdef FIXEDFOPEN
235: float    fopen( string filename, float mode ) =
236: {
      local float handle;
      if( mode == FILE_READ ) {
         return _fopen( filename, mode );
      }
   
      // check for data/
      filename = strzone( filename );
      if( substring( filename, 0, 5 ) != "data/" ) {
         print( "menu: fopen: all output must go into data/!\n" );
         return -1;
      }
      handle = _fopen( substring( filename, 5, 10000 ), mode );
      strunzone( filename );
      return handle;
     };
     #endif


The code looks perfectly fine to me. Why is FrikQCC flipping out? :?

[Sajt]

I don't think FrikQCC does #ifdefs and stuff. I'm pretty sure the Nexuiz team is using FTEQCC.

[Nash]

I decided not to bother anymore and just edit the DP source. It makes much more sense than trying to get the MenuQC to compile. :(

[Sajt]

Except for the fact that if you release something that is based on a modified DP engine, six months down the line people will be playing your mod with a six month old DP build

Although if your changes are minor you could probably merge them into the DP subversion tree, like Nexuiz does.

[FrikaC]

FrikQCC has limited ifdef support.

The main problem with that code is that FrikQCC treats the name "field" as a reserved word.

[xaGe]

He doesn't seem to need a current DP engine 6 months down the road, but an engine to do what he needs for is unrelated Quake game now... So when the mod is done its done...

The advantage would be for everyone else to use anything "cool" he might cook up... Anything is possible...

Except for the fact that if you release something that is based on a modified DP engine, six months down the line people will be playing your mod with a six month old DP build

FrikaC: What is the reason for that? I know your busy at the head, but is this something that can be changed via command line parameter or would it be a code change?

FrikQCC has limited ifdef support.

The main problem with that code is that FrikQCC treats the name "field" as a reserved word.

[FrikaC]

it's not changeable via commandline, it's a special type modifier, that admittedly has limited use.

[Nash]

Thanks for the information, Frika.

[FrikaC]

The purpose of it is this, for anyone that is curious. Say you have a line like:

.float blah;

it's clear you're defining a field named blah whose return subtype is float. But:

.float(float blegh) blah;

QuakeC handles this as a field whose subtype is function, the function type's subtype is float. But say you wanted to make a function that returns a field. Ain't no way unless you use the FrikQCC field keyword. field keyword works like the . operator only in reverse

float field blah;

declares a .float

float(float blegh) field blah;

declares a .float()

and

float field (float blegh) blah;

declares a function returning a .float. This is extremely limited in it's use and it was one of the wacky pointless features I added at some point. It's just a remedy for the odd associative property of . (it modifies the ENTIRE type to the right of the period, where as most other things modify the previously handled type.)