Mumbles

Roland has described exactly what you want, although it's described in a little more detail here. http://www.cplusplus.com/doc/tutorial/polymorphism/ It's the final section of that page in particular that you should read "Abstract base classes", but I would recommend reading the entire page from top to bottom...

Damn, I was silently doing one of those too. I thought you were doing SDL_net? For reference though, I was only considering IPv4.

No, summer starts in June... You can't rush these things... A British Summer however begins in the third week of May, and ends in the second week of June...

not enough to use the testing build. As you know, Debian users on the stable build are few and far between, but I might have to get razor qt manually because that's a while off going stable, but upgrading from KDE 3 to KDE 4 was the biggest mistake ever.

iPhone should score -1... Phones are for calling (or texting) people not playing Quake...

It's another point which generally makes ConvexCast superior. Although that superiority does make it slower than a single raycast. It's a shame that feature was never exposed

I don't know how the terrain system works. But on the off chance it uses Newton: What is the world size? Is the point on the terrain inside the world boundary? Does the raycast start inside the world boundary? Does the raycast end inside the world boundary? The first two of those are the most crucial, as only bodies inside the world can trigger the (hidden) "prefilter" and "process hit" callbacks.

This is probably an issue many of you have overlooked, but both the wiki, and (certainly for C) the headers only list values for keys you would expect to find on a US keyboard. Those of us with British keyboards are probably (in fact almost certainly) in a minority, but it's irritating when you're hard coding a specific button for the console. Yes, I know hard coding is normally considered bad practice, but it's normally considered OK for the console button not to be redefinable. The irritation comes from the fact that on a standard US keyboard, the key next to the number 1 is ` and with shift held down, it's ~ and so you can check for it by using KeyHit(KEY_TILDE). Unfortunately, that's not the case for British keyboards, our ~ is next to the enter key, instead, our key next to the number 1 generates: ` on it's own ¬ when pressed with shift ¦ when pressed with Alt Gr (That's another key that US keyboards don't have... It's in place if the right alt, but doesn't behave the same way). Some keyboards show it as a solid bar, with the split bar on the backslash. It may be down to OS, but Windows XP, when set to the English UK keyboard, produces the split bar (As a side note, UK users might have noticed the Euro currency sign on the 4 key, shared with the dollar sign, again, that's produced with the Alt Gr key. European vowels with accents are produced the same way too (áéíóú although it doesn't work with the Spanish letter ñ), but since Leadwerks can't test for secondary or tertiary key functions, that's just a bit of a "did you know") Back on track, the key I wanted the number for, isn't listed in the header files so I had to make a quick for loop to see which key it was, and I've done the same for the other problematic key: The backslash, which is in a totally different place on our keyboards when compared to US keyboards (ours is next to the left shift) enum { KEY_UK_SPLITBAR = 223, KEY_UK_BACKSLASH = 226 }; There is also an irregularity: The hash (#) key, which also produces a tilde (~) when shift is pressed is tested with the number 222, which is KEY_QUOTES The quote (') key, which also produces an at sign (@) when shift is pressed is tested with the value 223, which is KEY_TILDE As you see, these two are in the wrong order on British keyboards. Not exactly a show stopper, but could cause some confusion if you're someone's game with hard coded keys and they don't seem to respond, or if a game has a text input capability and the input doesn't seem to match.

Oi! Trademark infringement! Come on Mika, let's get him for every penny he's worth! We used the same name 2 years ago. Seriously, you might want to alter the name ever so slightly, otherwise if you're superstitious, at the slightest knockback, you may think it's doomed to go the same way as its identically named predecessor.

The other alternative is to remove the name from the enum, since it is already encapsulated by the class class aLabel { public: enum { TP_Center = 0, TP_TopLeft, TP_TopRight, TP_BottomLeft, TP_BottomRight }; int textPosition; }; switch(textPosition) { case TP_Center: //Blah blah - do stuff break; case TP_TopLeft: //More blah blah-ing } If the switch occurs outside an aLabel function, then just change the "case TP_Center:" to "case aLabel::TP_Center:" and obviously change the switch as well to either, (object instance).textPosition, or if text position isn't public (object instnace).getTextPosition()

Are the cannons working? For me, they are spamming the console with not a number ("NaN") errors, and they don't seem to be shooting anything.

And uh, does it work in Milkshape? or is it just something for the rich trust fund *bleep*s?

KeyHit and KeyDown are both available in the C DLL and they behave exactly as they would in Blitz Max (KeyPressed isn't available and MouseButtonDown is now MouseDown(int button)). It would make sense if Josh's TKeyHit(int key) command was just a single line wrapper function return KeyHit(key) so, if lua has access to the same commands, then it should work, then again, disclaimer -- I don't use lua, which is why I'm sticking with your method of of NOT-ing a variable... (which I'd never actually thought of before). if KeyHit(KEY_1)==1 then questionScreen=questionScreen*-1 end I myself, don't use Blitz (or lua), but I learned the distinction between hit and down whilst in my earlier years using Blitz 3D, and indeed Dark Basic had it too, except back in my DB times, I couldn't fathom the difference between "object hit" and "object collision", which worked in much the same way and KeyHit and KeyDown respectively, even though it was there in plain English in the help page.

The solutions provided already take this into account. They use KeyHit which (in Blitz) returns the number of times the specified key has been pressed since it was last checked. I think in LE 2 it's been reworked to simply be 1 if the key has been released and pressed again since the last check, and 0 if it's either not pressed, or still held down from the last check... However your point would be true if KeyDown was used since that simply returns 1 if the key is currently pressed, regardless of whether it is still being held down from last time, or a totally unique keypress. The flickering is more likely due to declaration and initialisation inside the main game loop (which was identified by Pixel Perfect), when it should be outside the game loop, but that wasn't explicitly stated when the solution was given.

I was going to write that too, but since it's already been done, I'll click that facebook tick thing instead...

As long as you save where the bullet / rocket is for each physics update... Draw the rocket at that position, and do a small raycast, like 1 unit in front of that position. Until the raycast hits something, then you hide rocket again.

Personally, I prefer raycasting for all projectiles (bullets and rockets). If realism isn't important and you don't care about bullet drop, wind or air resistance then it's a lot faster, and for bullets, you don't even need to draw it - you can just draw a spark and a bullet hole where it hit.

No way, no how... Not LE 2 anyway.

They always sound great on paper. But being part of one once (on this forum in fact), I soon felt way out of my depth, and I'm certainly part of the reason it never really worked....

1. Set the body's angle with the RotateEntity command before adding the "throwing" force. It will keep this orientation until it hits something. 2. Get the Entity's AABB. The mid point of each axis should either be the exact centre, or so close no one will know the difference (C/C++) TVec3 GetMidpoint(const TEntity &Entity) { TVec3 OutputVector; TVec6 AABB = GetEntityAABB(Entity); OutputVector.X = ((AABB.X1 - AABB.X0) / 2) + AABB.X0; OutputVector.Y = ((AABB.Y1 - AABB.Y0) / 2) + AABB.Y0; OutputVector.Z = ((AABB.Z1 - AABB.Z0) / 2) + AABB.Z0; return OutputVector; }

You can simplify your code quite a bit actually by using the mod operator... (Assuming it's C, which it looks like) //Mouse wheel checking m = LE.MouseZ(); int CurrentTowerCount = 5; //Every time you add a tower, increment this - this should actually have a higher scope visibility than just this function, otherwise it will keep resetting this value to 5 towers (0 through 4) every time it checks for mouse movement if (prevM != m) { (selectionID += (prevM - m)) %= CurrentTowerCount; //If it's going the wrong way, swap the += for a -= SetNewCurrentTempTower(); prevM = m;//I'm guessing you had this line as well... }

Graphics(Width,Height,(Fullscreen * 32)); Now that - is pure elegance... Trust me, I'm a pro...

All seems fine now. Res is fine, and stabile is always 1 (not sure if that's good or bad)...

Still flawed I'm afraid. In full screen, it's fine. 1280x720 window failed same as before. GLSL not supported, so call to Graphics still failed 1024x768 window gave me a 1920x1080 window. Yeah it loaded, but most of it was off screen. It's getting there, being able to choose your own resolution is a nice ability to have, but it seems if you choose window mode it completely ignores the other values you give it. I've also forgotten what I was meant to be looking at once again...

I'd probably remove the attachment in the first post. It's served its purpose now and is no longer the current version.