http://forum.spore.com/jforum/posts/list/30.page JForum - http://www.jforum.net [/i]


I have been experimenting with awareness and buildings.
I have built simple scenes and placed characters who have been programmed with a a simple advanced AI:
[b]SHOOT PLAYER IF AWARE of PLAYER
IDLE DANCE ALWAYS[/b]
THe NPCs I've place do not have a ranged weapon, so the net effect is that the NPC will turn and face me if he is aware of me, otherwise he dances.

By walking around, I can tell if the NPCs can see me.

[youtube]http://www.youtube.com/watch?v=f4wL2t61-y4[/youtube]
Here is the result of my study:
[IMG]http://i605.photobucket.com/albums/tt140/DavidKris/Awareness01.jpg[/IMG]
Blocks I,II,III are 3 separate buildings. I moved next to each NPC and noted whether each of the NPCs dances or faces the captain.
A can see B
B can see A,C,D,E,F
C can see B,D,E,F
D can see B,C,D,E,F
E can see B,C,D,E,F
F can see B,C,D,E
This is what you expect.

However, if blocks I and II are combined into a single building, here are the results:
A can see B
B can see A,F
C can see nothing
D can see nothing
E can see F
F can see B,E,

The only way I can explain this is that GA computes a bounding box that contains the building and then uses the bounding box to determine awareness.
[IMG]http://i605.photobucket.com/albums/tt140/DavidKris/Awareness02.jpg[/IMG]
C & D can't see anything because they are in the box. They can't see each other either.
B can't see E because the line of sight between the head of B and the head of E passes through the bounding box.

What this suggests is that if you are building interiors, you need to:
1) build the floor and the walls out of separate buildings.
2) if the scene is going to have boxes or a desk, these need to be separate objects. Otherwise their height contributes to the bound box of the floor and it can make it so that NPC cannot see things.

[b][color=red]IMPORTANT UPDATE 7/12[/color][size=18] [/size]
It appears that gates are transparent.[/b][size=24] [/size]
The bounding box of a gate and of disguised gates do NOT block line of sight. This means that by replacing the building with a disguised gate that uses that building, most of the problems will be solved.
1. NPCS can see (awareness tests and commands that depend on awareness work.
2. NPCs can transition onto and off of these disguised gates.
There are some problems if you move a disguised gate to far off the ground. It isn't a visiblity problem, but appears to be pathing issue. My guess is the the AI uses the ground geometry to figure out paths.

[b][color=red]IMPORTANT UPDATE 7/15 [/color][size=18] [/size][/b]
It appears that some of the pathing problems are due to [b]how the building is created in the building editor[/b].

[i]Edited in by SMLightning.[/i]

Tairon96 has found that how the building is edited in the building editor affects how captains walk on it.

Here is his original post:
[quote=Tairon96]Subject changed from:
"Collision detection glitch! Invisible steps??"
to
"Maxis Team read this! Floor bounding boxes faulty! Causer of problems detected! Tip for GA-creators!"

I was edited yesterday a great interior property made by [url=http://www.spore.com/sporepedia#qry=usr-codyr2391|2263554351]codyr2391[/url]. But problem I found was there seems to be an invisible barrier my test captain could only pass in one direction
[youtube]http://www.youtube.com/watch?v=1EWANnLu2jg[/youtube]

In the video you can see, my captain is bounched back as if there is a force field wall (There is none!). So I had to rip codyr2391's bridge apart to use it... Now I just experienced the the problem with an object I was editing today, too!

And I found an explanation for the yesterday's problem. Look here:

[img]http://jan-chr-kruse.gmxhome.de/Spore_2009-07-15_17-04-04.jpg[/img]

My captain (this time my real one) was stumbling between to wall sections. Fortunately he can jump - my test captain can't because I want check if all regions are reachable. So my real captain jumped and after several tries he managed to jump over the invisible obstacle. It looks like there is the complete section higher than you can see - my captain walks in midair!

Before I started today editing this wall section there were now such problems. I used a lot of <shift> and <ctrl> movements for editing. Is this causing these problems???

Is there any one out there who has experinced this problem, too?
[/quote]

And the result of his investigations:




[quote=Tairon96]Here are the videos:

(They are my first commented videos on YouTube It was not so easy

[size=16][b]First video: How to not edit your floor object![/b][/size]

[youtube]http://www.youtube.com/watch?v=BxutVPAiKRY[/youtube]

[size=16][b]And the second video: How to avoid this bug![/b][/size]

[youtube]http://www.youtube.com/watch?v=lrrn87KQsXE[/youtube]

[size=16][b]And the third video shows Iraultza87's perimeter wall I have edited for my adventure. Now there are no invisible steps between the wall sections. Do you want to join for a walk?[/b][/size]

[youtube]http://www.youtube.com/watch?v=ZNKcEhOMuEU[/youtube][/quote]
[size=18][color=red][b]
UPDATE 8/2[/b][/color][/size]

Just because you have fixed the visibility problem, you can still have problems with NPC walking on buildings.

It is my experience that any NPC activity on buildings as floors is buggy. Here is a very simple example:
NPC using basic AI, "mindless", patrol with way points.
[youtube]http://www.youtube.com/watch?v=V7gZmFhjKvU[/youtube]

If you change the building to a disguised gate (using the same building piece), you get better results:
[youtube]http://www.youtube.com/watch?v=4xA9GH7iaKY[/youtube]

However, you still have problems using a disguised gate as a bridge.
[youtube]http://www.youtube.com/watch?v=YSA6vaUd-mc[/youtube]

It appears that it uses the ground under the bridge for path calculations.



]]> http://forum.spore.com/jforum/posts/preList/35255/1069941.page http://forum.spore.com/jforum/posts/preList/35255/1069941.page GMT ]]> http://forum.spore.com/jforum/posts/preList/35255/1069954.page http://forum.spore.com/jforum/posts/preList/35255/1069954.page GMT
Very nice analysis indeed.]]> http://forum.spore.com/jforum/posts/preList/35255/1069962.page http://forum.spore.com/jforum/posts/preList/35255/1069962.page GMT http://forum.spore.com/jforum/posts/preList/35255/1069970.page http://forum.spore.com/jforum/posts/preList/35255/1069970.page GMT I'm working on and adventure and a video demoing this.
]]> http://forum.spore.com/jforum/posts/preList/35255/1070006.page http://forum.spore.com/jforum/posts/preList/35255/1070006.page GMT ]]> http://forum.spore.com/jforum/posts/preList/35255/1070233.page http://forum.spore.com/jforum/posts/preList/35255/1070233.page GMT ]]> http://forum.spore.com/jforum/posts/preList/35255/1070251.page http://forum.spore.com/jforum/posts/preList/35255/1070251.page GMT ]]> http://forum.spore.com/jforum/posts/preList/35255/1070810.page http://forum.spore.com/jforum/posts/preList/35255/1070810.page GMT
But I think this video shows one other problem which is much more relevant and game-damaging, and probably related to the Line of Sight behavior you've catalogued.

At the end, when you Jet Pack up to the top of the Yellow block. Your avatar lands on the edge of it.

Your left foot is angled and flush with the slope of the building, and looks as you'd expect.

However... your [b]right[/b] foot is sunken into the top of the building. It SHOULD be flush with it.

This demonstrates poor collision detection and/or clipping plane computation. This is a big issue for this game right now, and we've gotten zero response from Maxis on it so far.]]> http://forum.spore.com/jforum/posts/preList/35255/1070848.page http://forum.spore.com/jforum/posts/preList/35255/1070848.page GMT http://forum.spore.com/jforum/posts/preList/35255/1070861.page http://forum.spore.com/jforum/posts/preList/35255/1070861.page GMT this needs to be stickied or added into a tutorial somewhere!]]> http://forum.spore.com/jforum/posts/preList/35255/1070937.page http://forum.spore.com/jforum/posts/preList/35255/1070937.page GMT

At the moment, I would advise everyone to place 'responsive' NPCs in open areas and not too close to buildings and if you need an interior setting, use it for walk-through or decorative purposes only, unless you manage to work a way around - given the patience, of course.

I'm looking forward to the Dev's response and hope a solution is on the way soon. ]]> http://forum.spore.com/jforum/posts/preList/35255/1070940.page http://forum.spore.com/jforum/posts/preList/35255/1070940.page GMT
The bounding box creation also influences paths. By keeping the walls, floor, and roof separate you can reduce issues with paths you layout with your ai. Also be sure to place enough path points so that curvature doesn't mess up the pathing either. Paths on buildings works, but its finicky. You will have to test a lot.

Collision boxing is also a bit odd. It's not the same for everyone so it has something to do with the relationship of creature parts and particular shapes. It can also be influenced by processor performance. Slower or busier processors will cause more clipping issues. I figure this due to the fact that some people have a ton of clipping issues where others do not on the same objects.

Because of the way collision detection and avoidance works, the ai can't transition well or at all onto objects. They either must be on them or off them. The Ai also gets confused (little ? over their head) if the plane they are standing on is too close to the ground plane. There seems to be a minimum distance the surface they stand on needs to be from the ground, in order to avoid problems.

So you can build a mission in a "space ship" or building or what have you but it will take quite a bit of tweaking to get it to work. Large open space works better than narrow corridors and such.

Personally I think its all a little to finicky to rely on solely and this information should just be used to create some accents to your adventures.]]> http://forum.spore.com/jforum/posts/preList/35255/1070974.page http://forum.spore.com/jforum/posts/preList/35255/1070974.page GMT
But I think this video shows one other problem which is much more relevant and game-damaging, and probably related to the Line of Sight behavior you've catalogued.

At the end, when you Jet Pack up to the top of the Yellow block. Your avatar lands on the edge of it.

Your left foot is angled and flush with the slope of the building, and looks as you'd expect.

However... your [b]right[/b] foot is sunken into the top of the building. It SHOULD be flush with it.

This demonstrates poor collision detection and/or clipping plane computation. This is a big issue for this game right now, and we've gotten zero response from Maxis on it so far.[/quote]

I've seen the problem too. It does seem that the coordinates of the skin do not mesh with the coordinates of the blocking volume used for collision detection. In general, it seems that the problem escalates when you scale up the object. I didn't scale up the object in my demo, but buildings are naturally bigger than other props. The places where I have an issue with this is when items are dropped and they sink below the skin to that they are invisible or when NPCs walk entirely into walls. As for feet sinking into the floor, it is more a visual annoyance for me.

I don't mind simple visual bugs. I'm old enough to have played some really crude graphic games (I'm 41 years old).

It is a tough design decision. Which is worse, having characters sink into the object or have them float above? From an aesthetics point of view, sinking in is better?

My bigger issue with collision detection is that fast moving objects (like my captain with speed 5, jump 4, glide 4) can move so fast that the collision against the blocking volume on the surface nearest the captain is missed and you collide with the blocking volume on the far side of the object. The net result is that you are now trapped INSIDE the object.

]]> http://forum.spore.com/jforum/posts/preList/35255/1070990.page http://forum.spore.com/jforum/posts/preList/35255/1070990.page GMT http://forum.spore.com/jforum/posts/preList/35255/1070998.page http://forum.spore.com/jforum/posts/preList/35255/1070998.page GMT
The bounding box creation also influences paths. By keeping the walls, floor, and roof separate you can reduce issues with paths you layout with your ai. Also be sure to place enough path points so that curvature doesn't mess up the pathing either. Paths on buildings works, but its finicky. You will have to test a lot.

Collision boxing is also a bit odd. It's not the same for everyone so it has something to do with the relationship of creature parts and particular shapes. It can also be influenced by processor performance. Slower or busier processors will cause more clipping issues. I figure this due to the fact that some people have a ton of clipping issues where others do not on the same objects.

Because of the way collision detection and avoidance works, the ai can't transition well or at all onto objects. They either must be on them or off them. The Ai also gets confused (little ? over their head) if the plane they are standing on is too close to the ground plane. There seems to be a minimum distance the surface they stand on needs to be from the ground, in order to avoid problems.

So you can build a mission in a "space ship" or building or what have you but it will take quite a bit of tweaking to get it to work. Large open space works better than narrow corridors and such.

Personally I think its all a little to finicky to rely on solely and this information should just be used to create some accents to your adventures.[/quote]

I've suspected that much. Thanks for the details.

I thought I'd start with the awareness issue before checking pathing issues. I hope some of the pathing issues will be solved by fixing the awarness problem. I don't think the AI would be able to find a path when it can't see the destination or opponent in combat.



]]> http://forum.spore.com/jforum/posts/preList/35255/1071014.page http://forum.spore.com/jforum/posts/preList/35255/1071014.page GMT very interesting, and kind of explains some of the problems I've be having making my adventure.

It also make me wonder how much is effected just
by the placement of objects, trees, crates and such
around a building or by themselves, this may be why some of my scripts are inconstant?
or suddenly just stop working.
I'll have to toy with this and see what i find.

thank you
]]> http://forum.spore.com/jforum/posts/preList/35255/1071024.page http://forum.spore.com/jforum/posts/preList/35255/1071024.page GMT Pathing doesn't seem affected inside buildings - unless combined with awareness.

