Trouble with DR3
 

Greetings,

Is there anyone out there who been able to successfully compile the current CVS dump (DR3) in windows using VS.NET 2k3? I was able to compile World.exe, EQsharemem.dll, however Zone.exe will not compile, due to numerous "Constant too big" errors, 33 to be exact. I read another post regarding this issue and nobody answered the person. Then I found another post about the same thing in which FNW replied saying to make the constants smaller. I go to the lines where these errors are listed at, and find nothing that looks like it needs to be, or even should be adjusted, and certainly doesn't look like the examples FNW gave.

If anyone has been able to get around this, please tell me how it is done, OR, if anyone is willing to share a copy of the latest perl-enabled compilation of Zone.exe (DR3) please PM me. I would prefer to do my own compiling but at this point am willing to settle for someone elses.

Thanks in advance.

Regards,
SI

First, that didn't help. I'm not looking for quick smart-ass replies, like "Search is your friend" because ...I did search, for a long time, and that is why I bothered to post in the first place. Second, the post you linked to does not help me.

What you linked, is what I was referring to.

The examples he shows there does not even come close to anything shown on the lines that VS.NET reports the "Constant too big" error. Being that I am not a coder, I am unable to know what needs to be changed. I have never had a problem compiling the server binaries on my own till now, and that's what I need help with.

Still requesting help with this, or anyone generous enough to donate a DR3 Zone.exe. Thanks.

Regards,
SI

If the post http://www.eqemulator.net/forums/sho...89&postcount=2 is what sysadmin linked it is exactly your problem. Do what it says and you'll be in good shape

Alright, I'm going to have to post some examples. What FNW shows in that thread is NOT what I'm seeing on the lines that show as containing errors. Here are a few examples:

This is what shows in the VS.NET compiler after trying to compile. This is just ONE example of 33 errors, all are the same, "Constant too big":
I then double click that to go right to that file and line to edit it, and find this:
Not the 99999990e111 type thing that FNW is talking about. Soo...what would I edit in that line? I tried adjusting the numbers in a few of these instances but nothing changed, or errors started showing up in other files. Please note that almost all of the errors that showed up contained lines like this one, with a lot of mumbo jumbo and no large arbitrary numbers such as those described by FNW.

Here's another example:
Going there shows me this:
There are 5 lines almost exactly like this in the code surrounding that line. Why are they not pointed out like this one?

I am very new at C++ coding. The extent of my abilities include creating a hello world program in the console, and (used to be) compiling EQemu flawlessly. When I look at lines like that above though, it's a foreign language to me. I am very willing to learn, and am currently making an attempt in my spare time to work on my C++ skills, but I really need help with this.

Regards,
SI

as is saif.. SEARCH IS YOUR FRIEND
 

Visual Studio Developer site says


FNW knows his stuff, I don't but I was smart to find the same answer on VS2005 website and you did not, even when you searched "for a long time". Also you should rename yourself to sonic because as I see you have no intuition.

As you can see in my above post, I clearly state that I am very new to C++ coding, and reading this stuff is like a foreign language. Being new I would have no clue if the errors are something native to the EQemu code itself or something that can be fixed with outside help, therefore I did not look outside the community for assistance. Now that you've explained that to me, I will do that. Thanks for your advice.

Regards,
SI

You are in a better position than me, I do not know ANY c or c++ or VC or any other flavor. I myself have been flamed MANY times because I did not searched for the answer, or was dumb enough to not find the answer on the internet.

I simply was pointing out that WE(includes me also) should do the best in our power to find the answer before buggin a developer since they have more important things to think about and solve before answering any of mine or anyone elses noob questions.

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.

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.
.

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:
.

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

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.

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

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:

C2177
 

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

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

zone\client.h, line 293

zone\map.cpp, line 83-88

zone\pathing.cpp, line 549-550

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

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

If anyone is still having this problem:

1. Open client.h and find ClearAllProximities()
2. Change all the 1000e99 on that line to FLT_MAX.
3. Add #include <float.h> to the top of the file.

This should fix the vast majority of the "costant too large" messages. Any other errors should be easy to identify and fix, the reason why this instance was hard to find was because VS .Net would say the error was at a seemingly random location instead of the real location. Compounding this was the fact that about 30 files include client.h, making it seem like you had a ton of errors when it was really just one.

Thanks Lethal!!

You're dropping the Edgar1898 handle I see :(