Who said great minds don't think alike. I can't help but think you copied mine partially, they coincidentally have the same alias names. :P
mine are mostly derivatives from the showmapshot and genmapitems aliases though :D

genskyitems = [
guitext $arg2
if (= $numargs 2)[
n = (listlen $arg1)
loop i $n [
add-skybox = (at $arg1 $i)
title = $add-skybox
path = $arg2
guistayopen [
guibutton $title (concatword "skybox " (format "%1/%2 " $path $add-skybox)) "skybox"
]
]
] [
echo "Invalid usage. must define string and directory to work in"
echo "eg genskyitems $loopix loopix"
]
]

skyload = [if (strcmp (at $guirolloveraction 0) skybox) [guirolloveraction] [skybox $skybox]]

showskyshot = [
guilist [
guiimage (concatword (format "packages/%1"(at $guirolloveraction 1)) "_ft.jpg") $skyload 4 1 data/sandboxlogo.png
guiimage (concatword (format "packages/%1"(at $guirolloveraction 1)) "_rt.jpg") $skyload 4 1 data/sandboxlogo.png
]
guilist [
guiimage (concatword (format "packages/%1"(at $guirolloveraction 1)) "_lf.jpg") $skyload 4 1 data/sandboxlogo.png
guiimage (concatword (format "packages/%1"(at $guirolloveraction 1)) "_dn.jpg") $skyload 4 1 data/sandboxlogo.png
]
guilist [
guiimage (concatword (format "packages/%1"(at $guirolloveraction 1)) "_bk.jpg") $skyload 4 1 data/sandboxlogo.png
guiimage (concatword (format "packages/%1"(at $guirolloveraction 1)) "_up.jpg") $skyload 4 1 data/sandboxlogo.png
]
]

also mine is for CVS versions only at the moment, due to the use of $skybox :)
This is also another game, due to the backup image if the specified one isn't there

now, regarding elevators, the speed is the fourth variable, tmp3 in the quickedit menu I believe. a "guislider tmp3 0 100 entupdate" should do the trick if you're doing a /newentgui elevator. also keep in mind, the same variables apply for the platforms, direction, model, tag (for /platform) and speed.

~Hirato Kirata

I think I was tempted to post my variant already when I heard you were doing a skybox-menu ... you'll just have to believe me I'd already done mine. But regarding the similarity - I guess it's because we both copied from the same base functions :-P

LOL @ quickedit ... you know I've not actually started using that, although when I first found it I was like "EXACTLY (!) what I always wanted" ... damn force of habit!

did you even look at my fixed script version ?!?!
I fixed your alias-lookup issue in there as well ... it worked for me at least ...

Sorry, I forgot about that. Yes, it works for me. Thanks for your help. Should I use your version as a guide to help me create the speed alias on my version, or just update the node with yours. Also, I had a question about one of the lines of code in the config. What is the "my_elevator_model = 16" mean? I understand most of the other code, I just don't know what that part means. Is it like the default mapmodel or something? Anyway, thanks again for your help.

[ADMIN] : moved reply where it belongs

Well .. I did say it was what I believe it should be done like, so of course I'm of the opinion you should use my version in an update ;-)
I mean ... what would you do differently?
Pack in the whole needless menu stuff again?
Change an alias-name ?!

re: my_elevator_model = 16 ... kind of ... since the user will pass through the menu-step where they set their own value for it the value of 16 is completely useless at that point ... but I put it there to somehow emphasize the creation (and here really used default-value) of the my_elevator_speed-alias

Okay, I will update the node with your version. And thanks for the info. about the my_elevator_model = 16. I also discovered that if you try to add new mapmodels to the menu, it dosen't work, because in the elevators config, there is the mapmodel list, and the game is getting the mapmodels from there.

... that's just why you shouldn't replace vanilla content (like data/menus.cfg) - but rather - always make it additional, so that users have the transparency they need to know what influences what.

Any later assignment to an alias will override the previous one - just the same with menu-definitions and in this case the mapmodellist-alias ... that's Programmer's-101 ...

Well - if a user now installs your modification, they should be aware of this change to the model-list;
so if they either already have some tweakage there ... or later add other modifications that also claim they know better than the vanilla release mapmodel-list ... then they shouldn't really be suprised about inconsitencies.
As long as each modification is stripped to it's bare minimum locating the stuff that's causing the problem shouldn't be too hard - maybe even for non-Scripters ... but at least it shouldn't be too difficult to post a question here and get an answer like : remove the mapmodellist-tweakage from both, combine them manually and then put that in a my_combined_usage_of_the_two_modifications_Name-A_and_Name-B.cfg ... and call that additionally to the (now stripped of mapmodel-list modifications) calls to the two modifications Name-A and Name-B

I hope that wasn't too confusing now ... what I'm on about is:
make your own contributions as transparent and slim-lined as possible,
that way the interaction with other peoples work is less prone to inconsistent behaviour.

You're asking me why it was included?!? Because it was part of what was different in your menus.cfg to the release-version ... I just eliminated all the stuff that was just a copy from the file - added/tweaked your elevator-guis to have a useable guislider and that was it.

Anyway, I'm confused at what you're actually asking about ... of course you can still "add mapmodels" - nothing CubeScript can do can ever stop you from that ... whyever should something like that be possible?!?

It's just the fact that - since you seem to be keen on using GUIs (instead of typing commands manually) - I was assuming you'd like those models (as mentioned they're not part of the release set-of-files) to show up in the editing-place-a-mapmodel-GUI too ... that's why they're inside the mapmodellist alias .. oh, but while I'm typing I realise that you still need to load them .. just being in that list doesn't make them available as models with an index of 100+ - a line "mmodel ..." is required to actually occupy such an index .. which is what you need to know when constructing your elevator (meaning predefined values in your GUI definitions).

...ah...another read of your post - another interpretation:
Are you asking why when you delete the definition from the modification-script you still see a list of them in the editing GUI?
*cough* If so - see my last reply in the thread above re:programmers-101 ... actually there are even two reasosn:

1. data/menus.cfg : still has a definition for it (missing steve_e's models of course ...) [repeat: DO NO OVERWRITE DEFAULT FILES .. repeat ..]
2. config.cfg : will also hold any (in this case the one with steve_e's models) personal aliases/alias-redefinitions of yours

.. nowhere. You've got to learn to live with the fact the community is a bunch of individuals that look at stuff that interests them .. if no one is commenting, I guess no one has anything (more) to say.

Enough said.