Topic: I think I solved the double-fighter bug..

[FireSoul]

You see that topic? That's right. I really do think I've solved it. My tests show that I have.

Setup: 3 PCs. 1 as my own D2 server, and the other 2 as clients.
Time it took: Been trying all sorts of things since Tuesday..
Mission: Met_17PatrolEnemy  (found to cause it)

I'm sure some of you spotted the "Luc's Test Server" lately. This is what it was for.. and guess what, I think I fixed it.


Now, pay attention..
Anywhere you have a ship creation like this...

-------------------------------------
   mCreateShip( typeid( tAttackTeamShip ),
             shipScriptDescription.fClassName.c_str(),
             kStartPosition_W,
             shipScriptDescription.fMetaDatabaseID,
             gWC.fNWCustID++, 0, 0, -1, -1,
             shipScriptDescription.fCustomName.c_str(),
             static_cast<eShipOptions>( option | kCanBeCarrier | kStartPositionCanBeOffset ) );
-------------------------------------

.. you gotta find the file that handles the typeid.. (in this case, AttackTeamShip.cpp).
In there,  look for the mSetupState function and change it to something more restrictive:

-------------------------------------
void tAttackTeamShip::mSetupState()
{
   tTeamInfo* ti = fMissionInfo->mGetTeamHandle( mGetTeam() );
   if (ti)
   {
      if (! ( (!ti->mIsTeamHumanControlled()) && (!gScriptInterface.mIsHost()) ) )
      {
         mRegisterState( new tAttackTeamShipInitialState( ) );
         mGotoState( typeid( tAttackTeamShipInitialState ) );
      }
   }
}
-------------------------------------


Prevent NON-hosts from setting up the TeamState IF it's also an AI. If it's a player, you need the TeamState for the nonhost.


Now, I'm gonna try to compile as many missions as possible, but can someone get NuclearWessels and Karnak to see this? Thanks.

-- Luc

[FVA_C_ Blade_ XC]

 

[Durin]

 

[FireSoul]

Note: I think this also serves for the double-damage bug, which in my opinion is one and the same..  I will of course need someone to put up a test server..

[Green]

Green looks left towards J'inn, tilts head, scratches ear.  Green look right towards Hooch, tilts head, scratches ear.  Green looks back towards Krueg, tilts head, scratches ear.

What is a "shipScriptDescription.fClassName.c_str(),"?

Receives a bunch of hunched shoulders and 'ida know' replies ... "but it looks to be a good thing."

[Strafer]

What is a "shipScriptDescription.fClassName.c_str(),"?

A function requiring no parameters within a C++ Class, itself being passed as a parameter to another function. 

[Green]

What is a "shipScriptDescription.fClassName.c_str(),"?

A function requiring no parameters within a C++ Class, itself being passed as a parameter to another function. 

Green looks back at same audience, receives same response.  But knows whatever these magical words are that have been spoken are good.

[FPF-DieHard]

I guess there will be a new dowload fo the GW3 test server.

J'inn, reply to your email.

Karnak, will this fix work in your scripts?

[Lepton]

So the opposing AI's "state" was being set up twice before and this prevents that??

[FireSoul]

So the opposing AI's "state" was being set up twice before and this prevents that??

Technically, this was not "Double", it was "Multiplied by as many live players there are in the game". But in essence, yes. All non-hosts had their own sets of weapons and fighters on AI units. This seems to prevent that to happen. 


Edit: To make this a bit clearer..
.. each player's machine Always had and always will have their own version of each ship while in game, but only the host's should be the one used (and active).  It's like when you capture a carrier: it can spew out a bunch of fresh fighters.

Well.. that's because YOUR machine just took over and by its calculations, all the fighters are still inside. Proper capture code should be added to prevent this from happening.. but that's not something I want to get into..   The code for that exists in Coopace and I hope NuclearWessels or someone else could pick up on that.

-- Luc

[Capt_Bearslayer_XC]

Damn fine job, FS.

Thank you.

[Bonk]

Good work FireSoul!

Well.. that's because YOUR machine just took over and by its calculations, all the fighters are still inside. Proper capture code should be added to prevent this from happening.. but that's not something I want to get into..   The code for that exists in Coopace and I hope NuclearWessels or someone else could pick up on that.

So when can we expect say a half-dozen "Evil-Luc" D2 mission scripts?

[Strafer]

So when can we expect say a half-dozen "Evil-Luc" D2 mission scripts?

I suggested a handful of builds to have other test them, but more in an -AC Alan Cox fashion. Wouldn't want a repeat of the whole OPPLUS 4.0 thingie...

[FireSoul]

Good work FireSoul!

Well.. that's because YOUR machine just took over and by its calculations, all the fighters are still inside. Proper capture code should be added to prevent this from happening.. but that's not something I want to get into..   The code for that exists in Coopace and I hope NuclearWessels or someone else could pick up on that.

So when can we expect say a half-dozen "Evil-Luc" D2 mission scripts?

My personal preference would be for NuclearWessels to update his, but otherwise I want nothing else than updated missions for our servers.... especially the ones I will be playing on.   

[Bonk]

Good point Strafer, naming and permissions should be considered carefully. This is exactly why NW released his latest sources though, I'm sure he wouldn't mind -  but should certainly be asked for permission to release modified versions of his scripts (as opposed to "original" scripts implemented like this). I'm j/k about the "Evil-Luc" part...

Cool FireSoul, I was under the impression dave had set aside his D2 scripts for now, but  its definitely better for the original author to modify them, I agree. But as you suggest, if Dave doesn't get around to it I'd be happy to give any scripts you produce a whirl!  (Thanks for the hard work on this - I noted the "since tuesday" part...)

[FireSoul]

(Thanks for the hard work on this - I noted the "since tuesday" part...)

Yeah..

.. I was down to doing it with the scientific method:
1- Hypothesis
2- Experiment
3- Results
4- Conclusion

I tried a great many things until I was down to "trying anything that could even remotely make sense", and this was one of them. The obvious things didn't work, so I tried other options.

-- Luc

[KBFLordKrueg]

This indeed is good news, FS.
We all appreciate your untiring efforts with SFC!
 

[NuclearWessels]

Very Cool FS!

Yes, I'll update the pack - I'm in the process of cleaning up a bunch of other bugs and irritants, so will go through and incorporate that as well.

(Hopefully will have the revisions posted by Friday.)

Thanks heaps!
dave

[FireSoul]

Very Cool FS!

Yes, I'll update the pack - I'm in the process of cleaning up a bunch of other bugs and irritants, so will go through and incorporate that as well.

(Hopefully will have the revisions posted by Friday.)

Thanks heaps!
dave

I'm almost done compiling the packs with just this fix myself.. I will make it public so that we can get a test server up and know for sure that it worked.. what do you think? I'll make sure that it's not going to be confused as being one of your own releases.

-- Luc

[NuclearWessels]

Sure thing - thanks again!

dave

[FireSoul]

Sure thing - thanks again!

dave

See, I tested it with *1* mission, and that was at home with my own setup. I wanna see if it'll work with a whole buncha different missions, in the wild..

