PaulWeston

OK phew, turned out to be simple.

Thought I had both machines synched up with latest code, but had missed one of the animation .cs files for the player models, it had one less animation listed in the add sequences step.

Anyhow just did a compile fresh mirror on the other machine and all the anims work client side again. Glad it was just a synch issue.

lol ya that could be fun...

It's really weird, have never seen it before.

It's basically the same exe/dll as our other game, just with the PhysX taken out. In the other game, I always play it multiplayer and have never noticed these animation issues - and like I said it's the same engine, with the advanced character kit integrated. The codebase is from around T3D 3.0.

It must be script related, we are growing this new game and must have done something that breaks the animation sequences client-side. But what the hell would do that?!? If animations work host-side, how are they handled any differently on the client in terms of the scripts?

It will probably end up being something obvious I'm overlooking which I will figure out eventually, but I had to ask in case anyone had seen this before.

Thanks

Hi all,

Went to test our game in multiplayer, and the player animations are all wonky.

To the host, the client appears fine - if he changes weapons or does a salute or whatever the host sees it properly.

However, client-side, the player animations are all mixed up. When the client salutes, the host sees a salute but the client sees a wave. When the client dies, he sees a celebration animation while the host correctly sees the death animation.

I don't remember this being an issue before, and am wondering what could be causing it... I have used this same build/exe in another game and it was fine, so perhaps it is just something with my scripts. We are using a port of the Advanced Character Kit which controls the fancy animations, so when the player switches guns it plays a specific animation for that weapon. Also, he has swinging arms for melee weapons. All of that is messed up on the client but fine on the host.

There must be something that is screwing it up client-side, any ideas?

Thanks

If you are looking to remove unused objects (in this case triggers) that were added through a script, just surround them with a simgroup, and then delete that simgroup when you are done with it.

Then if you need the triggers back, just re-execute the .cs script that includes them.

We use this to add/remove deck objects from our Starship Enterprise. We have each deck's contents stored in a separate .cs file, and a trigger on each deck that is tagged with which objects to load. When you go to that deck it will execute the relevant script and load in all the objects for that deck. Then when you leave the deck (exit the trigger) it deletes the simgroups that it just loaded. When you go back to the deck, we re-execute the .cs. And so on...

Yeah, Renee was definitely the guy for this back in the day... our original version of the Enterprise built in 1.1 final relied heavily on the stuff he worked to get in that release :)

That's a great thought... we actually do have the ability to launch physics blocks at each other with a block firing gun, and that already works networked without much issue, so I would keep the status quo foe that.

However, I see great potential in doing client side only physics for when the vehicles and block walls are involved, as well as other times when I have physics blocks raining from the sky...

Is it really that simple? If the physics blocks are client side, how does the server handle collision and damage detection when a client hits a physics block in those cases?

Thanks, yes I had read that before and it makes sense... In some cases I do in fact want the physics effects to be networked, so that one player could crash into a wall which would break into blocks, and those would get in the way of the following player. I tried this in my PhysX game with mixed results, it would work on a low level, but too many moving objects and one client would crap out.

I never actually did figure out how to exclude certain things, is that something that can be done in script when a physics object is loaded? During gameplay I have code that creates new physics shapes in real time, so that you have a tower or wall of TSStatic blocks that convert on-the-fly to physics objects when they are hit with a projectile. Works great, you can build a tsstatic prefab house of blocks and then explode it with a grenade :)

But I would love to know how to control which objects get networked, is that easy enough to do?

Yes, I think the portal and zone code could benefit from some TLC :) If I remove all the portals and keep the zones I don't get the crashes as much, but there are still random anomalies now and then.

However, with my new loading/unloading scheme using the triggers, everything is flying... I can run deck to deck, and the objects all pop in and out without issues. The main decks are not bound by any zones anymore, so there are no random rendering anomalies from overlapping zones or portal viewing angles.

Removing the zones and portals entirely looks like it will work fine, they are not needed anymore if I can just load one deck's contents at a time as needed. I just need to have the deck floors and walls in place at all times, and that runs fine without zones thankfully :)

Was simply a matter of taking each deck and pulling out all the objects and saving them to separate files. Then I include the appropriate file when entering the deck trigger, and delete that simgroup when i exit the trigger. In a multiplayer situation, I don't delete a deck's objects if there is currently another player still in the trigger.

So far this is working, fingers crossed.

That's kind of what we concluded before, hence why we went with PhysX... I was just holding out hope :)

