Waiting for Host - Campaign Edition.

[mytruepower2]

Yup. I'm getting that rare, "Waiting for Host" bug in a campaign I've been trying to design.

It's a single-player campaign, running on my computer. It's not multiplayer, nor will it ever be. I should also say up front that this campaign is VERY trigger-heavy. Virtually everything is managed with triggers; the spell damage, the spells themselves, the item-access system and so forth.

The problem is that I've been trying to create an overworld/cave thing, where you go back and forth between two levels freely, like in the early parts of the Founding of Durotar campaign. Let's call these levels Overworld1 and Dungeon1.

I start out in overworld 1, go to dungeon 1, and it's all going fine. Then, I go back to overworld 1, and still no problems. However, when I go back into dungeon 1, I get the following error message.

"Waiting for Host..."
"Disconnect"

The disconnect button turns on after a short while, and I really have no choice but to click it and end the game.

I figured I wouldn't have to deal with lag if I kept my game single-player, but I'm not sure what's going on here. What causes this error message to arise in single player campaigns?

 

[Superz_Ze_Man]

could you show us the trigger your using for moving between the 2 caves please? Not much we can do without it.

 

[mytruepower2]

Fair enough, but here's the problem...

The trigger is enormous. I'll try to summarize what it does, however...

To Level 3
Events
Unit - A unit enters ToLevel3 <gen>
Conditions
(Triggering unit) Equal to MainHero
Actions
Trigger - Run Prepare for Level Transition <gen> (ignoring conditions)
Game - Set the next level... etc... Sets the next level.
Game - Victory Player 1 (Red) (Skip dialogs, Skip scores)

"Prepare for Level Transition" is where all the heavy stuff happens. There are no events or conditions, and it does the following things.

First, it creates four dummy hero units, for the purpose of carrying the hero's inventory from one level to the next, like so...

Unit - Create 1 Carrier for Player 12 (Brown) at (Random point in ItemTransferRange <gen>) facing Default building facing degrees
Set Carrier1 = (Last created unit)

This is done four times. Next, the contents of the custom inventory system that I designed is added to these carriers. This is done mostly with variables, and is hard to explain, but the trigger checks to see which "inventory screen" you're on first. This is why you need four carriers.

If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
CurrentInventorySlot Not equal to 1
CurrentInventorySlot Not equal to 0
Then - Actions
Hero - Create InventoryItems[1] and give it to Carrier1
Item - Set charges remaining in (Last created item) to Inventorycharges[1]
Else - Actions
Hero - Create (Item-type of (Item carried by MainHero in slot 1)) and give it to Carrier1
Item - Set charges remaining in (Last created item) to (Charges remaining in (Item carried by MainHero in slot 1))

This is done four all twenty-four item slots. After that, it's just a matter of storing and saving variables used by the game, which is done like so.

Game Cache - Store 2 as Levelfrom of Gameints in (Last created game cache)

This is the variable that tells you what level you've coming from; sometimes used to determine where your character should appear in the level, and to prevent cheating of certain kinds.

Game Cache - Store Carrier1 as Lv2Carry1 of Units in (Last created game cache)

The item carriers are saved in this way, with names that reference the level you came from, to make it hard to transfer later-level items to earlier levels.

Game Cache - Store PowersGained[1] as Powergained1 of Gameints in (Last created game cache)
Game Cache - Store CombosGained[1] as Combogained1 of Gameints in (Last created game cache)

These arrays have to be saved to the game cache, because they determine what powers and combos your character has already gained in the game, preventing it from displaying the "you've got a new power" message as soon as you enter the next level. There are thirteen of these.

Game Cache - Store MoveExperience[1] as Moveexp1 of Gameints in (Last created game cache)

Likewise, this determines the custom variable that each power references, in order to determine its strength. There are seven like it.

Game Cache - Store (Strength of MainHero (Exclude bonuses)) as Kstr2 of KStats in (Last created game cache)

Basic stuff here. Once again, to prevent cheating, the stats of the main hero unit are saved with the level number at the end of the game cache label.

Game Cache - Store MainHero as Kirin of Units in (Last created game cache)

Kirin isn't his real name, but you get the idea. The main hero is stored.

Game Cache - Save (Last created game cache)