..if you want, I can give you sources?
-- Luc

[Astarte]

Sure thing - thanks again!

dave

See, I tested it with *1* mission, and that was at home with my own setup. I wanna see if it'll work with a whole buncha different missions, in the wild..

..if you want, I can give you sources?
-- Luc

Yes...I got dizzy watching him go from one machine to another and back and again and...

Agh!

Good work dear!  Now sit down for a bit.

[FireSoul]

What? You're spying on me on the boards too, now?! 

[NuclearWessels]

Sure thing - thanks again!

dave

See, I tested it with *1* mission, and that was at home with my own setup. I wanna see if it'll work with a whole buncha different missions, in the wild..

..if you want, I can give you sources?
-- Luc

No, won't need the sources - I've already updated most of the scripts in one way or another anyway,
so I'll go through and apply the updates to my current versions.

thanks,
dave

PS - Geez Firesoul, what have you done for the community lately
dw

[FireSoul]

Sure thing - thanks again!

dave

See, I tested it with *1* mission, and that was at home with my own setup. I wanna see if it'll work with a whole buncha different missions, in the wild..

..if you want, I can give you sources?
-- Luc

No, won't need the sources - I've already updated most of the scripts in one way or another anyway,
so I'll go through and apply the updates to my current versions.

thanks,
dave

PS - Geez Firesoul, what have you done for the community lately
dw

Uh. Ok then. I guess I should just wait for your release for some testing.

[FireSoul]

I need someone to volunteer a server until ED can release his updated missions. I have prepared a "CoreMissions" pack for this. I did the necessary but minimal work, so I don't know that everything will be fixed for all missions.

Test (temporary) MissionPack:  http://pet.dhs.org/~firesoul/sfc2/NW-ED-double-bug/OPCoreMissions-doublebug-test.zip

We can only try it and find out.
-- Luc

[Bonk]

Sure, see reply on other thread... (logging in to MSN now...)

[Astarte]

What? You're spying on me on the boards too, now?! 

Nope.  Can't spy when it is public. *winks* 

I've gone from not knowing just what the heck you are talking about, to being able to read SSDs and giving you opinions on models.  I see from behind the scenes just how much work you do on this stuff.  About time I showed you my support publicly.

And I somewhat know a few of these here oddballs you hang around with.  I don't play SFC...kept Jinn'ing myself into rocks in the training missions...but..hope that doesn't make me any less a part of the group.

[likkerpig]

