[bigchunk1]

Glitches? In game crashes? Errors with recent builds? All of the above go here. This thread is meant to keep a clear list of all the technical hurdles that face Blue Planet Multi.

When posting, try to include:
The name of the mission the error occours in
What happened in the game
What are the assets/possible sexps involved

Hopefully, if everyone is familiar with these issues, we can get around to solving them or at least finding a reasonable workaround.


A list of all known issues will be maintined here:

Standalone servers don't allow use of the Keypress feature. (bp2-mc03)

Clients see a shifted lunar.pof while the host sees the lunar.pof in the correct position. (bp2-md06)

When-argument does not work as intended in some situations, requires further testing ( mission independent )

Player ships who are controlled by AI do not have their position tracked after death, and do not trigger sexps using the 'distance' operator ( mission independent )

A player's ballistic weapons (Gattlers Redeemers UX accelerators) generally begin with wildly negative counts, and are unable to be fired. Normal ammunition count is restored when a player respawns. (mission independent) - FRED Workaround Found

Player controlled capital ships have their turrets lock up at unknown times, turret-free-all yields mixed results (Capship PvP missions)

[General Battuta]

When-argument does not work as intended in some situations, requires further testing ( mission independent )

Could you post an example of this? A SEXP that doesn't work as intended?

[bigchunk1]

Just as an example let me extrapolate on an error Shade and Zalem and I found the other day...
This is for the Uhlan Dogfight on the Moon

When a host launches and plays bp2-md06 he/she sees this:

Looks pretty normal right? It should

When a client (non-host) launches and plays bp2-md06 he/she sees this:

Not normal right?

It seems as if the moon surface .pof is being moved upward a certain amount for all non-host players. I have no idea how this could be the case.

When-argument does not work as intended in some situations, requires further testing ( mission independent )

Could you post an example of this? A SEXP that doesn't work as intended?

Well, when we first implemented modular spawning we had a sexp that went something like:
When-Argument
any-of
Alpha 1
Alpha 2
Alpha 3
Alpha 4

-- <
Distance <argument> 'Spawn Point'
500

Set-object-position (blah blah)...

This didn't work in multiplayer since the event never triggered. Strangely enough, it seems to work using Every-time-argument, better still to make 4 separate events. I'm not sure why and more testing is needed before I can be sure enough what the problem is, but it's here in the thread so we can keep an eye on it.

[bigchunk1]

Karuna turrets only fire sometimes in 'The Blade Itself' conversion. The cause is unknown. Sometimes the frigate will begin firing turrets when hit by breamfire or in combat.

Plunder crashes on recent builds, probably when the player respawns.

[karajorma]

Standalone servers don't allow use of the Keypress feature. (bp2-mc03)

It's not just stand-alone where you will see that. Clients can't register that SEXP because clients never ever actually run SEXPs. It's just more obvious on the stand-alone because the host is also a client.

When-argument does not work as intended in some situations, requires further testing ( mission independent )

http://www.hard-light.net/forums/index.php?topic=74909.0 - That explains why it works with every-time but not with when. It's one of the examples of a time when you should be using every-time. If you need more help than that explanation, just ask, as it is kinda technical.

Player ships who are controlled by AI do not have their position tracked after death, and do not trigger sexps using the 'distance' operator ( mission independent )

I'd bet money this is the same issue as above.

[Lester]

Player ships who are controlled by AI do not have their position tracked after death, and do not trigger sexps using the 'distance' operator ( mission independent )

I'd bet money this is the same issue as above.

It isn't. I've been using  every-time-argument from the very first commit of the mission involved. The system works only sporadically, and I've never seen it work if testing it by myself (ie, only myself on an empty server). The sexp only moves me, completely ignoring the AI-controlled ships. All of the issues bigchunk listed are present in bp2-mc03, which also has some other rather peculiar bugs going on, such as directives in an event not appearing but the event working and triggering normally, and random music tracks being played even if there is no tabled music enabled, conflicting with event-driven music.

I've recently given the mission a revamp (and it still doesn't work ), but I can easily revert the changes if you want to witness the errors yourself.

