Editor causes bugs in local game?

[Azel]

So while building my Mod I tend to upload it via Private setting, and then when I want to play-test it I will download it via the Grimrock main screen menu. Sometimes this works just fine. Other times, when I load a saved game I notice that certain assets no longer function properly. A wall that should be invisible is suddenly showing in plain site. A gate that should remain Open until a Trigger is activated is suddenly Down and impassable.

I figure that it might be due to going back and forth between the game and the Editor; but I am also afraid I did something wrong in my Mod that causes it to randomly glitch this way. I figure I would ask here... has anyone noticed odd behavior while play testing a Mod?

[minmay]

viewtopic.php?f=22&t=9366

[Azel]

Dont think that applies in this case. The game doesn't crash, certain assets just suddenly get distorted or become visible when their attributes are set to hidden. Also, I never ever reference other Scripts. I think I can reproduce the error in a tiny sample Mod, with a single map, tiny space, and zero script/variables.

[Azel]

Well I think I figured out my problem. I will detail it here in case anyone else runs in to this issue.

The culprit was dungeon_wall_grating. In my Mod I create a lot of "thin" walls, which means I cannot use the standard Invisible Wall asset - since it takes up an entire square. Regular Asset Walls, such as Dungeon Walls, allow the player to walk right through them. Therefore, I was using dungeon_wall_grating (with the Model disabled to make it invisible) within each thin wall. This caused a collision any time the player attempts to walk through the thin wall.

The problem... as soon as a Player Saves and Reloads the game, the dungeon_wall_grating is no longer invisible; it's Model goes back to enabled. The player can see it plain as day. Odd things happened even in cases where I tried to keep the dungeon_wall_grating visible to the player but in an Open state (since it has door attributes). Again, if you Save and Reload the game, the dungeon_wall_grating falls back to a Closed state.

I did see this thread: http://grimrock.net/forum/viewtopic.php ... 41&p=88520

While no one said that this grating Asset should never be used, I guess that is pretty much the case (unless you create something where a stationary grating that serves no other purpose is the goal).

I re-ran some tests using tomb_wall_grating and everything is back to normal. Well, it will be as soon as I update every thin wall in my Mod to use tomb_wall_grating instead of dungeon_wall_grating. F-M-L

[minmay]

Code: Select all

defineObject{
	name = "dungeon_wall_grating",
	baseObject = "base_wall_grating",
	components = {
		{
			class = "Model",
			model = "assets/models/env/dungeon_wall_grating.fbx",
			staticShadow = true,
		},
	},
	editorIcon = 132,
	minimalSaveState = true,
}

minimalSaveState = true,
minimalSaveState = true,

viewtopic.php?f=22&t=9366

minimalSaveState
Objects defined as having "minimalSaveState" will have only minimal properties saved: their name, id, x, y, elevation, and facing. minimalSaveState should be used on objects such as walls and floors that won't change during gameplay. If you are changing the object in any way - using setWorldPosition, setWorldRotation, doing anything to its components such as setting wall text, etc. - then minimalSaveState is not appropriate. If you're confused, use the asset pack as a guide.

[Azel]

The Editor does not display which Assets use minimalSaveState and which do not, so again, your response does not apply here. I am not defining any objects. You seem to really want me to define objects for some reason, but nope... I don't wanna.

All I had to do was replace the Dungeon Wall Grating with the Tomb Wall Grating, and the problem went away. Based on your obsession with minimalSaveState, I assume it worked because the minimalSaveState for the Tomb Wall Grating is set to False (or simply not set at all). Whereas this property is set to True with Dungeon Wall Grating (thus causing my problem).

Either way, I am neither creating nor manipulating any object code so the real answer here is knowing which Assets can be manipulated easily via the Editor vs those that can't. Your writeup on minimalSaveState is directed at people who are defining objects, which I am not. I guess I could have looked up the code for these walls myself but I use a ton of walls/doors so... if I have to review every property in script before using each Asset then the process for Mod creation would be tedious and boring; no thanks.

The only thing your post does is explain "why" Dungeon Wall Grating is a bad choice... in a very long-winded and highly unnecessary way. A simple, "dont use that Asset that way, use another one," would have been suffice.

[Skuggasveinn]

Hi Azel

What minmay did was to hand you a very valuable information that every modder needs to know, if that modder is going to do anything more then just place vanilla assets in his mod he needs to know this, and it does very much apply to your problem, in fact it was the core of it.
What you did was to find a vanilla asset that works for you because it has minimalSaveState not set at all, but it should !!!!!
Consider this, it should !, so what happens if it gets patched down the road ?, yes your mod will get bugged.

You say you are not manipulating objects, but you are. By disabling a class like models or particles in a asset you are manipulating that asset. My advice to you is to change your policy on not defining your own objects, its the easiest thing to simply copy and past the tomb_wall_grating and change it name to something like az_tomb_wall_grating giving you full control over that asset and preventing potential trouble down the line with updates to the original game.

with best regards.
Skuggasveinn.

[Azel]

You say you are not manipulating objects, but you are.

Only through the Editor. My statement was not, "I am not manipulating objects," this was my statement, " I am neither creating nor manipulating any object code." You left out just enough to miss my point. I understand that the Editor is the tool between me and the code that gets changed; but I'm not changing the code directly without the Editor as the middle-man. Since the Editor does not display the Save State property, and I am only using the Editor for Mod development, knowing this particular asset works this way by default is more valuable than knowing which property setting in a LUA file I should look for.

If creating a Mod purely out of the Editor leads to bugs or an unstable game, then I just won't bother creating a Mod. Working out of the Editor is fun, working with script files feels like work.

Besides, the Save State property was not the source of all the problems I encountered during a Save/Reload. I found another graphic bug: when I laid a Dungeon Tile asset on top of a Beach Ground map, the game looked fine at first, but then the Dungeon Tile would "bug out" after a Save/Reload. I was able to correct this problem by using the Void floor before placing the Dungeon Tile. Now everything is perfect (so far).

So I solved 2 of my problems using the Editor and not worrying about object code. My Mod is 80% complete and now it seems virtually bug-free after a complete play-through last night. Hopefully a patch won't break it in any way, we'll just have to wait and see.