Page 16 of 49
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 4:35 am
by SpiderFighter
Komag wrote:no problem, I won't be able to start anything for at least 16 hours anyway
Ok, I should warn everyone the file is now over 50 megs. Please make sure you look through all the assets before you start designing, to be certain what you need isn't alreayd there. I'mn PMing the link to Komag, and I'll update the lsit in the morning...been a long day, and my girlfriend has been sick through most of it, so I haven't been able to take care of things here.
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 4:38 am
by Neikun
Also, be sure to compress your textures.
After I compressed my clean dungeon wallset textures, the filesize was reduced to one fifth of the size!
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 5:08 am
by HaunterV
i got a problem...
my walls have glitches and id say about 25 % are no longer working as intended... they seem to have lost their colission
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 5:52 am
by HaunterV
HaunterV wrote:i got a problem...
my walls have glitches and id say about 25 % are no longer working as intended... they seem to have lost their colission
According to Edsploration if more than one (secret)door shares a space only the 1st one has the collision information implemented.
any way to work around this?
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 12:42 pm
by SpiderFighter
HaunterV wrote:HaunterV wrote:i got a problem...
my walls have glitches and id say about 25 % are no longer working as intended... they seem to have lost their colission
According to Edsploration if more than one (secret)door shares a space only the 1st one has the collision information implemented.
any way to work around this?
Ooh.
I thought on the other thread you fixed this? Is this the "my doors are now illusary walls" probem you were having?
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 1:46 pm
by Grimwold
HaunterV wrote:HaunterV wrote:i got a problem...
my walls have glitches and id say about 25 % are no longer working as intended... they seem to have lost their colission
According to Edsploration if more than one (secret)door shares a space only the 1st one has the collision information implemented.
any way to work around this?
Am I reading this right that you've put more than 1 secret door on the same wall section? Was this to try and have the same doors open in different configurations? If so, you may need a different way to handle the multiple doors.. my script and suggestion to use door names assumed that each possible door would only be opened during 1 configuration.
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 2:00 pm
by Xanathar
I don't know if I have understood the problem properly, so I resume what I understand of it first:
- You want to do a maze-kind-of-thing where you have secret doors all around
- Some kind of activator (plates, levers, etc) do change the secret doors to a number of configurations
If this is the case you probably can do as following.
1) Define a table of tables for configurations:
Code: Select all
DOORSPATTERNS =
{
["config1"] = { "secret_door_1", "secret_door_5", "secret_door_7" },
["config2"] = { "secret_door_11", "secret_door_25", "secret_door_37" },
["config4"] = { "secret_door_2", "secret_door_5", "secret_door_7" },
}
ALLDOORS = { "secret_door_1", "secret_door_5", "secret_door_7", ....... etc etc etc }
2) Have an activate configuration method:
Code: Select all
function activatePattern(patternName)
for _, doorName in ipairs(ALLDOORS) do
local door = findEntity(doorName)
door:close()
end
for _, doorName in ipairs(DOORSPATTERNS[patternName]) do
local door = findEntity(doorName)
door:open()
end
end
3) find some way (whatever you want) to call activatePattern("config1") etc. etc.
Notes:
- There is no need to stay all-lower-case inside a scripting entity. Use whatever makes the code clearer (I usually stay with the convention that read-only values are all-upper-case).
- The code above is NOT TESTED.
- Never put objects inside table, always put the id of the objects - otherwise GrimRock crashes when saving.
- Always test the code in the game at regular intervals in time (say, once a day), including saving and reloading.
--
Edited for various fixes.
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 2:59 pm
by Grimwold
Great suggestions Xanathar.
For the activation I think he was using a timer to change the configs... and I suggested storing the previous config in a variable and using
repeat math.random until to find a different config.
The full discussion is here:
viewtopic.php?f=14&t=3973
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 3:17 pm
by Xanathar
Then, I'm copying the post there, and let's all continue this discussion on that thread.
Thanks!
Re: [CLOSED] Call to modders/mappers: "One Room" round robin
Posted: Mon Nov 05, 2012 5:05 pm
by Komag
This dungeon has problems right now! Uggardian will need to fix before I can work on my room. This seems to have not been tested in-game, something that we all MUST do before passing along.
first of all, the script near the lizard to "wake" him needs a "local" in front of gekko, or else you'll get a CTD every time you try to save the game after waking the lizard with error "cannot serialize table 'gekko' with metatable" due to the fact that gekko = was saved since it was not local.
more importantly, for some reason I can't figure out, the doors already start open when you fall down the pit, and sometimes the lizard even starts awake (in which case when you step on the hidden plate this time, the game will crash with "attempt to index global 'ice_lizard_statue_1' (a nil value)" due to the fact that the lizard is already awake). I don't know what's under the hood of the frost set, maybe that has something do to with it, no idea. Maybe the doors could just use a rename or something, I dunno. But I don't feel like debugging it anymore to fix things. Suggestion, rename EVERYTHING to unique custom names, not script_entity_15, door_12, etc, then fix the connections and try again. It's possible other people's complex scripts could mess with generic named entities