[SUGGESTION] [EDITOR] Remove Oddtabling option

[Nepster]

Status: The oddtable option has not been removed for now; but I discourage further use of it. Instead, use the new "Import Layout" option which imports another level's layout into the current level, without affecting the stats or skillset. Oddtabling probably will be removed at a later point in time.



Apart from being buggy, the oddtabling option doesn't fit within the scope of the editor: The Editor is about creating single levels, while oddtabling is a method to reference other levels via their position in a level pack. Actually I have yet to find a way to playtest oddtabled levels without creating level packs first. So having an oddtabling option in the Editor doesn't make any sense.

If anywhere, such oddtabling should be done in the Toolkit when creating the level pack as a whole. However I would even go so far as to remove the oddtabling option completely: It has only very limited applications, because one already has to know during the level creation phase where to put the levels, which is something that should be determined only after having all levels finished. Moreover it can easily break if the original level is moved around within the level pack, while just copying the terrain layout is almost as easy and much more stable.

[namida]

I don't think removing it altogether is justified. Perhaps improving how it works (eg. tracking by level ID, not by position), and indeed moving the option to the toolkit, is justified though.

[Simon]

Does the L1 NL pack depend on the oddtable still? Does it see any use in other packs?

-- Simon

[Nepster]

...eg. tracking by level ID, not by position...

Rank/Level number can easily be determined by the level designer. The level ID not. If you hadn't mentioned it several times, I would have no idea that such a thing even exists, and it still remains mysterious to me for what purposes the level ID is used? A much better way would be to use the file name of the level.

Nevertheless I am still not convinced, that keeping oddtabling is justified.

[namida]

Does the L1 NL pack depend on the oddtable still? Does it see any use in other packs?

-- Simon

Yes, NeoLemmix version of L1 uses it; so do (at least) the Extra Levels NXP, Lemmings Plus I and Lemmings Plus Omega.

...eg. tracking by level ID, not by position...

Rank/Level number can easily be determined by the level designer. The level ID not. If you hadn't mentioned it several times, I would have no idea that such a thing even exists, and it still remains mysterious to me for what purposes the level ID is used? A much better way would be to use the file name of the level.

Level ID is unique per level though - and if this is handled by the Flexi Toolkit internally, there is no need for the designer to ever see it; but (as long as the target level is not removed from the pack entirely) the target level could be tracked even if moved. To speed things up, this would best be checked at build-time rather than at play-time.

Currently, the only thing level ID is used for is checking whether or not a loaded replay is for the correct level. This check alone determines pass/fail on any replay that contains one; only in the case of older replays (prior to the introduction of level ID) are the game / rank / level numbers used.

Under the current structure, there are VERY obvious reasons why filename is not an option. This could of course change in the future.

[Nepster]

Currently, the only thing level ID is used for is checking whether or not a loaded replay is for the correct level. This check alone determines pass/fail on any replay that contains one; only in the case of older replays (prior to the introduction of level ID) are the game / rank / level numbers used.

Then the level IDs are far less unique than you think: I can load replays for Tomb Raider (Sun 2) when playing Tomb Raider II without getting any warnings (and vice versa).

[namida]

If a level is modified, the Level ID isn't changed (so that the replay will not show up as invalid just because there's a minor change) - this is also why a random ID number, and not, say, a CRC32 or MD5, is used. So - if a level is made using another level as a starting point, they'll share the same ID, unless the creator has used the "Reset Level ID" button.

I'm not sure how to go about changing this without breaking the original intent of keeping it the same between changes, apart from maybe having Flexi Toolkit assign a level a new ID if it detects two with the same one.

Perhaps, one other acceptable workaround might be to add a feature to the editor to load the layout / etc (anything that oddtabling copies) from another level, while leaving the things it doesn't copy unchanged from the current level. While not quite as convenient (once all else is working) as oddtabling, it would still improve the copying of layouts between levels compared to not having any features aimed towards it at all.

[namida]

Have not made any changes in regard to this (except fixing the related crash when oddtabling is self-referencing or circular) for the V1.41n player / V1.08 toolkit update. Still considering the best way to approach this problem; it might be best to leave it until a time when there's a major overhaul of how things work.

[Nepster]

Summary of the rest of this post: Although Simon's cull-o-mania is too much for my taste, I still think that the oddtabling option can be removed completely, because it is barely ever used and its effect can be reproduced by standard editor actions.

...it might be best to leave it until a time when there's a major overhaul of how things work.

Once the level files are stored in a more accessible way, oddtabling becomes superfluous anyway. Then one can just copy the header with all the level stats from one level file into the other. No need for any oddtabling option in the editor any more.

Under the current structure, there are VERY obvious reasons why filename is not an option. This could of course change in the future.

Sorry, but I do not see the "VERY obvious reasons": The toolkit (or rather the system.dat) already has the names of the level files and their location to load them when creating the .nxp. So I see no reason why one cannot use it for oddtabling purposes as well. Of course once creating the .nxp, this info has to be translated e.g. to the current oddtabling references, but there is no need to do this already in an earlier step.