I successfully had NPCs walk along a path in a hallway made of modular pieces containing of the walls and the roof and the same in a room made as one building. I had to remove the floor in both to get them to move from the spot as they easily got stuck, and there sometimes is some hesitation, especially when an object is placed nearby or when another NPC is crossing their path.

I have also tested the 'move to' action, which gets them stuck in a wall sometimes due to the floor plan, but they will eventually find their way as well as when they are set to always 'follow' the player or another NPC.]]> http://forum.spore.com/jforum/posts/preList/35255/1071038.page http://forum.spore.com/jforum/posts/preList/35255/1071038.page GMT
Yep. Exactly.

Between your video, and my experiences, I can only conclude:

1. When Maxis put collision on building parts, they didn't actually place the collision boundry on the texture layers, but just pumped out an automated code to get collision between the vertices. This is the only way the scaling issue could occur.

2. Line of sight was not given true collision detection, but is more 2D in approach. Pathing is probably the same.


[quote]My bigger issue with collision detection is that fast moving objects (like my captain with speed 5, jump 4, glide 4) can move so fast that the collision against the blocking volume on the surface nearest the captain is missed and you collide with the blocking volume on the far side of the object. The net result is that you are now trapped INSIDE the object.[/quote]

I just experienced the EXACT same problem in an adventure I created. Please take a minute to read over this. If you have enough time, play the mission and see an entire concept ruined by this issue.

http://forum.spore.com/jforum/posts/list/35260.page

]]> http://forum.spore.com/jforum/posts/preList/35255/1071048.page http://forum.spore.com/jforum/posts/preList/35255/1071048.page GMT http://forum.spore.com/jforum/posts/preList/35255/1071143.page http://forum.spore.com/jforum/posts/preList/35255/1071143.page GMT Between your video, and my experiences, I can only conclude:

1. When Maxis put collision on building parts, they didn't actually place the collision boundry on the texture layers, but just pumped out an automated code to get collision between the vertices. This is the only way the scaling issue could occur.
[/quote]

I recall reading about the clipping problems with detail parts placed on the mouths of creatures. It turns out that they offload the calculations of the mouth polygon coordinates to the graphic card GPU (they just tell the GPU display this blob with this skin and distortion, and the GPU figures out where the polygons go) and because of this they don't really know the coordinates of the surface on the mouth so they cannot positions the details placed on the mouth correctly. The details are just a fixed offset from the center of the face object. For most mouths the upper jaw is fixed and the lower jaw does the animating. This is why parts attached to lower jaws have such problems.

Maybe the same is happening with buildings. The collision logic is based on the vertices and the GPU is programmed to draw a cylinder with a skin with a certain radius to generate the rounded edge of block (or a plane of a certain thickness).

Has anyone tested to see if the sinking effects are more pronouced with building parts that have rounded corners?
]]> http://forum.spore.com/jforum/posts/preList/35255/1071381.page http://forum.spore.com/jforum/posts/preList/35255/1071381.page GMT
Indirectly I think I have.... the mission I created in my referenced post has large spherical moons. The problem seems to be pronounced enough no one has finished it.]]> http://forum.spore.com/jforum/posts/preList/35255/1071484.page http://forum.spore.com/jforum/posts/preList/35255/1071484.page GMT
Also, the conclusions you made on awareness are not limited to Advanced AI. These hold true for basic and intermediate AI as well.

We've just added some extra notes to the [url=http://forum.spore.com/jforum/posts/list/34155.page]Advanced AI guide[/url] that you might be interested in.

[quote=MaxisCactus]
[b]Awareness[/b]
It is not necessary to use the “aware of” condition unless it is different from the target of the action. For example, “pick up stick if aware of stick” is the same as “pick up stick”. Awareness is built into attack, give and pick up. Follow is an exception, it’s more like tracking something.

[b]First Sighting[/b]
First sighting means the first time a creature sees something. The most obvious use is “emote greet when first sighting player”. This will cause the creature to wave once the first time it sees the player, but not upon subsequent sightings of the player. [/quote]]]> http://forum.spore.com/jforum/posts/preList/35255/1071975.page http://forum.spore.com/jforum/posts/preList/35255/1071975.page GMT
So it would seem that single building interiors (floor + walls in a single building) and most floors with built up regions (floor + steps or floor + furniture) will have problems if the interior requires any awareness based AI (basic or advanced AI): attack, pickup, give, and any conditional based. It doesn't appear to prevent the captain from doing this actions, only the NPC's ability to do these things. (the captain can give to the NPC, but the NPC won't give to the captain).

The work around appears to be to for the floor, walls, roof and furnitureto all be separate buildings.

I would think that the bounding box optimization would also apply to path finding -- the path finding algorithms do not see doorways or other opening within buildings, but only navigate arround buildings. Is this the case?

If so, what does that mean for using disguised buildings as gates?
Or, in getting NPC to walk over buildings as bridges?

Are there any exception when NPCs are tasked with following the captain? Or will the captain's follower get stuck too?

I have noticed problems with suing disguised building as gates -- the open state does not remember the orientation or the closed state (here is an adventure that demonstrates the problem: [url]http://www.spore.com/sporepedia#qry=sast-500387856989 [/url]).

]]> http://forum.spore.com/jforum/posts/preList/35255/1072915.page http://forum.spore.com/jforum/posts/preList/35255/1072915.page GMT I never would of had the patience to do all of that xD. and this will help make all of the future Adventures a little better a step at a time ]]> http://forum.spore.com/jforum/posts/preList/35255/1072948.page http://forum.spore.com/jforum/posts/preList/35255/1072948.page GMT
If so, what does that mean for using disguised buildings as gates?
Or, in getting NPC to walk over buildings as bridges?[/quote]
Bridges obviously don't work. There's a little side-quest in the very first Adventure Town adventure about leading lost spoffits to the girl who herds them, and you can't possibly do it because she's surrounded by bridges which the spoffits refuse to set foot on. I was astounded to find that the mission designed to show off GA had such a glaring bug, and nobody had caught it during testing.

As for gates, the adventure I'm working on at the moment has a point at which an AI creature must exit a city gate, which I had built as one big building. Having tried many things, I've found the AI will follow the player through the gate, but "move to" and "patrol" commands will make the AI stop at the opening, and go no further.

I found that if I raised the whole gate off the ground far enough for the creature to go under it, it suddenly worked. Although that, of course, couldn't be a solution since the city walls were now floating. Still, it was a useful test.

The final solution was simply to rebuild the gate as two separate side wall pieces and a floating top piece. THREE separate buildings. The gate looks exactly the same, and the AI can suddenly navigate through it with ease.

I think that illustrates the answer to your question.]]> http://forum.spore.com/jforum/posts/preList/35255/1073232.page http://forum.spore.com/jforum/posts/preList/35255/1073232.page GMT
1)You have answered a question for many players.

2)You did it using a scientific approach.

Not to belittle your incredible discovery(it is incredible), but I'm more ionterested in number 2. Not enough people take the time to think about how to test the problem, hypotheisise, experiment, and anylyze to the degree you did. The majority of people I speak to only go as deep as puddles. This is something I would like to see more of.

Once again, kudos to you.

(Sigh, this means I need to COMPLETELY redesign my space station in order to have a battle there...)




[quote]Bridges obviously don't work.[/quote]

Well... they do and they don't. The problem with the bridges in adventure town is that they have part of them, above the actual surface. If you could make the bridges with sepertate from the things(for lack of a better word) that prevent you from walking off the side, then you could potentially herd the Spoffits. It's all because those things(again) raise the bouding box above the actual bridge, essentially making it as high as those things(need... better... word...) for the Spoffits.

I am equally estounded.]]> http://forum.spore.com/jforum/posts/preList/35255/1073353.page http://forum.spore.com/jforum/posts/preList/35255/1073353.page GMT



[quote]Bridges obviously don't work.[/quote]

Well... they do and they don't. The problem with the bridges in adventure town is that they have part of them, above the actual surface. If you could make the bridges with sepertate from the things(for lack of a better word) that prevent you from walking off the side, then you could potentially herd the Spoffits. It's all because those things(again) raise the bouding box above the actual bridge, essentially making it as high as those things(need... better... word...) for the Spoffits.

I am equally estounded.[/quote]

Npc almost always never cross objects from the ground plane to the object. They can't make the transition. IF your npc are already on an object plane and you want them to cross a bridge, then yes that will work if it's built correctly.]]> http://forum.spore.com/jforum/posts/preList/35255/1073389.page http://forum.spore.com/jforum/posts/preList/35255/1073389.page GMT http://forum.spore.com/jforum/posts/preList/35255/1073396.page http://forum.spore.com/jforum/posts/preList/35255/1073396.page GMT
Back to the drawing board, literally.]]> http://forum.spore.com/jforum/posts/preList/35255/1073413.page http://forum.spore.com/jforum/posts/preList/35255/1073413.page GMT http://forum.spore.com/jforum/posts/preList/35255/1073434.page http://forum.spore.com/jforum/posts/preList/35255/1073434.page GMT http://forum.spore.com/jforum/posts/preList/35255/1073462.page http://forum.spore.com/jforum/posts/preList/35255/1073462.page GMT But it doesn't make sense if there's a big gaping hole within the box.]]> http://forum.spore.com/jforum/posts/preList/35255/1073475.page http://forum.spore.com/jforum/posts/preList/35255/1073475.page GMT But it doesn't make sense if there's a big gaping hole within the box.[/quote]

Andeavor it may seem stupid but the reason they chose to make it a simple bounding box was due to resource expense. Meaning that to make the bounding box conform to the actual geometry of the object would either take up to much cpu, memory, file size, load time and/ or rendering speed (usually this sort of thing cost cpu/gpu). In order for it to work the way we would like would mean increasing one or more of the listed items. Hopefully they can come up with a solution that can fit with in their performance parameters for the game but, I wouldn't hold your breath. ]]> http://forum.spore.com/jforum/posts/preList/35255/1073504.page http://forum.spore.com/jforum/posts/preList/35255/1073504.page GMT Would it take so much more of a difference to reduce the bounding box to the actual geometry? I mean it (somehow) works for the clipping, where a cast member can actually walk through a room made out of one building. Keep the awareness 'globe' present at all times and have it be interrupted only when something gets in the way, just the same when they bump into it "physically".]]> http://forum.spore.com/jforum/posts/preList/35255/1073532.page http://forum.spore.com/jforum/posts/preList/35255/1073532.page GMT
Indeed, it would definitely streamline building levels if the bounding boxes were based on the same geometry that the clipping was based. Or at least if they made a new feature where building parts snapped to each other like they do in Building Editor... that would solve two problems at once: a.) frustration at having to make incredibly fine adjustments to xyz rotation of all building pieces, and b.) still allow awareness to work properly.

EDIT... I think the best way around this at the moment is to plan out each separate room on my starship in detail, determining wall height, position, etc. Then, building the whole object in building editor, then, slowly deleting pieces and saving each modular part as separate pieces, then undoing, deleting different pieces and saving as new, etc.

For example, the side walls of my bridge consist of two slim, wall blocks of different heights. Since they're symmetrical on each side, all I have to do is save on type of object which includes a tall and short block together. That way, it saves on individual building slots in GA, and also makes it a bit less painless to rotate them into the right position.]]> http://forum.spore.com/jforum/posts/preList/35255/1073629.page http://forum.spore.com/jforum/posts/preList/35255/1073629.page GMT
Did you test building's 'body' blocks vs. 'decorative' blocks (far right tab in editor)?

Spore On ]]> http://forum.spore.com/jforum/posts/preList/35255/1073665.page http://forum.spore.com/jforum/posts/preList/35255/1073665.page GMT The snap-on would only really work if yup placeed a building on top of another as they use the same center point. When you place two buildings next to each other, you will notice that thy are on an angle according to the planet surface's curvature.

I find the building adjustment is easier if you use a pattern on top of the building elements that allows for proper lineup, such as the checkered one or the ones with horizontal/vertical lines.

[quote=Prometheus09]EDIT... I think the best way around this at the moment is to plan out each separate room on my starship in detail, determining wall height, position, etc. Then, building the whole object in building editor, then, slowly deleting pieces and saving each modular part as separate pieces, then undoing, deleting different pieces and saving as new, etc.[/quote]
Welcome to my world. I can't tell you how many times I edited the building elements to extract walls, pillars, roofs, etc. to make it work while staying within the lowest complexity possible.

[quote=Prometheus09]For example, the side walls of my bridge consist of two slim, wall blocks of different heights. Since they're symmetrical on each side, all I have to do is save on type of object which includes a tall and short block together. That way, it saves on individual building slots in GA, and also makes it a bit less painless to rotate them into the right position.[/quote]
If you have opposite walls, but want them to look slightly different, make the details on both sides of the wall so you save one building slot and only have to trun them appropriately when placing on the planet.]]> http://forum.spore.com/jforum/posts/preList/35255/1073684.page http://forum.spore.com/jforum/posts/preList/35255/1073684.page GMT ...

I find the building adjustment is easier if you use a pattern on top of the building elements that allows for proper lineup, such as the checkered one or the ones with horizontal/vertical lines.

