Discussion in 'Mapping Questions & Discussion' started by Thanks4TheDiscordBanIibo, Jun 27, 2016.
I don't think you could change textures with the i/o system. But you could have multiple skybox brushes with different textures, and disable all but the ones used for the holiday.
You can change the skybox as long as you do it before the map initially loads. Not 100% sure, but if you had a point_servercommand do sv_skyname <sky> as the map spawns (so originating from a logic_auto maybe?) you should have a different skybox on holidays.
the catch here is that the server running the map needs to set "sv_allow_point_servercommand always"
You should ask @Crash how he did it on wubwubwub. That map has like 3 skybox brushes or something. Or watch his video on it, he has one breaking down the map logic 'n stuff (sill waiting on how Trainsawlaser does things though )
One thing you could do for Christmas is make snow displacements on roofs, stairs and the ground, export them to VMFs and use Propper to compile them into prop_dynamic.
He has 2 different skyboxes, however one is more of a psuedo-skybox. The initial desert scene has brushes on 5 sides with literall skybox textures of dust bowl or something. When the map launches into space, the fake skybox is removed and the actual skybox becomes visible (space). You'll notice the fake skybox actually rotates when taking off, something impossible to do with normal skyboxes. So sadly he really only uses one true skybox in his map!
I think I brought this up before; it's possible to have a material proxy that changes some properties of the material when an entity sends an input, isn't it? You might want to look into that.
It's possible to switch between two light_environment by naming them. There's some information about it somewhere on the forum. Obviously you'd get two sets of lightmaps so keep an eye on that.
I think Byre does that when the alien ship explodes, actually!
Hell, why do you have each spawnpoint named differently? It's useless waste of entdata.
It would be a good idea to read the thread before you make remarks about something that's already irrelevant to begin with
I'm not sure giving each spawn point a unique name would increase the size of the entity data block any more than giving each spawn point the same name. We're talking about kilobytes here though, which really don't matter.
Entdata here is increased by a lot of outputs.
Almost - it's a point light with a high constant value.
The 'entdata' is increased by io, but there is no limit on entdata (afaik). There is a limit on entities (2048 networked, 2048 non-networked) but I've seen a map work on a full server that had over 700% 'entdata'. And as Wormatty said the increase of naming things is negligible.
@404UserNotFound For the soundscape enable/disable, I don't think you can toggle a soundscape point entity, but you should be able to toggle the soundscape triggers if you use that method of soundscapes.
You can also, if you want, put the outputs into several logic_relay which you can trigger through the IsAprilFools/etc outputs and then have each relay do the rest from the OnTrigger input. This will make it easier to test things out in the meantime because while in-game you can type into console (with sv_cheats 1 on):
and it will trigger that relay for you to test and see what happens. This is also useful for organisation.
That's true. Though I would presume anyone who knew about these things would be using wildcards to address each of the uniquely-named entities with one output. e.g. SpawnPoint_Blue_*
Do you not see the irony in you posting something even more irrlevant over a simple mistake?
I'd love to see more about this, when I looked it up I just found a facepunch thread with a glitchy example made using a modified version of VRAD. So clearly it's possible in the engine, but I don't see how it'd be done.
No, because I didn't post anything irrelevant. I answered his question using a quote from the OP.
The irrelevance of their post's irrelevance is irrelevant.
Separate names with a comma.