[bigchunk1]

Player ships who are controlled by AI do not have their position tracked after death, and do not trigger sexps using the 'distance' operator ( mission independent )

I'd bet money this is the same issue as above.

Thanks for the reply Karajorma. This issue has been confusing us for the past few weeks. My theory is that whatever variables that track the position of an AI controlled player ship are dropped when that ship is destroyed the first time (like singleplayer AI). As Lester said, every-time works... but only in special situations, which may prove my theory to be incorrect.

Edit: Found a workaround for the Negative Ammunition Spawn glitch, maybe it was battuta's idea I don't remember. A when ->true set-ammo sexp fixes it. Not too bad of a compromise, you need to set the sexp for every primary bank of every player ship in every mission, but it works like nothing was ever wrong.

 

[karajorma]

It isn't. I've been using  every-time-argument from the very first commit of the mission involved. The system works only sporadically, and I've never seen it work if testing it by myself (ie, only myself on an empty server). The sexp only moves me, completely ignoring the AI-controlled ships.

Hang on a sec, the issue listed was that the SEXP never triggers, then you say that it does trigger and only moves you. Which is it?

Anyway, either way I'm not about to debug the mission itself since I'm not a member of the BP Multi staff. If you can trigger the same error in a sample mission using FS2 retail data then it's obviously a code bug. If you can't, my money is on FREDding error.

If you post the event in question though, I will look at it.

[Lester]

Done and replicated using retail data on 3612r. The mission involved is in the attachment. As predicted, the sexp works for the first time, moving all three ships, but upon death only moves the player ship.



<< click  Added a mediafire link- Bigchunk1>>

[attachment deleted by ninja]

[bigchunk1]

Just to be clear, modular spawning is how we 'move' the spawnpoint in multiplayer missions. This is essential in missions such as 'Delenda Est' where the action near the end of the mission is quite far from the original spawnpoint.

There are two separate obstacles we face in getting the modular spawn system to work:

One is that When-Argument does not always work. Karajorma's thread has helped shed some light on why this is the case.

We have gotten around this issue by using every-time-argument or by using a separate event for each player ship.

The second issue is that player ship AIs (player ships which are not controlled by a human in the game) do not relocate themselves under the modular spawn system. I did a test, and this is because the distance operator does not trigger for the player ship AIs. This is why I suspect that player AI ships do not have their coordinates tracked after death.

(when)
 and
   -some event triggered
   -distance
     spawnpoint
     Alpha X
->relocate ship

Human controlled player ships are relocated properly so long as you avoid using when-argument.

MatthTheGeek made a modular spawn system which bypasses the second issue by not allowing the player ships to die. It involves imposing a guardian on the player and relocating him or her until the number of 'fake lives' expires. It works well, but it is not an ideal system. For example, self-destruct has unintended consequences and the player does not have a respawn menu upon death.

[bigchunk1]

Turrets lock up on player capital ships. Sometimes this can be fixed by a 'turret-free-all' sexp, but only sometimes. The turrets sometimes free up on respawn or when hit by beamfire or other forms of aggression. I'm not sure why it is the case. We need to find a solution or capital ship PvP will be unreliable.

Anyone know what the problem might be?

[karajorma]

Hmmmmm. On looking into it, this isn't a bug so much as a design flaw in the distance SEXPs. They use sexp_get_object_ship_wing_point_team() which will always return OSWPT_TYPE_EXITED for any ship which has been destroyed (which apparently includes the wingmen but not alpha 1 I suspect). The result is the SEXP will return SEXP_NAN_FOREVER for any ship which has respawned.

If I fix this I'm definitely going to break any missions that assumed that distance only worked for the first respawn. That's a really stupid assumption though and it's probably broken more multiplayer missions than it will break if I fix it.

Stick it in Mantis and I will try to take a look at it when I have time.

[bigchunk1]

Mantis report submitted. Many thanks for looking into the distance sexp issue Karajorma! 

[bigchunk1]

Universal Truth has the "players have not been properly assigned to their ships" error which crashes everyone just before the briefing.

I believe I know the root of the problem, but i'm just making a note of it here.