...
[/quote]

This makes it very easy to place aligned elements.
Then before publishing, edit the buildings and repaint to the pattern/texture you desire.

Spore On ]]> http://forum.spore.com/jforum/posts/preList/35255/1073690.page http://forum.spore.com/jforum/posts/preList/35255/1073690.page GMT Then before publishing, edit the buildings and repaint to the pattern/texture you desire.

Spore On [/quote]
Ha! I didn't even think of [i]that[/i].

Thanks! ]]> http://forum.spore.com/jforum/posts/preList/35255/1073697.page http://forum.spore.com/jforum/posts/preList/35255/1073697.page GMT
Your idea for a checkered pattern is good. I tend to use linear textures anyways, so that's sort of how I lined up the pieces in my first adventure (which actually aren't lined up perfectly at all). Still, it is majorly time consuming. So, my two tactics for building a sprawling space station are these:

[b]1.) [/b]To achieve a perfectly flat floors between multiple flat building pieces:

Create the largest flat piece I can in editor, then load it into GA and scale it up to the largest possible size. Then, I will load in all my floor sections, and rotate them so they are as flush as possible with the larger flat piece. After achieving flat floors throughout the various rooms, I can simply delete the larger piece, then proceed to add walls, etc, adjusting them based on the angles of the floors.

[b]2.)[/b] To minimize complexity:

First, I am building the pieces of the rooms in as large of "blocks" as possible, while taking into consideration the bounding boxes' effects on awareness. Second, for all symmetrical parts, like you said, I am making just one version that can be rotated at will. Third, since this mission takes place entirely in a starship, I have used turned all the planet textures to pure black, and set up the walls in such a way that it would take an extreme angle to ruin the illusion of being in space, but you can still look outside and see the stars through viewports. I have also added stationary spaceship vehicles in the near distance, to give the illusion of being on a starship that's part of a larger fleet.

I've got a feeling this one is still going to take awhile, but I doubt it will be as arduous as my first mission, since I have a better idea of how to do things, and because of this thread, and because I'm planning ahead.

Whew! Sorry for another long post lol]]> http://forum.spore.com/jforum/posts/preList/35255/1073746.page http://forum.spore.com/jforum/posts/preList/35255/1073746.page GMT http://forum.spore.com/jforum/posts/preList/35255/1073940.page http://forum.spore.com/jforum/posts/preList/35255/1073940.page GMT Would it take so much more of a difference to reduce the bounding box to the actual geometry? I mean it (somehow) works for the clipping, where a cast member can actually walk through a room made out of one building. Keep the awareness 'globe' present at all times and have it be interrupted only when something gets in the way, just the same when they bump into it "physically".[/quote]

Yes it would. Right now there is 1 bounding box per building. Your suggestion is to change that to 1 bounding box per building part. Assuming the average building has 10 parts, you have increased the number of bounding boxes by a factor of 10. So a worst case estimate would be that things take 10 times as long.

Right now, the do the advanced clipping with just the captain. Your suggestion would do this for all the NPCs.

You could speed this estimate up by:
- Only checking the parts within a building if the line of sight passes though the bounding box of the building.
- Only checking the bounging boxes of parts from certain tabs of the building editor (i.e, ignore details). This might create problems with certain creations. It could then be possible to build walls out of detail parts that would allow NPCs to see the player, but block the player from seeing the NPC.
- Only checking the bounding boxes of parts that exceed a certain size.

It may be possible to examine the building and come up with a small set of bounding boxes. However, this would be a very difficult task for player generated content.
]]> http://forum.spore.com/jforum/posts/preList/35255/1074102.page http://forum.spore.com/jforum/posts/preList/35255/1074102.page GMT
The NPC in the building without a floor was capable of both leaving and re-entering the enclosed building area, but if he was inside the building he could not shoot me. As soon as he left, he started shooting. The NPC in the building with a floor was able to leave the building, but could not re-enter it, he just shortened his patrol to just outside the building. Again, he could shoot me once he left the building, but not before. In both cases, if I was inside the building neither could shoot me, no matter where they were.

Just my results, your mileage may vary.]]> http://forum.spore.com/jforum/posts/preList/35255/1075708.page http://forum.spore.com/jforum/posts/preList/35255/1075708.page GMT
Thanks for your report. Your results seem consistent with my tests: the bounding box blocks all vision. It is as if the box formed by the walls is filled with a think fog and the NPCs cannot see.

I've not done any real move to/patrol tests. But it does seem that NPC can follow paths through spaces they cannot see through if you give them markers. Would those NPCs wander of the building if you didn't tell them to patrol and just wander?

It also seems that awareness rules might be different once combat has started. It does seem that I can shoot NPCs who can't see me and once I do they are able to fight back. Sometimes they are able to shoot through walls and hillsides <grin>.
]]> http://forum.spore.com/jforum/posts/preList/35255/1075796.page http://forum.spore.com/jforum/posts/preList/35255/1075796.page GMT
Hey Grimbot, I have you buddied and seen the props you have been working on. I figured you would run into a problem sadly. Looking forward to your dungeon planet.

Your low hanging stalactites are the issue. You have to think of every object being contained in a box that can contain the objects entire volume.

When setting up rooms, you have to think in terms of those bounding boxes. Floor, walls, ceiling, and other details need to be separate. Care needs to be taken into account for bounding boxes that might cut off awareness.

So if you have a ceiling with two stalactites on it then the bounding box is going to be as wide as that entire object and as high and deep. If the stalactites are separate, then the box will contain just the stalactite "cone" in it. If its low enough it will mess with the line of sight of an npc and essentially act like a wall.

Also ai will not transition surfaces. They need to either stay on the ground surface or stay on the floor surface you created. They can navigate the floors though if no bounding boxes block them.

You can still create your mission, but its just going to be a bit more tedious to do so. Get ready to LOTS of testing.

It's best to create a test mission file that you don't publish, to test out your concepts roughly first. Then go and make all your awesome little details after you know things work. A lot of people are getting frustrated because they didn't test and just expected things to work after they spent 20 hrs building stuff. That's backwards. Make stuff after proof of concept. Saves you time.]]> http://forum.spore.com/jforum/posts/preList/35255/1075827.page http://forum.spore.com/jforum/posts/preList/35255/1075827.page GMT
I have a creature that is in a tower, and there is a roof over its head and everything, and the AI doesn't, seem to mess up with it. (the building is one single unit) however, in the same adventure, there is another building with a creature on it, and its AI gets severely messed up. doesn't make sense.]]> http://forum.spore.com/jforum/posts/preList/35255/1075830.page http://forum.spore.com/jforum/posts/preList/35255/1075830.page GMT I mentioned before that the patrol path still works despite their visual impairment inside buildings. And if I let them wander, they storm off into any given direction and get stuck near a wall, not quite knowing what is going on. They appear to have a question mark next to their mood smiley.]]> http://forum.spore.com/jforum/posts/preList/35255/1075851.page http://forum.spore.com/jforum/posts/preList/35255/1075851.page GMT I mentioned before that the patrol path still works despite their visual impairment inside buildings. And if I let them wander, they storm off into any given direction and get stuck near a wall, not quite knowing what is going on. They appear to have a question mark next to their mood smiley.[/quote]

that little question mark is there to let you know there is a problem with the ai being able to execute it routine. Problems with pathing, behaviors, accomplishing goals etc... cause it to appear.]]> http://forum.spore.com/jforum/posts/preList/35255/1075886.page http://forum.spore.com/jforum/posts/preList/35255/1075886.page GMT I knew that meant something. ]]> http://forum.spore.com/jforum/posts/preList/35255/1075899.page http://forum.spore.com/jforum/posts/preList/35255/1075899.page GMT
I have a creature that is in a tower, and there is a roof over its head and everything, and the AI doesn't, seem to mess up with it. (the building is one single unit) however, in the same adventure, there is another building with a creature on it, and its AI gets severely messed up. doesn't make sense.[/quote]

It may not be the building that the NPC is standing on but some other building that blocks the view of the NPC.
I really like putting up extra NPC with:
[b]SHOOT XXX
IDLE DANCE ALWAYS[/b]
as the AI. then by viewing the NPC behavior, I can often figure out the awareness issue.

Also remember, it is only a subset of the AI stuff that has problems -- anything depending on awareness. The captain can talk to or give without a problem. Often the NPC can follow and may attack if attacked.

I can take a look, if you want.
1. Add "(do not play)" to the title of your adventure.
2. Lock the captain.
3. Share your creation.
4. Post a link to the adventure here, with a description of the specific problems you are having (what each NPC should be doing)
Steps 1 & 2 are to minimize the chance that others will try to play the adventure.


]]> http://forum.spore.com/jforum/posts/preList/35255/1076063.page http://forum.spore.com/jforum/posts/preList/35255/1076063.page GMT http://forum.spore.com/jforum/posts/preList/35255/1077015.page http://forum.spore.com/jforum/posts/preList/35255/1077015.page GMT You can still create your mission, but its just going to be a bit more tedious to do so. Get ready to LOTS of testing.
[/quote]

Yeah. That's why I've only released one adventure so far.

Most of my ideas, it turns out, were a bit beyond the scope of GA...]]> http://forum.spore.com/jforum/posts/preList/35255/1077671.page http://forum.spore.com/jforum/posts/preList/35255/1077671.page GMT You can still create your mission, but its just going to be a bit more tedious to do so. Get ready to LOTS of testing.
[/quote]

Yeah. That's why I've only released one adventure so far.

Most of my ideas, it turns out, were a bit beyond the scope of GA...[/quote]

I hear you... I was all pumped with drawn out floor plans from multiple angles yesterday evening, and I even started building the bridge to this starship in my level... then I came and read the updated thread about the same time last night, and realized I was in for some major changes. I managed to create working set of pieces for the bridge, with very few bounding box areas. What I've also noticed (but have yet to test again) is that if the bounding box is only at the NPC's waist-level or so, it will still be aware of you. So, in some cases, half walls are okay, unless your captain is incredibly small (as one of my test captains proved).

All it not lost for your dungeon planet though, I think, Grim. It may seem like a major pain in the butt, but you could try what I did when testing awareness and bounding boxes for my starship bridge.

Basically, I loaded the whole bridge building into editor, and then I would, say, delete all pieces except the floor. Save As New as "Bridge Floor" (do not replace original of course!). Then, reload the complete bridge building again, this time, removing all parts except the southern wall. Save As New as "Bridge Southern Wall".... and so on and so on. This way, you won't have to completely rebuild everything, since the smaller, individual objects still exist inside the original "whole" building object.

Furthermore, I lumped together as many parts on the same plane as possible... for example, the east and west walls of the bridge consist of three walls of tall, medium, and low height, overlapping. Instead of saving each one of those individually, I saved one object that contained all three pieces, since they all run along the same plane.

Hopefully that helps, or you've probably already thought of that!]]> http://forum.spore.com/jforum/posts/preList/35255/1077767.page http://forum.spore.com/jforum/posts/preList/35255/1077767.page GMT
For now I'm working on tightening up a final version of "Red Hot Rescue" and I'm almost done with a fun little garbage planet I've been using as a test-bed for stuff. I included some of my "Rebel Scum" pieces and they seem to work pretty flawlessly. The creatures inside seem to be able to see me, though I've noticed that once I kill one the other goes into "panic mode" and starts running around screaming. I wish that was something I could control, but... good enough!

I've pulled apart some larger stuff in the editors and it does help quite a bit!

I'm learning more and more every day! The hard way, I guess, but it's learnin'!]]> http://forum.spore.com/jforum/posts/preList/35255/1077813.page http://forum.spore.com/jforum/posts/preList/35255/1077813.page GMT http://forum.spore.com/jforum/posts/preList/35255/1077859.page http://forum.spore.com/jforum/posts/preList/35255/1077859.page GMT I hear you... I was all pumped with drawn out floor plans from multiple angles yesterday evening, and I even started building the bridge to this starship in my level... then I came and read the updated thread about the same time last night, and realized I was in for some major changes. I managed to create working set of pieces for the bridge, with very few bounding box areas. What I've also noticed (but have yet to test again) is that if the bounding box is only at the NPC's waist-level or so, it will still be aware of you. So, in some cases, half walls are okay, unless your captain is incredibly small (as one of my test captains proved).
[/quote]

From what I can tell the visibility test goes from the head (eyes?) of the captain to center of mass(?) of the NPC. So things waist high should be ok.

]]> http://forum.spore.com/jforum/posts/preList/35255/1077926.page http://forum.spore.com/jforum/posts/preList/35255/1077926.page GMT http://forum.spore.com/jforum/posts/preList/35255/1077962.page http://forum.spore.com/jforum/posts/preList/35255/1077962.page GMT
So I have played extensively with bounding boxes, etc... everything I've made seems alright, as long as it doesn't stretch too far across any one important plane xyz).

Howver, I finally finished the floor and walls of my bridge, and so I decided to start capping it off with a ceiling (towards the back), with attached "window frame" pieces. Mind you, this all exists along the x and y axes, not the z (up/down) axis. Also, it is placed at least two levels above the ground floor of the bridge.

