View previous topic :: View next topic |
Author |
Message |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Sat Oct 20, 2007 3:18 pm Post subject: Problem compiling MenuQC |
|
|
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: |
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: |
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. :( |
|
Back to top |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Sat Oct 20, 2007 10:49 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Sat Oct 20, 2007 10:51 pm Post subject: |
|
|
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/ _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Sun Oct 21, 2007 8:11 am Post subject: |
|
|
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... |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Sun Oct 21, 2007 8:57 am Post subject: |
|
|
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 _________________
 |
|
Back to top |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Sun Oct 21, 2007 12:22 pm Post subject: |
|
|
Really? I wouldn't know. |
|
Back to top |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Sun Oct 21, 2007 7:25 pm Post subject: |
|
|
Nexuiz's MenuQC also won't compile with FrikQCC 2.6:
Code: |
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: |
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? :? |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Mon Oct 22, 2007 7:56 am Post subject: |
|
|
I don't think FrikQCC does #ifdefs and stuff. I'm pretty sure the Nexuiz team is using FTEQCC. _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Mon Oct 22, 2007 10:17 am Post subject: |
|
|
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. :( |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Mon Oct 22, 2007 4:28 pm Post subject: |
|
|
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. _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Mon Oct 22, 2007 8:23 pm Post subject: |
|
|
FrikQCC has limited ifdef support.
The main problem with that code is that FrikQCC treats the name "field" as a reserved word. |
|
Back to top |
|
 |
xaGe

Joined: 01 Mar 2006 Posts: 329 Location: Upstate, New York
|
Posted: Mon Oct 22, 2007 8:47 pm Post subject: |
|
|
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...
Sajt wrote: | 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?
FrikaC wrote: | FrikQCC has limited ifdef support.
The main problem with that code is that FrikQCC treats the name "field" as a reserved word. |
|
|
Back to top |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Tue Oct 23, 2007 3:19 pm Post subject: |
|
|
it's not changeable via commandline, it's a special type modifier, that admittedly has limited use. |
|
Back to top |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Wed Oct 24, 2007 10:40 am Post subject: |
|
|
Thanks for the information, Frika. |
|
Back to top |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Wed Oct 24, 2007 3:03 pm Post subject: |
|
|
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.) |
|
Back to top |
|
 |
|