Ask for help about creating mods and scripts for Grimrock 2 or share your tips, scripts, tools and assets with other modders here. Warning: forum contains spoilers!
Eleven Warrior wrote:Sorry mate I don't understand what you are saying ahy? You should have them already you guys made the game.....
EDIT: I could be wrong here but I think you guys were not prepared for the onslaught of the editor, and as for game testers did you actually use anyone else besides your team?? If not bad move. Most DEVS use outside testers to see if their game works eg: when a player gets a Skype message or presses certain key to check something else thats happening in their world lol. I have seen the bugs and to be honest you really need to get outside game testers before release ahy. Once again as in many games I have played I asked the same questions and got the reply: No we tested in house... They also had the same problems you have had sorry to be a pain but that's how games fall. This I do know. I have been playing games since 1977. Thxs for you time
My point exactly is that while we have the assets here, we can't just package them as-is and send them off. We'll have to do a cleanup pass so that the package contains what it should and that all temporary assets (for prototype purposes or otherwise) are cleaned out and that assets that we don't have the licence to redistribute (mainly assets that we have bought from elsewhere such as SFX but also some models and textures might also be included) are cleaned up. The asset folder contains over 10000 files so take my word for it: there's a lot of work involved with preparing the asset pack.
Yes, we tested the game externally. Around 40 beta test keys were used, in addition to some folks who tested the game on our office or our home computers. During the beta and RC period we fixed around 200 bugs and made 373 other improvements. We intentionally left supporting the editor and modding tools after the launch since we put the main campaign as a priority since that's what people would be playing first. In my point of view the game is technically quite solid and bug free so I have to admit that I don't quite understand your criticism here...
function tprint (tbl, indent)
if not indent then indent = 0
end
for k, v in pairs(tbl) do
formatting = string.rep(" ", indent) .. k .. ": "
if type(v) == "table" then
print(formatting)
tprint(v, indent+1)
else
print(formatting .. v)
end
end
end
If you and a dev can get this working I'll paypal you and buy another LoG2. ~laughs~ No, seriously! var_dump(obj) would be invaluable!
function tprint (tbl, indent)
if not indent then indent = 0
end
for k, v in pairs(tbl) do
formatting = string.rep(" ", indent) .. k .. ": "
if type(v) == "table" then
print(formatting)
tprint(v, indent+1)
else
print(formatting .. v)
end
end
end
If you and a dev can get this working I'll paypal you and buy another LoG2. ~laughs~ No, seriously! var_dump(obj) would be invaluable!
We still didn't get the confirmation that's it's an actual table variable... I mean, my function works well if I use it on newly created array:
antti wrote:Yeah, it's on our TODO-list but it'll take quite a bit of work since there's a lot of content we have to sort through. We just can't take a copy of our asset folders and put it in a zip file
function tprint (tbl, indent)
if not indent then indent = 0
end
for k, v in pairs(tbl) do
formatting = string.rep(" ", indent) .. k .. ": "
if type(v) == "table" then
print(formatting)
tprint(v, indent+1)
else
print(formatting .. v)
end
end
end
If you and a dev can get this working I'll paypal you and buy another LoG2. ~laughs~ No, seriously! var_dump(obj) would be invaluable!
We still didn't get the confirmation that's it's an actual table variable... I mean, my function works well if I use it on newly created array:
Maybe defineObject = {...} is parsed somehow and is stored in game engine in a different way...
I'm pretty sure they are tables, as you can see with print(); but their contents are not exposed to the script interface. And there are very good reasons for not exposing everything to the scripting interface:
- Some functions and variables are dangerous to expose. You don't want modders to be able to change the player's settings or read and write arbitrary files.
- Everything you allow the scripting API to do is another thing you have to document and stress test. The documentation and testing workload would be huge.
- This one is probably not too important for Grimrock specifically, but you might want to keep parts of the engine hidden to make it harder for someone to steal or reverse engineer them.