So my awareness test character was on the bridge ground level, and I added the ceiling/roof object. This overhangs part of the bridge floor where the test NPC is standing, BUT, the bounding box should not extend that far downward, since it is incredibly thin along the z axis, and is two levels above the ground level.

Yet, the NPC will not see me when the ceiling is placed on the bridge... like, WHAT? I understand this bounding box concept very well now, but I can't see why a flat object, two floors above, would affect the awareness of a creature on the ground level?

I wish I could explain better, but sheesh... at least the FRONT part of the bridge is still out of this weird and unexpected bounding box limit.]]> http://forum.spore.com/jforum/posts/preList/35255/1078589.page http://forum.spore.com/jforum/posts/preList/35255/1078589.page GMT So my awareness test character was on the bridge ground level, and I added the ceiling/roof object. This overhangs part of the bridge floor where the test NPC is standing, BUT, the bounding box should not extend that far downward, since it is incredibly thin along the z axis, and is two levels above the ground level.

Yet, the NPC will not see me when the ceiling is placed on the bridge... like, WHAT? I understand this bounding box concept very well now, but I can't see why a flat object, two floors above, would affect the awareness of a creature on the ground level?

I wish I could explain better, but sheesh... at least the FRONT part of the bridge is still out of this weird and unexpected bounding box limit.[/quote]

Providing a link to the adventure or pictures of the problem might help.

One thing I've not yet done is figure out what happens to the bounding box if your rotate the object. I have no idea what happens if you take a flat piece like a floor and rotate it 90 degrees to it becomes a wall or rotate a wall so it becomes a ceiling. From a computational stand point, it is easiest of the box coordinates are relative to the planet surface, so that the walls of the bounding box are always perpendicular to the ground (assuming a flat ground).

The other thing I want to explore is where the bounding boxes/visibilities rules are different for disguised gates.
]]> http://forum.spore.com/jforum/posts/preList/35255/1079006.page http://forum.spore.com/jforum/posts/preList/35255/1079006.page GMT
Strangely enough, most of the creatures in the casino that I built in the same idiotic way as the hospital (which should just count as one big fat bounding box) function just as I want them to. ]]> http://forum.spore.com/jforum/posts/preList/35255/1079102.page http://forum.spore.com/jforum/posts/preList/35255/1079102.page GMT
A creature in a bounding box is totally blind, even to other creatures in the box.

I'm pretty sure this does happen with pathing too, when other actors who are in your 'crew' or set to follow your captain, being inside the bounding box can cause them to stop following your captain.]]> http://forum.spore.com/jforum/posts/preList/35255/1081591.page http://forum.spore.com/jforum/posts/preList/35255/1081591.page GMT
Luckily I don't have anything planned soon that will use huge interiors or should have any problems with buildings. However when I start my adaption of Shining Soul II.....ugh, it's gonna be hard enough without having to worry about the dungeons.]]> http://forum.spore.com/jforum/posts/preList/35255/1082020.page http://forum.spore.com/jforum/posts/preList/35255/1082020.page GMT It appears that gates are transparent.
The bounding box of a gate and of disguised gates do NOT block line of sight. This means that by replacing the building with a disguised gate that uses that building, most of the problems will be solved.
1. NPCS can see (awareness tests and commands that depend on awareness work.
2. NPCs can transition onto and off of these disguised gates.
There are some problems if you move a disguised gate to far off the ground. It isn't a visiblity problem, but appears to be pathing issue. My guess is the the AI uses the ground geometry to figure out paths.
]]> http://forum.spore.com/jforum/posts/preList/35255/1087358.page http://forum.spore.com/jforum/posts/preList/35255/1087358.page GMT http://forum.spore.com/jforum/posts/preList/35255/1088495.page http://forum.spore.com/jforum/posts/preList/35255/1088495.page GMT It appears that gates are transparent.
The bounding box of a gate and of disguised gates do NOT block line of sight. This means that by replacing the building with a disguised gate that uses that building, most of the problems will be solved.
1. NPCS can see (awareness tests and commands that depend on awareness work.
2. NPCs can transition onto and off of these disguised gates.
There are some problems if you move a disguised gate to far off the ground. It isn't a visiblity problem, but appears to be pathing issue. My guess is the the AI uses the ground geometry to figure out paths.
[/quote]

Nice! Testing this discovery out. ]]> http://forum.spore.com/jforum/posts/preList/35255/1090094.page http://forum.spore.com/jforum/posts/preList/35255/1090094.page GMT
http://www.youtube.com/watch?v=ZgXp8z1OwMs

An awareness test in Spore using two buildings. The first room was made as a single floor/wall unit in the Building Editor. The second room is a gate disguised as the first room. The video demonstrates that creatures in the gate room do in fact recognize--and attack--each other as they should while the ones in the first room are blind to each other's presence. The gate room creatures even manage to go out a door and onto ground! The obvious downsides: The textures for the walls of the disguised gate never "pop", instead looking muddy. Also, the chettesus (cheetah spider) charged through a wall when it REALLY wanted its prey. ]]> http://forum.spore.com/jforum/posts/preList/35255/1090508.page http://forum.spore.com/jforum/posts/preList/35255/1090508.page GMT I was wondering about this after learning that you can interact through a closed invisible gate. Transitioning too eh? cool.

Well This makes things interesting in the level building side of things. Now we will need to use a combination of disguised full buildings with normal parts to help control awareness.

What annoys me is that this had to be tested by the community when maxis could have simply mentioned this in a faq or something. Instead all they do is pop in and say "well sweeetie, aren't you cute and clever here is a pat on the head for getting it right". I guess they assumed that their customers heads would implode if anything technical was mentioned by them about the editor.]]> http://forum.spore.com/jforum/posts/preList/35255/1090852.page http://forum.spore.com/jforum/posts/preList/35255/1090852.page GMT
http://www.youtube.com/watch?v=ZgXp8z1OwMs

An awareness test in Spore using two buildings. The first room was made as a single floor/wall unit in the Building Editor. The second room is a gate disguised as the first room. The video demonstrates that creatures in the gate room do in fact recognize--and attack--each other as they should while the ones in the first room are blind to each other's presence. The gate room creatures even manage to go out a door and onto ground! The obvious downsides: The textures for the walls of the disguised gate never "pop", instead looking muddy. Also, the chettesus (cheetah spider) charged through a wall when it REALLY wanted its prey. [/quote]

Okay folks, I've conducted more tests. I deconstructed the room and reassembled the components separately in the adventure editor. Seven pieces total with walls, floor, door overhang, ceiling, pillar and teleport pad. I sic'd the creatures on each other and it worked . . . sort of. They would go blind whenever one of them got close to a wall or in a corner, so I removed the corner pillars. I also converted the telepad into a disguised gate so the creature wouldn't get tripped up on it. Their performance improved, but they still went blind when they wandered near a wall. I then realized that the walls in question had detailing on them.
Conclusion: use absolutely flat walls with no extraneous details hanging off of them. Having said that, we all know you can't save a building in the Building Editor unless you use at least 3 parts, so you can either duplicate the part twice, shrink the clones and nest them in the original part, or you can try detailing the wall as long as the details are nearly flush with the wall's surface. Big wall details extend the BBB (bounding box blindness) well beyond the wall itself.
So Grimbot, your second idea for the dungeon planet is closest, except your walls can't have built-in pillars. They must be separate units. Also use disguised gates for your stalactites so your creatures can see through them and if need be, charge through them. I would also suggest building rooms you know are going to have a lot of target interactions in a way the confines the action away from the walls or give your creatures a minimum wandering area in the room. In a factory brawl, for instance, you could have the fight area confined by railings so the battle doesn't end with everyone against the walls with question marks over their heads.
I'll create vids of my results.


In summary: seperate walls, floors, ceilings; walls should be modular and as flat as possible, including any details; convert furnishings and details into disguised gates if you don't mind the texture drop.]]> http://forum.spore.com/jforum/posts/preList/35255/1092812.page http://forum.spore.com/jforum/posts/preList/35255/1092812.page GMT Remeber, that the bounding box is the box that encloses all the details of the building. So when you have thin walls with larger diameter pillars, the width of the bounding box expands to include the thinkness of the pillars. (Just like the height grew to enclose objects put on top of flooring.)

The problem is that the collision surfaces are not the same as the awareness bounding box. When you have think pillars and thin walls, a character can enter the bounding box (because he is only stopped by the collsion surface) where he gets stuck in the bounding box's awareness trap.

This suggests several solutions:
- If you use columns as part of the wall, don't have them extend very far from the wall. So square columns that aren't much thinker than the wall would work better than thick round columns.
- Adding a thick footing to the wall, should give a collision surface much closer to the awareness blocking volume so that the NPCs can't get stuck.
- Place invisible gates in front of the walls to keep out NPCs (and the captain). This is really only useful for really detailed walls that you want to keep for decoration.
- Keep this in mind when creating your adventure. If you aren't having groups attack each other, you only have NPCs who attacking the captain, then it one is less likely to have problems. Yes, the captain might try to exploit this -- but if he does, he risks getting stuck [u]in[/u] the wall. (that issue needs to be another thread).

But the best solution might be to:
[u][b]Build the walls and columns as separate pieces[/b][/u]
This is probably easiest to implement and only costs 2 slots on the building pallet.

]]> http://forum.spore.com/jforum/posts/preList/35255/1093024.page http://forum.spore.com/jforum/posts/preList/35255/1093024.page GMT http://forum.spore.com/jforum/posts/preList/35255/1093846.page http://forum.spore.com/jforum/posts/preList/35255/1093846.page GMT http://forum.spore.com/jforum/posts/preList/35255/1095849.page http://forum.spore.com/jforum/posts/preList/35255/1095849.page GMT
Great post, good research!

You're like... the Sporean Newton, with all those theories and drawings with stickman and numbers! lol

JK, great information there

I'll just add a tip: for complexity purposes, if you're going to make a building with NO npcs, or only stopped npcs (like a guard, for example) you can make a full building

But everyone knows that, I guess.
Whatever.
4:31 AM here. I'm sleepy. Bye.]]> http://forum.spore.com/jforum/posts/preList/35255/1095905.page http://forum.spore.com/jforum/posts/preList/35255/1095905.page GMT
http://www.spore.com/sporepedia#qry=usr-Nihthasu7|2263174575%3Asast-500397273613

Also I put our theories into action by releasing a Director's Cut of my last adventure, [i]Optorc[/i]. Now the climax is climactic. Check out both the original and the DC versions to see the difference. And remember to back out of the room during the countdown to really appreciate the change.
I broke down the room into three(!) pieces: wall, door, window. I also took the pylons off of the ceiling, eliminating that blind spot. As for the disguised gate floor in the room, it only actually appears in the adventure during the goal it's needed for. Otherwise more conventional flooring--without that sinking feeling--is featured. Also since the floor doesn't touch the walls--play it to find out why--I didn't have to worry about any BBB nonsense from the built-in wall monitors.]]> http://forum.spore.com/jforum/posts/preList/35255/1095943.page http://forum.spore.com/jforum/posts/preList/35255/1095943.page GMT http://forum.spore.com/jforum/posts/preList/35255/1095956.page http://forum.spore.com/jforum/posts/preList/35255/1095956.page GMT
DGing... unless Maxis makes a patch to fix this, I can see "DGing" becoming a commonly used term around these parts ]]> http://forum.spore.com/jforum/posts/preList/35255/1096035.page http://forum.spore.com/jforum/posts/preList/35255/1096035.page GMT
If you build a building on a large square base, then the extent of the base will determine the size of the bounding box. So putting NPCs on the square base puts them [b]inside [/b]the bounding box. Sinking the buidling into the ground does not solve the problem -- it doesn't change the geometry of the bounding box. Similarly, if the building consists of a cluster of smaller buildings, then the bonding box encloses all the buildings. So putting NPCs between the buildings, puts them [b]inside[/b] the bounding box too.

So this might explain the problems people have with outdoor combats.

Also keep in mind, that the awareness bounding box only affect some actions. It won't affect your ability to talk to the NPCs or give them items.




]]> http://forum.spore.com/jforum/posts/preList/35255/1096625.page http://forum.spore.com/jforum/posts/preList/35255/1096625.page GMT ]]> http://forum.spore.com/jforum/posts/preList/35255/1096807.page http://forum.spore.com/jforum/posts/preList/35255/1096807.page GMT
If you build a building on a large square base, then the extent of the base will determine the size of the bounding box. So putting NPCs on the square base puts them [b]inside [/b]the bounding box. Sinking the buidling into the ground does not solve the problem -- it doesn't change the geometry of the bounding box. Similarly, if the building consists of a cluster of smaller buildings, then the bonding box encloses all the buildings. So putting NPCs between the buildings, puts them [b]inside[/b] the bounding box too.

So this might explain the problems people have with outdoor combats.

Also keep in mind, that the awareness bounding box only affect some actions. It won't affect your ability to talk to the NPCs or give them items.
[/quote]

Yup. If you make a block of buildings to fill out the skyline, you won't be able to effectively fight between the individual buildings on that block. Again it comes down to knowing where your brawls and other targeted interactions are going to take place and creating a modular set for that locale.]]> http://forum.spore.com/jforum/posts/preList/35255/1098075.page http://forum.spore.com/jforum/posts/preList/35255/1098075.page GMT [/quote]

