Jump to content


  • Posts

  • Joined

  • Last visited

Tiel's Achievements

  1. I don't think there's a property for ScatterSky that lets you render a bottom half to it. If you were to use the Skybox class instead, that does let you specify a cubemap and get a complete surrounding sky without the whitespace, but at the expense of the cool features scattersky has like the day/night cycle. What you could do is hide it, which will help in other ways too (nothing's more jarring than running into the edge of the world!) The first is elevation. If you make the terrain itself higher on the Z Axis, the corners of the scattersky become a lot less apparent from the ground. http://imageshack.com/a/img922/5391/4tR62V.png http://imageshack.com/a/img924/3849/muSwvR.png Also in this level there is a lot of terrain variation (default Outpost.mis). If there are hills blocking the whitespace, not only do you hide it but you also have a legit reason to prevent people from going to the edges and looking out into the abyss. Outpost is pretty big, only a small part of it is playable, the rest is just window dressing so it looks and feels like you're in the middle of something. Window dressing. http://imageshack.com/a/img923/695/LbGjRU.png With intervening terrain, height, and designing the level in your favor, the last thing you can do to make it less obvious is adding fog to the level. I think even if you went to the edge of outpost you can barely see the black (or yellow I guess) just because it's fogged out and blends well. http://imageshack.com/a/img924/7741/ZPRXh6.png There's also a waterPlane, which extends forever and does a lot to obscure it. Not always practical though. Honestly if you ask me your best bet is to design maps in a way that there's always something obscuring the blank space, like steep cliffs or mountains in the horizon, and raising your level enough that players can't see the edges of the umbrella from the highest point. Alternatively, Skybox is always an option if you want to sacrifice some options.
  2. When telling a client.camera to orbitobject around a serverside object, it will work as expected. Perfect! http://imageshack.com/a/img923/2739/LnrQvS.gif However, upon newtonMode=true; While the camera will perform smoothly on a localclient connection, http://imageshack.com/a/img923/2442/fRgrEO.gif any clients attempting to connect through gameconnection means will have a positively jerky experience. http://imageshack.com/a/img924/7886/3XSXhS.gif The camera will function fine in newtonmode as long as it's not tracking a moving serverside object. I'm convinced it's a networking issue given the circumstances but I don't know how to go about fixing it. Help pl0x? PS: Running T3D 3.10
  3. Tiel

    Not clear on x64

    Hello! I've read the article on the wiki regarding compiling a 64 bit build of T3D, but not entirely clear on a couple of items on this list. Firstly, "go into the DLL project, and remove the asm files from platform/ and math/. They are not currently compatible with a 64bit environment." Does this mean functionality available in x86 on the TS side of things will not be in the finished product? Secondly, "Any additional plugins such as physics will need to have the appropriate 64-bit includes and libs as well." So I've been told I'm not the smartest guy on the block :lol: What I do gather is that there are libraries that certain addons rely on that are only present in the distributed version of T3D's source in their 32 bit form. Plugins are the options available when doing the compilation in CMAKE? (Like Bullet, etc, memory's a bit foggy and away from computer for a couple of days) So hypothetically if I weren't selecting any of those options I wouldn't have to worry about anything? I presume C++ resources available throughout the web would be in good working order *unless* they had includes in their code to the defunct libs?
  4. When you set up a multiplayer server, I understand there's a dissonance between what's on the server vs the client. Correct me if I'm wrong, but on connect, a client has objects in the game world 'ghosted' to them, is the word. Following that any game logic should be on the server. Because if you do, say function serverCmdassignproperty(%thing) { %thing.juice="tampa"; } A client attempting to access %thing.juice without calling a server command will not be able to retrieve the string "yes" and Torque throws a warning, at least in my tests. This seems safe enough...or is it? Are there any circumstances where a client would be able to get %thing.juice without invoking a commandtoserver? Is there anything that should be done further to ensure .juice stays out of the wrong hands?
  5. Okay, that seemed to please it. Although, if I might go offtopic, I've also been trying to get this guy to work: http://www.garagegames.com/community/forums/viewthread/107847 // If we're mounted to them, don't give them anything! ShapeBase* obj = this; while(obj->getObjectMount()) if((SceneObject*)obj->getObjectMount() == convex->getObject()) return; else obj = obj->getObjectMount(); This displeases the compiler: error C2440: '=' : cannot convert from 'SceneObject *' to 'ShapeBase *' What I'm trying to do is mount staticshapes to an AIPlayer but it sounds like the collision's immobilizing them.
  6. A resource I'm trying to port has the lines // projected point mPtScreen = mPtProj; // alignment offset mPtScreen += offsetAlign; // screen offset mPtScreen += mOffsetScreen; // setTrgPosition(mPtScreen); mBounds.point=mPtScreen; Problem being mBounds is private as of a few years ago. I'm not even going to pretend I'm comfortable with C++, but from what I've gathered this last line is to set the position of the control via mBounds.point (which is the topleftcorner of a ctrl to the best of my knowledge, forgive my ignorance). So getExtent() or getBounds, the replacement for retrieving extents with mBounds, wouldn't exactly work here, as those are functions that return a value, not the other way around. Getting to the point, is there a replacement for mBounds.point?
  7. Thanks for your thoughts, I was never able to get shapenameHUD working, it's reluctant to function when set up like so What I'm working with is http://imageshack.com/a/img924/6854/I6LWgT.png I'm not certain it's possible to get similar results with shapeNameHUD - also there's a lot going on in the gamespace and not sure how to make the control discriminate objects.
  8. I'm looking for a way to have a billboard always face the screen, not just the camera position in the world. This is to put a kind of 3D text above certain objects-kinda like waypoints but editable (is there a term for this?). What I have now works well enough, just not supergood with the BBs presenting themselves at an angle to adjust to the camera. I think the only alternative would be to have hidden textctrls on playgui and schedule them to update when a special object is in view, though that seems less than ideal. Greatly appreciate any input here
  9. Ah, yes, got it. I went ahead and just stripped all the art and a good deal of script files from full and put my own stuff in, good to go. Though with DX11 enabled in the project @ CMAKE there are a few strange artifacts. http://imageshack.com/a/img922/4065/52naUn.png (this is a guiobjectview with a model of an earth like planet with normals and specular. Or it would be, anyway, heh) Went into options, there's a handy dropdown to switch the GPU over to D3D11, but restarting yields failed to compile shader: C:\Users\cocka\Desktop\Torque3D-development\My Projects\Void\Null\game\shaders\procedural\5004b9ce_P.hlsl(52,23): error X3086: the 'sampler2D' keyword is deprecated in strict mode; use 'SamplerState' instead C:\Users\cocka\Desktop\Torque3D-development\Engine\source\gfx\D3D11\gfxD3D11Shader.cpp(924,0): {Fatal-ISV} - Unable to compile shader! I am lost haha, should I create a thread for this?
  10. Forgive my ignorance, but is calef's fix still applicable then? I'm trying to compile what's in the development branch right now with dx11 and running into the same issue when attempting to load an existing project.
  11. That would be incredibly useful. The transition to DAE support invited tons of new pipelines but the documentation never caught up.
  12. Is that true? Man, I'm actually half decent in C#, guess I've just never had a reason to prefix numbers in variables before until torque's skin tutorial. Whelp, you live to learn.
  13. good god you are completely and utterly right, feeling pretty dumb. Thank you for taking the time to enlighten this ignorant fool. Though, gotta say, wish this were annotated somewhere.
  14. but whyyy dad like I'd wanted to use the skinning system with such materials, but those have to be a prefix, no?
  • Create New...