The game cache is saved, and the game completes the remaining actions in the first trigger.

If you also need to find out how the game processes each of these variables, I can explain that too.

---

Update: I ran some tests, and it seems to have something to do with the variable arrays that I use for calculation spell acquisition and/or spell strength. Is there some problem that prevents the game cache from properly cataloging array values?

I'll run another test later to determine whether I run into this problem with every array value, or only with the move arrays, but knowing this bit of information would save me a lot of time.

---

Update 2: Ran another test. It's not a problem with all arrays, so my guess is that no arrays are really having this problem. It might be an issue with one of the other triggers, or it might be an issue with how the array variables are stored between levels. I'll try condensing the triggers this afternoon, and if that doesn't work, I'll at least know what the problem is.

 

[Vizel]

I was having a similar problem with my campaign. I'm using the same sort of system as you are.

You say it's trigger heavy...so you're not going to like this but...

Try turning off triggers one by one. Now, that probably won't do anything, based on what you're talking about, so try temporarily removing some stuff, like variables. As in, don't store them.

Now, the last thing I can say is...

Make sure you have some kind of check system like

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • Map4NewGame Equal to True
  • Then - Actions
    • Game - Save game as Overworld1.w3z and change level to Dungeon1.w3x (Skip scores)
  • Else - Actions
    • Game - Save game as Overworld1.w3z and load Dungeon1.w3z (Skip scores)

Basically, make sure you're loading the saved file, not creating a new file. Make sure your File names are correct, and consistent.

Basically, all I'm trying to say is make sure stuff is correctly spelled and placed.

Although, I've never had a "Waiting for host" issue before... I have been disconnected when trying to originally implement my system. What worked for me was disabling my Fullscreen Inventory, and removing all the said components from my save/load system. So try that. Although... I recommend making backups. Or comments

Hope I was able to be of some help, I know the frustration with this transition stuff. Also, if you do figure out what the problem is, I might bug you to see if you can find my problem if it arises again,

 

[mytruepower2]

I feel fantastic! And I never felt as good as how I feel right now!

I have succeeded in eradicating the error message, thanks to a few more tests, and some very good advice. First off, thanks for the good sense advice, Superz_Ze_Man. Secondly, Vizel, thank you for encouraging me to study my triggers a bit more closely. Thanks to you two, I now know both how to fix the problem, and what the error message means.

It seems that in storing level data, Warcraft 3 differentiates between units/items/invisible values/destructibles/etc and quests/player properties/strings/etc. In short, there's a difference between things you interact with via the units, and things you can only view with the UI interface in-game.

If you continually add new units to a unit group in rapid succession, TWE doesn't even flinch, so I sort of assumed a quest would react the same way. However, I had a trigger set up, to add new contents to quest descriptions (basically, to tell you how to execute your combos,) like so...

Set Combosqueststring = (Combosqueststring + Low Fog - D R E |n)
Quest - Change the description of CombosQuest to Combosqueststring
Set Combosqueststring = (Combosqueststring + Sword Flurry - R E Q |n)
Quest - Change the description of CombosQuest to Combosqueststring

etc... The problem is that the computer tried to execute this command by adding both "sword flurry" and "low fog" to the quest description simultaneously, and it couldn't figure out what order to put them in. Because it was supposed to display it in the quest screen, the interface itself failed, and the error message displayed was meant to tell me that.

"Waiting for Host" in this context, means "your string cannot be displayed in the interface, because it makes no sense."

To fix this problem, I just had to put tiny wait commands in between the string additions, like so.

Set Combosqueststring = (Combosqueststring + Low Fog - D R E |n)
Quest - Change the description of CombosQuest to Combosqueststring
Wait 0.10 seconds
Set Combosqueststring = (Combosqueststring + Sword Flurry - R E Q |n)
Quest - Change the description of CombosQuest to Combosqueststring

Thanks again to everyone who helped me out. Much obliged.

 

[Vizel]

I'm just glad I was able to help, and that's quite an intricate situation. I'll keep that in mind for the future. Although all of my "Quests" will be informational, and the actual Quests will be purely triggered since it'll be easier that way... I think. I know how to do it this way, anyway. Thanks for explaining what your problem was.