YES please do

You have some great dungeon stuff. Shame if you weren't able to use it.

So flat normal floors will not allow the AI to behave consistently? Even if it is raised off the ground a ways? I did some minor tests with raised flat floors and didn't seem to have a problem... just as long as the ai stayed on the object surface and didn't transition.]]> http://forum.spore.com/jforum/posts/preList/35255/1098170.page http://forum.spore.com/jforum/posts/preList/35255/1098170.page GMT My test adventure shows that a regular floor will work (in a modular walled room), but not as dependably as a DG floor. And in [i]Optorc DC[/i] I have both in one of the rooms. They trade off during the crucial goal.]]> http://forum.spore.com/jforum/posts/preList/35255/1098531.page http://forum.spore.com/jforum/posts/preList/35255/1098531.page GMT http://forum.spore.com/jforum/posts/preList/35255/1102278.page http://forum.spore.com/jforum/posts/preList/35255/1102278.page GMT
Here is his original post:
[quote=Tairon96]Subject changed from:
"Collision detection glitch! Invisible steps??"
to
"Maxis Team read this! Floor bounding boxes faulty! Causer of problems detected! Tip for GA-creators!"

I was edited yesterday a great interior property made by [url=http://www.spore.com/sporepedia#qry=usr-codyr2391|2263554351]codyr2391[/url]. But problem I found was there seems to be an invisible barrier my test captain could only pass in one direction
[youtube]http://www.youtube.com/watch?v=1EWANnLu2jg[/youtube]

In the video you can see, my captain is bounched back as if there is a force field wall (There is none!). So I had to rip codyr2391's bridge apart to use it... Now I just experienced the the problem with an object I was editing today, too!

And I found an explanation for the yesterday's problem. Look here:

[img]http://jan-chr-kruse.gmxhome.de/Spore_2009-07-15_17-04-04.jpg[/img]

My captain (this time my real one) was stumbling between to wall sections. Fortunately he can jump - my test captain can't because I want check if all regions are reachable. So my real captain jumped and after several tries he managed to jump over the invisible obstacle. It looks like there is the complete section higher than you can see - my captain walks in midair!

Before I started today editing this wall section there were now such problems. I used a lot of <shift> and <ctrl> movements for editing. Is this causing these problems???

Is there any one out there who has experinced this problem, too?
[/quote]

And the result of his investigations:




[quote=Tairon96]Here are the videos:

(They are my first commented videos on YouTube It was not so easy

[size=16][b]First video: How to not edit your floor object![/b][/size]

[youtube]http://www.youtube.com/watch?v=BxutVPAiKRY[/youtube]

[size=16][b]And the second video: How to avoid this bug![/b][/size]

[youtube]http://www.youtube.com/watch?v=lrrn87KQsXE[/youtube]

[size=16][b]And the third video shows Iraultza87's perimeter wall I have edited for my adventure. Now there are no invisible steps between the wall sections. Do you want to join for a walk?[/b][/size]

[youtube]http://www.youtube.com/watch?v=ZNKcEhOMuEU[/youtube][/quote]
]]> http://forum.spore.com/jforum/posts/preList/35255/1103351.page http://forum.spore.com/jforum/posts/preList/35255/1103351.page GMT http://forum.spore.com/jforum/posts/preList/35255/1113304.page http://forum.spore.com/jforum/posts/preList/35255/1113304.page GMT Two questions though:
Are this axis aligned bounding boxes or oriented bounding boxes?
Is there a cheat to render the bounding boxes for debugging?]]> http://forum.spore.com/jforum/posts/preList/35255/1114920.page http://forum.spore.com/jforum/posts/preList/35255/1114920.page GMT Two questions though:
Are this axis aligned bounding boxes or oriented bounding boxes?
Is there a cheat to render the bounding boxes for debugging?[/quote]

As far as I can tell, when you rotate the object on the planet, the bounding box rotates. I've not done any testing of rotating the object in the building editor to see what happens to the bounding box.

I can't find any cheat for rendering the bounding box. The "blockmode" cheat only renders blocks for the creatures.
]]> http://forum.spore.com/jforum/posts/preList/35255/1117169.page http://forum.spore.com/jforum/posts/preList/35255/1117169.page GMT
Regards

SMLightning]]> http://forum.spore.com/jforum/posts/preList/35255/1118145.page http://forum.spore.com/jforum/posts/preList/35255/1118145.page GMT
Why do you make adventures
What kind of adventures will you make

personnaly i think those should be removed and this thread and another should be stickied]]> http://forum.spore.com/jforum/posts/preList/35255/1118264.page http://forum.spore.com/jforum/posts/preList/35255/1118264.page GMT
In my latest mission, i built the floor, roof, and each of the walls separately (I used the same part over and over for the walls). I put a guy in there, not 5 feet away from me, and he still wouldn't attack. I could go up to him, push him, and he would still only stand there, growling and threatening me. Only after i started attacking him did he attack me back.

Is this just a problem with my game? Or should all the walls be made together?]]> http://forum.spore.com/jforum/posts/preList/35255/1118354.page http://forum.spore.com/jforum/posts/preList/35255/1118354.page GMT
Doesn't the threaten behavior insinuate that the creature is aware of you?]]> http://forum.spore.com/jforum/posts/preList/35255/1118356.page http://forum.spore.com/jforum/posts/preList/35255/1118356.page GMT
Doesn't the threaten behavior insinuate that the creature is aware of you?[/quote]

He didn't have the threaten behavior, i just set him to aggressive. ]]> http://forum.spore.com/jforum/posts/preList/35255/1118361.page http://forum.spore.com/jforum/posts/preList/35255/1118361.page GMT
In my latest mission, i built the floor, roof, and each of the walls separately (I used the same part over and over for the walls). I put a guy in there, not 5 feet away from me, and he still wouldn't attack. I could go up to him, push him, and he would still only stand there, growling and threatening me. Only after i started attacking him did he attack me back.

Is this just a problem with my game? Or should all the walls be made together?[/quote]

Awareness is just one aspect of combat. The NPC must also find a path to the player. If you read page 6 of this thread, there is an example of how you build the building affects the collision surfaces (I don't fully understand that my self).

After attacking the NPC so he attacks you, if you move away does he follow?

Things I would try:
1. Remove the floor and used road or plaza decorations from the terrain editor.

2. Rebuild the scene testing after each step:
a. Remove the roof, walls, and floor. Test to see if the combat works.
b. Delete the NPC. Add the floor. Add the NPC. Test.
c. Add the walls one at a time. Test after each wall.
d. Add the roof.

3. Change the floor into a disguised gate.

]]> http://forum.spore.com/jforum/posts/preList/35255/1118590.page http://forum.spore.com/jforum/posts/preList/35255/1118590.page GMT
In my latest mission, i built the floor, roof, and each of the walls separately (I used the same part over and over for the walls). I put a guy in there, not 5 feet away from me, and he still wouldn't attack. I could go up to him, push him, and he would still only stand there, growling and threatening me. Only after i started attacking him did he attack me back.

Is this just a problem with my game? Or should all the walls be made together?[/quote]

Make your floors disguised gates.]]> http://forum.spore.com/jforum/posts/preList/35255/1125549.page http://forum.spore.com/jforum/posts/preList/35255/1125549.page GMT
A floor (at least the ones I was testing) don't seem to work well when close to the surface.]]> http://forum.spore.com/jforum/posts/preList/35255/1125605.page http://forum.spore.com/jforum/posts/preList/35255/1125605.page GMT
Supposedly messengers will not trigger with some captains. I assume this is because the messengers for some reason are not detecting the captains bounding blocks in their awareness. Perhaps how the captain was built attributes to this issue? Or there is a bug that causes some captain models to not have proper bounding blocks?

Further investigation is needed. Seems to be a rare issue.]]> http://forum.spore.com/jforum/posts/preList/35255/1125615.page http://forum.spore.com/jforum/posts/preList/35255/1125615.page GMT
Supposedly messengers will not trigger with some captains. I assume this is because the messengers for some reason are not detecting the captains bounding blocks in their awareness. Perhaps how the captain was built attributes to this issue? Or there is a bug that causes some captain models to not have proper bounding blocks?

Further investigation is needed. Seems to be a rare issue.[/quote]

From what I can tell, visibility is line of sight from one creature's head to another creatures head. It could be that with short captains, the line of sight from the messenger to the captain gets blocked by the bounding box of scenery items. Then again, it could just be that the messengers are being triggered by [b]IF AWARE OF[/b], just fine, but because of momentum and pathing imprecisions, the messenger isn't passing exactly through way points and miss teleporters.

Or it could be that the captains are using [b]sneak [/b]and so are effectively [b]invisible [/b]with respect to [b]IF AWARE OF[/b].

I'm wondering if having multiple redundant messengers will fix the problem. I don't think they'd cost must complexity.

]]> http://forum.spore.com/jforum/posts/preList/35255/1125643.page http://forum.spore.com/jforum/posts/preList/35255/1125643.page GMT
For example (sorry for the ASCII art diagram lol)


o = messenger


T = short captain

[] = wall

Imagine this setup:


__o_[]_T__

In that setup, the messenger is so small, it's not aware of the captain, even though the wall should be short enough normally. But, because the messenger is so close to the wall, it doesn't detect the captain at all.

I might test this out in a bit with varying height captains, short walls, and messengers. The messengers seem to work out best when their behaviors aren't so captain-based, but rather based off of characters/objects/events that stay static throughout adventure play... unlike unlocked captains' size.
]]> http://forum.spore.com/jforum/posts/preList/35255/1125665.page http://forum.spore.com/jforum/posts/preList/35255/1125665.page GMT
Supposedly messengers will not trigger with some captains. I assume this is because the messengers for some reason are not detecting the captains bounding blocks in their awareness. Perhaps how the captain was built attributes to this issue? Or there is a bug that causes some captain models to not have proper bounding blocks?

Further investigation is needed. Seems to be a rare issue.[/quote]

From what I can tell, visibility is line of sight from one creature's head to another creatures head. It could be that with short captains, the line of sight from the messenger to the captain gets blocked by the bounding box of scenery items. Then again, it could just be that the messengers are being triggered by [b]IF AWARE OF[/b], just fine, but because of momentum and pathing imprecisions, the messenger isn't passing exactly through way points and miss teleporters.

Or it could be that the captains are using [b]sneak [/b]and so are effectively [b]invisible [/b]with respect to [b]IF AWARE OF[/b].

I'm wondering if having multiple redundant messengers will fix the problem. I don't think they'd cost must complexity.

[/quote]


Some good theories. However I just concluded some extensive testing. I just tested over 60 captains in one of the missions that were reported to me. Each captain was quite different. From tiny to tall. Abstract to realistic. Ones that were mostly decorations. Even ones with invisible parts. AI and messengers triggered every time.

If the issue exists, I cannot recreate it. So it may just be a rare system specific bug. Which is the worse kind of bug because for a bug to be fixed it needs to be reliably reproducible.

If anyone has had this issue and can reproduce it please post the captain that you used so others can test.]]> http://forum.spore.com/jforum/posts/preList/35255/1125691.page http://forum.spore.com/jforum/posts/preList/35255/1125691.page GMT
For example (sorry for the ASCII art diagram lol)


o = messenger


T = short captain

[] = wall

Imagine this setup:


__o_[]_T__

In that setup, the messenger is so small, it's not aware of the captain, even though the wall should be short enough normally. But, because the messenger is so close to the wall, it doesn't detect the captain at all.

I might test this out in a bit with varying height captains, short walls, and messengers. The messengers seem to work out best when their behaviors aren't so captain-based, but rather based off of characters/objects/events that stay static throughout adventure play... unlike unlocked captains' size.
[/quote]

Theoretically speaking, I believe you would be correct in that situation if what DVDmaster says is correct about how creatures detect each other. Care should be taken with such setups.]]> http://forum.spore.com/jforum/posts/preList/35255/1125695.page http://forum.spore.com/jforum/posts/preList/35255/1125695.page GMT
Here's a thought (don't know if this was mentioned before), can the eyes on the messenger make any difference? Not really the "type" of eyes (although, maybe that too?), but the placement or number of them? I don't know if line-of-sight actually takes eyes into affect or not but it might be worth some testing. Could explain some things. Just a theory. Well, maybe even more of a question.




]]> http://forum.spore.com/jforum/posts/preList/35255/1125819.page http://forum.spore.com/jforum/posts/preList/35255/1125819.page GMT
Here's a thought (don't know if this was mentioned before), can the eyes on the messenger make any difference? Not really the "type" of eyes (although, maybe that too?), but the placement or number of them? I don't know if line-of-sight actually takes eyes into affect or not but it might be worth some testing. Could explain some things. Just a theory. Well, maybe even more of a question.




[/quote]

As far as I can tell, it doesn't actually matter at all what type of eyes a creature has, or how many. In fact, I don't think it matters if they even have eyes, because if you download and play with vladi's messenger tutorials, you will notice that his "bote" messengers have no eyes at all. So, awareness isn't actually dependent on what we as humans consider sight... it's strictly defined by the awareness radius we set, whether the messenger even has any eyes or not.

