I wanna cog something, any projects around here looking for a part-time cogger?

I would help, but I'm not a great cogger.

Ah, what timing you have. I was just about to PM you, but because you posted this, I'll ask here.

I have been working on a "rotating" space station level that requires players to walk and jump on what the game engine considers the walls and ceiling. I have some cogs that almost work properly for what I want, but would like to have another person's help on it (especially a person with your cogging experience). Are you interested in helping me explore this idea?

[Edit: Removed off-topic statements.]

Oh, and LKOH_SniperWolf has requested help on his idea, too.

Thanks,

Then make a real flashlight, a train cog and a flyable ship cog for me .:)

*Kabump*



Sounds interesting. I know if your level is all 3do, you can do it all in WoW style with hardly any serious setbacks.



I replied to his thread.



Specifics would be nice.

From Hell Raiser:
Hmm...my understanding of WoW style (this really should be called "using PhysicsFlags0x90", or even better "using PhysicsFlags0x90-0x800") is that it only allowed walking on walls and not jumping. If this were for single player, a 3do that actually rotated might work, but would probably still be tricky to have moving doors and such. Of course, my idea is for multiplayer, so I do not think a 3do using PhysicsFlags0x90-0x800 would work well.

I have been testing two cogs: one for jumping properly on any surface (this seems to work correctly) and one for aligning the player properly on any surface (this is the unfinished one).

Some terminolgy is needed first. A floor, slant, wall, or ceiling is a surface in relation to the space station, not a surface in relation to the game engine. A floor is a surface upon which the player stands on perpendicularly. A slant is a surface that is sloped and the player can stand on it, but not perpendicularly. A ceiling or wall is a surface that is not a floor or slant (i.e. a player can't stand on it).

The "aligning" cog uses a pulse that detects when the player attaches to and detaches from a surface. If the player attaches, then a check is made to see if the surface is a floor, slant, or other. If a floor, allow attachment and align to surface; if a slant, allow attachment, but align to the designated floor of this sector; if other, disallow attachment. Some of this is allowing for situations where a player somehow does not have feet pointing toward a floor or slant (maybe because player used a jetpack).

The main problem the cog has is that it randomly crashes. A crash seems to happen when crossing an adjoin (maybe reattaching?). It could be caused by receiving pulse when other pulse-processing is occurring.

Can you think of a different way of handling the "aligning" (for instance, without using a pulse)?

I figured you wanted a challenge; here it is.

If anyone is interested, I could post the cog. I have not done so because the cog uses another cog (the new touched message) and the cog is long enough to take a bit of time to explain. (It seems like all of my posts are long, so I didn't want to bother everyone again with another of my complicated cogs.)

Mind setting me up with the cog in a level so that I might be able to test it? From what I've read, your only problem is that it crashes, right?

I have uploaded the test gob that I have been using. The gob is an MP episode with one test level and its related cogs. Both the level and the cogs are somewhat in disarray (i.e. some comments might be invalid due to code being shifted around).

The aligning cog is called startup.cog. The class_toucher and object_toucher cogs are updated versions of my new touched message cogs mentioned in this thread; they send a touched message to kyle.cog, which then sends the user1 message to the startup.cog. Except for the touched message addition, nothing else in kyle.cog was changed.

I think if the set of lines (which are not "properly" indented) that starts with dummyFeet = FireProjectile... is commented out, the crash does not occur; at least, it did not crash within the typical time that I would run around in the level testing different actions.

There is a lot more I could say about the test level, but I will have to write more tomorrow.

Thanks to all who even try out the test gob. It is not pretty, but it should give a feel for where I am headed with the physics of the station.

Have fun,

for the flashlight

train: I mean like in Half Life at the Beginning:

You go into the train and it drive through xxx frames.....

the best thing is, if it is like the touchme-elevator.....

the go throught xxx frames (if you could do that, if not make 10 Frames)

flyable: forgot that....

Some technical notes on the space station test cog:
- The sector thrusts push the player toward all surfaces except the two circular-like sections on the opposite ends of the station. There is no sector thrust in the middle of the station, i.e. in the air.
- The game engine's floor (default mat) is next to a slant with a gray texture. The modified physics should keep the player standing as if he were standing on the two floors it sits between. I usually notice a slight twitch when entering or exiting the slant (explained later). The same goes for the game engine's ceiling (gray circle within octagon texture), except there the floor has a slant on either side of it.
- There is a "pit" on one of the game engine's walls. If the player walks over either of its two larger edges into it, the player auto-aligns to the pit's wall before correctly aligning to the pit's bottom. Aligning to the wall should not happen. I have not successfully found an elegant way of handling this situation. An inelegant workaround is to require the level to have a 270+degree angle between the wall and floor/slant where the sector thrust changes direction.
- Note that the game engine's walls and ceiling can use the standard floor sounds (normal, metal, ground, water). (This was probably already known, but noting it just in case it was not documented.)
- The test gob has an unused cog called sector_gravity.cog, which was my earliest method for the changed physics. It uses the entered and exited messages for each floor and slant. This would mean linking all of the floors and slants of the level to the cog (which I dislike, as my other thread posts have at least alluded to).
- To align the player properly on a slant, 5 passes are made through the pulse because the only way I could think of aligning the player properly was to attach him to the floor (auto-aligning him) and then reattaching back to the slant (without auto-aligning). Using a separate object to do this and then teleporting the player to the object works, but the auto-aligning attachment seems to need something in the game engine processing between pulses. Without the engine processing between certain steps of the attachment, the auto-aligning uses a previous alignment that the player had, as if the game engine sets a flag to remember the current auto-alignment.
- Note that if you fire the bryar pistol, it's projectile does not go in a straight line, but is affected by the sector thrusts. (This might have been known already.)

Some general notes:
- One of the reasons for going to all of this trouble is to make it as easy as possible for making space station levels (hint hint).
- I am trying to allow all kinds of mods, such as those with a jetpack or grappling hook, to be playable within the space station levels.
- I think it would be fun to have players start or respawn on the game engine's walls and ceiling, without really knowing where the "true" floor is.

Trying to keep my forum posts short,

Would you like fries with that? :p



Eh, not interesting enough... :p

Zeq, I shot you an email. I'm looking through the cogs.

Then make me a realistic-mirror cog!!!!(please)

That would require "mirror" 3dos of every object that you'll use in the level that isn't symettrical (players, some guns, ect ect), and "mirrored" keyframes for the player.

Give me that, and you'll have your realistic-mirror cog. :p

Also I'm working on a grapple hook that you can swing from, and Zeq's space station WoW stuff, so my plates a little full.

That's what I was trying to figure out for this... however, I think I just might have to do without any reflections of the players...

I have a pretty simple cog on request. I want to use the storm trooper cog. But instead of him shooting you on sight, he wont shoot at you untill you've shot. Like, wont even know your there or pay any attention to you untill you've shot.

Z@nardi: have you tried setting the AI's flags so that the AI is "asleep" in the class cog's "created" message block and then simply "wake" the AI by changing its flags in the class cog's "damaged" message block?

Just a quick thought before bed

-Jackpot

Hey Jackpot, thanks for the info, though I don't cog so i dont think it will help me too much

Z@N, just add a SendTrigger message to a cog attached to your projectiles on 'created', and if the class cogs of the troopers detect that they're a certain distance from you when this happens, then change their AI class to an agressive one if it isn't already.