since this discussion came up again recently, i wanted to start a discussion and list of features for a potential 1.13 v1.0 "stable milestone release".

Definition: the "stable milestone release" is a version or package of the 1.13 project, that incorporates as many new features that work 100% as intendend and as few bugs as possible.
it is the first real release version of 1.13 project and serves as the base for modders to build upon. it is separated from the regular 1.13 SVN developement, since recent features are not to be implemented. instead, this release is to be updated through patches or newer versions much less often, but also more thoroughly.

think of the SVN updates als minor internal releases and the milestone packages as mayor official releases.

the aim is to provide a stable modding platform on a fairly regular base with a new, bug free release every 4 to 6 months maybe, so modders know what they are dealing with and don´t always have the hassle with new bugged features and constant changing code and engine.

the guys responsible for this will be the current 1.13 developer team and the coders.

as for now, i would recommend a aimed release date for "stable milestone release v1.0" of christmas 2007.

the release build should incorporate as many bugfixes, flawlessly working features and improvements as possible and a clean and final data structure, especially in XMLs, as well as the corresponding and equally flawlessly working modder tools.

the aim for the coder team, which will have to provide all that is, to assemble a list of minor and major features, which they are pretty sure they can get done 100% until the release date.
mercilessly excluding all the recent new features and bigger changes (like new inventory project) that still are flawed and need more developement.

minor features are things like AI improvements, new animations, new weapons and items, cleaned and streamlined code etc.

major features are things like the new inventory project, bigger maps, heavily changed and extended XMLs, externalized prof.dat, LUA.dll and all things that can severely improve and change the game experience and moddability.

so i hereby pledge the dutiful coders of bearspit forum to gather and think about this.
can this be done? an if yes, until the desired release date? what would you need to do and who would be able and willing to coordinate this?

come and share your thoughts and ideas about it. it´s a worthy goal to work for, don´t you think?

since the main focus for this "milestone version idea" would have to be stability, i'd go for critical bugfixes first:

vehicle CTD: i already made a suggestion to Lesh on how to evade this without having to shuffle all slots around, exactly the same way as it is handled with more than 18 mercenaries, the game just tell you you can't hire any more. same would have to go with vehicles, if you attempt to enter a third vehicle, be it in tactical or strategic screen --> error message and your action to enter the vehicle is aborted

map loading CTD: this one's the biggest bugger around as soon as you reach mid to endgame stages. however it is intermittent and apparently, not everybody has it, soo.... not sure it'll ever be fixed. Biggest issue for me at the moment.


i don't want to end up with an endless wishlist, but certain primary and secondary modmaking requirements should be mentioned because you're idea is to have modmakers be able to work with that milestone release:

primary modmaking requirements

RPC and EPC face coordinates. anybody ever looked at the UC-1.13 hybrid betatesting thread? they were majorly screwed by the lack of an externalisation or a hack or whatever it would be for those faces. and NO, these coords are not part of prof.dat and don't depend on the lack of prof.dat externalisation.
They are in the exe most probably just as a set of 4 values each RPC/ EPC in the exe/ source

externalised mining sectors
the sector in which income is generated and to which to "free" head miners are automatically assigned to require to be editable if anybody ever wants to seriously change ja2 town placement. Similar things go about "facilities" such as hospital, shooting range, airports. However in my book, mines have a certain priority, as they're usually the most important targets for the player.
then airport, bobby ray availability sector and heli refuelling sites are important too.

secondary requirements

i was going to put additional undergroundlevels to the primary ones, but then i changed my mind. However as soon as somebody can move the mines and the towns more efficiently, new sublevels will be required, for any story changes and town layout changes they have to be changeable.
i remember sending a mod that did such changes to rowa21 some months ago but maybe the code wasn't exactly what was wanted... i don't know, haven't heard about it anymore.


i may have forgotten about many things that i'd add to secondary requirements. maybe i'll add them later. Maybe other people can add comparable things. maybe a more stable editor to the critical bugfixes, as i'm not the only one experiencing editor freezes and crashes, but then, maps can be created in betaeditor and only items added in the 1.13 editor so these problems can be circumvented for the moment
the editor would come in where mauser names modmaking tools. the editor currently does have a bit of a screwed mal loading/ saving routine which effectivly spoils the possibility to easily switch your custom data folder when working on mods, so there's room for improvement as well.