Edit: As an added example of this, I have creatures with no eyes that I have used as NPCs in some of non-shared adventures. During Test Drive, they can still "see". That is to say... they still react to other creatures within their awareness radius, even though they don't have eyes.

Edit 2: Nevermind that... the Phaleen do have eyes. God... been so long since I played with them in CC. Sorry. However, the bote messengers have no eyes.]]> http://forum.spore.com/jforum/posts/preList/35255/1125869.page http://forum.spore.com/jforum/posts/preList/35255/1125869.page GMT
Any messenger AI will fail if it depends on [b]AWARE of PLAYER [/b]if the player is invisible. It might fail on AWARE OF ITEM if that item is held by a stealthy character -- I haven't tested this.

Depending on how dangerous the adventure, I often do as much as I can while invisible. Sometimes, I get get all the way to the final boss before having to become visible (completely ignoring all the minions).






]]> http://forum.spore.com/jforum/posts/preList/35255/1126459.page http://forum.spore.com/jforum/posts/preList/35255/1126459.page GMT
Some good theories. However I just concluded some extensive testing. I just tested over 60 captains in one of the missions that were reported to me. Each captain was quite different. From tiny to tall. Abstract to realistic. Ones that were mostly decorations. Even ones with invisible parts. AI and messengers triggered every time.

If the issue exists, I cannot recreate it. So it may just be a rare system specific bug. Which is the worse kind of bug because for a bug to be fixed it needs to be reliably reproducible.

If anyone has had this issue and can reproduce it please post the captain that you used so others can test.[/quote]

Can you show me the adventure and which messenger.]]> http://forum.spore.com/jforum/posts/preList/35255/1126467.page http://forum.spore.com/jforum/posts/preList/35255/1126467.page GMT
You can also have problems when captains move while and NPC is acting and the movement causes the NPC's behavior to abort (and for some reason they don't restart). For example:
[b]PICKUP OBJECT ALWAYS
GIVE OBJECT to PLAYER ALWAYS
IDLE DANCE ALWAYS[/b]

If the NPC starts to give the object to the captain and the captain moves away, the NPC can sometimes get stuck in the middle of the give and you can't reset the NPC. THe NPC just stands there, he doesn't dance. Approaching the NPC does not retrigger the give. Sometimes if you wait long enough (15+ seconds) , the NPC will reset.

Sometimes you can fix this by using:
[b]GIVE OBJECT PLAYER TIMER 10 SECONDS
[/b]This will make the NPC give the object and try again every 10 seconds.
]]> http://forum.spore.com/jforum/posts/preList/35255/1126565.page http://forum.spore.com/jforum/posts/preList/35255/1126565.page GMT
I had someone specifically point out the problem on the "how to use physics" demo that I edited for Vladi. They said that they had one captain work fine, but two others that for some reason would not trigger the messenger.

I downloaded all his captains and plan to test them. I did run my own tests with a variety ( little over 60) captains made by different people with very different configurations and couldn't recreate the issue.

Please have a look at it though. You should have it in your demos sporecast.]]> http://forum.spore.com/jforum/posts/preList/35255/1127431.page http://forum.spore.com/jforum/posts/preList/35255/1127431.page GMT
I've noticed that you put the messenger in a box of gates. If you are trying to save on complexity, you can get away with just the "roof" gate if you lower the roof to just about messenger height (or at least small enough so that the captain can't get under it.
]]> http://forum.spore.com/jforum/posts/preList/35255/1127670.page http://forum.spore.com/jforum/posts/preList/35255/1127670.page GMT
Need to test this further to understand whats going on exactly but the two demos are completely broken for me now. Would you be so kind as to test them as well. I'd like to get to the bottom of the issue.]]> http://forum.spore.com/jforum/posts/preList/35255/1130970.page http://forum.spore.com/jforum/posts/preList/35255/1130970.page GMT
Need to test this further to understand whats going on exactly but the two demos are completely broken for me now. Would you be so kind as to test them as well. I'd like to get to the bottom of the issue.[/quote]

I might have noticed something, but I'm not completely sure yet. I have been working on an adventure that uses messengers but it seems that the messengers no longer respond as quickly as before. At least, movement-wise. For instance, if you have a messenger set to follow the player upon becoming aware of the player, it seems that messenger may sit there for a bit before deciding to follow the player. Needs more testing though. Might just be due to other stuff I have going on too.




]]> http://forum.spore.com/jforum/posts/preList/35255/1131470.page http://forum.spore.com/jforum/posts/preList/35255/1131470.page GMT
Need to test this further to understand whats going on exactly but the two demos are completely broken for me now. Would you be so kind as to test them as well. I'd like to get to the bottom of the issue.[/quote]

I won't be able to test until next week. I'm checking email at work, but on evenings and weekends and I will be at comic-con in San Diego.

]]> http://forum.spore.com/jforum/posts/preList/35255/1131734.page http://forum.spore.com/jforum/posts/preList/35255/1131734.page GMT
I have taken a quick look at the physics example and it is a lot less reliable than before. When I resize messengers and keys, and play with the visibility of objects (gates and teleporters), I notice a few things:

a. There is a slight delay before the key is picked up. I don't know if this is different than before.

b. Some times the messenger steps on the teleporter before getting the key. I think this is because the messenger is picking a different direction to approach and pick up the key and as it circles the key, it accidentally steps on the teleport. Moving the teleporter further away fixes this.

c. Since the messenger is so small, it might be getting suck trying to walk on the teleport pad. You can rotate the pad so that the surface is flush with the hillside.

d. Sometimes the messenger steps on the teleporter but misses the gate on the destination side (or just stands still on the stationary side). I like to add more move to waypoints to direct the messenger though the gate after arriving at the teleport destination.

e. You might want to change the rule order on your messenger so that the pickup occurs before the move if aware. That way it will be less likely for the messenger to take off before picking up the key.

One general problem with patches is that the adventures have been hand tuned for the quirks of the game and as EA/Maxis changes things, they can break our hand tuning.









]]> http://forum.spore.com/jforum/posts/preList/35255/1132090.page http://forum.spore.com/jforum/posts/preList/35255/1132090.page GMT
I have taken a quick look at the physics example and it is a lot less reliable than before. When I resize messengers and keys, and play with the visibility of objects (gates and teleporters), I notice a few things:

a. There is a slight delay before the key is picked up. I don't know if this is different than before.

b. Some times the messenger steps on the teleporter before getting the key. I think this is because the messenger is picking a different direction to approach and pick up the key and as it circles the key, it accidentally steps on the teleport. Moving the teleporter further away fixes this.

c. Since the messenger is so small, it might be getting suck trying to walk on the teleport pad. You can rotate the pad so that the surface is flush with the hillside.

d. Sometimes the messenger steps on the teleporter but misses the gate on the destination side (or just stands still on the stationary side). I like to add more move to waypoints to direct the messenger though the gate after arriving at the teleport destination.

e. You might want to change the rule order on your messenger so that the pickup occurs before the move if aware. That way it will be less likely for the messenger to take off before picking up the key.

One general problem with patches is that the adventures have been hand tuned for the quirks of the game and as EA/Maxis changes things, they can break our hand tuning.

[/quote]

a. There is a slight delay before the key is picked up. I don't know if this is different than before.

This didn't use to happen. Prometheus pointed out that this is happening now as well. There seems to be a longer delay with them triggering. He also noticed they move slower than before.

c. Since the messenger is so small, it might be getting suck trying to walk on the teleport pad. You can rotate the pad so that the surface is flush with the hillside.

weird, this was not an issue before. I'm wondering if changes to the collision and animation engines in this patch is what is screwing things up.

d. Sometimes the messenger steps on the teleporter but misses the gate on the destination side (or just stands still on the stationary side). I like to add more move to waypoints to direct the messenger though the gate after arriving at the teleport destination.

In my own tests it appears that the messengers never pick up an item now. The other demo "how to use messengers", the messengers get triggered just fine, but they will not pickup the wanted posters. I even tried different ai settings and they just won't do it.

They are aware of the posters (scroll object) and point at them but can not grab them anymore. They definitely try to though. My guess is that the extensive changes to the animation system messed things up. The tiny guys for whatever reason can no longer grab objects in their mouths....OR they cannot get close enough to the objects because the bounding boxes for them have been changed.

The next step is to test if size, hands, legs, and eyes make any difference to this issue.
]]> http://forum.spore.com/jforum/posts/preList/35255/1132132.page http://forum.spore.com/jforum/posts/preList/35255/1132132.page GMT http://forum.spore.com/jforum/posts/preList/35255/1133198.page http://forum.spore.com/jforum/posts/preList/35255/1133198.page GMT http://forum.spore.com/jforum/posts/preList/35255/1133363.page http://forum.spore.com/jforum/posts/preList/35255/1133363.page GMT
This didn't use to happen. Prometheus pointed out that this is happening now as well. There seems to be a longer delay with them triggering. He also noticed they move slower than before.[/quote]

I haven't really been seeing much of a delay in messengers picking up keys. At least, in my testing with the messenger and the key right next to each other. But, there is definitely now a delay in the time before the messenger starts to move once they become aware of the player.

However, I'm having the messenger pick up the key immediately. If you're noticing a delay with the key being picked up, it may actually be due to the [i]delay in awareness reaction before the messenger actually decides to pick up the key[/i]. Have you tried testing with the messenger always picking up the key? When I do that, the key gets picked up right away. If you're triggering the picking up of the key by awareness of the player, I'm suspecting that's where you're getting the delay in this particular situation as it seems any messenger action triggered by the awareness of the player seems to have a delay now.




]]> http://forum.spore.com/jforum/posts/preList/35255/1134281.page http://forum.spore.com/jforum/posts/preList/35255/1134281.page GMT http://forum.spore.com/jforum/posts/preList/35255/1148829.page http://forum.spore.com/jforum/posts/preList/35255/1148829.page GMT I really think this is an issue which maxis needs to address even if it means breaking a lot of adventures already made because this issue causes far to many problems and ruins so many adventures.Collision detection absolutely needs to be fixed I can't tell you how many times I've seen npc's get stuck in walls. It can really ruin thing's when those npc's need to be interacted with.
For once I would like it if maxis used there own team to test and debug this game rather than there customers. Im really getting sick of these problems.]]> http://forum.spore.com/jforum/posts/preList/35255/1153891.page http://forum.spore.com/jforum/posts/preList/35255/1153891.page GMT
Ps. I have patch 1.05.1 and I made sure to set the NPCs awareness to max]]> http://forum.spore.com/jforum/posts/preList/35255/1162686.page http://forum.spore.com/jforum/posts/preList/35255/1162686.page GMT
Ps. I have patch 1.05.1 and I made sure to set the NPCs awareness to max[/quote]

You also have to look at the geometry of each individual wall and floor piece. For example, if you have the floor and a table combined as a single building object, then the bounding box will be as tall as the tallest object attached to the floor. This can make a bounding box that is too tall and makes NPC's blind.

This also applies to walls. If you build walls that have wide bottoms, or object like torches sticking out, or attached roof pieces, the bound box expands until the width encloses all of those peices. If an NPC is too close to the wall, he can end up inside the bounding box and is effectively blind. It can apply to ceilings too if you have structures that hang down from the ceiling.

One good way to determine if this is happening is to give the NPC this AI:
[b]SHOOT PLAYER ALWAYS
IDLE DANCE ALWAYS[/b]
Then test drive and look at the NPC's behavior. Is it looking at you or is it dancing? If it is dancing then the NPC cannot see the captain.

Another reason the NPC may not be attacking is that the NPC cannot figure out how to get to the captain. I've not really figured out the exact circumstances that cause this, but it can be effected by the terrain under the floor or if there are other buildings above or below the current floor.

Some people have had better success by using a disguised gate for the floor instead of using a building.

]]> http://forum.spore.com/jforum/posts/preList/35255/1162780.page http://forum.spore.com/jforum/posts/preList/35255/1162780.page GMT
Ps. I have patch 1.05.1 and I made sure to set the NPCs awareness to max[/quote]

You also have to look at the geometry of each individual wall and floor piece. For example, if you have the floor and a table combined as a single building object, then the bounding box will be as tall as the tallest object attached to the floor. This can make a bounding box that is too tall and makes NPC's blind.

This also applies to walls. If you build walls that have wide bottoms, or object like torches sticking out, or attached roof pieces, the bound box expands until the width encloses all of those peices. If an NPC is too close to the wall, he can end up inside the bounding box and is effectively blind. It can apply to ceilings too if you have structures that hang down from the ceiling.

One good way to determine if this is happening is to give the NPC this AI:
[b]SHOOT PLAYER ALWAYS
IDLE DANCE ALWAYS[/b]
Then test drive and look at the NPC's behavior. Is it looking at you or is it dancing? If it is dancing then the NPC cannot see the captain.

Another reason the NPC may not be attacking is that the NPC cannot figure out how to get to the captain. I've not really figured out the exact circumstances that cause this, but it can be effected by the terrain under the floor or if there are other buildings above or below the current floor.