Perhaps, one other acceptable workaround might be to add a feature to the editor to load the layout / etc (anything that oddtabling copies) from another level, while leaving the things it doesn't copy unchanged from the current level. While not quite as convenient (once all else is working) as oddtabling, it would still improve the copying of layouts between levels compared to not having any features aimed towards it at all.

This would be an improvement, because it is much more stable, allows for playtesting levels in the editor and its effect is much more self-evident to new level designers. However you really should think hard about whether this option is needed at all. Although it has some some uses, they still are very limited. So I fear that (similar to oddtabling) this option will hardly ever be used. Does this really outweight the disadvantage of making the editor more complicated?

Looking at my own habits in using software in general, I see the following: Whenever I need to do something new, the first thoughts are always "How can I do this with the options I regularly use and know where to find?" Only when something turns out to be very difficult or outright impossible with them, I look whether there are new options I could use.
Applying this to the NeoLemmix Editor: The standard actions loading and saving levels together with changing level stats does precisely the job that oddtabling/load only terrain does as well. So it is very unlikely that I will ever use this.

This brings me to a last question: Does anyone (DynaLem, GigaLem, ...) currently working on a NeoLemmix level pack plan to use oddtabling or would you use the load only terrain option?

[namida]

Sorry, but I do not see the "VERY obvious reasons": The toolkit (or rather the system.dat) already has the names of the level files and their location to load them when creating the .nxp. So I see no reason why one cannot use it for oddtabling purposes as well. Of course once creating the .nxp, this info has to be translated e.g. to the current oddtabling references, but there is no need to do this already in an earlier step.

No; it does not save the location of the source file. It imports the contents of the level file, and places them in the appropriate place in the right LEVELxxx.DAT file. So - as far as the toolkit is concerned, there is no "Just Dig.lvl" or "Fun01.lvl". There is the first level in "LEVEL000.DAT", and that's all. Thus, under the current setup, the only ways Tricky 15 could refer to it for oddtabling is either "Fun 1 Level 1", or by Just Dig!'s level ID (which I don't know off-hand).

Applying this to the NeoLemmix Editor: The standard actions loading and saving levels together with changing level stats does precisely the job that oddtabling/load only terrain does as well. So it is very unlikely that I will ever use this.

This works very well for creating the initial version. Now suppose a backroute is found in the repeat that requires significant changes to the terrain. Assuming you aren't okay with just leaving some terrain differences between the two versions, you must either make those same changes in the earlier version, or change the stats all over again. Or, you could Ctrl+C the entire level, clear the terrain in the earlier level, then Ctrl+V - although this wouldn't copy, say, a change to the level size, or screen start position. These kind of situations - not just that of making the level in the first place - is why oddtabling was added.

[Nepster]

This works very well for creating the initial version. Now suppose a backroute is found in the repeat that requires significant changes to the terrain. Assuming you aren't okay with just leaving some terrain differences between the two versions, you must either make those same changes in the earlier version, or change the stats all over again. Or, you could Ctrl+C the entire level, clear the terrain in the earlier level, then Ctrl+V - although this wouldn't copy, say, a change to the level size, or screen start position. These kind of situations - not just that of making the level in the first place - is why oddtabling was added.

In theory this sounds very nice, but in reality I found copying level stats by hand the easier way. This is why I asked the question in my previous post, who would use the oddtabling/... feature?

[namida]

If there really isn't that much opposition, I guess I can look at stripping it out editor-side.

If anyone does feel this feature should be kept (or that the alternative, of an "import terrain" feature, is worth having - although this can always be implemented later, it doesn't have to be decided on now), let me know here. Otherwise, I'll strip this out of the editor soon.

Player-side, I would rather wait until it's been gone from the editor for quite a while before doing anything.

[mobius]

I think it's a nice feature but I never bothered to figure out how to use it out of laziness.

Having it as a feature in the levelpack maker makes more sense to me than in the editor.

[Proxima]

This works very well for creating the initial version. Now suppose a backroute is found in the repeat that requires significant changes to the terrain. Assuming you aren't okay with just leaving some terrain differences between the two versions, you must either make those same changes in the earlier version, or change the stats all over again. Or, you could Ctrl+C the entire level, clear the terrain in the earlier level, then Ctrl+V - although this wouldn't copy, say, a change to the level size, or screen start position. These kind of situations - not just that of making the level in the first place - is why oddtabling was added.

I would prefer it to be kept for this reason. It is a convenience when making packs with repeat levels with identical terrain, which I like to do.

[Wafflem]

I'm also not using oddtabling for my upcoming pack. As far as I am on progress, there are no repeat levels in my pack except for one, but the terrain layout of the repeat is slightly changed.

Whether the oddtabling is removed or not won't really affect me.