isenthalpic53

I am working with a VBA script run inside of Excel that can be used to feed parameters into a planing hull simulator. I am compiling a .odl file to generate a typelib (.tlb) but it appears that the typelib is not being properly registered, meaning when I add new functions they are not showing up. Although the system gives a current date and time when I actually view the typelib using OleView it is clear that the changes I tried to make during the compilation are not getting through. Similarly, if I, say, keep everything else the same but change version from 1.0 to 1.1, the registry only shows version 1.0 (what I currently have installed) but as I understand it should have a subfolder for each version. I am using Visual Studio 2005. Here are snippets of the odl // pwrs.odl : type library source for pwrs.exe // This file will be processed by the MIDL compiler to produce the // type library (pwrs.tlb). [ uuid(FBA79343-34E9-11D1-8A7F-000000000000), version(1.1) ] library Pwrs { importlib("stdole32.tlb"); // Primary dispatch interface for CPwrsDoc typedef enum { // Vessel Characteristics VCH_FOREPERP = 1, VCH_AFTPERP, VCH_LCG, VCH_VCG, VCH_RG, VCH_W, VCH_KAR, VCH_CBF, VCH_CBMM, VCH_CDC, VCH_CPILEUP1, VCH_CPILEUP2, VCH_CPILEUP3, VCH_CPILEUP4, VCH_OPVELOCITY, VCH_CALMHEAVE, VCH_PITCHRG, VCH_ROLLRG, VCH_TCG, VCH_B22Q, VCH_B44Q, VCH_B66Q, VCH_LATADMFACTOR, VCH_ROLLADMFACTOR, VCH_ATRANSOM } enumVesselChar; ... (all other required enums defined) ... [ uuid(FBA79344-34E9-11D1-8A7F-000000000000) ] dispinterface IPwrs { properties: // NOTE - ClassWizard will maintain property information here. // Use extreme caution when editing this section. //{{AFX_ODL_PROP(CPwrsDoc) [id(1)] boolean bPrintHeadings; [id(2)] boolean bPrintTitle; [id(3)] short cDelim; ... [id(25)] enumHydCoeffStatus iHydParamStatus; [id(26)] short iOpVelUnits; [id(27)] enumResidForceMode iResidForceMode; [id(28)] double dCalmHeave; //}}AFX_ODL_PROP methods: // NOTE - ClassWizard will maintain method information here. // Use extreme caution when editing this section. //{{AFX_ODL_METHOD(CPwrsDoc) [id(29)] boolean SetVesselChar(enumVesselChar iVar, double dVal); [id(30)] double GetVesselChar(short iVar); ... [id(166)] boolean SaveTextWindowAs(BSTR sPath); [id(167)] boolean SimpleHydrostatics(VARIANT_BOOL bCtrlValid); //}}AFX_ODL_METHOD }; // Class information for CPwrsDoc [ uuid(FBA79342-34E9-11D1-8A7F-000000000000) ] coclass Document { [default] dispinterface IPwrs; }; //{{AFX_APPEND_ODL}} //}}AFX_APPEND_ODL}} };

Thank you for the informed replies.

I am looking at UniBlue's registry cleaner. Does it seem like it's worth the $30? UniBlue registry cleaner [Edited by - Ravuya on August 16, 2009 12:45:33 AM]

compute the impulse to exactly change the tangential velocity to zero and compare it with the dynamic friction force and the static friction force and select the proper one to use.

If you want to make it really nasty look for the gyroscopic effect (pitching an airplane with a spinning propellor creates a roll moment). That's just kind of annoying/stupid for most practical flight simulators though (but something I wasn't even aware of until recently).

I snagged the mesa GLU NURBS implementation and for my purposes it's exactly what I need. Thank you for the suggestion.

At some level OpenGL (well, glu) turns your control points/knots into vertex data before rendering. Is there a way to get access to these vertices? I have a hull form of a containership, describe by splines (4th order I think), and I'm trying to take this data and turn it into flat panels (for which I need the vertex data). Thanks for reading.

I recompiled the jpeg.lib with VS 2005. I could build the application if I statically linked to MFC, but that inflated my binary to 3 MB, up from about 200KB. If anyone's interested, I've included the updated .h and .lib files here: http://www.yourfilehost.com/media.ph...eglib_VS2005.h http://www.yourfilehost.com/media.ph...peg_VS2005.lib

Not sure if this is an inappropriate place to put this question. I have been trying to add jpeg loading code to an MFC application in Visual Studio 2005. I'm not sure if I'm linking in a bad order or using improper compiler options, etc. I've been poking around for well over an hour, I'm sure this is something minor, but when I add my texture loading code, which uses jpeg.lib, I get the following error: Quote: 1>jpeg.lib(jerror.obj) : error LNK2019: unresolved external symbol __iob referenced in function _output_message 1>.\Debug/Viewer.exe : fatal error LNK1120: 1 unresolved externals Any ideas?

yeah, lightmaps are for static lighting of an environment (although doesn't quake 2 basically do a dynamic lightmap for like the default blaster gun thing and such?) I believe you can have the world lit by a static lightmap and still have your headlights apply added lighting. You can also look into shaders and build a 'real' lighting model rather than doing GL's built in lighting and lighting hacks (light mapping is basically considered a lighting hack).

It seems you aren't re-normalizing the summed vector that is to be your normal. It also seems suspicious that you must recompute the triangle normals within the vertex normal computation code (don't you already store the triangle normals for other uses?)

Your problem is likely due to floating point errors. On top of what has been suggested, you should also compute a parametric value that is slightly less than the computed parametric value. I've never been able to get collision detection and response to work without post-processing the collisions and manually checking for penetrations.

To piggy back on what has been said, I know a guy that was hired by an oil company in his graduate program to develop mathematical equations for the flow of crude through their pipelines, with the purpose of optimizing flow which cuts costs. One *single equation* in the analysis was roughly four pages long. This is not trivial stuff.

I don't believe you need to pay anything additional for MFC so long as you've got Visual Studio. I had headaches installing wxWidgets and getting their OpenGL examples to run without crashing. Developing elaborate GUIs with *either* is going to give you massive headaches, I promise you that. Like I said, unless you *really* need to have an elaborate GUI I'd just go with GLUT. Heck, when I've developed applications that only need limited interaction I just use pure Win32.

MFC isn't obsolete. There are regular updates and it is still in wide use in the commercial world. Both approaches are going to give you headaches. wxWidgets is cross platform, but you can quickly get started with MFC because the Visual Studio class wizards will add the code hooks when you add controls onto forms (at least with visual studio 2005). Unless you *really* need an elaborate GUI, I'd forgo both MFC and wxWidgets and use GLUT. That will give you enough functionality for buttons and controls. I'd only go with wxWidgets if you must have cross-platform functionality. If you are only shooting for Windows boxes MFC would be my suggestion.