Some people have had better success by using a disguised gate for the floor instead of using a building.

[/quote]

The walls have a very faint V Shape,but since the room is small, the NPC can only see me when im outside the bounding box

EDIT: The walls have a very faint V Shape,but since the room is small, the NPC can only see me when im outside the bounding box,which is almost never]]> http://forum.spore.com/jforum/posts/preList/35255/1162872.page http://forum.spore.com/jforum/posts/preList/35255/1162872.page GMT [IMG]http://i605.photobucket.com/albums/tt140/DavidKris/Awareness02.jpg[/IMG][/quote]

Hey DVDMaster, I have a question for you.

I don't know if you have figured this out already or if you'd need to test it ( I'm too lazy to test it myself ) but what would happen if you tried the following couple of configurations?

[img]http://farm3.static.flickr.com/2446/3767593857_8db56a6663.jpg[/img]

[img]http://farm3.static.flickr.com/2428/3768394268_d52b2d11db.jpg[/img]

I know that "A" and "B" [i]should[/i] ( ) both be able to see each other in either case and "C" and "D" [i]should[/i] ( ) also both be able to see each other in either case. But, can "A/B" see "C/D" in either case?

Edit: Also, I can't understand why they can't just make the bounding boxes of items equal to (or, actually slightly larger by a pixel or two) than the item. For instance, creatures can partially enter objects you use for walls. Is that mainly related to the creature itself or to the wall object? While it seems that the bounding area for creature visibility runs the full length of objects, the bounding portion of that object is less than what appears for the image of that object. Therefore, you can partially walk into a wall (and get stuck between walls because of it etc). To try and explain better, imagine a box inside another box. The outer box would be the image of the wall itself while the inner box would be the actual bounding area. Why not make them equal? I can understand the bounding box not being larger (or "too much" larger) because then you'll have floating characters but why not at least "equal?" Right now, seems they're not even all that close in size to each other.




]]> http://forum.spore.com/jforum/posts/preList/35255/1164246.page http://forum.spore.com/jforum/posts/preList/35255/1164246.page GMT http://forum.spore.com/jforum/posts/preList/35255/1164267.page http://forum.spore.com/jforum/posts/preList/35255/1164267.page GMT
This might not be the exact place for this... but did any of you guys get a "there are updates available" message when you logged into Spore yesterday? I didn't get the stuff yet, but is it possible they've released a patch of the patch? lol I just couldn't find anything about it on the SporeDay page, or find any notes.

Anyhow, sorry... resume!]]> http://forum.spore.com/jforum/posts/preList/35255/1164708.page http://forum.spore.com/jforum/posts/preList/35255/1164708.page GMT
Hey DVDMaster, I have a question for you.

I don't know if you have figured this out already or if you'd need to test it ( I'm too lazy to test it myself ) but what would happen if you tried the following couple of configurations?

[img]http://farm3.static.flickr.com/2446/3767593857_8db56a6663.jpg[/img]

[img]http://farm3.static.flickr.com/2428/3768394268_d52b2d11db.jpg[/img]

I know that "A" and "B" [i]should[/i] ( ) both be able to see each other in either case and "C" and "D" [i]should[/i] ( ) also both be able to see each other in either case. But, can "A/B" see "C/D" in either case?[/quote]

It shouldn't make any difference because none of the blocks are taller than the characters. The bounding box is a box that encloses all the parts of a building and when you draw a box around the blocks, characters a,b,c,d, all end up outside the box.


[quote=iiiHuman]Edit: Also, I can't understand why they can't just make the bounding boxes of items equal to (or, actually slightly larger by a pixel or two) than the item. For instance, creatures can partially enter objects you use for walls. Is that mainly related to the creature itself or to the wall object? While it seems that the bounding area for creature visibility runs the full length of objects, the bounding portion of that object is less than what appears for the image of that object. Therefore, you can partially walk into a wall (and get stuck between walls because of it etc). To try and explain better, imagine a box inside another box. The outer box would be the image of the wall itself while the inner box would be the actual bounding area. Why not make them equal? I can understand the bounding box not being larger (or "too much" larger) because then you'll have floating characters but why not at least "equal?" Right now, seems they're not even all that close in size to each other.
[/quote]

There are two separate things here.

First is [b]visibility [/b]-- can NPC1 see NPC2? The visibility is used for AI purposes. This is determine by drawing a line between the heads of NPC1 and the NPC2 and see if that line can go from NPC1 to NPC2 without passing through the visibility bounding box. The visibility bounding box is a single box that encloses all the parts of the building. At every tick of clock, the computer has to determine the visibility between every possible pair of NPCs -- and then has to see if the line of sight intersects each of the bounding boxes. If the programmers decided to check visibility using each of the component pieces in a building, there would probably be many more calculations.

The developers might be able to improve this by using multiple visibility boxes per bulding, but not one per part. Maybe by sorting by size or part type, they can add a few more boxes per building that gives a better result.

The second issue is [b]collisions [/b]-- where does the character bump into the object. Collisions use the geometry of the actual pieces instead of a single bounding box for the entire building. And as you noted, it is separate from the visual skin of the building. Part of the reason that the skin is different from the collision surfaces is that the skin is generated by the GPU in the graphics card and the collsion surfaces are generated by the CPU. The collision calculations are done using a simple model -- here is a cube with these dimensions. What is sent to the GPU is more complicated -- here is a cube with these dimensions, with a certain thickness, with rounded corners with radius X, using this texture. The GPU takes that information and calculates all the surfaces needed to display it on the screen. The results of the GPU calculations cannot be sent back to the CPU to be used in collision detection and doing all those calculations with the CPU would slow things down to much.

This same thing occurs with creature animations when you attack parts to the heads of creatures. The skin surfaces are calculated by the GPU but the placement of parts is calculated by the CPU. This is why you get strange clipping problems when you attack details to the lower jaw.

Given the choice of having the skin outside the collsion surface or inside the collision surface, you get a better visual effect if the collision surface is inside the skin. It gives the impression of touching the object as opposed to hovering on top of. Compare the experience of standing on a building vs. standing on a vehicle -- I prefer the effect of standing on buildings.

[b]However, there are bugs in the collision logic that do not stop characters before they pass through the collision surface. [/b]And once passed though an outer collision surface, the character collides with some other collision surface. This gets the character stuck inside the surface. This happens with faster moving characters (speed 4 or 5; flight; falling from high distances; being knocked by damage. Changing the collision surfaces so that they are outside the skin won't fix this problem because it isn't a visual issue. The problem is that the collision logic [b]fails.[/b]

]]> http://forum.spore.com/jforum/posts/preList/35255/1169941.page http://forum.spore.com/jforum/posts/preList/35255/1169941.page GMT . Changing the collision surfaces so that they are outside the skin won't fix this problem because it isn't a visual issue. The problem is that the collision logic [b]fails.[/b][/quote]

Wow, thanks for your in-depth reply. That explains a LOT on all accounts.




]]> http://forum.spore.com/jforum/posts/preList/35255/1171183.page http://forum.spore.com/jforum/posts/preList/35255/1171183.page GMT
This same thing occurs with creature animations when you attack parts to the heads of creatures. The skin surfaces are calculated by the GPU but the placement of parts is calculated by the CPU. This is why you get strange clipping problems when you attack details to the lower jaw.

Given the choice of having the skin outside the collsion surface or inside the collision surface, you get a better visual effect if the collision surface is inside the skin. It gives the impression of touching the object as opposed to hovering on top of. Compare the experience of standing on a building vs. standing on a vehicle -- I prefer the effect of standing on buildings.[/quote]

Okay, I have another question for you DVDMaster. With this whole "collision" thing and certain parts being done by the CPU and other parts being done by the GPU, where does the planet collision system fall into all of this and why can't the buildings be done the same?

For instance, if you captain is standing on the surface of a planet, he appears to be standing directly on the planet surface. He isn't standing above surface but he also isn't standing just below the surface. However, you make a platform (out of a building) and your captain appears to be standing partially below the surface of that object rather than directly on the surface like that of the planet. So, it just seems that it shouldn't be too hard for the programmers to make it so collision surfaces appear the same as the graphics surfaces.

Yes, ignoring the whole collision "failure" problem at the moment. Just want my captain's feet to line up directly on the surface of an object like they do on the surface of the planet itself already.




]]> http://forum.spore.com/jforum/posts/preList/35255/1187468.page http://forum.spore.com/jforum/posts/preList/35255/1187468.page GMT Okay, I have another question for you DVDMaster. With this whole "collision" thing and certain parts being done by the CPU and other parts being done by the GPU, where does the planet collision system fall into all of this and why can't the buildings be done the same?

For instance, if you captain is standing on the surface of a planet, he appears to be standing directly on the planet surface. He isn't standing above surface but he also isn't standing just below the surface. However, you make a platform (out of a building) and your captain appears to be standing partially below the surface of that object rather than directly on the surface like that of the planet. So, it just seems that it shouldn't be too hard for the programmers to make it so collision surfaces appear the same as the graphics surfaces.
[/quote]

Except that the are many more graphic surfaces than collision surfaces. For example, if you look that the cubical building piece (upper left on the bodies tap), there are just 6 collision surfaces (each face of the cube), but there are a lot more graphical surfaces -- approximately 50 (when you count each surface of the edge details). So from a computation stand point there would be about 9 times as many collision surface calculations. And this is just in a single building piece. And these types of calculations have been optiimatized in GPU's and not all that optimized in CPUs. So from a calculations per second perspective, using every single surface for collsions is just not feasable if you want the game to run on the largest number of computers possible. So it seems necessary to use collsion sufaces approximations instead of using the actual geometry of the buildings.

In addition, they may not actually calculate whether you hand or foot (or each body part) hits the surfaces or not. They just use a single center of mass point and compare the center of mass to the collisions surfaces to figure out where whether to prevent the character from moving in a direction or not. Then could send all the information to the GPU and let it figure out what parts are visible or not. GPU are optimized for these calculations.

I do think that a better decision could have been made about where to put the actual collision surfaces in each building piece. Right now, I think the collision surfaces correspond to the wire frame skeleton used to generate the skin model. This information that was already readily available from developing spore and concluded that that existing information was good enough for most adventures (or at least the adventures the developer team came up with). When building pieces are used for walls, the moving into the building effect isn't all that annoying -- who cares of a hand or elbow clips into the wall as you walk by. It would be less annoying than having the collision surfaces outside the building (like they are when standing on vehicles).

But creating a new collision geometry system is probably a very complex task.

A simple fix would be to provide some new building part bodies that don't have any round edges or complex edge details -- super simple cubes -- so that we could use these parts for building structures that we are to stand upon.


]]> http://forum.spore.com/jforum/posts/preList/35255/1187838.page http://forum.spore.com/jforum/posts/preList/35255/1187838.page GMT Just because you have fixed the visibility problem, you can still have problems with NPC walking on buildings.

It is my experience that any NPC activity on buildings as floors is buggy. Here is a very simple example:
NPC using basic AI, "mindless", patrol with way points.
[youtube]http://www.youtube.com/watch?v=V7gZmFhjKvU[/youtube]

If you change the building to a disguised gate (using the same building piece), you get better results:
[youtube]http://www.youtube.com/watch?v=4xA9GH7iaKY[/youtube]

However, you still have problems using a disguised gate as a bridge.
[youtube]http://www.youtube.com/watch?v=YSA6vaUd-mc[/youtube]

It appears that it uses the ground under the bridge for path calculations.

]]> http://forum.spore.com/jforum/posts/preList/35255/1188001.page http://forum.spore.com/jforum/posts/preList/35255/1188001.page GMT
They just use a single center of mass point and compare the center of mass to the collisions surfaces to figure out where whether to prevent the character from moving in a direction or not. Then could send all the information to the GPU and let it figure out what parts are visible or not. GPU are optimized for these calculations.

I do think that a better decision could have been made about where to put the actual collision surfaces in each building piece. Right now, I think the collision surfaces correspond to the wire frame skeleton used to generate the skin model.

But creating a new collision geometry system is probably a very complex task.

A simple fix would be to provide some new building part bodies that don't have any round edges or complex edge details -- super simple cubes -- so that we could use these parts for building structures that we are to stand upon.[/quote]

Okay, wait a second. Let's see if we're on the same page here and she how complicated this really would have to be or not.

Let's start with a picture:

[img]http://i845.photobucket.com/albums/ab14/iiiHuman/Collision-Calculation-01.png?t=1249278662[/img]

Now, for discussion's sake, let's say:

The [b][color=red]Rounded Red Box[/color][/b] is the sideview graphics cutout of a building piece that is not your standard cube (due to the rounded edges).

The [b][color=blue]Inner Dashed Blue Box[/color][/b] is a simplified version of a possible frame for the actual object (the red box is the graphics for it).

The [b]Outer Dashed Black Box[/b] is a better approximation of where collision [i]SHOULD/COULD[/i] take place instead.

The [b][color=green]Green Circle[/color][/b] in the upper-right hand corner is an example of an additional graphic piece that could either be separate from or part of the original object.

