Bard

oh there could easily have been - a simple "trackir multiplier" value that defaults at 1 and could be entered. would allow you to easily modify the panning speeds. put in 0.75 and it' would be 3/4 speed. update the panning code to pan in accordance.

was hoping there was a pan speed control within the sim or it's config files so i didn't need to edit all the points in the trackir software (pain in the butt). couldn't find one so did the point editing.

I have a Turtler Beach Santa Cruz, best card out there IMHO... ;) I've never had any FPS hit from the sounds. yeah - i'd be very interested to see how your card performs with this.

download this file. http://taipans.dyndns.org/stuff/test.zip follow the instructions in the file. If you could post here with your system specs and your results it'll be very helpful.

initial testing seems to indicate the large FPS hit of sounds is still there from 1.00. need to work through that on the weekend. anyone here have a turtle beach soundcard? the reason i ask is that in the last run of tests 1 particular soundcard did not display the same loss of framerates. It might be that this issue is not considered worth looking at by ED, so if there's a "magic lomac soundcard" to be found it might be worthwhile getting one.

but here's the mistake you are making... He doesn't need to have developed a game to be able to recognise where there are programmatical problems - the "you haven't made a game so you know jack" is incorrect regardless of whether he has done so or not. It doesn't take a firearms instructor to know enough firearms safety to be safe - same thing here. All it takes is someone who has had some basic formal schooling in programming and design to spot and know there are problems. What's being commented on are BASIC fundamentals of programming and design. I can tell from what lexicon is saying that he does have a fundamental understanding. I can also tell that he has more than a fundamental understanding since he understands the kind of problems you get from debugging ambiguous code, something not appreciated by people who haven't done it - this indicates experience. You might have noticed that he made no claim as to whether he is an uberprogrammer with 20 years experience, he just made an analysis and posted it and has let IT talk for him. To me what he said made complete sense and indicates he does actually know what he is talking about. Just because he's talking about stuff beyond your field of expertise doesn't mean you should be insulting him (and that is exactly what you were doing) and then trying to invalidate his analysis. I appreciate that you can't just "take him at his word" without proof, but it doesn't mean you can just write off what they say. People making bogus claims are pretty quickly shown to be the liars they are, because there are always going to be people out there who DO know what they are talking about who will be all too happy to jump on them.

cool you understand the concept :) Ambiguous code can be like having piles and piles of paper on your desk and you are looking for a phone number you wrote down, you know which pile it is in, except you wrote down just the number and nothing else. the number is there somewhere, but when you find it you can't be sure if it is the right number until you try it, and you might have to try a few different numbers before you get the right one. it might have taken a few extra seconds to write the person's name down when you wrote the number, but you didn't think you were going to need it again. you'd be suprised at how often code is written this way - it takes more effort, time and discipline to do it in an organised manner, and often there's pressure to get it done ASAP rather than to do it "neatly".

You would have to allign the clickable overlay with the view. And the view tends to be a bit more shaky trackIr. You could ofcourse hit "centre" and then disable the trackIr but i'm just trying to picture myself doing that just to press a button with my mouse - i dont think so. Maybe some would. I'm not saggin the idea at all. I think it sounds very good for those who really like clickable pits. But i think that it would be more usefull to people who uses a joystick hat to look around. yep, you are right there, but a dead zone in trackir suffices (that is what i use since i hate view moving about when i am on an attack run) or you could even program a centre view/disable toggle key in control manager. i wonder - wouldn't it be great if the overlay could know the pitch and yaw values of the pit ingame through LUA or shared memory queries and apply them to the overlay. hmm.. i don't think you'd need to know how far away the panel was from where the view is pivoting, though doing so would prevent zoom level being a factor.

ruggbutt, you really need to stop the snide remarks when someone with expertise you know nothing about makes comments that you don't like. the "if you can do better" argument is well.. not even an argument, it's not even a justification - in fact it's nothing.

not sure what you mean by that - in what way? trackir is used as a seperate device than the mouse. so you use the mouse for the clickable pit and you use the trackir for looking about.

actually there is a chance for one if i understand something ch users may be getting. i might be a bit confused on it, but something is being worked on for the CH control manager software - it can detect where your mousecursor is and if you click, it can peform commands based on it. this means that if an "image map" (for those familiar with using them in webpages) is made of the inside of the cockpit and suitably programmed, we can actually have "clickable pits" in sims that don't support them natively. of course , you would need to be at a certain angle etc, but i am sure that with control manager you could program the view to go to default and the correct zoom and allow it to be done. this might be a little way away - was speaking to bob church about it today.

heheh. ok.

it really depends on the kind of thing you do whether you will notice the problems or not. not EVERYTHING is broken, and you can do some limited stuff and it all be ok. My thing was wanting to do multiplayer co-op in our squad, or head to head beyond simple gunzo dogfights. the kind of problems we encountered were crippling - missiles not exploding (we're primarily a NATO squad), HUGE warping - we're talking kilometers at a time, AI air defenses not working, enemy aircraft turning invisible, players getting that light blue screen bug so they can't see anything, the AI seeming to home in on one player while ignoring all others. It was simply unplayable. we could do some simple stuff, like takeoffs, landings and circuits and bombing convoys but - that gets kinda boring after a few weeks ;)

beer is good :)

