1056 réponses à ce sujet

[Tchos]

Thank you both. This module begins with a little "briefing" in the pregame area, to describe some of the features of the module before you head out into it, so I'll include a note about that in the briefing. There are of course also map pins in town, as well as the ability to ask any patrolling watchman where to find things, but now that you mention it, I should add a little note to the watchmen's conversation to tell the player to look for the signposts, too.

I've also been writing a readme that goes into greater detail about my design choices, especially in regard to party management, for anyone unfamiliar with how to build a party comprised of both imported PCs and recruited companions.

Modifié par Tchos, 15 janvier 2013 - 11:37 .

[Arkalezth]

Tchos wrote...
I didn't find anything like this in the available resources.

That's surprising to me, because I remember seeing at least one of those sign posts in a PW I used to play (though only with two arrows), and I could be wrong, but I don't think the builder made a new model for it, so I've always assumed that it was available in the vanilla toolset or through a mod on the Vault.

Or do you mean sign posts with more than two arrows?

[Tchos]

I didn't find any at all, but I wouldn't be surprised to see it in a PW. There are many custom resources that are exclusive to PWs that are not available to single-player builders like me. Or, there might be one that I overlooked, but I did many searches for signs.

[Tchos]

I can't even count or estimate how many hours have been wasted fighting with the walkmeshes in this toolset. Today, it was hours upon hours.

