Trouble with DR3

[RangerDown]

There's no need for the personal attacks. The code that SI is reporting is worthy of investigation, since 0.5 should be a perfectly valid value for a float. The MSKB article posted does little to remedy the fact that 0.5 is a nice middle-of-the-road value for a "float" type.

What may be wrong in this case is either the compiler you're using is somehow confused or improperly set, or the actual offender is one or two lines above or below the line number you're seeing in error messages. Your compiler may, for whatever reason, have a different idea of what a "float" is than the standard data type.

If others are getting C2177's on those very lines, then something may be wrong with the code. But I've visually verified the code you pasted follows proper syntax, and since you are the only one reporting errors there, we have to assume the problem lies in the compiler you are using.

[sysadmin]

In my experience with other programming languages the same compiler led to different errors when using different hardware, aside the options used to configure the compiler.

I think the best possible solution would be to search the knowledge base at the compiler's developer site. They might have already a solution, or at least a workaround.
.

[sysadmin]

This might be irrelevant to the problem in VS2k3 but an interesting read, seems microsoft crippled the c compilers a long time ago due to a marketing decision.

Link

Jack Klein wrote:

Re: Error C2177 Constant too big when compiling Gammal.c
On 3 Mar 2004 15:51:34 -0500, Antoun Kanawati <antounk@comcast.net> wrote in
comp.lang.c++.moderated:

This is just plain wrong, at least about long double. Microsoft knew very well what long double was, from version 3.0 of their MS-DOS only Microsoft C compiler. They supported the Intel coprocessor/FPU 80 bit extended precision type.

This support continued through all of their 16-bit compilers (Microsoft C and C++ 7.0, and Visual C++ 1.52). It was only when they introduced Windows NT and 32 bit compilers that they made a marketing decision to drop extended precision type.

Their stated reason was that some of the processors for which they were planning to sell Windows NT did not have hardware support for floating point types wider than 64 bits. Their decision was that portability to other processors running Windows NT was more important than the programmer's decision whether or not to choose precision over compatibility.

You can see this on Microsoft's web site at the following link:

http://support.microsoft.com/support.../Q129/2/09.asp

Visual C++ 4, 5, and 6 all supported long doubles. But they all implement long double as 64 bit FPU floating point types, identical with double. The last version of Visual C++ that supported 80 bit Intel FPU extended precision 80 bit types for long double was the last 16 bit compiler,
Visual C++ 1.52.

I wouldn't know if they have brought this support back in 7.0 or 7.1, but I doubt it.

Their marketing decision seriously cripples Visual C++ on the x86 for some types of serious numerical and engineering programming. Others, such as Borland and GCC, do not have this limitation.

.

[sonicintuition]

Thanks guys. Now that I have a clearer picture of why this may be happening I'm not so damned confused. I'm not even going to try compiling this any more, nothing I've tried is making anything any better. Changing numbers around only leads to more constant too big errors on other lines in other files. Messing with something this deep is just too much for someone with almost 0 experience in C++ coding. So I'll just let the developers do their thing for now.

I'm still requesting a copy of DR3's Zone.exe from anyone generous enough, since that is now my only option of getting it. I just wanted to test it out on my server, see the new bug fixes in action, etc. If anyone would be willing to lend a hand PM me. Thank you.

Regards,
SI

[sysadmin]

I would suggest you register on a Microsoft support forum and post the problem there. I am not sure you will get a solution, but at least would make microsoft aware of the error you are having.

[sonicintuition]

I'll probably do that because, despite my frustration, I'd still like to learn how to program with C++ and I'm sure there is a wealth of knowledge to be had there. Thanks again for the advice.

I've been offered a copy of Zone.exe for DR3 so I won't be posting about this anymore. Thanks to all who tried to help.

Regards,
SI

[sysadmin]

It seems this will not change anytime soon since they are still using 64bit long double double for variable structure.

This is straight from MS Visual Studio website:

Double Structure
Represents a double-precision floating point number.

For a list of all members of this type, see Double Members.

System.Object
System.ValueType
System.Double

[Visual Basic]
<Serializable>
Public Structure Double
Implements IComparable, IFormattable, IConvertible
[C#]
[Serializable]
public struct Double : IComparable, IFormattable, IConvertible
[C++]
[Serializable]
public __value struct Double : public IComparable, IFormattable,
IConvertible
[JScript] In JScript, you can use the structures in the .NET Framework, but you cannot define your own.

Thread Safety
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Remarks
The Double value type represents a double-precision 64-bit number with values ranging from negative 1.79769313486232e308 to positive 1.79769313486232e308, as well as positive or negative zero, PositiveInfinity, NegativeInfinity, and Not-a-Number (NaN).

[hellkat138]

Im getting the exact same thing he is on visual basic 2003

[garim12]

I had the same problem on my machine using Visual Studio .NET 2003... the real root of the problem is that Microsoft's compilers rarely tell you where the real problem is. They'll claim a problem with a line like

GroupEXPBonus = 0.1;

when the real problem is in a completely different source file that it included 1000 lines ago.
According to FLT_MAX on my system, the max size for a float in VS.NET 2k3 is about 3.4e38... so all the recently changed lines that increased constant sizes will break this compiler.


Anyway, here's all the places in the recent CVS version where constants are too big for VS.NET 2k3:


zone\client.cpp, line 209-211

proximity_x = 9e100; //arbitrary large number
proximity_y = 9e100;
proximity_z = 9e100;

zone\client.h, line 293

inline void ClearAllProximities() { entity_list.ProcessMove(this, 1000e99, 1000e99, 1000e99); proximity_x = 1000e99; proximity_y = 1000e99; proximity_z = 1000e99; }

zone\map.cpp, line 83-88

_minz = 999999e111;
_minx = 999999e111;
_miny = 999999e111;
_maxz = -999999e111;
_maxx = -999999e111;
_maxy = -999999e111;

zone\pathing.cpp, line 549-550

best_dist2 = 9999999e111;
bestl_dist2 = 9999999e111;

The easy quick solution is to change all of these to something smaller. The better solution is probably using something like this:

#ifdef WIN32
#DEFINE MAXFLOAT 999e10
#else
#DEFINE MAXFLOAT 999e100
#endif

...but I don't really know if this problem exists in all Windows based compilers or just Visual Studio.