Regarding our random PhysX-related lockups I mentioned, it was mostly when trying to play networked with other clients. Things got out of synch and things like racing games didn't work well networked. So I guess that's where maybe Rigids could be better?

As you say, it's a trade-off to think about I guess.

Thanks

Of course, that makes sense...

In my other game, I use the PhysX3 advanced plugin that Timmy and Andrew were working on... It's great but yes it had a few mods that had to be made to code outside the physx3 folder so it was not as benign as it could be.

I'm looking for any solution that provides good physics on objects, vehicles and players, but lets me add a lot of them to the scene and have them explode this way and that as I see fit, controlled through script. What we have with the PhysX3 plugin is good, but it still chokes out when I try to really push the amount of objects. I thought maybe your work with the RigidShapes may be something I could try to see if I can replicate the functionality I have, just with better performance and less overhead than the PhysX?

Looks great what you have there :)

Awesome :) Is this stuff in the 3.7 RC by chance? Or is it in one of your private forks?

OK, wow, I think i just solved my problem...

Just as a test, I removed all the portals and the crashes stopped. I'm guessing that when turning around to face aft, even though there are walls between me and those portals, the engine is still trying to calculate what I can see from my viewing angle as I look towards those portals.

Now, without portals the zones are kind of useless, as when looking down a staircase you now don't see the deck below until you enter the zone... and if I try to load everything in the ship without zones it will choke out and sometimes crash.

So, I came up with a solution where instead of a zone I have a trigger for each deck, and when you enter the trigger I load in all the objects for that deck. Then I remove when you go to next deck, and so on. I load the main deck models at startup, the floors walls and ceilings, just not the objects until I need them.

I can now run at a full sprint from the bridge all the way down to deck 24 in about 3 minutes with no crashing.

So, to sum up, f**k portals lol.

P

Hey all,

I'm in the process of porting some old code into 3.7 RC to test, and am having trouble figuring out a few of the changes required...

Can anyone offer any help with these errors?

*****

error C2665: 'Con::addCommand' : none of the 10 overloads could convert all the argument types

code:

void fxGuiSnooper::consoleInit()

{

Con::addCommand("fxGuiSnooper", "setOverlayBitmap", cfxGuiBitmapSetOverlayBitmap, "fxGuiSnooper.setOverlayBitmap(Bitmap)", 3, 3);

}

*****

error C2664: 'String::VToString' : cannot convert parameter 2 from 'U32 *' to 'va_list'

code:

U32 framerate = target->getActualFramerate ();

if (target->mIsSingleFrame)

line += " | [single Frame]";

else

line += " | [FPS: " + String::VToString ("%i", &framerate) + "]";

line += " (Refs: " + String::VToString ("%i", &target->mRefCount) + ")";

*****

The first error (Con::AddCommand) appears in other files as well, where old code has been integrated. 3.7 RC includes Con::AddCommand all over the place and it's fine, just my old code doesn't work. It must be something I have to include with my old code or something, or the syntax is different now, I just can't see it.

The second error I see it's because in 3.7 RC it now passes args as the second parameter for VToString, I'm just unclear on how to convert the above code to use args?

Thanks!

We are 32 bit... would love to go 64 but we use awesomium extensively and it only works in 32 bit.

I'm intrigued by your comment about placement and overlaps... how have you found is the best way to do them, and what should I try to avoid?

Also, I have never checked out occluders, is that something I should try?

Thanks :)

Looks like I'm not set up to make videos right now, my kids borrowed my webcam lol...

However I did manage to draw up this VERY crude scribble stick-man drawing that shows the issue (see attachment).

I am wondering why, when looking back and down (which is in the direction of many other zones/portals), that the engine totally chokes for a few seconds, as if it is trying to render everything that is back there, even though A) everything back there is encased by other zones, and B) there are physical walls between me and the next zone, in addition to the zone itself. Do the DAE walls not do any sort of culling at all?

Anyhow, sorry for the crudeness of the drawing, but it will give you an idea.

Thanks again!

hand drawing of ship layout with zone anomalies

Thanks Jeff...

Sure, I could try and make a video, but it wouldn't really show much.

Basically, when I take the stairs down from the bridge to deck 2, I am transitioning from one zone to another. When I do so, I can see the deck2 stuff pop in as it should, and 20% of the time it will be fine. But other times, just because of the particular direction or angle I am facing perhaps, I immediately get the crash popup "NCC1701-3D has stopped working", with no noticeable errors in the console.log.

