Making traps

[Obsttorte]

Edit: Btw, this is a problem of id's crappy physics engine. It only ever counts "connects" between moveables, but does not apply pressure due to gravity once moveables are at rest. So there is actually not a good way to find out how much force whatever-you-stacked applies to the crate. If this was available, things would be so much easier.

 

this has to do with performance I think

in doom 3 itself the physics never occurred crappy to me, this is something coming from the new gameplay enforced by the mod

[ungoliant]

staying on the easy script level forces the mapper do deal with scripting, what is in my opinion a good thing as it never hurts do learn something new

I'm starting to like you!

[Obsttorte]

 

But that's right

 

mappers also have to learn how darkradiant works, how to create good looking areas out of simple geometric forms and so on

so why not a little bit scripting (and baking pie, man I have to learn this )

[RPGista]

Well, it is a completely different discipline, very very few would go through that kind of trouble, when there is a million aspects of plain mission making to master. I agree that realisticaly, contributions need to be made universal and user friendly, or you might help the odd initiated mapper once or twice, and ignored by all. Mappers NEED prefabs they can just drop there and customise. A trap that takes a coder weeks to sort out and would take a random guy months might be a moment in a 2 hours mission, it is also a matter of cost-benefit... One man teams with several talents (architecture, gameplay, story, scripting) are very hard to come by.

[Obsttorte]

I think we misunderstood each other.

I said "a little bit scripting". I dont say that everybody shall learn everthing in perfect. I'm not a good scripter myself (and a terrible mapper).

 

I also prefer everything packed up and ready to go. But if its not there I dont think other mappers couldnt handle something that another guy just prepaired and is willing to explain, so they had at least only a few things to change to adopt the whole thing to their mission.

[Tels]

I think we misunderstood each other.

I said "a little bit scripting". I dont say that everybody shall learn everthing in perfect. I'm not a good scripter myself (and a terrible mapper).

 

I also prefer everything packed up and ready to go. But if its not there I dont think other mappers couldnt handle something that another guy just prepaired and is willing to explain, so they had at least only a few things to change to adopt the whole thing to their mission.

 

Will I am basially with your idea here (people should learn new things, it isn't hard etc.) you have also to consider that a lot of people are simple not able to do this. They might be a master of archetecture, but couldn't code their way of a paper bag even if their life depends on it.

 

Not only is our documentation quite bad for people who know what they are doing, but it is next to impossible for someone who never programmed in his life. Questions from people (who produce high quality FMs!) I have seen over the years where as follows:

 

* why does main() have the parantheses after it, are they important?

* Why is $Player1->getFoo() not working (it is $player1, with a lower-case P)

* why is player->getFoo() not working (missing $ and 1)

* my X broke (the name got changed, and the script broke)

* what is a subroutine?

 

etc. All the most basic questions. Of course it would be cool if people could learn the basics, but the idea we always try to follow here is that you shouldn't spend 10 h learning something to get a basic trap, lever, or door working.

 

Even prefabs have their disadvantages - it is not really possible to update them later unless you invest a lot of time (which is error prone. Never underestimate how many errors will creep into a map and how much time you will spend correctng them before release, only to find quite a lot of bugs slipped through).

 

Right now mapping needs to get easier, not more complicated.

[Obsttorte]

* why does main() have the parantheses after it, are they important?

* Why is $Player1->getFoo() not working (it is $player1, with a lower-case P)

* why is player->getFoo() not working (missing $ and 1)

* my X broke (the name got changed, and the script broke)

* what is a subroutine?

reminds me of my work as a math tutor

 

of course you are right, no necasserity to make things more complicated as they are

 

but at least some people will be able to arrange with it, I think

and maybe its better to just let them try it out instead of scaring them off by telling them it is all to complicated

(or maybe not, I don't know)

Edited September 12, 2012 by Obsttorte

[RPGista]

What you guys are coming up with and brainstorming is very much appreciated. Just stressing the point that in a complex mapping system like doom3/TDM, every step by step or ready made feature would be the ideal.

 

I dont remember many physical puzzles (another way to use your trap weight system), so I would be interested in that. In glenham tower, loose things wont hold your weight will and fall or break under you. The proccess of making mass count to achieve a certain state semms quite useful.

 

On a parallel note, I wonder if it is already possible to apply force to AI reliably - if you swing a log tied to a rope, will it knock the guard down and kill him; if a wall from a derelict building crumbles, will the it crush AI under it? What about the famous indiana jones giant ball?

[Obsttorte]

On a parallel note, I wonder if it is already possible to apply force to AI reliably - if you swing a log tied to a rope, will it knock the guard down and kill him; if a wall from a derelict building crumbles, will the it crush AI under it? What about the famous indiana jones giant ball?

 

found this http://wiki.thedarkm...s_Damage_Things, tried it out but it doesn't seem to work , donno

Edited September 12, 2012 by Obsttorte