soooon.

a LOT of development is personal, but there are methods taught world wide - generally in the design side of things. That's how educational institutions manage to teach it. Also, some languages are more formalised than others - the newer ones tend to be less so. just like anything else, you can either make your own choices in how to do things, or follow other "best practices" or methods. for err.. finiteless.... often a messy program works - that's the whole point of writing the program, the problem occurs when you are trying to add or tweak things within it or troubleshoot it.

I wouldn't put too much credence in what he says. Everyone on the net is an expert.............................and a millionaire. actually what he says makes perfectly good sense, and is a logical explanation for the cascading effect that fixes are having. i've worked on a lot of other's people's code (brought in as a consultant to fix problems in software) and i understand totally what he means by ambiguous code. when programming, a lot of people tend to sit down and start coding right from their head - ESPECIALLY when they are under time constraints. The code doesn't get commented properly, ambiguous variable names are used, subroutines are ill structured and generally you end up with a program that is like a carpenter hammering a house together rather than working from a blueprint. The house ends up being the result of the skill, foresight and experience of the carpenter (and no-one is perfect), whereas even a mediocre carpenter can follow a plan and get it right. This very often leads to code that does not make sense even to the programmer later without actually working back through the code and "reverse designing" if you will. I've had to sit down for weeks at a time reverse designing systems so i could track down a single logic error, because you have to design to the way they coded it, not the way they SHOULD have. In the end the time you save just coding is just false economy unless you got it perfect and you have a perfect memory. Such a programmer would be worth their weight in gold, and i've not met one. The whole purpose of the design process is to allow you to get it logically right before you even start coding, and you work to the design. Makes it very easy to insert extra functionality too because you can look at the design and figure out where the extra functionality should connect. of course - this is all conjecture - but to anyone with professional programming experience in reasonably large projects the delays and the difficulties being encountered are atypical of undisciplined development.

oh btw - if any of you guys play counterstrike, I admin a couple of servers. If there are admins on it's pretty much f***tard free. 66.150.164.58:27015 best times are usually in the evenings after 6:30pm when all the other old folks get home from work.

I think we ALL want this patch to be as complete as possible, because let's face it - i don't think there's a lot of faith that we're going to get another patch afterwards unless there's something HORRIBLY wrong in the opinion of the devs. HOPEFULLY - 1.02 will do the trick. I don't expect flawless (not the way things have been going and after reading lexicon's quick analysis of the code he has seen) but I do expect to be able to do the stuff our squad wanted to do - online engagements in as realistic a manner as possible within the sim without crippling bugs. I suppose it's come down to what is an acceptable level of bugginess. How can you even quantify such a thing?

at the risk of getting spanked for referring to something in a locked thread... seriously - what rammstein said about ED and UBI OWING us a product that works is spot on. We've already PAID for a working product and we have yet to receive it - what is so hard to understand about that? all this other stuff that has started BECAUSE patching to 1.02 is taking so long is fluff. It changes not a thing that we still don't have a working product. I too fear that we're going to end up with something that is going to have bugs left over that will cripple certain aspects - i hope we don't, but when i see stuff like the cascading effect of fixing score displays i can't help but wonder what kind of state the code is in and whether there's stuff being broken that isn't being noticed. I can't expect UBI or the betatesters to go and retest EVERYTHING after each patch. With each passing day i feel more and more pity for the beta testers who are testing this frankensteins monster without getting paid to do so. The problem isn't rammstein, nor criticisms (no matter how oft repeated), the problem would be those who can't read his posts or those of others without getting undies in a twist and becoming insulting. So far there's been very little undie twisting in these forums. Cheers.

aah - i was wondering about decompilation myself. It would be a very good way to get past the "you haven't seen the code so you can't spot bad coding" argument. unfortunately decompiled code is a pain in the butt to read as whitespace characters aren't included - like reading a whole book with no formatting. you can infer a great deal about the code by the difficulties that are occurring when one thing is altered causing a chain reaction that breaks other things, but i don't expect everyone to be able to understand WHY this happens without a long and tiring (and very very boring) conversation about program design and keeping your data structure organised. what's even scarier - is what if there are "other" seemingly unrelated things breaking that aren't being noticed because they were working quite well before? time to cross fingers and HOPE. I don't think posting the source would be a good idea.

it must SUCK to touch one thing and it break another.

in the EU this is already coming to pass. Here in canada we have industry sponsored groups like CAAST who enforce the rights of software publishers and developers, yet there's no body sufficiently versed in software protecting the rights of consumers.

Not to take anything away from the beta testers, but the moderation over at the UBI LOMAC forum stinks to high heaven - whether it's the act of one or many of the moderators the whole lot has been given the reputation. I see the post above as illustration of that. The complexity for beta testing is very reliant on how good the shape the software is in in the first place - and we can see from 1.0 and 1.01 that it wasn't good. Trolling for bugs is a very time consuming way of doing it and i would hate to be in the LOMAC testers shoes - especially trying to test without being able to yell over a partition at devs for immediate feedback. Don't judge the beta testing effort from the forum moderation (if you can call it moderation - it definitely isn't moderate), the two are seperate, even if some people belong to both groups.

i'm glad the problems are being found and fixed. i'd hate to have waited for 7 months only to get a patch that still leaves aspects of the game crippled.