Tried to debug this using a debug build, but that has never worked well for me... It points me to generic spots in the code that could be being called from anywhere. It's really hard to trace line by line exactly where it is having a problem.

The only thing in console.log that I have noticed, which did not seem to appear in our 3.0 version or prior, is various shader compiler errors. I get a lot of "cannot compile shader, out of memory" errors as I move through the ship. It doesn't crash immediately after those errors, but they are there a few dozen lines before each crash in console.log.

Have made sure I have latest shader code, latest engine code, and latest game/core code. The only thing that is saved from our old 3.0 is all the scripts, because they were so heavily customized. Would not want to have to try and merge our custom scripts into the latest scripts, unless absolutely necessary for some reason.

Are there any known issues with the zones, or guidelines as to best practices? I'm wondering what the deal is with whether they can overlap or not, how that impacts things, and if the zone does not completely encapsulate everything (ie. if it is off by a few points in vertical scale, so the ceiling/floor above intermittently appears/disappears based on viewing angle) does that cause problems?

Also, if I am on the bridge and turn around to face the rear of the ship (where there are many objects hidden within variouos zones) the engine totally chugs for a few seconds when facing that direction. But there is a wall between me and the rest of the ship, as well as the fact that the bridge is a self-contained zone, so why would facing the rear be any more taxing than facing the front, unless it is somehow still rendering that stuff even if I am in a zone. There are also a lot of portals back there, which open up the view to even more zones, and it looks as if the walls of the ship are not blocking my "view" through those portals. Which doesn't make sense - shouldn't a DAE object, like a set of walls, act as a culling block or something? It shouldn't be trying to render stuff behind that that I can't see, right?

Hello all,

First time posting at this new forum, have been a long time user of the garagegames.com forums/resources... Great to see so much action here!

Anyhow, I am having some issues lately with the new Torque versions, and I'm hoping somebody can shed some light for me...

In a nutshell, we have built the complete Star Trek original series Enterprise in T3D, and we give it away for free on our web site for fans. It was originally created in T3D 1.1B3, then migrated up to 1.1 Final, and a year or two ago we migrated again to 3.0 in order to integrate Oculus Rift support. Things were more or less fine, and the current download of the game is using that 3.0 build without any major issues.

However, now I am trying to bring the code up to the latest version 3.6, to take advantage of the new features. Was able to merge everything together (an arduous task because we also use AFX and many other mods/resources), and it compiles and runs, but whenever I switch zones in the ship by moving from one deck to another, the game will crash 80% of the time when transitioning zones.

The zones were never an issue before, we need them because the ship is so big and so full of stuff that the engine will crash on load if we do not zone the decks. But now they seem to be causing problems.

Cannot 100% confirm it is the zones, because we also integrated the old Male Advanced Character kit into our project, which required some porting and hacking to make it work with a newer version of T3d than it was ever intended for. So it could be something with that engine code that is messing things up... But our characters all animate properly and look great and have the melee functionality, so I'd like to think the ACK is working fine.

My question about the zones is this: Is there an optimal way to use them? We currently have large horizontal zones, one per deck, for 24 decks. Each zone encapsulates the entire deck's width and height, so that only the deck floor/walls of the current zone are visible at any one time. Sometimes they are not perfect and the entire deck/walls do not disappear, but everything within does. I have been tweaking the zones to try and get them all to fully make their deck disappear when not inside, but this is not always possible because of the close proximity of each zone one on top of the other. I am trying to avoid zone overlap.

Have placed portals at all staircases and elevator shafts, etc, so you can see through to the next zone, and am very happy with how it is all laid out, but I'm just wondering if having 24 zones stacked on top of each other is maybe not the best way. Would it be better to have fewer zones, say one for the saucer section, one for the neck, and one for the lower hull? To give the engine a break in terms of calculating zone contents visibility all the time?

Just looking for some help/ideas, because at this time we are stuck with our old 3.0 version and I would really like to bring it up to date and be able to walk the whole ship again.

Thanks in advance!

Paul

OK, that's cool... Do I take this to mean you have achieved near-PhysX like reaction of RigidShapes? Because that looks like a PhysX build there :)

Would love to give this a try - I have a PhysX game that is being finnicky and I wanted to maybe rewrite it a bit to use RigidShapes instead, but the stock RigidShape was too clunky and not as smooth as PhysX when I tried originally, that's why we went with PhysX.

But if the same can now be done with only RigidShapes, would love to test that out!

Thanks