With this in mind, it seems that the actual collision area could be computed by just adding to distance the surface of the inner frame is from its center. You could roughly compute this based on the outer flat surface of where the graphic will be drawn. Now, this shouldn't have to be computed each time (regardless of the size of the object) because, as you expand or contract the size of the object (changing the size of its inner frame), the outer edge of the graphic will also change in size accordingly and stay the same distance away from the edge of the inner frame. Creating a static value that can be stored.

For the most part, this should suffice. For the rounded corners (depending on how the inner frame is truly created), there might be a little bit of floating distance, but I believe this wouldn't be much of a problem for people when designing building parts that can be walked on etc.

In the case of the additional green circle (like the pylons on the corners of some building parts), they probably have their own inner frame (or center) that the distance is specified for. So, the same can be applied to that portion.

Best part is, even if the distance the graphic is drawn from its inner frame is different for each type of building piece, you wouldn't have to compute this each time. You would just have to store a static value to add to the distance of the inner frame to compensate for that graphic based on which object (type of building piece) was used. This would result in the outer dashed black box.

In fact, it almost seems that the "visibility" box around an object is partially based on this idea too (not sure). However, with the visibility box, it's computed on the outermost edge of the farthest part of the object. Which, of course, would be very bad to use as then you'd have a collision surface WAY OFF.

But, it seems it gets even better. By using a stored static value of a distance from the edge of the inner frame, the visibility box could be equal to that of the new collision box using the method I'm describing. Of course, there'd still need to be the computations of what can be seen at a certain angle etc. But, that wouldn't affect the predetermined collision surface distance. Also, by using the stored static value, the GPU can use that prestored value to help with its computations of where to draw the actual surfaces of the object and cut down on some of the computing for it.

As for textures, that doesn't matter since those are flat and drawn on the surface and do not affect the actual shape of the object.

In fact, since computations have to be made as to how and where to draw textures on an object (how far from the framework, etc), another possibility could be to use at least part of those computations to maybe determine the collision surfaces. Once they are computed, temporarily store those values for collision detection.

Now, it would help a lot to know exactly how they are computing object frames and graphic surfaces etc. Then, we could better determine an appropriate and simple solution. The point is, I think there is a simple solution without causing much more computations having to take place.

However, you might have a better grasp on what they are doing and can explain where I'm wrong here. Which, I actually look forward to since it still seems like there's tons of acceptible possibilities to fix the problems and get around it being lots more complicated.




]]> http://forum.spore.com/jforum/posts/preList/35255/1188263.page http://forum.spore.com/jforum/posts/preList/35255/1188263.page GMT
It is my experience that any NPC activity on buildings as floors is buggy.

It appears that it uses the ground under the bridge for path calculations.[/quote]

Yeah, those videos clearly show that there are definitely bugs in path calculations. I think the biggest problem there is that the paths do appear to be computed using the surface of the planet rather than the surface of the top object being crossed. I say the top object since you can have a floor above another floor etc etc. But, the top object being the one being crossed not including any more above it (like a ceiling etc). Just to be clear.




]]> http://forum.spore.com/jforum/posts/preList/35255/1188277.page http://forum.spore.com/jforum/posts/preList/35255/1188277.page GMT
With this in mind, it seems that the actual collision area could be computed by just adding to distance the surface of the inner frame is from its center. You could roughly compute this based on the outer flat surface of where the graphic will be drawn. Now, this shouldn't have to be computed each time (regardless of the size of the object) because, as you expand or contract the size of the object (changing the size of its inner frame), the outer edge of the graphic will also change in size accordingly and stay the same distance away from the edge of the inner frame. Creating a static value that can be stored.

For the most part, this should suffice. For the rounded corners (depending on how the inner frame is truly created), there might be a little bit of floating distance, but I believe this wouldn't be much of a problem for people when designing building parts that can be walked on etc.[/quote]

Yes. This is all doable. Is just that you they'd have to build the data structures for all this additional information and then check every possible place where any of the geometry is accessed and decide at each instance wether to use the current inner box or your proposed outbox.


[quote=iiiHuman]
In the case of the additional green circle (like the pylons on the corners of some building parts), they probably have their own inner frame (or center) that the distance is specified for. So, the same can be applied to that portion.[/quote]

I'm not sure whether they have their own inner box for collision or not. I haven't done enough testing. It may be that those corner pieces only have skin geometry that only exists on the GPU and not the CPU.

[quote=iiiHuman]In fact, it almost seems that the "visibility" box around an object is partially based on this idea too (not sure). However, with the visibility box, it's computed on the outermost edge of the farthest part of the object. Which, of course, would be very bad to use as then you'd have a collision surface WAY OFF.[/quote]

From what I can tell, there is just a single visibility box for the entire building. So when you have complex building shapes, the visibility bounding box is very different from the skin box.

[quote=iiiHuman]
But, it seems it gets even better. By using a stored static value of a distance from the edge of the inner frame, the visibility box could be equal to that of the new collision box using the method I'm describing. Of course, there'd still need to be the computations of what can be seen at a certain angle etc. But, that wouldn't affect the predetermined collision surface distance. Also, by using the stored static value, the GPU can use that prestored value to help with its computations of where to draw the actual surfaces of the object and cut down on some of the computing for it.
[/quote]

That is what they are already doing. They are telling the GPU to draw a cube with rounded corners with a given radius with walls of a given thickness. It is just that they are using the coordinates of that box for the collision surface. What they need what you suggest -- calculate a new collision surface that takes into account the thickness of the walls and the radius of the rounded corners.

One of the basic challenges is that while the GPU is good at these calculations, it isn't really good at passing the results back to the CPU. So to implement your solution, these additional calculations would have to be done on the CPU.

In addition, it doubles the amount of information needed to be kept in memory -- they tell need the existing inner box for drawing the skin and your suggested outer box is a addition.

]]> http://forum.spore.com/jforum/posts/preList/35255/1189333.page http://forum.spore.com/jforum/posts/preList/35255/1189333.page GMT * use a disguised gate as bridge
* connect both shores with a thin languet under the bridge (no ship can pass this bridge now!)
* use invisible gates to prevent the NPC use the natural bridge.
* tell the NPC with several waypoints the correct way

[size=16][b]Spore - NPC walking over a bridge [/b][/size]
[youtube]http://www.youtube.com/watch?v=VchMwp6cBus[/youtube]

(The fat crab like creature is my test captain. The small guy with the big red key opening the red gate is the npc crossing the bridge.)

[youtube]http://www.youtube.com/watch?v=coAQy82PkCE[/youtube]

[size=16][b]And this is the way how it looks like in the editor:[/b][/size]
[IMG]http://img4.imageshack.us/img4/7426/spore20090803110409.png[/IMG]
[/quote]]]> http://forum.spore.com/jforum/posts/preList/35255/1189357.page http://forum.spore.com/jforum/posts/preList/35255/1189357.page GMT * use a disguised gate as bridge
* connect both shores with a thin languet under the bridge (no ship can pass this bridge now!)
* use invisible gates to prevent the NPC use the natural bridge.
* tell the NPC with several waypoints the correct way

[size=16][b]Spore - NPC walking over a bridge [/b][/size]
[youtube]http://www.youtube.com/watch?v=VchMwp6cBus[/youtube]

(The fat crab like creature is my test captain. The small guy with the big red key opening the red gate is the npc crossing the bridge.)

[youtube]http://www.youtube.com/watch?v=coAQy82PkCE[/youtube]

[size=16][b]And this is the way how it looks like in the editor:[/b][/size]
[IMG]http://img4.imageshack.us/img4/7426/spore20090803110409.png[/IMG][/quote]

Has anyone tried this (or something similar) with vehicles? Would be cool to see a tank actually cross a bridge.




]]> http://forum.spore.com/jforum/posts/preList/35255/1193527.page http://forum.spore.com/jforum/posts/preList/35255/1193527.page GMT * use a disguised gate as bridge
* connect both shores with a thin languet under the bridge (no ship can pass this bridge now!)
* use invisible gates to prevent the NPC use the natural bridge.
* tell the NPC with several waypoints the correct way

[size=16][b]Spore - NPC walking over a bridge [/b][/size]
[youtube]http://www.youtube.com/watch?v=VchMwp6cBus[/youtube]

(The fat crab like creature is my test captain. The small guy with the big red key opening the red gate is the npc crossing the bridge.)

[youtube]http://www.youtube.com/watch?v=coAQy82PkCE[/youtube]

[size=16][b]And this is the way how it looks like in the editor:[/b][/size]
[IMG]http://img4.imageshack.us/img4/7426/spore20090803110409.png[/IMG][/quote]

Has anyone tried this (or something similar) with vehicles? Would be cool to see a tank actually cross a bridge.




[/quote]


I will be trying to do this soon.
I have an adventure - in the making - that has a continent to which a "life-form" - made island is attached.
I have a vehicle crossing from the island to the continent and back.
This currently uses a land-bridge, though I want to use a building-bridge, as I stated earlier.
I shall post here with the results-if I remember.]]> http://forum.spore.com/jforum/posts/preList/35255/1209592.page http://forum.spore.com/jforum/posts/preList/35255/1209592.page GMT I found an easier way to get rid of the awareness problem, and a very simple one too! If you disguise a gate as the building (as in the 8/2 update) enemies and allies are completely aware of everything around them, disabling that annoying view box. Hope this helps! ]]> http://forum.spore.com/jforum/posts/preList/35255/1209964.page http://forum.spore.com/jforum/posts/preList/35255/1209964.page GMT I will be trying to do this soon.
I have an adventure - in the making - that has a continent to which a "life-form" - made island is attached.
I have a vehicle crossing from the island to the continent and back.
This currently uses a land-bridge, though I want to use a building-bridge, as I stated earlier.
I shall post here with the results-if I remember.[/quote]

Just a quick note to clarifyTairon96's method. He is putting a disguised gate on top of a land-bridge.
]]> http://forum.spore.com/jforum/posts/preList/35255/1211109.page http://forum.spore.com/jforum/posts/preList/35255/1211109.page GMT I found an easier way to get rid of the awareness problem, and a very simple one too! If you disguise a gate as the building (as in the 8/2 update) enemies and allies are completely aware of everything around them, disabling that annoying view box. Hope this helps! [/quote]

Yes, I discovered this on 7/12 and have noted this in several places on this thread (and other threads in the GA forums). Switching from buildings to disguised gates fixes several problems with visibility and pathing problems. However, it is a pain to implement (takes more steps), takes up important game object slots, and I suspect that it costs more complexity (more information has to be stored about disguised gates instead of normal buildings).

]]> http://forum.spore.com/jforum/posts/preList/35255/1211117.page http://forum.spore.com/jforum/posts/preList/35255/1211117.page GMT I found an easier way to get rid of the awareness problem, and a very simple one too! If you disguise a gate as the building (as in the 8/2 update) enemies and allies are completely aware of everything around them, disabling that annoying view box. Hope this helps! [/quote]

The other thing I don't like about disguising things as gates is that a gate has this humming sound that you can't get rid of. It would be a much more attractive solution if there was a way to "shut the gate up", as I don't want a wooden tribal bridge to be accompanied by a static humming noice.

Been reading through a lot of this thread, and there is definitely a lot of useful information here.

Hopefully Maxis decide to look into this problem and improve it (significantly) for the next patch.]]> http://forum.spore.com/jforum/posts/preList/35255/1212750.page http://forum.spore.com/jforum/posts/preList/35255/1212750.page GMT http://forum.spore.com/jforum/posts/preList/35255/1231218.page http://forum.spore.com/jforum/posts/preList/35255/1231218.page GMT
I agree that invisible or disguised gates should not hum.
]]> http://forum.spore.com/jforum/posts/preList/35255/1232152.page http://forum.spore.com/jforum/posts/preList/35255/1232152.page GMT [b]However, there are bugs in the collision logic that do not stop characters before they pass through the collision surface. [/b]And once passed though an outer collision surface, the character collides with some other collision surface. This gets the character stuck inside the surface. [b][size=24]This happens with faster moving characters[/size][/b] (speed 4 or 5; flight; falling from high distances; being knocked by damage. Changing the collision surfaces so that they are outside the skin won't fix this problem because it isn't a visual issue. The problem is that the collision logic [b]fails.[/b]

[/quote]

You mean my captains high speed has been the reason this happens to me so much? So five speed can also handicap me? NOOOOO!]]> http://forum.spore.com/jforum/posts/preList/35255/1249688.page http://forum.spore.com/jforum/posts/preList/35255/1249688.page GMT
Testing is very important i can see, so looks like I'll be doing alot of experimentation with this expansion pack.]]> http://forum.spore.com/jforum/posts/preList/35255/1281172.page http://forum.spore.com/jforum/posts/preList/35255/1281172.page GMT ]]> http://forum.spore.com/jforum/posts/preList/35255/1360840.page http://forum.spore.com/jforum/posts/preList/35255/1360840.page GMT
Very nice analysis indeed.[/quote] Spell it right, ignorent; - Tomo Arigato, Mr. Sporeato ]]> http://forum.spore.com/jforum/posts/preList/35255/1396232.page http://forum.spore.com/jforum/posts/preList/35255/1396232.page GMT