i knew it, i would end up with a long wishlist. dang.
but it coulda been pages longer, so yeah...

oh, yeah, i forgot another secondary requirement would be the externalisation of the more important text strings in the exe/ source

i sent kaiden a rather detailed list about that some time ago.

most important for any modmaker would be the excessive occurences of Deidranna, arulco, skyrider
the email adresses (Enrico, john kulba, etc.)
certain quest pop-up messages (nope, not all of them are in quests.edt, unfortunately)
and a number of other texts for example hardcoded sector names (e.g. Meduna airport)

i call this secondary requirement because it isn't really technically needed to make a mod work, but to design any sort of credible quest changes, arch enemy change, setting change, helicopter pilot character change etc. it would be needed.

Most obvious example is the "silent skyrider" feature (what if my chopper pilot has a totally different name, huh?) and the description of difficulty modes ("deidranna will kick your ass HARD". Too bad there's no deidranna in the game...)

Hmm. How about militia doesn't turn hostile when one of them stupidly steps on one of the mines you've placed? That could really mess up someone's game and force them to reload.

How about militia not turning hostile under any condition?

yeah means you can kill those 2 b*****ds in Balime and not get shot to pieces

militia and civ's shouldn't step on landmines at all. they never did in vanilla ja2 and this was better that way if you ask me. i though i'd read this bug was fixed somewhere...

however, not f*cking up with the militia shouldn't be that critical an issue, should it?

Yeah Milita are important seeing as they are so much more useful than before. Also the advent of roaming Militia means things don't just get slow in towns...

While I agree this would be a good new feature it is bound to be really buggy. There is specific sector mine stuff hard coded all over in the code and probably int he scripting and a lot of it is not obvious. Moving mines will require certain other things too like having Crepitus lairs under them unless we disallow Crepitus if mines are moved (which wouldn't bother me).

you ever had bugs in chitzena mine?

that's one of the mines i moved in vengeance

the other one was cambria mine, but i think you can't have bugs there either... i tend to forget these things.

as far as the crep lairs are concerned, they can remain wherever they are and you add a teleport, we wouldn't really need new crep lairs, but it would go into a similar direction as the additional sublevels. But that would be up to the modmaker who moves the mines. There don't need to be any crepitus in this fictional modmaker's mod. I think it's wrong to bind the crepitus to the sector where you get steady income. it's basicly only the steady income and the automtaic distribution of the head miners (even this is only for convenience, i guess it could be done without)

if my steady source of income is a bank that i blackmail, i don't need creps appearing in their vault and eating their gold reserves ;-)

the crepitus are unrelated to the sectors of income. only in the vanilla sci-fi storyline arc, and even there you have a crep lair at tixa, so this is practically irrelevant. What's important to move the towns is steady money income location and auto-distribution of head miners for convinience and saving character slots.

It's great that this addressed, finally!
Please do it, guys!

Thank you so much.

Uh, it can be important in some cases especially if the Queen is Aggressive and has thousands of troops. Your defense of a sector can become totally compromised if a militia happens to step on a mine and they all decide to turn on you. It would be easy just to not have militia go hostile, ever.

allright guys, before this spins off into another "features i´d really like to see asap" thread, i want to make clear once more, that it´s completely up to the current coders and devs to make this happen or not.

this said, i would really appreciate, if the devs and coders could speak up here and tell us their perspective and opinion about the whole thing.

and i also want to stress, that this "milestone release" should only be assembled with features that are already implemented as of now or in immediate developement, so they can most likely be implemented, tested and bugfixed until the desired release date.

everything else would be for the following milestone releases, no matter how urgent these features might be wanted. we just have to radically concentrate on what we have just now and what we can possibly archieve in the next few months, before all the new coders wander off again, leaving even more half finished and buggy features in the project.

my intention is also, to somehow guarantee, that those people currently working on the coding of new features and general bugfixing, finish their jobs as soon as possible before taking on new features, that possibly never get completed properly.

Players and modders alike now need stability and dependability of the general platform and the corresponding tools, so they can learn and try to utilize all the new features we already have.

it is time for this project, to go onto the next level and become something more than an "eternal alpha". Especially since the sequels to JA2 are about to be released shortly.

because if those prove to be more stable and moddable from the beginning than current 1.13, we can assume that a lot of manpower will wander off to these new, fertile grounds, probably leaving 1.13 dying slowly which ot clearly doesn´t deserve.

but the only thing that can keep the interest on 1.13 alive in the community and for the casual Jagged Alliance fans out there, would be new and exciting mods.

personally, i just cannot stand playtesting the vanilla arulco setting over and over again.
always the same maps and only a new feature here and there.
MFM mod and DBB mod prove to be quite some fun together, but i won´t touch JA2 again when i am through with my current game until i see some new mods.

and for that, we really need a stable base release and flawlessly working tools.

it´s a matter of reason.

so please dear coders and active developers, take this into consideration and try to find a consensus and make a decision to give the community what it direly needs, for the sake of the future of the project you are working so hard for.

What is MFM mod?

Militia Factions Mod from Will gates my clueless friend:

http://www.ja-galaxy-forum.com/board/ubbthreads.php/ubb/postlist/Board/40/page/1

wow, didnt catched it... i thought it is not finished...

wait... is it possible to combine DBB and MFM?

no, it´s not really finished. but in a playable state anyways.

and yes, since 1.13 version of MFM doesn´t have a own weaponsmod, it´s fully compatible with DBB mod, which is exactly what i am currently playing.

i suggest you try that too. and now, please back to topic again.

allright, any response from any coder/developer?

anyone? ANYONE?

RoWA21, Overhaul, Kaiden, Starwalker, SpaceViking, ChrisL, anyone?

please someone answer here and if possible, discuss this matter internally, then give us a response and perhaps a list of features and a date for release?

please someone responsible answer this thread, it´s only for the good of the project and community!
nobody asks anything impossible or proposterous here from anybody.

Well. The least I can do is sticky your topic. ;-)

thanks Marlboro, that would be helpful i guess.

I am not a coder, and internally I did not hear anything about this topic...

RPC and EPC face coordinates
Could these result from redrawing 600x480(?) / 800x600 / 1024x768 ?
I'm thinking that the screen-fill (hire 1 merc and s/he has 5 empty boxes next their face)
This screen fill has been made in a higher-res, but the portaits may not have been.

no it doesn't.

it comes from the fact that RPC 48x43 face coords aren't listed in prof.dat, and the programmes used to edit those coordinates are incompatible with 1.13

coords don't change with resolution, otherwise you'd have the same issue for any (even existing) Mercs, yet the problem is only and exclusivly with RPC's.

technically, it's just a small bunch of numbers that i can't imagine to be used in that many places.
but circumventing the edition of those coords leads to a redesign of most custom faces, renders some 3 RPC faces inanimated (those that tested ja2 1.13 RR will know what i mean) and, for example for the existing faces that existing mods are using, makes most of their RPC's incompatible with 1.13, unless the (48x43) faces are redesigned from scratch (which is a PITA if you already had your characters working in earlier ja2 versions)

for example UC 1.13 mod hybrid had to redesign quite a bunch of their RPC's. I've dropped some of my RPC faces as well.

come on guys, i know you coders are all busy n`shit but you could really take this a little more seriously.

please some dev take the lead on this and at least give it a try.
make a official deadline and to do list, so every contributor knows what to do and until when he should be finished.

I am totally with Mauser. I think we need a good start point before big map, 100AP and LBE changes to conclude the essence of 113 developments within the last two years.

the "Camouflage" skill should be removed entirely.
Shadow could be equipped with a ghillie suit from start on.

Thats not a bad idea. That would allow for better choice of skills for him too.

Is he a sniper or a CQB guy? Cos if he's CQB then the Ghillie suit won't help much. But the Stealth Ops equipment would...

shadow should have stealth and night ops...so a ghillie suit would be right prolly

the stealth suit is sci-fi only, and the starting gears only differ by difficuilty level and tons-of-guns enabled or not.
but maybe you could make a unique custom ghillie, providing some minor to average protection while maintaining his permanent camouflage? perhaps he also would refuse to pass it to other mercs, making him more unique even.

and to your question wether he's rather sniper or cqb, i'd say both because he is physically pretty strong to both hit and run as sniper, but also to sneak on people and cut their throats.
however he has the "lone wolf" trait which is maybe better suited for the lone sniper than for a stealth team.

Maybe a custom Camoflaged armour (based off Guardian Vest, Kevlar Helmet and Leggings) or maybe a Twaron Recon setup but unique to him to make him keep his uniqueness. He also deserves Night Ops or Rooftop Sniping or Knifing.

oh yes that would be nice. have them know the landmine locations, i mean i haven't used landmines for town/SAM defense for years because of this.

I'd like to add a vote for removing the Camouflage skill, regardless of how the effect on Shadow is handled. I trust you guys to get that right. But the terrain specific camo makes the skill next to useless because it's single terrain, and the ghillie suit and camouflaged armor types (including stealth suit) make the skill largely redundant.

Although I gotta say that a permanently all-terrain-camouflaged Shadow, with no need for specific equipment, and who would change colors with the terrain, like a chameleon, would be really cool. Probably virtually impossible to implement, but really cool.

In my opinion, every features that :
-is breaking the gameplay, or is breaking the AI in a way or another
-is known to give or increase the chance of a CTD
should be removed from a "v1.0 stable milestone" release until the feature is fixed.

Only after a really stable milestone version is released, those features should be added back and reworked to be fixed, considering how debugging a bigger code is in comparison to a "lighter" one.

I have currently 2 installs of Jagged Alliance 2, one that is staying with the original 1.12 and one that is always updated with the latest of the SVN and executables (and each time saves games are deleted to avoid ctd related to mixmatched versions), so far only the 1.12 can be played for more than a hour without experimenting a CTD.

And as i strongly prefer the way 1.13 improved the options, i can only beg for a really stable release even if it means less of those new added features.

What version are you running? I have played many stable hours using v911.exe and the v1202.exe.
I have a latest up to date SVN folder but that is for testing only and is expected to contain bugs and other annoying things. The SVN build is great but use the 911/1080/1202/B17 exes for more stable and prolonged play. They will all work with the latest data files from SVN so theres no reason not to use them

@ JAPH - Yeah I totally agree with the Shadow issue. He is wasted with only the camo and stealth skills. Especially since Camo needs to be done to the terrain now. If He did go Chameleon then it would be easy to see what you need for your other mercs too I wonder if it is possible to implement? That way we also need a few snow maps to use snow camo too I think an all white Shadow is a fantastic contradiction

@ CrUsHeR - I've been hoping for that for a while too. I landmined Balime recently and the enemy has refused to attack it since But it would make sense to stop militia walking over your landmines and immediately going hostile. Thing is you need them to go hostile for acts against them so a method of stopping militia walking on the mines without affecting the enemy walking on them is needed.

I must take my previous statement back.

On your reply, along all the exes you suggested (and that i already tried in their time and showed me the same kind of random CTD once a hour), i noticed you suggested the b17.

So far i always avoided the beta exes provided by Overhaul , as i always thought the word beta was very similar to experimental , and so would be more prone to those dreaded CTD than the SVN or official releases that had enough of them.

Then some days ago, i re-installed JA2, the latest SVN , then for the 1st time i used the beta 17 executable. And so far i am shocked , i played -lot- of hours in a row during my nights, being currently at day 60 , having conquered 4 cities and have not experienced a single CTD.

That is really awesome, i doubt i will install any more exe or SVN, as on the several dozen i tried, that's the only one that allowed me so much hours of game without those annoying CTD, at least i can really play instead of trying to refrain myself to do several actions that increased the odds of CTD with other .exes .

Of course, the only action i do not do is saving during a combat, playing always in iron man mode, as saving during a combat was already a CTD-friendly process in every official version of JA2 from 1.0 to 1.12.

Thanks for suggesting the beta 17, i don't know what is different with this b17 from previous and following executables, but i can now enjoy really the 1.13 to full extent.

yup..overhauls beta17 is so far the best exe out..his stuff is usually somewhat better than what you get from svn(personal opinion..but having been able to play over half the game crashfree is a strong statement ) and the best part is his beta threads allowing folks to try them out on thier own volition without having to accept it as part of the 1.13 package..we have way too many cooks in the coding kitchen sometimes and ya get some goofy stuff..but byfar..aside from lalien and rowa..overhaul is the best cook (and he dosnt have ego hissy fits like some :P )

Camou-skill.
I though that meant the merc is constantly camouflaged,
the camo-index being a 100%(wood-type) always,
... neither snow nor rain ... or wading a rapid-stream will make the camo-index go down.

Now a hundred percent quantity cannot be added to ... camou is not changeable.
But if the camou-skill-effect could be turned into 99%-constant ...

(Dunno how the terrain-change/cameleon would be automate-able)

That's why we are getting to install some sort of quality control.

yeah. maybe starting building exes basing on beta17 would help.

sure there are some fixes made after beta 17 like the sam sites bugfix and such that would be good to have.

beta18 to 20 where unfortunately not as stable :cries:

Yes, indeed. The procedure should be like Overhaul is already doing: give his changes to the community to test them thoroughly, and if it's free of bugs, some 'master-integrator' (or whatever we call that guy) will put it into the release-code. At least that's the plan for now.

I believe , other than the executable and files version , another important factor of a stable game can be both the ingame and the .ini options setup by the player.

As from reading the board, i noticed some people are encountering some bugs with the same exe i use , but as i never had such problems myself, i think the difference may be in the way they have setup the game options.

That difference in player options must do things even more difficult for the 1.13 coders to debug.

If it can help some people wanting to have a stable enough game with the beta 17, in my "stable for hours" game played with the beta17 .exe , and in which i have encountered no CTD after 5 towns captured (a premiere for me with 1.13), i have the following specific options in the .ini :

-no drassen massive attack as i experienced CTD in some case during it in most of the previous version of 1.13, i prefered not to take the risk again.
-no rain, as i imagine the added code for it could put an extra load on the existing calculations and internal processes.
-no lighting thunder either for the same reason
-animation time to 0 for each enemy/militia/civilian/creatures , to speed up the turn calculation a lot, i have not experienced a single lockup , things that was not that rare in my previous 1.13 games.
-no more than 3 IMPS (each different voiced as i read having 2 IMP with same voice could be faulty) in my game (unfortunately the 3 died during an assault on a SAM site in which the enemy AI got some very lucky shots, my only losses so far)
-no mobile militia and restrict roaming set to true, as i don't want them roaming the map or command militia to do my job of attacking sector, i just use them as nearby sectors reinforcement just in case, may lower the amount of calculations of the game in strategic map.
-no veteran militia trainable, as it would make things too easy
-i left the sight range to the default 13
-for gameplay reason i used limited vision (as i was annoyed to have everyone having eyes in their backs), that may help the game by not displaying everything around but only what the units can see in their fov.
-Pablo stealing disabled , as after playing the game for years Pablo stealing ceased to amuse me.
-the enemy investigate sector is set to false while the re-assign reinforcement is set to true, as i don't like to explore a location in real time and suddenly having the sector invaded by an enemy troop, i prefer this to be managed by the strategic map instead.
As the comment suggest that it is dumbing down the AI, that could mean that it is less extra-calculations to do for it mixed with the original AI code.
-dynamic ammo weight is set to false, as i am not sure how much this feature can impact my already small inventory, i prefered to use the original values.


Other than that i believe most of the ini settings were left to their default configuration, so no custom troops amount for the queen, no aggressive behaviour either (as i imagine it could lead the game to have more calculation to process with the increased amount of troop moves it could create)

Now for the campaign options, as they may have their importance in regards to stability
-Realistic , so that means no creatures , so no creature code, checks, scripts etc...
-Iron Man mode , as from past experience from even before 1.13 , JA2 has always been very unstable when someone saved/loaded during a battle, at least with iron man mode, i am not even tempted to take the risk of a ctd in combat.
-just "great" choice for , as i don't want the pistol for too much time, but i don't want the high end and sci fi weaponry available, or available too soon, i don't think it can have an impact on stability though.

Then , finally for the game options, i have the following (i do not need the low cpu, but if low cpu is lowering the amount and frequency of calculations and other internal process, i believe it could have an impact on stability).


I have been ambushed 2 times by Bloodcats, and destroyed their lair without encountering a single problem too, another good point of the beta 17 .executable (i could not say the same with the previous versions i tested)

1.13 has become too much of a firearm simulator then anything else. I do not feel it adds anything to the game except unnessesary hassle. But instead of throwing them out altogether, the extra features added could be externelized, so players can choose if they want to manually cock a shotgun, have muzzle suppressors, or be burdened with specific scopes and GLs for specific weapons.

Oh yeah, and totaly remove all the useless items from BRay, like the unfirms and barrets and crap. These would have been supercool in a 3D engine which could have displayed worn items as skin on 3D models, but in a sprite-based game, to quete Reiner Wolfcastle: "they do nothing!" And those are not the only useless items that were intentionally added. A silver plate, a platinum watch and cigars have their value as items to sell, but a shovel?! It could have at least been used as yet another item to bludgeon people with.

To summerize: externelize new weapon features and keep the attachment selection simplified. Not everyone are gun experts here, and if you are then you can use the externelized options to reflect your discerning tatses.

I´m really with Tyco on that one, there´s simply no need to be too realistic in JA2 (hey, its turnbased, it will never be realistic, ever), sure it might be nice to have things to choose from, but there must be a limit somewhere, though I believe the attachements are fine as they are now (in the newest svn release), it shouldn´t be too hard for anyone to figure out where the attachments go, but I don´t really see a point adding even more items.

@ Robsoie

Nice pointers. People should read your post closely. And take advantage of it.


@ Tyco & Cougar

Looks like 1.13's name needs to be changed to 1.13 Mod Base. Because that is what it is. The reason there is a lot of stuff being added is because that's the easiest thing to do at the moment, adding graphics is the easy part. Anyone can add and remove stuff to there liking. And we have good editors now. The XML Editor works good, albeit it does need to be updated a little, but just as soon as Mugsy is available again it will be. We have a good Map Editor, also needs tweaking, but it works good none the less. Now we are getting a very cool INI Editor from RoWa21, which is already in the alpha stages of testing and hopefully will be available soon to everyone. Basic out of the box 1.13 is not a very friendly game for the casual player. It never was or will be meant for the casual player. It's for advanced players only. And most important of all for people wanting to create mods of there own. If you take the time to learn how to use the editors, then you can tweak the game to your liking. Better yet...make some mods. So I get a little miffed when people start spouting off as to why this is in the game or why is that there, why why why. You have all the tools you need to do what you want, learn to use them already.

Just as long as the ini would offer the option to use original ja2's "simplified" weapons interface. It seems like the 1.13 modders got a "little" carried away. They were very quick to change the way weapons work from the ground up but did not include and option in the INI to use all these changes or not.

I became and avid gun nut from playing this game too, but this is really overkill.

There's also the question of what these changes actually do for the game experience. The manual shotgun cocking/bolt driving doesn't add. If I could cycle through different cartridges in the chamger then this new feature would have been great, but its pointless the way JA2 works.

According to the wiki if you only want the old tons of guns options + the UB guns, you can choose "Normal Guns".

i think everyone is totally overwhelmed by the amount of guns when they start playing, but after some time you will see that the learning curve isn't that bad, and you will be able to recognize 95% of the guns by their silhoutte and roughly know their stats.

@gpmg
I've got no complaints against the veriaty of weapons and ammo: this indeed I can choose in the options menu. Its not that I want the old, limited weapons list that always made me wish there was room to add more. Rather its old weapons interface. That is to say, the old way weapon damage and range worked and the old AP cost for operating the weapons. Thats an option that should be available in the INI.

But, now that I think about it, all that info is stored in the EXE itself, so I'm not sure how that can be done. I guess I could change all the values myself back to the way I like them, but I would still be stuck with the pointless manual cocking and bolting of shotguns and rifles. Its cute, but like the cloths offered in BRay's, totally pointless.

you can disable the manual cocking stuff in weapons.xml

just use a "replace" function and replace all "usesmanualreload>1<usesmanualreload" by "usesmanualreload>0<usesmanualreload"

i think i misspelled the tag's name but it is somewhere to the bottomn of each weapon entry. you find the first one and can derive its correct name from there.
make a backup of the file in case something goes wrong.

by the way that's not an option but a weapon stat/ data and that's why it doesn't belong into the options.ini but inot weapons.xml

matter of fact my above advice was probably misleading

the tags are

<APsToReloadManually>0</APsToReloadManually>

and

<ManualReloadSound>0</ManualReloadSound>

while changing the latter shouldn't be necessary to get rid of the manual reload action.

so it defines ap used not only yes/ no, that means you'd have to run a couple of replace functions. But since weapons.xml is so small a file, that should still be a matter of minutes.

replace <APsToReloadManually>1</APsToReloadManually>

with <APsToReloadManually>0</APsToReloadManually>


replace <APsToReloadManually>2</APsToReloadManually>

with <APsToReloadManually>0</APsToReloadManually>


replace <APsToReloadManually>3</APsToReloadManually>

with <APsToReloadManually>0</APsToReloadManually>


repeat for higher numbers if they are used.

You didn't? I am curious about that! IIRC, we discussed it in the "1.13 direction" email thread, end of July. let me search my mails... yes, on 24th of July, 18:00 CEST I wrote:



Ooopps! Sorry!!! This mail was only directed to the C-Coders. Sorry for bothering you, Starwalker! You really didn't hear anything about it.

-> To the community:
If we C-Coders would do the job as good as Starwalker & Marlboro do (in graphics and XML), it would shurely be better in your eyes. But the other aspect is, Starwalker and Marlboro now have a very stable interface for their work. So, they have only to be careful (it's a matter of fact, the doing their job very carefully!).

The C-Coders have a much more diffucult situation here: often a simple change in the code opens up a sleeping bug from original SirTech code. There are a lot of stack overruns, wild pointers, wrong but coincidently harmless values in variables and constants and such crap. This is doing sometimes a CTD, but most times it only hurts memory which is not used until you leave the game. Inserting / changing code sometimes shifts the position in RAM, where the bad access occurs - voila, a "new" bug is reborn.

I am not the only one, who is involved in pure bughunting. But please, let me more tell about my current part in the 1.13 Team:
In late spring '07, I completely stopped the development of a flexible common syslogd logging module for JA2, as well as for my "JA2 Smokeless Mod" (a melee weapon mod). I started to port the whole C-Code to another compiler which has the automatic bug-hunting tool CodeGuard. This task is still far beyound completion and it eats up all my spare time. The SirTech Code was made for MicroSoft Visual C++ 6 and MicroSoft allows things that are forbidden in Borland (and vvs.). Thus, something must be reworked to run under both compilers. My intention was to only improve code quality. At the end of this process I (hope I will) be able to find a lot of stack corrumption, wild pointers and so on. But it will be based on an 9xx release of the code. And CodeGuard is not able to find bugs when compiling the code, but when running it. So I have to append in intensive testing phase, playing the whole game with almost all sectors, dialoges, weapons, item combos and so on. Another approach is the use of a better lexical scanner. Such a tool will find bugs before the compilation process. I use pc-lint sometimes, but lint gives tons of warnings.

The main problems of my CodeGuard approach are:

• it eats up a lot of time each weekend
• it will last very long until any result
• I have to touch each single .CPP and .H file, with no support from further C-Coders
• results will not be available before completing the job by 100%
• I will find a lot of hidden errors which didn't any harm yet, so I have to bother the other with fixing things that are completely unknown until now
• I will find errors in a 9xx release, so I have to generate a lot of patches which must interworked into the recent code
• Somebody should to merge all my Borland adaptions to the then actual 18xx release, so we can use CodeGuard in the future again

The main problems of my PC-Lint approach are:

• It gives an immediate result, but is a Sisyphus like job to find only the really harmful ones out.
• PC-Lint warns about every dangerous style, potential (but possibly not actual) errorneous code and so on. The SirTech code is (in means of PC-Lint) full of such crap.
• Making such a big project being "lint clean" is a too big job for a single programmer. In fact, it is wrong to try so. Lint shall be used from the beginning on. Only then it can develop its real power.

So you can see, all we need is: man power. Every programmer, who can use a Borland Developer Studio 2006 and has a little bit of experience in adopting Win32-MSC programs to Win32-BorlandC programs, can support us. Finally, Starwalker's slogan fits perfect...

with best regards,
Sergeant_Kolja