It was another run of work on the docks, fixing some things that became broken in the previous session and adding more signposts, and adding the last of the sign descriptions. I found that I had enough room in the walkable area of town to reduce the grid size by 1 unit on each side, which I hoped would make it easier to open the thing (out of memory errors are one of the errors given when it doesn't just crash without explanation).

This unfortunately required rebaking the walkmesh. One result of this was that the tile around the Merchants' League HQ became completely unwalkable again, which I traced to the fact that I swapped a torch environmental object with a lamp, which I had neglected to make into an environmental object. Too many placeables on the tile was the cause of it, even though there were nearly none at all. Converting to environmental fixed it.

The other result was that the walkable docks regained gaps between them where they should attach. Dealing with these docks has caused many lost hours in the past as well, and I've tried so many variations on the setup, I just can't understand what the problem is.

I've tried it with the docks as placeables using their own walkmeshes, at different elevations or identical ones, touching, overlapping, or barely separated, with walkable land painted underneath or none, and at different distances from the terrain they border.

More time was spent with the docks as environmental objects, with walkmesh helpers taking their places. Again, countless variations, including those above, and with mesh blockers in the form of invisible boxes, or with cutters, or without either. There are 3 dock objects. One is the base, and the other two jut out from that one, perpendicularly. I had managed to get all of these perfectly connected with no gaps in the walkmesh after many attempts, but after many hours of attempts following my edits today, I couldn't recapture that elusive state of affairs.

[Dann-J]

The walkmesh can be a royal pain. That's probably why MotB used one huge placeable for the sunken ruins docks, rather than trying to stitch separate parts together in the toolset. Or perhaps they *did* try the latter first, and resorted to a new model because it was easier in the long run.

Sometimes it's better to create little islands of terrain in between the dock or bridge placeables, rather than trying to butt them right up against each other. It might not look as good, but it's far less frustrating.

[Tchos]

Actually, I think the MotB method, as Dann mentioned, may be the way to go here. I'll see about changing those docks into one large placeable with a single walkmesh and see if that solves this once and for all. I really can't do a raised terrain under these docks, since there's very a sharp incline just beside them, and the terrain doesn't seem to have enough fine control or resolution, unless I can somehow select individual terrain polygons and raise or lower them numerically. Complicating this is that this particular part of the terrain is at a 45° angle from the mesh, which I think is a very bad idea.

[Tchos]

I'm not sure what you mean, about doubling it up and then removing one, but I think what I'll do is leave the environmental docks as they are now, and just make a custom invisible walkmesh object for it.

[kamal_]

Building many otherwise impossible walkmeshes made (relatively) straightforward.
kamalpoe.blogspot.com/2012/08/making-walkmesh-and-ground-be-two.html

Make a second copy of the area, and build up the ground to get the walkmesh you want, swap the ground with the ground from the copy of the area that has the ground level you want.

[Tchos]

If not for the 45° angle I spoke of earlier, which makes raised terrain unsuitable in any case, I would certainly use that method for its better aesthetics. I'll keep it in mind for other less extreme instances.

[kamal_]

With walkmesh cutters, you can cut any shape you wish. Make a big blob of ground and cut your shape out. I've done very complicated shapes cut out of french curves.

[Tchos]

In this particular case, it's not a matter of walk/not walk, but a case of walk/walk, but at sharply different elevations, at a poorly-chosen angle for the resolution of the terrain mesh. There was also a ramp between them at an earlier stage, but I've long since changed that. The way you propose may work despite my misgivings, but I'm trying this other way first, since it would not involve adjusting the terrain.

[Tchos]

Things are worse than I thought. I was in my minimal bootup working on the area some more, and was going to try to bake it again, but was doing some other edits before then, and on one of the saves, I was given a very bad error. Out of memory on a save. So it couldn't save it, despite multiple tries, but of course it overwrote the area files with its failure anyway. I ended up with a 0-byte docks.git file. Just wiped out like that.

Imagine losing this large and very important area entirely! That's the first time something like that has happened to me.

I backed up the area just before I started work on it yesterday, so all I lost was yesterday's work. This is a reminder that we should back up our work often.

[kevL]

Tchos wrote...

I ended up with a 0-byte docks.git file.

i think that was the one I was getting not so long ago. Eventually came to the conclusion it was an out-of-Memory error too .. it seems related to the size of my Override ( haven't checked how .Haks, extra open areas, etc relate to this ). I've tried removing things I thought were big mem-hogs like perhaps models & added blueprints but couldn't nail it .... now i'm constantly renaming (1) a very clean playerfolder & (2) my player playerfolder, back and forth.

Sticking to the clean one with only the necessities has cut down my crashes a lot, T. But I also tend to keep a <module_bak> module folder right beside the working folder and copy the contents over before making a save. A little double-click batch file in the working directory could do that, more conveniently than copy-paste,

[Tchos]

The strange thing is that I thought reducing the size of the area would make it more stable and use less memory, and it only introduced new problems.  The positive side of this reversion to the backup is that the walkmesh is back to the way it was before, meaning walkable docks with no gaps.

At any rate, for the past hour I've been pruning down the number of unnecessary placeables, to see if that helps.

Modifié par Tchos, 17 janvier 2013 - 11:37 .

[kevL]

i'd work under the impression it's not so much your area, as the notion that the toolset itself will grab and hold onto as many resources as it finds ( ergo pushing out RAM for the more important area )

good luck in any case,

[Tchos]

Someone correct me if I'm wrong, but if I changed a walkmesh helper's appearance to a dock, it wouldn't just look like a dock, it would be a dock, and it would be using the walkmesh built into the dock model.  So it would accomplish the same thing to just bake it as a single placeable, and then convert it to environmental after the bake.

However, the dock is no longer an issue, as mentioned in my last post.  The area is also working, so there's no need for a rebuild.  Still, for possible future incidents, all discussion is good.

[Lugaid of the Red Stripes]

Terracoppa is good for rebuilding, too, for future reference.

[Tchos]

I re-fixed all the things in the docks area that were lost in the corruption, and finished adding the signposts. There are still a couple of extra things to fix that I found in my last runthrough, but very minor ones.

One thing I found is that doors have inherent problems. I have a couple of doors that have notes posted on them, and you can read the notes. But I found that even if a door is flagged as static, it interferes with the selection of placeables in front of it. I had thought at first that it was a problem with the placeables, but it was definitely the doors.

Considering that doors marked as static cannot be affected or changed by script, I can't see any reason for this behaviour. They should not react at all.

So, my conclusion is that transition doors (doors that transition the player to a different area, rather than doors that open within a single area) should best not be doors at all, but placeables. Considering that I already use a script to replace the standard door transition system (which I made to eliminate the superfluous animated opening of the door into a black void), a door placeable works just as well.

It works better, in fact, since placeable doors can be marked unusable instead of static, allowing me to "leave the door open" (so to speak) for activating those doors in a later patch, whereas actual doors cannot be marked unusable. I prefer not to leave-an-active but locked door in any spot where the player is not actually meant to go, even if I may add it later, because when I play a game and see a locked door, that says to me that there's something behind it, and I'm missing something if I can't open it. If there's not really anything behind it, then I could be unnecessarily wasting a lot of time looking for a way to open it, and that's something I won't do to my players if I can help it. Therefore, in my work, all active doors, locked or not, must be openable in some way.

The only downside is that placeable doors use the default "use" cursor that looks like an asterisk when you hover over them, instead of the "door" cursor. But with properly named doors like "Entrance to Town Hall", the cursor isn't as necessary to indicate to the player what's going to happen if they click it.

At any rate, my next module will use nothing but placeable doors for doors leading to transitions, and reserve actual doors for those that swing open between rooms in a single area. It allows things like this:

hhttp://www.youtube.com/watch?v=rJ3gp8foY1E

In other news, I've been learning more about good lighting in this engine. In this last runthrough I had point light shadows turned on. I had been playing with them turned off for quite a long time, because I've seen them create some extremely harsh shadows in some places in the OC and in mods I've played.

I noticed they were back on only after seeing that the contrast seemed stronger and the colours richer. I think it actually looked better this way in most cases. I believe those harsh shadows I had encountered before were due to those lights being set to cast shadows of a high intensity (where I think "1" = completely black, and something like 0.2 or 0.3 is more appropriate for a normal room where light bounces off the walls and ceilings). Some prefabs include lights, and those lights no doubt have a range of shadow intensity settings, or in other cases are set not to cast shadows at all. I think it was that, combined with perhaps too many lights in one spot, that created the harsh shadows in the OC that turned me off of point light shadows, which is too bad, because it can really make an area look much better as long as the lights are set carefully. I think on my near-final playthrough, I'll see how all the areas look with point light shadows turned on, and adjust if necessary.

[kamal_]

Tchos wrote...


At any rate, my next module will use nothing but placeable doors for doors leading to transitions, and reserve actual doors for those that swing open between rooms in a single area. It allows things like this:

hhttp://www.youtube.com/watch?v=rJ3gp8foY1E

You can have a regular door do that :-)  The OC does it for buildings at Crossroads Keep when you build upgrades (my generic stronghold does it too, but it uses the scripts from the OC).

Modifié par kamal_, 18 janvier 2013 - 10:43 .

[Tchos]

By "that", I assume you're referring to the multiple destinations. In my case, I'm doing it by using a ga_ script to set a local variable on the door.

However, the enabling and disabling of the ability to highlight it or use the door cannot be done with a normal door as far as I can tell, and normal doors have the additional problem of interfering with the selection of placeables in front of them.