We have a level that we work with in the development version. Here is a screenshot of it:





However, when we publish it and do NOTHING else to it, we get the following:






We did some investigation and used ent_next to cycle through all the entities. We did this in both our development and published versions:



As you can see, some level geometry is completely missing from our published version. Notice also that the two golems on the left are missing in the list and replaced by starbases (the blocky objects). Similarly, the tree to the right is replaced by our ball entity and also missing from our published list.

Another symptom (not seen in these shots) is that non-level geometry that is created by clients will come in with the wrong orientation and the wrong scale. We have all the nosends on but even when we turn them off and manually set the scale to 1, the problems persist.

Any clue as to what could be causing this?

There can be many reasons for this, but my first 2 suspects are loading a saved game that was saved with a different application, or connecting to a multiplayer server that runs a different application. Both causes different entity indices and subsequently, wrong entities in your level.

Note that the development and release version are slightly different, so you can not mix saved games or mix server/clients among them.

Well we don't save or load games so that's not an issue.

As to the multiplayer, we have the exact same code on developement as on publishing. We have the same levels in all our application, we bind all the needed models in every client and the server, and we are very careful to separate our network indicies from our local indicies. Furthermore, if it was a bad index issue, it should affect development and publishing equally and as you can see, in development things run fine.

If the difference that you are refering to is the list we have above, note the following: in development everything is running fine and when we output all the entities in the level (using ent_next() calls), the "development version" list is what we get; when we publish and follow the exact same procedure, using the ent_next() results in the "published version" column and thus the missing models.

In other words, the missing models are not of our doing; that is one of the symptoms that we are noticing and everything is exactly the same in publishing than what we have in development.

A few followup points:

1) It needs emphasizing that what you see above is the result of running the exact development code but published under A6.6 Pro with the resource option on. Hence the only difference is the WRS packing and perhaps a slightly faster run-time. There were no code or setting changes between the dev and pub versions.

2) As you can see from our entity list, the models that are missing are correctly bound to the level. This can be seen in the trees where there are plenty of tree01's in the published version but some are missing. Hence it can't be a BIND issue.

3) It also needs emphasizing that only entities that are part of the level are missing. All the entities that are created with ent_create are present ALTHOUGH THEY STILL SUFFER A SCALING PROBLEM. So the entities are not responding correctly thoughout the system but entities that come in with the level behaive differently than entities that are ent_created after level_load.

4) Finally, we thought that maybe we weren't giving the level_load enough time to work in the pub version. We normally have a wait(3) after the session_connect and a wait(3) after level_load and this has always worked in dev. To test this idea out, we changed both waits to wait(-1)... the problems were still there exactly as before.

Ok, the first thing to check then is if the problem is related to the level or to your multiplayer script. For this, run the project in single player mode and check if the level then looks ok. You can also publish a test project that only opens your level, but does nothing else.

We will however perform the test as you suggest and see what happens.

However, regardless of these results, it is mystifying to us as to why the development version looks perfect but the published version is where we see the errors. Do you have some idea as to why that would happen (since the script and level and everything is the same in both)?

There are several internal differences between development and release versions - the speed is different and internal lists, responsible for the entity indices, can also be different. However I'm sure we'll find out.

Quote:

---

the speed is different

---

We knew this one. We have several timing issues in our game where we use wait(1) and this causes irregular behaiviour. However, we've ruled out timing in this issue since we have no control over entity creation when it's part of the level.

Quote:

---

internal lists, responsible for the entity indices, can also be different.

---

Now this is interesting! We had noticed that when we do dev vs. pub, the handles seemed to be different from run after run. However, we were not sure WHY they would be different.

Could you expand a bit on this point? Why would the internal lists in publishing be different than in development? I would like to know for as you stated before, we need to make sure that our network indicies do not interfere with the other indicies. The solution we've used is to put anything that will go over the network (strings, texts in strings, variables, function/actions) as a header in the begining of the file and replicate this header among all our applications. Hence, in principle, every application gets the same index for every network object. But by what you say, going from dev to pub may actaully interfere with this process.

Curious to know more about how the internl list is managed in dev and pub!

The entity lists are built up when entities are created. When an entity is created on the client, the server updates its internal lists, generates an index and sends it to the client. The speed of the application and of the network determines the order in which entities are sorted into the list, and thus their indices.

Only within a session the entity indices are guaranteed to be the same on server and clients. When you start up the server the next time and run the very same game with the same clients, the indices of the same entities can be different. They tend to be the same on the same system, but are possibly different between development and release version, or when you move the server to a different PC.

However this can normally not cause a problem. The only thing you should not do is assuming in your script that entities are always created in the same order or have the same pointers or indices.