Clients unable to join aircraft positions...

[ENO]

Okay- here's a new one... server is stable but nobody is able to join the A-10s.

 

I heard from one of the regulars and dismissed the claim, figuring he must have just done something wrong. I then went in and tried to join and it's like I wasn't even in a position.

 

It's affecting two different missions... that are completely unrelated- both of which have been resaved with current versions on the server.

 

One was recently updated while the other wasn't.

 

One runs CTTS and MIST while the other doesn't- so literally no relation except that people couldn't occupy most spots.

 

I just went into the log and saw this... I had joined a variety of different A-10 slots and yet this is what it says: 00154.441 INFO NET: client[2] is ready to start

00154.441 INFO NET: spawning client[2]

00154.451 INFO NET: client[2] started

00172.541 INFO NET: Lua: Client [2] "Eno" joined Blue in "Soldier M249"(201)

00178.561 INFO NET: Lua: Client [2] "Eno" joined Blue in "Paratrooper RPG-16"(202)

00182.281 INFO NET: Lua: Client [2] "Eno" joined Blue in "Soldier M4"(206)

00185.352 INFO NET: Lua: Client [2] "Eno" joined Blue in "Soldier M249"(201)

00204.952 INFO NET: client[2] has left the game

00205.048 INFO NET: Lua: Disconnected client [2] "Eno"

00205.048 INFO NET: remove: client 2

00205.050 INFO NET: simulation paused, modelTime = 57.311000

00289.886 INFO Config: netview stopped

00289.995 INFO NET: messages tracked: 88

00289.995 INFO NET:

 

 

Whoops- something is amiss here.

 

I switched back to Mistv 2 and got this instead:

 

00042.717 INFO NET: Lua: Client [1] "Eno's Firehouse" joined Blue in "A-10C"(201)

 

Maybe this is one Grimes and I will need to chip away at...

Edited September 10, 2013 by ENO

[Grimes]

Going to need the missions to test this. Preferably if you still have a copy of the bugged version.

[ENO]

Both these versions are bugged...

 

I thought it may have been that script I added in but the .e version is with MIST 2 and the only mod to CTTS was to include the RPG unit.

Edited September 10, 2013 by ENO

[Grimes]

Welp, now I know what happens if scripts spawn units with the same group or unit id as a client...

 

The good news is I don't think its a bug. The bad news is my initial reaction and hypothesis that it was impossible that this might be scripting related was completely wrong. At least its not the fault of mist. :) So here is whats happening. He has the default unit counter start at 100 for everything, which means his script decides to spawn stuff in at unitId 100+. If you have anything in the mission already using that Id, which you certainly do in this case, that object will get overwritten. In some cases the object is a client aircraft. Thus X aircraft magically gets turned into an "M4 Infantry" dynamically because it shares the same unit or group Id. Must experiment to see if there is a practical use for that further...

 

 

 

 

Changing the default values on lines 305, 306, and 307 to a value not likely to be reached in the editor should fix it. Actually I'd offset 307 by at least 1000 just to be safe because I'm pretty sure the id used for static objects is shared with unitId or groupId.

 

groupCounter = 10000
unitCounter = 100000
logcargoCounter = 110000

 

Why he has it set to 100 by default seems kind of odd as it will very likely overwrite objects in the editor and he makes it look like that is a value you should never ever touch. It doesn't really matter to the scripting engine what group/unit id it is given to spawn a unit, it just needs a real number greater than 0. Btw, I said its not entirely the fault of mist because the CTT script still populates group and unitIds anyways, and then hands that data to mist to spawn the group with that little modification I suggested for you to make to it. Even without that modification, with the values at the default 100, the error should still occur in a mission of that size.

[ENO]

Thanks a ton grimes- so I will change that default counter and go from there.

 

 

Edit: I did adjust the counter and then went back into the mission to choose every slot- and as you assumed it worked according to my log. No more conflicts.

Edited September 10, 2013 by ENO

[shelt]

I thought the issue was addressed earlier in the thread,

maybe not the same issue, but I was getting the same results when spawning

 

http://forums.eagle.ru/showpost.php?p=1818517&postcount=43

[ENO]

I'd seen something like that before actually- but I hadn't put the two together since I wasn't that familiar with the script. Admittedly it's not my forte- that and so many other things.

 

Anyway it is an issue with that CTTS script so guys building larger missions should be aware of it. And, if I see someone experiencing something similar in the future I'll know the first place to look. Not necessarily at the CTTS script (I don't want to sound like I'm ragging on it- I'm certainly not)... but at the fact that the script does what it's told and conflicts generally result in one of the two not existing.

 

Interesting to know though... is it a "roll of the dice" or will the spawned units ALWAYS overwrite the alternate spots?

 

 

 

On a separate note and more pertinent to the thread- I just had the mission mentioned above crash on me running the modified CTTS Script along with MIST 3.1- though I don't suspect either directly of causing the crash I thought I'd mention that I did have 1 of the A-10C slots (the first A-10C slot at Gelen) not function though the log correctly shows it assigned to me.

 

Shortly after trying that, the mission crashed. It was within a couple minutes of someone taking over one of the Mi8 slots. I say it kind of over my shoulder as I do have a separate "crash" forum entry along with all pertinent files HERE.

Edited September 11, 2013 by ENO