In Development for 08-06-04 V1.15 is out the door and most of our focus is now on 1.16 and future dev. Most I say because we still have a CTD out there in 1.15 which we are working to nail down. Weve determined why it is happening and when and weve put a fix into beta. This one has been most difficult to find as it does not produce any logs. The beta team now has an executable that produces logs and we have sent them into the live server to reproduce it. Hopefully that will pay off in the coming days. I wanted you to know that we are aware and working on it, priority number one at the moment. With that said, lets take a look at whats currently in development.
In Development
ATGs:The work on ATGs is moving apace well. We expect them to be ready for release with 1.16 in the coming weeks. The French gun has been particularly troublesome as we need to make a variant that was used in North Africa but is not documented well and surviving examples are poorly restored. This gun will also be different than other guns in that it will likely have a small traverse angle but will be quickly and easily redeployed.
Tanks:The tanks are coming along nicely; both the Crusader 6pdr and the PzIVG are all but complete. When the set is complete as a whole well add them to the RDP choices.
Differentiated RDP:With the introduction of the new ATG it is more imperative than ever that we have research times that change based on what and how many are being researched. Basically this system will make lesser projects more viable as they will be faster to introduce into the game than more complex projects. This change will lead to variety of RDP changes in the future that will culminate with factories turning Resource Points generated by the facilities in towns, into vehicles.
New Buildings:The new capture office and town buildings are looking great. Next up is a new church. Im hoping for a bell that dings when you hit it, myself.
First Person Infantry Revamp:Toto is working on a long term project to improve the look and feel of all first person infantry art and animations. Nothing is expected for a deliverable soon but keep an eye out for his updates.
In Game Map:Terrain II work has given us our first pay off in conjunction with the new UI tool. For 1.16 were looking to add the functionality from the UI map into the game. Once thats complete and we have the associated strat messages (like ownerships) displaying well be in a position to start adding other features. In fact Id like to have todays topic of discussion to be about what you do and do not want to show in the in game map.
Blowable Bridges:Recent strat work on the host has made available the ability to have destroyable bridges in the game. Currently our plans include the ability for sappers to use a tool kit on them to help them rebuild faster. Satchel charges and bombs will be able to destroy them. Weve got a lot of tweaking to do on this system but our initial stab is 4 sc250he or f200 bombs to do the job and about 10 sappers worth of satchels. Player expectations should be that most bridges will likely be blown when encountered and an effort to secure the bridge head and commence repair operations will be needed in order to make it serviceable. We are undecided if they will auto rebuild and if so it will likely be slowly, very slowly.
Capture Objectives (Attack Objectives):Deployment calls for an acting brigade commander to place objectives that his officers can post missions to. Weve added the base functionality for the fallback objective, though it will be much different under deployment and were looking at adding capture objectives next. These objectives will allow the drawing of radio tables in towns where they are placed. We would like them to limited in number available to based on the server population though translating this to always on brigades may be difficult. Regardless these will work o concentrate players for battle and give a strategic level of play to the game that is clearly visible from the map. Were still in design on these so I cant give more specifics but Im guessing that next weeks community manager questions will be filled with these so well likely spend several days next week nailing down the finer points of the design.
Id like to start a discussion thread for this week with the topics of in game map and objectives. If you have beef with the objectives or thoughts youd like to share, wed like to hear them. Now that fallback and HAAC have been in for a few weeks they are starting to settle out and we can begin evaluating changes that may need to be made. That discussion thread is
here.
Here are the community questions gathered by our community management team from the forums this week.
Q: The Fallback is a heated topic. Can we expect a change in the way it
operates anytime in the near future?
A: Deployment will certainly bring about changes as you wont be falling back to a place that has any supply at all, youll only be falling back with the supply you have. This level of risk management will be crucial for the success of a brigade. In the interim I am not certain but it is possible. Fallback is intended to give control of a town over to the enemy and regroup forces to change a loosing defense into a winning defense. Before fallback came into the game, the only real defense was bunker duty, which was of little effect. Fallback allows for an enemy caught off guard and without a prepared defense to mount one. Fallback, in game play terms is no different than an enemy capturing your AB. It allows offensive firebases to remain open while the defensive firebases open giving a fight over the town to combatants on both sides. In that way it is functioning correctly. No changes can be expected to that functionality. There may however be other changes needed to address how it is or is not being utilized. There may also need to be time for player tactics to adapt to the changing rules, as is always necessary when the game changes in any dramatic fashion. On the other hand I would expect some changes to HAAC in the future, though the outcry of the player base seems largely diminished on that issue as of late. HAAC needs to have more risk involved and needs to stop rewarding the defender with hundreds of infantry for failing to actually hold control.
Q: We have heard that TOE will be in 1.16, and we have heard that it will not. Will it be in 1.16 or later?
A: ToEs will come after capture objectives, at this time it does not seem likely that ToEs will be in 1.16.
Q: Will deployment limit my ability to play in different areas?
A: No, though it will reward you for sticking with your group. When new guys come into a unit, they are generally not as well known and respected as unit veterans.
Q: How will attack objectives work?
A: Attack objectives will be placed on the map by command. They will enable the capture of the town they are on and thus the advancement of the supply chain.
Q: With the new way that nades cause damage, are you planning on expanding this into other areas, like bombs?
A: Probably at some point though its effect on bombs will not be as beneficial. Increasing the amount of shrapnel generated by a bomb will decrease the average shrapnel weight for each generated shrapnel piece. This is less desirable in most cases.
Q: Will we be able to blow up bridges in the near future? If so, how will it work?
A: In beta, sappers have the ability to place satchel on bridges and blow them up. We are adding the ability for sappers to use a tool kit on the bridge to affect its repair. Bombers will also have the ability to blow bridges. Under deployment this will change somewhat as you will be required to have an objective place on a bridge to repair or destroy it. That objective will enable officers to post mission to that objective and enlisted men can then join in the mission to complete the objective. For now, the system will be more open allowing players to affect it as they wish. This will undoubtedly raise calls of griefing amongst the players but in the end, griefers will have a hard time overcoming the wishes of the controlling side.
Q: Will lights be introduced in the future?
A: Yes. Once support for older video hardware can be dropped well introduce these.
Q: Have you given thought to flares? If so, any plans on them in the near future?
A: Flares are in effect lights. Currently the most popular cards on the market do not offer to display a great enough quantity of individual point source lights to adequately reflect their expected usage in our game. Until we can show everyone the flares going off overhead then we wont choose to show them to only a few. I think theres actually a deeper question here, such as Are you planning to do anything to affect night fighting? but I could be wrong.
Q: Any plans on increasing the number of factories in the near future?
A: Not in the near future no. Until we have better bombing tracking and a need to have more factories to support changes in the supply system I can see no real need. Its likely that Im missing something in this regard; if there is a reason we should add more bombing targets please drop me a mail.
Q: Do you have any plans on adjusting the radio timers down?
A: No. Radios are an abstraction of securing land. If that land is truly secure then it really doesnt matter how long the radio timer takes. If any changes were made here, Id like to see the removal of the timer and set the control to an area/time equation that ensures that your supply isnt moved to a place that you dont actually wholly control.
Q: Does rafter do anything useful?
A: Not with a 10 foot pole.
Thats all for this week. Dont forget to drop by the discussion thread and share your mind.
Well see you on the Meuse!
_________________
Dana V. Baldwin
"Gophur"
Producer
WWIIOL
The only Hungarian squad in WWII Online
HUN HQ: http://www.wwiionline.hu
Comments
Ho hum ..... bridges have ALWAYS been blowable ... Rats merely set the damage threshold to the value of a small tactical nuke to prevent bridges being blown for the past 2 years.
Everything else on that list generates a huge yawn. No word yet on actually getting what is already in game working correctly!
hehe, nice last jab there, too bad it comes off as jaded.
You do realize that more of this game actually works very well then doesn't right? If you did then you'd realize how silly that comment is, and how far from the truth it actually is. The only real issue they are working on right now is the CTD while flying, which come about with 1.15, they have been slowed in tracking this bug because it wasn't creating logs when it crashed to desktop, but they've got beta testers with clients that will crash with a log, so expect a fix soon would be my guess. Always helps to know where to look doesn't it?
That list is a great one. Many of the things mentioned there have been long standing issues or are parts of the puzzle in what is needed to bring in the Deployment and Brigade Spawn systems. I guess its not as much as you'd like fast enough but for me I like what I see. What more could a guy want from a point release? New ATG's, new Tanks, new Target, new 3D buildings, which add plenty of new content to the game, and then there are more core rules changes like attack objectives, changing hold at all costs, new map functionality... wow sounds pretty cool to me. But then again, I still play the game, do you? Might be part of the reason I still get stoked about it.
And yes most of us long time ww2ol players know that bridges were blowable with large damage values set on them. The point they are making was that now the new strat host work allows us to blow them and repair them and the strat host will track it. Wether or not they always could before if you had a small tactic nuke is irrellevant the point is that its new functionality and something we couldn't do before, bridges were not part of the strat update system, now they are. One more good thing KFS1 has helped bring to the game before they had actually hoped (terrain2 was best guess before). It's a very real and tangible addition to the game and it will effect how river warfare will be waged. Only those who don't understand it would yawn over such a cool new addition to the game.
Yep, you look pretty jaded to me. Thats fine, but atleast make your arguements have some depth and meaning, cuz anyone who's been around this games development for a decent period and knows the scope of things will gladly hand you the reasons why thats a pathetic dig and nothing else without breaking a sweat. Pretty much like I just did.
Beatbox's new account mabye?
www.Razorbacks2.com
www.razorbacks-squad.com
Ugh .. please do NOT associate me with that creature!
Don't get me wrong, new content is always welcome. It helps drag in new players who may not know any better, and get so excited by the appearance of the 190, or Spit IXc, or PzIVg that they don't notice how many core elements of the game are simply BROKEN!
Or are you suggesting that the physics model for the game works correctly?
Because if you are, RickB would be pleased to hear it. He's refused to do any work on it for months claiming that it is a steaming pile of garbage, and any attempts to get it working correctly would be likely to break it irretrievably.
Do YOU have any idea how the code in WW2OL is held together? Remember the really bad stutters of a few months back? They appeared after RickB removed what he said was a totally useless section of code from the physics model. The code didn't actually DO anything ... and the Rats had absolutely no damn idea why players were suddenly getting these awful stutters. RickB ended up reinserting that piece of worthless code just in case it made a difference.
It didn't, but does that tell you something about how the game works?
The Rats have NO DAMN IDEA how half of this game works! The guy who wrote the physics code no longer works for CRS, and that code is not documented at ALL! That's why we get these weird bugs in every single damn release.
It's like having a car where the engine won't start, and emptying the ashtray just in case that fixes the problem.
Well no offense to RickB but to quote my ol' pappy, "He might be able to water on water, but he still scares the fish." I've seen them introduce their own code over the last few years that had nothing to do with physics, memory functions, grpahic engine overhauls etc and they had their issues. Its easy to point fingers at someone who is not there to defend themselves or their work.
Don't get me wrong I don't blame him for saying he doesn't want to go through that undocumented mess of a physics system. I doubt anyone in their right mind would want to do so. With no documentation that is pure lunacy, and also having read his blogs I know he's alot like the programmers I worked with long ago who were very anal about code change and documenting any and all additions or change. Nothing wrong with that attitude. But that does not mean its a completely garbage physics engine, after all we're 3 years into the game and the only thing that is a glaring issue with the system is that airframes have lateral instability that does not become an issue until you do some really stupid things as a pilot (ie: induce heavy rudder input greater then 25% instantaneously), and due to the fact we all have super human strength in game to be able to do so, and also lets not forget planes don't have structrual stress damage which would be another reason super human strength we have no would suck incredibly...
Let not assume too much about the initial phyics programmer, he might have documentation of his own which for whatever reason he never had time to make presentable, or decided not to include for whatever reasons, hey I've seen million dollar Heating Ventillation and Control designs that didn't have "Fan curves" heck I'm breaking a set of plans down which have piss poor documentation, the reasoning behind it is likely that nobody had the common sense to ask the right questions which would have forced the designs to properly document their design and fan selections etc... Lack of documentation, or messy programming habits does not in itself mean the code does not function, it just means understanding and altering or working with it in the basis Rickb and the Rats need to is not practical, it would take just as long to sit down and figure it out as it would to re-write a new system, and given the fact that some or many of the requirements or spec's for that engine will have changed it makes more sense to do a rewrite, alteast that is what I took from RickB's comments on the physics engine.
Theres alot of things in this game that have been re-written or need more fidelity. But the way you're looking at it we should throw the baby out with the bath-water. Your over-stating the problem greatly imo, if it was as bad as you say the game would be unplayable, but on the contrary it plays very well most of the time. Sure it needs plenty of improvement in more areas then just the physics engine, but is that not what the Rats deliver each patch? Improvement? I think so, sure I don't agree with all their choices, radial clutter was a waste of time to me, but its their game they must choose its development path. Who am I to judge, just as I question who we are to judge a physics engine we have only heard talk of and have no real understanding of what it actually is. All I know is that it works better then most if any I've ever seen. Especially since it functions and operates not only on planes, or boats, or trucks, or tanks, or infantry, but all of them. That's pretty amazing when you think about it. Not perfect, but still amazing.
Do I want to see them tell RickB to rewrite a new physics engine? Heck yes, but I can also understand why they are willing to say, "It works well enough as is, we can get more bang for our buck elsewhere for now." They didn't say it was perfect, but as I've already said, it works well enough now that they don't need to focus on it. You seem to feel its totally FUBAR, but I interpret RickB's words a bit differently. You see, a man who says "I won't work with that mess of undocumented code." can not actually tell you where it works really well, and were it does not. Because he just told you he is not willing to take the time to figure out how it works. That is acceptable, as one who has programmed a game or two and used other persons code I can agree with his assessment. It IS a waste of time to do that. But it does not mean that code is crap or useless, just that it could be better, documented, and that he doesn't understand it nor has any desire to try to understand it. He feels he could do it better himself, and he's likely right, but only time will tell I would imagine.
See where I'm going here?
My big issue with your reply was that you misconstrued the point about the bridges making it sound as though they were not adding or doing anything, insinuating that it was a smoke and mirror trick which it is not as I explained. Now in regards to the physics engine you claim it is terrible, utter crap and likely the cause of bugs in the game... based on what? The opinion of another programmer who doesn't like the mess he's been left to sift through. I agree it sux but its hardly a strong basis for judgement of the engine itself. No better then heresay really.
What I am suggesting here is that neither you, nor I, nor RickB for that matter understands the Physics engine of the game well enough to know what it uses and does not use, what it simplified and what it focused on to make the game function as close to reality as it does over so many different levels. And to suggest otherwise is to overstate both your understanding of it and how it works within the mechanics of the game as a whole.
We don't know anything for certain. Lets not pretend too. My issue was with how you were portraying your issues with the game based on limited knowledge and being vague about those issues all the while over-stating the problems. I still contend that if the major core functions of this game were as broken as you claim them to be then the game itself would be pretty well unplayable, but since the game does in fact play quite well it is not as broken as you claim.
Instead I would counter that when you are constantly changing, or adding to a game engine that is very large and complex as is this one, and that many elements are inter-related on many different levels you can not always understand every facet of every change or the issues that might arise be they from the client, the server, or the software be it the graphics engine, physics engine, network/transport layer, memory functions etc.
You are overly simplifying your statements, but that does not make them any more true imo.
Just my .02's and the only real problem I have with your discourse, really.
Did you actually read what you wrote? Bearing in mind that EVERYTHING in WW2OL is dependent on the physics code - ammunition, tanks, aircraft .... EVERYTHING ..... and you say that "understanding and altering or working with it ..... is not practical".
Hell man ..... its the CORE of WW2OL! And yet the guys who are developing the game don't understand the core programming of the game!
That's all I'm saying as well. The Rats are devoting time to issues like radial clutter when the core programming of the game is screaming out for a re-write!
OK, so we agree the lead programmer for the game does not understand, nor does he have any desire to understand, the core programming at the center of this game. I'm glad we agree on something!
The importance of understanding the core programming of the game cannot, in my opinion, be overstated. Having this mass of physics code at the center of the game, like some modern day Gordian Knot, leads to all kinds of issues we've both experienced over the past few years.
When was the last time the Rats released a patch that did NOT introduce a serious, debilitating bug into the game? Frame rate freezes, stutters, CTD's, Mac Players being able to see tags on BOTH sides, HE bugs, MG bugs, Panchars, Daimatty's, unkillable 232's, unkillable Havocs/Db7's, 500mph Hurricanes.
Sure, those things get fixed over time, but even those bugs don't get fixed by treating the illness, they just patch over the symptom. Remember the 'fly inverted faster' bug? How did they fix that? Not by modifying the flight models of the aircraft (treating the cause), but by introducing code which simply kills the engine after a certain time inverted.
Grab an aircraft and take it up to 10,000 feet. Turn the engine OFF and roll inverted and glide around for a while. After a minute or two black smoke will pour from your engine as it fries itself, even though its OFF.
Or the HE bug. Remember that classic? HE penetrating tanks and killing crews? How did they fix that? Not by addressing the physics model (treating the cause), but by effectively setting the rounds to 'pre-detonate' well away from the enemy tank. Why do you think 232's and Panhards are now invulnerable to HE fire?
That wouldnt be quite so bad, except that Hatch comes on the forums and makes a totally bogus claim about the reason for the bug in the first place ... a claim which was demonstrably untrue to anyone who thought about it for more than about 2 seconds.
Everything is connected to everything else in WW2OL. The glue holding everything together is the physics code at the heart of the game. If that works, everything works.
But trying to develop the game with the current physics code is like dropping a Ferrari chassis onto a Volkswagon engine ... it might look pretty, but as soon as you look under the hood you'll realise that its just a sham.
Well I have to dissagree. Mostly on 3 major points.
1 - The physics engine is not EVERYTHING in the game. It's just what you seem to feel is worth mentioning, but that does make it accurate as I see it. It is not, and stating as much does not make it any more true.
2 - The physics engine is not completely broken and in need of immediate rewrite. And I guess the strongest case I can offer as proof of that is the developers themselves. If it was the case they would have their head coder working on it, but instead he is current rewriting the Update System/Transport Layer (see point #1) which will address more problems with the current game then the "Lateral Instability" issue which is in my opinion the only glaring issue outstanding with the current physics engine.
3 - Your assuming all those things are by-products of the physics engine. Now I'm assuming you are doing this because you feel the physics engine runs everything. Some of those things are modelling errors, some of those things are physics related, but why do you immediately assume all things which error with the physics engine are because of the system itself. There is just as many chances that the error was a result of a coder making an inappropriate procedure call, or providing inccorect data, or misinterpreting or using the resulting answer it provided incorrectly.
You see, from my perspective you are both over-stating and over-simplifying the issue to skew it in your favour or make your case. I'm not saying your totally off base or wrong I honestly can't say as I know enough for certain about what we ar discussing to say anything for certain I'm just trying to point out where I perceive you are not seeing things as clearly or accurately as I think you could, although a few points you state are indeed totally wrong. Things like needing to know everything about a system in a program to be able to use it, that is totally wrong and anyone who has used Libraries and Open Source will tell you as much.
I just question some of your reasoning and perceptions of the issue. I don't think you've made a good and clear case nor do I feel you understand the system or programming in general well enough to conclusively say you do. But it is my belief that this conversation is going no where fast and I have other duties and interests I must attend to so I'm going to avoid doing a breakdown reply and try to move this to another level. For one because I believe that level is beyond both our understanding of the system being discussed. We are end users, we can't really know anything for sure, we are just guessing. We have to keep that in mind and try not to make had statements about things we really can't know for 100% certainty imo.
ciao,