Dammit Firesoul, you found the perfect woman!
(Aside from Kroma, sorry baby, yer always #1 in my books!)

[el-Karnak]

My personal preference would be for NuclearWessels to update his, but otherwise I want nothing else than updated missions for our servers.... especially the ones I will be playing on.   

This is the kind of political crap that makes me want to continue staying away from SFC.

I'm sure the feeling is mutual with many such people in this community.

[likkerpig]

My personal preference would be for NuclearWessels to update his, but otherwise I want nothing else than updated missions for our servers.... especially the ones I will be playing on.   

This is the kind of political crap that makes me want to continue staying away from SFC.

I'm sure the feeling is mutual with many such people in this community.

Karnak, I think FS meant that he wanted the mission developer to modify the script, rather than tamper with it himself.
Just talking out of my ass here but I think FS is very sensitive about designer's rights and didn't want to step on anyone's toes.
NW has been the only scripter posting recently (yourself and Tracey being absent) so he addressed it to NW.
Once again, just my impression but I do not think any insult was intended.

[el-Karnak]

My personal preference would be for NuclearWessels to update his, but otherwise I want nothing else than updated missions for our servers.... especially the ones I will be playing on.   

This is the kind of political crap that makes me want to continue staying away from SFC.

I'm sure the feeling is mutual with many such people in this community.

Karnak, I think FS meant that he wanted the mission developer to modify the script, rather than tamper with it himself.
Just talking out of my ass here but I think FS is very sensitive about designer's rights and didn't want to step on anyone's toes.
NW has been the only scripter posting recently (yourself and Tracey being absent) so he addressed it to NW.
Once again, just my impression but I do not think any insult was intended.

Umm...No.  It's no secret that FS does not like me or EEK scripts and I don't like people that back-stab.

Since he wants only NW scripts updated then I think I'll oblige him.

This community really sucks to see such garbage posted. End of Story.

Not worth my time anymore.

[FireSoul]

My personal preference would be for NuclearWessels to update his, but otherwise I want nothing else than updated missions for our servers.... especially the ones I will be playing on.   

This is the kind of political crap that makes me want to continue staying away from SFC.

I'm sure the feeling is mutual with many such people in this community.

I sure don't see having said anything wrong:
The EvillDave packs are NuclearWessel's, and I would rather see him update his packs as he see fits than someone else take over.
.. and..
The reason why I spent time on this was to make things better so that I can go have good games.

There's nothing political about what I said. Did you misunderstand?

[FireSoul]

Umm...No.  It's no secret that FS does not like me or EEK scripts and I don't like people that back-stab.

Since he wants only NW scripts updated then I think I'll oblige him.

This community really sucks to see such garbage posted. End of Story.

Not worth my time anymore.

Get off your high horse Karnak. If I wanted only his missions to be fixed, I woulda posted to him, only, and not here. I posted here, publically, so that you can pick up on the fix too, which was my intention from the very beginning.

Posts like this is why I think you're a strange cookie.  The reason I don't like you is because of a few posts you have done in the past which are against stuff I like, such as telling Gary Plana that you don't want to be in SFB material, and not wanting to share the sources to your missions after I've shared mine with you.

However, I still enjoy blasting at you on the 'battlefield' where it's supposed to be.

-- Luc

[el-Karnak]

My personal preference would be for NuclearWessels to update his, but otherwise I want nothing else than updated missions for our servers.... especially the ones I will be playing on.   

This is the kind of political crap that makes me want to continue staying away from SFC.

I'm sure the feeling is mutual with many such people in this community.

I sure don't see having said anything wrong:
The EvillDave packs are NuclearWessel's, and I would rather see him update his packs as he see fits than someone else take over.
.. and..
The reason why I spent time on this was to make things better so that I can go have good games.

There's nothing political about what I said. Did you misunderstand?

Cut the I-am-innocent act.  You went around telling people I stole your code which absolutely false.  The Co-op Ace code was given to me a long time before I met you. Anything useful was tested out a long time ago.

Forgive me if I take you posts with a grain of salt. And I don't like slanderers.

I've really had it with you.  Next time STFU.

[FireSoul]

Jesus F***!

Take this bugfix code and go fix your missions already. This isn't about you and me. This is about the D2 and what we like to do.

[FireSoul]

To everyone:

This fix works.  I spent a few hours playing on Gravity Well with Bonk.  It does not fix the host left issues. In fact, double-fighters and everything.. and AI controlling my ship problems still occur, there.

However.. all the normal missions work very nicely.

[likkerpig]

Karnak,
You and I have had our little pissing contest, as have many others with you.
I buried the hatchet and complimented you on the great missions you have created. Kudos! They are well done.
I stand by my first post, I do not think any insult was intended.
Back to my first paragraph, I (and once again I may be talking out of my ass) think you read too much into things and look for insults where they don't exist.
How about you and FS pm each other and set up the mods to get rid of the bug? When Tracey comes back do the same thing.
You have a great deal of talent and are an asset to the game, but your hair trigger temper leads to a lot of conflict.
My 2 cents.


Can't believe I am trying to defuse a situation....
Egging it on is my nature...
Must be getting old.

[NuclearWessels]

To everyone:

This fix works.  I spent a few hours playing on Gravity Well with Bonk.  It does not fix the host left issues. In fact, double-fighters and everything.. and AI controlling my ship problems still occur, there.

However.. all the normal missions work very nicely.

Cool news FS - thanks again!

Knowing that fixes the double-fighter bug under normal circumstances but not under "host left" also gives a few more clues about to how to deal with the host left issues.

dave

[likkerpig]

Screw it.
Several posts made while I made my last one.
Hey, I tried.

[FireSoul]

To everyone:

This fix works.  I spent a few hours playing on Gravity Well with Bonk.  It does not fix the host left issues. In fact, double-fighters and everything.. and AI controlling my ship problems still occur, there.

However.. all the normal missions work very nicely.

Cool news FS - thanks again!

Knowing that fixes the double-fighter bug under normal circumstances but not under "host left" also gives a few more clues about to how to deal with the host left issues.

dave

Indeed. The 'double' effect was present with a host-left. This tells me a new host was elected PRIOR to game start.. and the old host still is the host for his/her side of things..

Is there a way to know what the team# of the player joining the game is at game start? If it's not team0 and it's a host before the game started, it could be a hostleft problem. Furthermore if team0 is still present, it *is* positively a hostleft problem. .. any way to check this before the mission starts, during even set-up and ship creation?!

*Sigh*.

[NuclearWessels]

Interesting - for each mission we do know which team the host should be (though which specific team isn't completely consistent across all the scripts), so if we get a positive on IsHost for another team then yes, we should be able to dig a bit deeper ... cool beans!

thanks yet again!
dave

[Bonk]

C'mon Karnak, chill man. Don't disappoint me here, please. I respect you and enjoy your missions. Your original post on this thread was clearly a misinterpretation.

I have swapped out the test missions for the EEK2.1 missions for the week and will swap the EEK2.1 back in next week (master missionlist blob editor now...).

I was talking to Firesoul about this describing what you had told me about these kind of scripting issues and to be honest I did't get alot of what he was saying as I'm not a scripter... I was wishing you were there to understand and have an intelligent response.  I know we can get together on this.

Please for ole Bonk, play nice... ignore past politics... make a new start. Firesoul is a strong character and so are you, but both talented and interested in the same game.

I have been using his shiplist and your missions for ages now, just think how happy I'd be if you guys cooperated.

I know you put a lot of work into multiplayer stability in your missions, and I thought you already had this covered. Its a complicated puzzle and teamwork is the only solution, as we all have real jobs to go to tomorrow.

Please Karnak?

[Bonk]

Is there a way to know what the team# of the player joining the game is at game start? If it's not team0 and it's a host before the game started, it could be a hostleft problem. Furthermore if team0 is still present, it *is* positively a hostleft problem. .. any way to check this before the mission starts, during even set-up and ship creation?!

Thats exactly the kind of suff Karnak was telling me about while testing EEK2.1 on the Gravity well, much of which I just smiled and nodded at (appreciating but not understanding), here's two guys who will understand what you're talking about Karnak.  For ol Bonk can you give your valued input here? With the three of you on it we could have the most stable missions ever... I'd be right happy.

[FireSoul]

Interesting - for each mission we do know which team the host should be (though which specific team isn't completely consistent across all the scripts), so if we get a positive on IsHost for another team then yes, we should be able to dig a bit deeper ... cool beans!

thanks yet again!
dave

Ex-actly.

Think of it like this:

If current player is the host, but is not Team0.. *and* team0 is present and has ships in play, then there's a problem.

Explanation:
Team0 is always the classic host.. and if Team0 has indeed dropped, then all of the ships under his control should have gone "poof" with him at the time of the drop. The presence of ships belonging to Team0 with a HostLeft situation could be used to detect the hostleft situation is happening.


*ding* idea!
If we can't prevent it, perhaps we can call for an end to the mission right at the beginning and have a "Draw" result? Perhaps some kind of text blurb announcing this is because the hostleft problem was detected?

[Bonk]

Explanation:
Team0 is always the classic host.. and if Team0 has indeed dropped, then all of the ships under his control should have gone "poof" with him at the time of the drop. The presence of ships belonging to Team0 with a HostLeft situation could be used to detect the hostleft situation is happening.

But the host left message often happens when the host has not left/dropped at all...

[FireSoul]

NuclearWessels: Caution! With the fix of the ship states, you should be aware of the following potential problem.

Do you have any missions where capture is possible? On capture, a new state is registered for the captured ship. It could spew out fresh fighters for the new controller's state (these were technically always there in the ship, just not activated).

For OP, there's a solution:
If the ship is captured, you could have the host (it just needs to be done once) set the number of fighters on the ship to 0. This is bound to be right more often than not. Based on experience, the host will actually send a NetMsg to the other clients to set it to 0 too with this command. (mSetFighters).

-- Luc

[FireSoul]

Explanation:
Team0 is always the classic host.. and if Team0 has indeed dropped, then all of the ships under his control should have gone "poof" with him at the time of the drop. The presence of ships belonging to Team0 with a HostLeft situation could be used to detect the hostleft situation is happening.

But the host left message often happens when the host has not left/dropped at all...

No, but there's a mOnHostChanged event that exists in the API! It could be used to contain this source and trigger the draw, if that's the wanted solution.

[Bonk]

Having it end in a draw would probably be better than dealing with double fire... and the reduced "Alt-outs" would keep the db cleaner... until we find a better solution that would certainly do if it works.

[FPF-DieHard]

Karnak, Firesoul has no aggenda with this.  There are no politics.  He It was simply for the betterment of the community.

He fixed this with an ED script simply because that source code is public.  EEK missions are not.   it is that simple.

I love EEK missions, the AI stripping and the stable 3v3 I've had with them are priceless to me.   Unfortunately, the double-fighter bug is a deal breaker.  The current batch of EEK missions cannot be used.

Who cares who fixed the bug?  Use this fix and make your scripts better.

Please, I really want to use your missions.

[FireSoul]

Having it end in a draw would probably be better than dealing with double fire... and the reduced "Alt-outs" would keep the db cleaner... until we find a better solution that would certainly do if it works.

I forsee possible problems.  The HostLeft bug isn't detected by all players all the time.
. like the original host still thinks it's a host, and no hostleft msg came up. The other player will exit with a Draw .. .. but I don't think it can make the original host player exit.

However, it may clean up the mission sufficiently to alow it to end normally.

[Astarte]

Dammit Firesoul, you found the perfect woman!
(Aside from Kroma, sorry baby, yer always #1 in my books!)

*cries*  It's the TUTU!  I don't have a pretty pink fluffy tutu!

[likkerpig]

Dammit Firesoul, you found the perfect woman!
(Aside from Kroma, sorry baby, yer always #1 in my books!)

*cries*  It's the TUTU!  I don't have a pretty pink fluffy tutu!

It always comes down to that doesn't it?

[762_XC]

Outstanding work FS! 

[KBF-Dogmatix_XC]

Totally agree, t00l....this is great news.


Thanks for the work, FireSoul!



And to Karnak:  "Holy completely and totally missing the point, Bat Man!"   

[FPF-DieHard]

Karnak has given me a test mission with FS's fixed code for the double fighter bug.  This will be on the GW3 test server.

More to follow.

[FireSoul]

Hey. DH. Nice title!

FPF-DieHard
Starcastling Twat

[Capt_Bearslayer_XC]

Hey. DH. Nice title!

FPF-DieHard
Starcastling Twat

All the Hydrans from GW2 should have that added to their signatures...

[NuclearWessels]

OK, I've posted updated packs for

Core missions
Total War missions
The whole shebang

though the big one says it still has about 20 minutes to go on the upload

These include Firesoul's fix for the double-fighter bug, plus a host of minor other fixes (incorrect reporting of  some mission results, the stupid routine that named AI ships things like .I.II.III, etc etc)

thanks again FS!
dave

[FPF-DieHard]

Dowloading now . . .

Um, which one was the "runner" mission?

[GDA-S'Cipio]

OK, I've posted updated packs for

Core missions
Total War missions
The whole shebang

though the big one says it still has about 20 minutes to go on the upload

These include Firesoul's fix for the double-fighter bug, plus a host of minor other fixes (incorrect reporting of  some mission results, the stupid routine that named AI ships things like .I.II.III, etc etc)

thanks again FS!
dave

I've never run the total war pack, but I know some have.  Is it absolutely impossible to draft an ally in the Total War pack even if you want to, or does the DV shift just not get mucked up if you happen to draft an enemy as an ally?

-S'Cipio

[NuclearWessels]

<scratches head>

DH .... I think that was one of the "10" patrols , but can't remember which one (Met_NW10PatrolEnemy or Met_NW10PatrolEnemy_tw ??)

Scippy ... the TW pack will only draft your own race on your side, and will only draft from your "worst enemy" for the opposition side

dave

EDIT: the whole shebang seems to have completed uploading now

[FPF-DieHard]

<scratches head>

DH .... I think that was one of the "10" patrols , but can't remember which one (Met_NW10PatrolEnemy or Met_NW10PatrolEnemy_tw ??)

Scippy ... the TW pack will only draft your own race on your side, and will only draft from your "worst enemy" for the opposition side

dave

EDIT: the whole shebang seems to have completed uploading now

Yup, testing now.

Dod you have any patrols that do not start the players in motion?

[NuclearWessels]

Yup, testing now.

Dod you have any patrols that do not start the players in motion?

Damn!  Knew there was something else I wanted to do - I was going to add a setting so admins could turn that off if they wanted to.

I'll add and test that over the next week or so,
Doh!

dave

[FPF-DieHard]

You rock!

What about AI-stripping and base busting?  Have those been fixed? 

Tell me exactly what you need tested, I will get it done.

[NuclearWessels]

You rock!

What about AI-stripping and base busting?  Have those been fixed? 

Tell me exactly what you need tested, I will get it done.

The AI stripping still isn't up to snuff - I've got a fix, but it's a longer term deal (need to change a bunch of things in the way I'm generating AI to get that right, so it will also wind up needing more extensive testing)

I'm pretty sure I fixed the base busting, but will have to go back and double-check - it was in progress, but I can't remember if I finished testing it or not

For the testing, look for anything you remember that bugs ya, make a list, and let me know.   No promises of course, but I'll see what I can do [EDIT: keeping in mind that I can't do much about Hexx ]

dave

[[RK] Castrin]

Great work FS!! 

Karnak, I think FS meant that he wanted the mission developer to modify the script, rather than tamper with it himself.
Just talking out of my ass here but I think FS is very sensitive about designer's rights and didn't want to step on anyone's toes.
NW has been the only scripter posting recently (yourself and Tracey being absent) so he addressed it to NW.
Once again, just my impression but I do not think any insult was intended.

Umm...No.  It's no secret that FS does not like me or EEK scripts and I don't like people that back-stab.

Since he wants only NW scripts updated then I think I'll oblige him.

This community really sucks to see such garbage posted. End of Story.

Not worth my time anymore.

Geeez, did you even read the FIRST post he made?

Now, I'm gonna try to compile as many missions as possible, but can someone get NuclearWessels and Karnak to see this? Thanks.

-- Luc

Karnak, I'm sad you feel it nessisary to post things like this.

 

[FireSoul]

OK, I've posted updated packs for

Core missions
Total War missions
The whole shebang

I'm fetching the missions now, also. Seems that you have your coding hat back well back on now.

[Strafer]

OK, I've posted updated packs for

Core missions
Total War missions
The whole shebang

I'm fetching the missions now, also. Seems that you have your coding hat back well back on now.

...staple gun, anyone? 

[NuclearWessels]

I'm fetching the missions now, also. Seems that you have your coding hat back well back on now.

Nothing like a break to give you a fresh batch of enthusiasm!  Of course, it also doesn't hurt that the mrs is quite distracted setting up some consultancy work right now

dave

[Bonk]

OK, I've posted updated packs for

Core missions
Total War missions
The whole shebang

though the big one says it still has about 20 minutes to go on the upload

These include Firesoul's fix for the double-fighter bug, plus a host of minor other fixes (incorrect reporting of  some mission results, the stupid routine that named AI ships things like .I.II.III, etc etc)

thanks again FS!
dave

I've never run the total war pack, but I know some have.  Is it absolutely impossible to draft an ally in the Total War pack even if you want to, or does the DV shift just not get mucked up if you happen to draft an enemy as an ally?

-S'Cipio

The total war pack is intended for servers with no allies. If you use the regular missions you end up getting allied enemy ships (if that makes any sense.. lol), thus the total war pack... I'll give the new set a whirl on the Gravity Well tomorrow.

Thanks Dave!

[el-Karnak]

You see that topic? That's right. I really do think I've solved it. My tests show that I have.

Setup: 3 PCs. 1 as my own D2 server, and the other 2 as clients.
Time it took: Been trying all sorts of things since Tuesday..
Mission: Met_17PatrolEnemy  (found to cause it)

I'm sure some of you spotted the "Luc's Test Server" lately. This is what it was for.. and guess what, I think I fixed it.


Now, pay attention..
Anywhere you have a ship creation like this...

-------------------------------------
   mCreateShip( typeid( tAttackTeamShip ),
             shipScriptDescription.fClassName.c_str(),
             kStartPosition_W,
             shipScriptDescription.fMetaDatabaseID,
             gWC.fNWCustID++, 0, 0, -1, -1,
             shipScriptDescription.fCustomName.c_str(),
             static_cast<eShipOptions>( option | kCanBeCarrier | kStartPositionCanBeOffset ) );
-------------------------------------

.. you gotta find the file that handles the typeid.. (in this case, AttackTeamShip.cpp).
In there,  look for the mSetupState function and change it to something more restrictive:

-------------------------------------
void tAttackTeamShip::mSetupState()
{
   tTeamInfo* ti = fMissionInfo->mGetTeamHandle( mGetTeam() );
   if (ti)
   {
      if (! ( (!ti->mIsTeamHumanControlled()) && (!gScriptInterface.mIsHost()) ) )
      {
         mRegisterState( new tAttackTeamShipInitialState( ) );
         mGotoState( typeid( tAttackTeamShipInitialState ) );
      }
   }
}
-------------------------------------


Prevent NON-hosts from setting up the TeamState IF it's also an AI. If it's a player, you need the TeamState for the nonhost.


Now, I'm gonna try to compile as many missions as possible, but can someone get NuclearWessels and Karnak to see this? Thanks.

-- Luc

This code fix won't work for stand-alone AI creation routines like this:

void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes SmallestHullSize, eClassTypes LargestHullSize, int32 VariantPercent, int32 Position, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

[FireSoul]

void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes SmallestHullSize, eClassTypes LargestHullSize, int32 VariantPercent, int32 Position, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

Yes it does. ShipClass, the first parameter, is present. Here's the prototype of the function that I used in my example:

void   mCreateShip( const type_info& ShipClass, const char* ClassName, int32 Position, int32 MetaDatabaseID, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

All of the mCreateShip functions use it. Basically, you just have to figure out where the ShipClass used is located, and make sure only the host can register the TeamState for the AIs.

.. thankfully, the default ShipClass "typeid( tShipInfo )", which is hosted from within the API,  does not register a team state, so we don't have to worry about it.  That covers about all bases.

-- Luc

[Julin Eurthyr]

[EDIT: keeping in mind that I can't do much about Hexx ]

Couldn't you write a routine along the lines of:

If host=Hexx then
X=rand (100)
If X > 90 then fill map with T-bombs
endif
endif

And put it into every mission?       

Just a little reminder of what he'll have to face every mission with an ally...

[FireSoul]

[EDIT: keeping in mind that I can't do much about Hexx ]

Couldn't you write a routine along the lines of:

If host=Hexx then
X=rand (100)
If X > 90 then fill map with T-bombs
endif
endif

And put it into every mission?       

Just a little reminder of what he'll have to face every mission with an ally...

heh..

.. nope.. we don't have access to the player names, the current hex, or even the stardate.. sorry.
.. think! It woulda been done LONG ago!

[el-Karnak]

void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes SmallestHullSize, eClassTypes LargestHullSize, int32 VariantPercent, int32 Position, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

Yes it does. ShipClass, the first parameter, is present. Here's the prototype of the function that I used in my example:

void   mCreateShip( const type_info& ShipClass, const char* ClassName, int32 Position, int32 MetaDatabaseID, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

All of the mCreateShip functions use it. Basically, you just have to figure out where the ShipClass used is located, and make sure only the host can register the TeamState for the AIs.

.. thankfully, the default ShipClass "typeid( tShipInfo )", which is hosted from within the API,  does not register a team state, so we don't have to worry about it.  That covers about all bases.

-- Luc

Nope. It does not work. The mCreateShip function is:

void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes SmallestHullSize, eClassTypes LargestHullSize, int32 VariantPercent, int32 Position, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

Not the one you use in ::CreateNewShip function.

Try it out before you post next time, wonder-boy.

[Cleaven]

Try it out before you post next time, wonder-boy.

Nothing has changed. Not one single solitary thing.

[FPF-DieHard]

karnak, play nice. 

[FireSoul]

*sigh*

From the API, there are 4 mCreateShip functions. Here are their prototype, with the important bit in red.

TeamInfo.h:

   void   mCreateShip( const type_info& shipClass, const tShipInGame& ShipData);
   void   mCreateShip( const type_info& ShipClass, const char* ClassName, int32 Position, int32 MetaDatabaseID, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions ); // The only one used
   void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes ShipType, int32 VariantPercent, int32 Position, /*int32 MetaDatabaseID,*/ int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions, eRace Race = kNoRace );

   void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes SmallestHullSize, eClassTypes LargestHullSize, int32 VariantPercent, int32 Position, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

They all use the shipClass param which allows you to define your own ShipInfo code. Within the ShipInfo file is where the problem is, so the issue is not[/red] the mCreateShip function.

But I'll play along. 

• The first mCreateShip listed here, above, calls mCreateTeamShip to do the final work.
• The 2nd comes from my original example. It also  calls mCreateTeamShip to do the final work
• The 3rd comes from your complaint. Within the API I see that that one calls
  mCreateFleet, which in turn calls mCreateTeamFleet, which in turn calls mCreateTeamShip within its loop.
• The 4th mCreateShip also calls mCreateFleet, and follows the same path as the 3rd one.

So. They all use the parameter which defines the shipClass to use. You use that to track down the bug within the source, where the Registeration of TeamState is, and you make it more restrictive to prevent the double-fighters/weapons.. .. and they all end up within the same function of the API.

I would like to point out that other functions, such as mCreateTeamFleet and mCreateCPUFleet, also do this.


Edit: Oh! NOTE:
If you're Registering the TeamState elsewhere, for whatever reason you need to do this, then you need to add the restriction that only the host should Register that State for the AI ships. The focus is the State: make sure it's not run on all machines.

[FireSoul]

*back from shower* ..

.. forget about the mCreateShips. You just need some focus towards the goal.

Just locate everywhere the Team States are being registered, and prevent non-hosts from registering the state for AI teams. The mCreateShip functions will help you find these, and that was stated in the first post.

It can be anywhere in the code that can access functions in the ShipInfo class. It is possible to register a new state from within a state overriding to original one.

[FPF-SCM_TraceyG_XC]

So simple when its figured out, good job Firesoul.

If the host drops, particularly before teams have been setup (say right at the beginning) or later if a new team is added, will mIsHost() report the new updated host correctly, in other words, does this function work properly?

[FireSoul]

So simple when its figured out, good job Firesoul.

If the host drops, particularly before teams have been setup (say right at the beginning) or later if a new team is added, will mIsHost() report the new updated host correctly, in other words, does this function work properly?

Based on results cause by a HostLeft the other night, yes. Further testing where the host purposely drops is recommended for more infomation. Actual registration of AIs in mOnHostChanged might be useful so that new elected host can take over if a host drop occurs later on in the game. A reset of AI commands would also be recommended.

-- Luc

[NuclearWessels]

What about AI-stripping and base busting?  Have those been fixed? 

Tell me exactly what you need tested, I will get it done.

Heh, whoops 

Fluf made me cut and paste a goof through a bunch of the team files while setting up the posted pack.  If  you do run across any real weirdness in the current batch it's Fluf's fault, not the result of FS's fighter-bug fix

Will have it corrected tomorrow, along with more news on the speed setting

dave

EDIT: modified to correctly allocate blame

[762_XC]

if you do run across any real weirdness in the current batch it's my fault, not the result of FS's fighter-bug fix

Incorrect Dave, it's Fluf's fault.

[Fluf]

Yeah get it together Dave!  Everything in the Universe is MY FAULT! 

[NuclearWessels]

Correction duly noted

dave

[Black]

And all is well in the universe ...   

Good work FS!!!

[NuclearWessels]

<scratches the stubble and stretches a few times>

OK, just a bit of an update.

It turns out that in some cases a shipstate class does currently need to be maintained for all teams - notably when it's responsible for performing updates on VCs.   The seek-and-destroy missions should be ok, but some of the ones with additional goals/requirements will need some changes before this fix can be fully applied.  Anywho, as I'm going through this I'm jotting down notes on what will need to be done to fix the remaining cases.

(The short version is that for now the fix might not get applied to some of the ships in some of the missions, but it'll be a minority.)

When I get the updated pack posted one of the big things to watch for in testing is misreporting of wins/losses -  if there's a mission consistently failing to give either the player or a draftee proper credit for a win then the odds are I've updated a case I shouldn't have.

DH - I'm going to have to postpone the speed configuration setting while I get this stuff squared away, but hopefully can come back to it (next week mb?)

dave

[762_XC]

<gives ED another karma boost>

Thank you Dave!

[FireSoul]

<scratches the stubble and stretches a few times>

OK, just a bit of an update.

It turns out that in some cases a shipstate class does currently need to be maintained for all teams - notably when it's responsible for performing updates on VCs.   The seek-and-destroy missions should be ok, but some of the ones with additional goals/requirements will need some changes before this fix can be fully applied.  Anywho, as I'm going through this I'm jotting down notes on what will need to be done to fix the remaining cases.

(The short version is that for now the fix might not get applied to some of the ships in some of the missions, but it'll be a minority.)

When I get the updated pack posted one of the big things to watch for in testing is misreporting of wins/losses -  if there's a mission consistently failing to give either the player or a draftee proper credit for a win then the odds are I've updated a case I shouldn't have.

DH - I'm going to have to postpone the speed configuration setting while I get this stuff squared away, but hopefully can come back to it (next week mb?)

dave

Hmmm..
.. why would non-hosts have to deal with the shipstates (and teamstates while at it) of the AIs? Is there a way to redo these exceptions so that only the host cares about this?

[FPF-DieHard]

Thanks Dave.   If we go live on August 21, we pretty much need the missions ready by August 14.

Again, I have a work around that would allow the existing missions to work in GW3.  Simply restrict ALL carriers in the Client shiplist.  They will no longer show up in missions but will still be available for players to purchase in the shipyards.

[FireSoul]

Thanks Dave.   If we go live on August 21, we pretty much need the missions ready by August 14.

Again, I have a work around that would allow the existing missions to work in GW3.  Simply restrict ALL carriers in the Client shiplist.  They will no longer show up in missions but will still be available for players to purchase in the shipyards.

I have something to add..
.. just like the double-fighter bug, the double weapons were always in effect.. most people probably just never noticed. Are you sure of your fix?

[NuclearWessels]

Hmmm..
.. why would non-hosts have to deal with the shipstates (and teamstates while at it) of the AIs? Is there a way to redo these exceptions so that only the host cares about this?

I don't think there should be an issue redoing the handful of exceptions - haven't spotted any yet that should be overly difficult ...  "cautiously optimistic" is the phrase

dave

[FPF-DieHard]

Thanks Dave.   If we go live on August 21, we pretty much need the missions ready by August 14.

Again, I have a work around that would allow the existing missions to work in GW3.  Simply restrict ALL carriers in the Client shiplist.  They will no longer show up in missions but will still be available for players to purchase in the shipyards.

I have something to add..
.. just like the double-fighter bug, the double weapons were always in effect.. most people probably just never noticed. Are you sure of your fix?

The EEK missions do not due double heavy weapons any more (90% certain that got fixed).  I have seen double-mauler shots with the current ED core missions.

Double weapons is mostly noticable with plasma, we haven't seen plasma on the GW series yet.

As far as my "fix," Both EEK and ED missions will not draw restricted ships so this SHOULD work, I have not had a chance to test it yet.

[FireSoul]

no carriers.. that's gonna get boring..


..waitaminute, I'll be flying Klingon! Their fighters SUCK!..
... Carry on. 

[FPF-DieHard]

no carriers.. that's gonna get boring..


..waitaminute, I'll be flying Klingon! Their fighters SUCK!..
... Carry on. 

More boring than Stock missions?   

[762_XC]

I would rather watch a sewing tournament than play stock missions again!

[NuclearWessels]

Yup, testing now.

Dod you have any patrols that do not start the players in motion?

Most of the _tw patrols start you off standing still (can't honestly remember when I did that) so if the total war pack is ok for you at least there are a few options

dave

[NuclearWessels]

Core missions
Total War missions
The whole shebang

OK, I've completed the script revisions and tested the majority of the core/total war missions (plus a handful of the weirdo specialty missions) and no glitches so far.

EDIT: all three updated versions are now online

Keep your eyes peeled for abnormal mission endings or results reporting,
hopefully other than that we'll be ok

thanks again!
dave

[FireSoul]

Fetching now. Which server has these missions? Bonk's?

[Bonk]

The Gravity Well is running the latest Total War pack now.

[el-Karnak]

*sigh*

From the API, there are 4 mCreateShip functions. Here are their prototype, with the important bit in red.

TeamInfo.h:

   void   mCreateShip( const type_info& shipClass, const tShipInGame& ShipData);
   void   mCreateShip( const type_info& ShipClass, const char* ClassName, int32 Position, int32 MetaDatabaseID, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions ); // The only one used
   void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes ShipType, int32 VariantPercent, int32 Position, /*int32 MetaDatabaseID,*/ int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions, eRace Race = kNoRace );

   void   mCreateShip( const type_info& ShipClass, int32 TotalBPV, eClassTypes SmallestHullSize, eClassTypes LargestHullSize, int32 VariantPercent, int32 Position, int32 CustomID, int32 StartX, int32 StartY, int32 EndX, int32 EndY, const char* CustomName, eShipOptions ShipOptions );

They all use the shipClass param which allows you to define your own ShipInfo code. Within the ShipInfo file is where the problem is, so the issue is not[/red] the mCreateShip function.

But I'll play along. 

• The first mCreateShip listed here, above, calls mCreateTeamShip to do the final work.
• The 2nd comes from my original example. It also  calls mCreateTeamShip to do the final work
• The 3rd comes from your complaint. Within the API I see that that one calls
  mCreateFleet, which in turn calls mCreateTeamFleet, which in turn calls mCreateTeamShip within its loop.
• The 4th mCreateShip also calls mCreateFleet, and follows the same path as the 3rd one.

So. They all use the parameter which defines the shipClass to use. You use that to track down the bug within the source, where the Registeration of TeamState is, and you make it more restrictive to prevent the double-fighters/weapons.. .. and they all end up within the same function of the API.

I would like to point out that other functions, such as mCreateTeamFleet and mCreateCPUFleet, also do this.


Edit: Oh! NOTE:
If you're Registering the TeamState elsewhere, for whatever reason you need to do this, then you need to add the restriction that only the host should Register that State for the AI ships. The focus is the State: make sure it's not run on all machines.

I'm more interested in actual test results that use API in question rather than the theory.

This "that only the host should Register that State for the AI ships" makes a whole lot more sense rather than say all human controlled team need to register the ship states too.  If so, it's not gonna work and we have the test results to prove it *jerks thumb at DH*.

Where are yours?

Come back with evidence that API calls to every one of these API routines:

li]The first mCreateShip listed here, above, calls mCreateTeamShip to do the final work.[/li]
[li]The 2nd comes from my original example. It also  calls mCreateTeamShip to do the final work[/li]
[li]The 3rd comes from your complaint. Within the API I see that that one calls
mCreateFleet, which in turn calls mCreateTeamFleet, which in turn calls mCreateTeamShip within its loop.[/li]
[li]The 4th mCreateShip also calls mCreateFleet, and follows the same path as the 3rd one.[/li]

work and then we can say it's fixed. It's an empirical science not theoretical conjecture.

As for your arrogant *sighs*. Kindly put them away in the Castrin and Cleaven toybox with the rest of their toys.

Nothing has changed. Not one single solitary thing.

Yep, still after all these years, you still don't need a hair-cut. *snicker*

[FPF-DieHard]

Karnak, I chat with both you and FS all the time.   There is no need for this pissing contest.   Please edit that post and make it a little more civil.

Both of you are a great asset to the community.  he is being nice, you should be to.

[FireSoul]

I give up. He doesn't want to understand nor try.

[el-Karnak]

he is being nice, you should be to.

If I thought he was being nice then I would be civil.

[FPF-DieHard]

he is being nice, you should be to.

If I thought he was being nice then I would be civil.

HE IS BEING NICE!!   FS and I chat all the time and he doesn't have a mean intention in him.  Stuff gets lost on the forums and misunderstood.   FS is only trying to be helpful.

[el-Karnak]

HE IS BEING NICE!!   FS and I chat all the time and he doesn't have a mean intention in him.  Stuff gets lost on the forums and misunderstood.   FS is only trying to be helpful.

Yeah, it comes out a lot more clearer in TS conversations.  Get Dizzy to say the same and then we can assess that issue in a different light.

I give up. He doesn't want to understand nor try.

Am trying very hard not to give out one of your arrogant *sigh*'s and inject your arrogant tone in the post.

Simply speaking, you only see half the picture here and only have half-a-solution.  Don't make like you got it all figure out when you don't. I have gone through everything you posted and 90% of it was already tried months ago.  The remaining 10% got quickly disproven in a couple tests with DH a couple nights ago.  When I have time I'll figure this mess out and then post the results.   If somebody comes up with it and I see it then I will happily acknowledge it. You can say that I come from the "Show Me" state of Missouri.

[FireSoul]

(dammit!    )

The mCreateShip functions are not part of the problem. Don't you see? They're named here because they are useful only to indicate what shipClass you're using. You then track down the state file for this shipState and you find out where the TeamStates are being registered.
So do me a favour and drop the focus on these functions and look at what I have written here below.


What you need to do is this, very specifically:
Prevent non-hosts from handling TestStates for AI teams. Only the Host should do that.


Since I don't have access to your sources, I will leave it up to you to figure out how it applies. However, feel free to use the example I have posted in the very very first post of this thread.

[Astarte]

Am trying very hard not to give out one of your arrogant *sigh*'s and inject your arrogant tone in the post.

Simply speaking, you only see half the picture here and only have half-a-solution.  Don't make like you got it all figure out when you don't. I have gone through everything you posted and 90% of it was already tried months ago.  The remaining 10% got quickly disproven in a couple tests with DH a couple nights ago.  When I have time I'll figure this mess out and then post the results.   If somebody comes up with it and I see it then I will happily acknowledge it. You can say that I come from the "Show Me" state of Missouri.

Luc arrogant?  Sometimes, but this isn't one of those times.  Frustrated? Tired?  That sounds more like it.

Perhaps this fix won't work for your missions.  As far as I have gathered, you have not shared your source code with anyone, so it is up to you and you only to be able to assess its impact in your missions.

Luc tested his results fairly carefully, and in the examples he stated.  He has also stated what he does and does not know about it.  It is not for him to prove anymore.  This fix is being used and tested now.

In the end, it is up to you to use the fix or not.  *shrugs*

[Cleaven]

he is being nice, you should be to.

If I thought he was being nice then I would be civil.

Folks, you are dealing with the Toad Prince here, get used to it.

[FireSoul]

Core missions
Total War missions
The whole shebang

OK, I've completed the script revisions and tested the majority of the core/total war missions (plus a handful of the weirdo specialty missions) and no glitches so far.

EDIT: all three updated versions are now online

Keep your eyes peeled for abnormal mission endings or results reporting,
hopefully other than that we'll be ok

thanks again!
dave

Have you ever thought of making installers? It's darn easy, and the installer kit's free:
http://nsis.sourceforge.net/

Also, I'm sure some people here would be happy to help you out on this matter. After all, all you need the installer to do is look up the SFC:OP/EAW install dir, confirm things and let her rip. An uninstaller is automatically created with a quick command within the installer-generator-instruction file, and you can have it added to the control panel's uninstall menu as well as add an icon to the uninstaller somewhere.

In fact, I'm betting the installer's size would be smaller than these .ZIPs with the new compression LZMA scheme..

[FireSoul]

Uhhh... Dave? I think you should forget about zipping your missions from now on..  I decided to spend a little bit of time to make you an example installer for your "WholeShabang" all OPMissions pack.

The results are this:

Code: [Select]

Output: "C:\Documents and Settings\FireSoul\Desktop\NW\ED_OPMissions.exe"
Install: 3 pages (192 bytes), 1 section (24 bytes), 163 instructions (4564 bytes), 189 strings (4686 bytes), 1 language table (230 bytes).
Uninstall: 3 pages (192 bytes),
1 section (24 bytes), 158 instructions (4424 bytes), 192 strings (7950 bytes), 1 language table (214 bytes).

Using lzma (compress whole) compression.

EXE header size:               33280 / 35328 bytes
Install code:                          (10000 bytes)
Install data:                          (46524042 bytes)
Uninstall code+data:                   (13872 bytes)
Compressed data:             3993825 / 46547914 bytes
CRC (0x595B8C7A):                  4 / 4 bytes

Total size:                  4027109 / 46583246 bytes (8.6%)

4. Megs. Four Megabytes.

4 MB! .. yes sir. That's your 20MB ZIP file right there beaten to a pulp with this new fancy-dandy compression protocol.

Here's the installer:  http://pet.dhs.org/~firesoul/sfc2/NW/installer/ED_OPMissions.exe
Here's the installer instructions file: http://pet.dhs.org/~firesoul/sfc2/NW/installer/Z_NW_All_OP_Missions.nsi


Seriously, take this and stop using ZIP. You'll do us all a favour. 
This installer will install everything into the right place. It also creates an uninstaller and places it into  the Control Panel's Add/Remove Programs which uninstalls all files it added. Additionally, you can run the uninstaller from the SFC:OP directory.

I suggest you take and tweak the installer file to do whatever you want it to do.

-- Luc

[NuclearWessels]

LOL - thanks again Firesoul, will take a look at it on Monday - do you ever sleep man?

dave

[Astarte]

LOL - thanks again Firesoul, will take a look at it on Monday - do you ever sleep man?

dave

*drags FS off to bed*

I'm sure he will slip out sometime and start working on the models.

[FireSoul]

yeah. See? I just got up, and it's noon.   
-- Luc

[FireSoul]

I updated the 2 files above (installer).

.. also: Dave, ou have way too many MCT files. OP has a limit of 64, and between your pack, and my EAW_for_OP pack, there's not enough room.

.. I can help you with adding install component options, if you want. I had to figure it out today because I made an installer pack for the EAW for OP missions.


Edit: See: http://www.dynaverse.net/forum/index.php?topic=163344617.msg1122416343#msg1122416343

[NuclearWessels]

Yeah, the mcts are a legacy of the different pack combos - kept on adding them and not thinning the beasties out.  You're right though, I really need to go through and clean that up.  <adds to list>

dave

[NuclearWessels]

Thanks again FS - I finally downloaded NSIS and think I have the installer set up the way I want, and will definitely be using that from now on instead of the zip files.

I did also finally go through and clean up all the .mct files (cut it back to just the one biggie per race) and eliminated the errors and redundancies within the mcts themselves.

I'm still testing some additional fixes and tweaks for DH, then will probably post the installer for the updated pack tomorrow arvo

thanks!
dave

[Rod ONeal]

Very good news. I'll be DLing this on ASAP. Thanks for all of the hard work, guys. Without the scripters this game would be in real trouble, IMO.

[el-Karnak]

(dammit!    )

What you need to do is this, very specifically:
Prevent non-hosts from handling TestStates for AI teams. Only the Host should do that.

If this was true then dbl-fighter EEK would have been fixed in SS2.  You still have not explained why the dbl-fighter bug does not show up in stock missions. 

What you need to do is this, very specifically:  spit out a mission script that uses the mCreateShip function I detailed and see if it works. Don't use any of the dynascript mCreateSHip(). Just the stand-alone mCreateShip() functions.

In the end, it is up to you to use the fix or not.  *shrugs*

So far, it's not usable in EEK which is the point I have been trying to get across. Unless you know something about scripting perhap you should stay out of it?  There's a thought....

[FireSoul]

*shrug* too bad. I gave you all the info I had.
Oh, and I will be honest: I do not know why the stock missions still remain ok.

-- Luc

[Astarte]

In the end, it is up to you to use the fix or not.  *shrugs*

So far, it's not usable in EEK which is the point I have been trying to get across. Unless you know something about scripting perhap you should stay out of it?  There's a thought....

And the point I AM trying to get across to you is TOO BAD.  Luc worked with the information he has and came up with a solution.  He provided you with all the information he had.  *gets a feeling of deja vu from saying this in her previous post*

Doesn't take a programmer to know that you can't fix what you don't have. 

Ever occur to you to go "Oh damn, doesn't work in this case.  I wonder what is different between my scripts and the stock missions?"  *gasp*  Could common sense actually apply?  OMG!  Who would have thought??!!  People can use....common sense!

Now pull up your pants, you've just been offically spanked.  Now grow up.

[Rod ONeal]

Does anyone think that it might help to have one of Taldren's (ex)scripters take a look at Dave's or Karnak's Source codes for a mission and see if they could spot the problem? Or possibly ask if they encountered this and, if so, how they got around it?

Just a thought.

[KBF-Crim]

heh...I think they would flee like frightend deer.....

 ;Dj/k

[el-Karnak]

All right. I had some time this week to really take a look at this. The buggy code in EEK mission causing the dbl-fighter bug was these two lines:

// Enable AI Officers
for(i = kECMOfficer; i <= kShuttleOfficer; i++)
mChangeAIOfficerState((eAIOfficers)i, kTrue);

Namely, the kFighterOfficer.

The FireSoul script had not effect on the EEK scripts. It did not matter if we used FS script fix or not. As a precaution, tonite's tests reveal them to most probably be un-necessary ones at that, EEK already compensated for any BaseState issues with the missions made a year ago for SS2 even though the stock missions, that don't produce dbl-fighter bugs, don't use the BaseState checks.

Bottom-line: as long as the mChangeAIOfficerState(..) routine calls were out of the tTeamShip::SetupShip(..) call, the dbl-fighter bugs were gone.  Any scripts out there using this routine need to be fixed otherwise they'll dbl-fighter bug break.

Many thanks to Bonk and DRB for being great Co-op mission testers. Things really started to move when all 3 of us got into the s/w testing groove with one guy coding, one guy pushing the new scripts on the GWell dyna and then 2 players playing while the not in-mission guy looked up the enemy Hydran ships to verify their fighter complements.

Funny thing is that if I did not get overly aggressive in my officer AI coding then this 18 month old bug would never have appeared in EEK missions...OOPS!! 

[FPF-DieHard]

Compile away!  I'll throw them on the test server tommorow night.

[Dizzy]

Whoohaw!

[el-Karnak]

In the end, it is up to you to use the fix or not.  *shrugs*

So far, it's not usable in EEK which is the point I have been trying to get across. Unless you know something about scripting perhap you should stay out of it?  There's a thought....

And the point I AM trying to get across to you is TOO BAD.  Luc worked with the information he has and came up with a solution.  He provided you with all the information he had.  *gets a feeling of deja vu from saying this in her previous post*

Doesn't take a programmer to know that you can't fix what you don't have. 

Ever occur to you to go "Oh damn, doesn't work in this case.  I wonder what is different between my scripts and the stock missions?"  *gasp*  Could common sense actually apply?  OMG!  Who would have thought??!!  People can use....common sense!

Now pull up your pants, you've just been offically spanked.  Now grow up.

You're the one who needs to grow up. Post assinine crap like this again and it goes to the Admins.

 Or would you prefer to me to go running to my wife like your husband did and get her to flame-roast you that way you royally deserve for your immature attitude; especially, when FS has this dbl-fighter bug code fix all wrong.

It's now proven. Or perhaps, you have issues dealing with reality too?

[FPF-DieHard]

Karnak, please delete that post.

[FireSoul]

Don't worry about it: I'm locking the thread. (It's still mine.) 

This entire exercise is over and complete.

-- Luc

[FVA_C_ Blade_ XC]

Ok ,

First of all thanks guys for the fix.

Now,you all knock off the p00p!

[FPF-SCM_TraceyG_XC]

Bump (so I dont forget where this thread is)