FreeBuild Project continues under Torque 3D
» > >
» Goto page Previous  1, 2, 3, 4 ... 15, 16, 17  Next
» View previous topic :: View next topic  
KermMartian wrote:
(1) Player model

Aren't we supposed to use the LDraw player model?
KermMartian wrote:
Well, it seems to me that the major pieces of content are:

(1) Player model
(2) Bricks

SpaceNinja is right on with this one. Bricks, player models, and vehicles pretty much all go together, with some skeletal animation code/brick grouping code to build larger single-object models from smaller components.
<- Please Support on Lego Ideas
So in other words, we're basically keeping no object content from TBG/Freebuild other than the map objects?
Geopipe
KermMartian wrote:
So in other words, we're basically keeping no object content from TBG/Freebuild other than the map objects?

Well, no object content from Blockland/TBM. Freebuild has very few of its very own models (except for a few weapons I made).

[edit]

Rather than going straight to gameplay porting, I'm merging my original work on the LDraw parser for stock TGE 1.5.2, and the improvements I made when I ported it to OSG friendly code, to try and get LDraw rendering up and running off the bat.
<- Please Support on Lego Ideas
As far as I can tell, everything is set for me to start working on rendering.

I appear to have successfully parsed a 1/3 MB LDraw model in a fraction of a second. We'll see how the performance is when it comes time to render, but BrickSmith is not a happy camper when faced with it.

Quote:
==>echo(testLDrawParseFile("blockade_runner.mpd"));
caching MPD file lego10019.ldr

Caching MPD subfile lego10019.ldr
Cached lego10019.ldr, used 110 tokens
caching MPD file lego10019a.ldr

Caching MPD subfile lego10019a.ldr
Cached lego10019a.ldr, used 2931 tokens
caching MPD file lego10019a1.ldr

Caching MPD subfile lego10019a1.ldr
Cached lego10019a1.ldr, used 303 tokens
caching MPD file lego10019a2.ldr

Caching MPD subfile lego10019a2.ldr
Cached lego10019a2.ldr, used 303 tokens
caching MPD file lego10019a3l.ldr

Caching MPD subfile lego10019a3l.ldr
MPD subfile lego10019a3l.ldr is large, increasing cache to 32768 tokens
Cached lego10019a3l.ldr, used 19611 tokens
caching MPD file lego10019a3r.ldr

Caching MPD subfile lego10019a3r.ldr
MPD subfile lego10019a3r.ldr is large, increasing cache to 32768 tokens
Cached lego10019a3r.ldr, used 19611 tokens
caching MPD file lego10019a3al.ldr

Caching MPD subfile lego10019a3al.ldr
Cached lego10019a3al.ldr, used 89 tokens
caching MPD file lego10019a3ar.ldr

Caching MPD subfile lego10019a3ar.ldr
Cached lego10019a3ar.ldr, used 89 tokens
caching MPD file lego10019a3bl.ldr

Caching MPD subfile lego10019a3bl.ldr
Cached lego10019a3bl.ldr, used 89 tokens
caching MPD file lego10019a3br.ldr

Caching MPD subfile lego10019a3br.ldr
Cached lego10019a3br.ldr, used 89 tokens
caching MPD file lego10019a3c.ldr

Caching MPD subfile lego10019a3c.ldr
Cached lego10019a3c.ldr, used 89 tokens
caching MPD file lego10019a3d.ldr

Caching MPD subfile lego10019a3d.ldr
Cached lego10019a3d.ldr, used 89 tokens
caching MPD file lego10019a3e.ldr

Caching MPD subfile lego10019a3e.ldr
Cached lego10019a3e.ldr, used 89 tokens
caching MPD file lego10019a3f.ldr

Caching MPD subfile lego10019a3f.ldr
Cached lego10019a3f.ldr, used 89 tokens
caching MPD file lego10019a3g.ldr

Caching MPD subfile lego10019a3g.ldr
Cached lego10019a3g.ldr, used 89 tokens
caching MPD file lego10019a3s1l.ldr

Caching MPD subfile lego10019a3s1l.ldr
Cached lego10019a3s1l.ldr, used 214 tokens
caching MPD file lego10019a3s1r.ldr

Caching MPD subfile lego10019a3s1r.ldr
Cached lego10019a3s1r.ldr, used 214 tokens
caching MPD file lego10019a3s2l.ldr

Caching MPD subfile lego10019a3s2l.ldr
Cached lego10019a3s2l.ldr, used 118 tokens
caching MPD file lego10019a3s2r.ldr

Caching MPD subfile lego10019a3s2r.ldr
Cached lego10019a3s2r.ldr, used 118 tokens
caching MPD file lego10019a3s3.ldr

Caching MPD subfile lego10019a3s3.ldr
Cached lego10019a3s3.ldr, used 102 tokens
caching MPD file lego10019b.ldr

Caching MPD subfile lego10019b.ldr
Cached lego10019b.ldr, used 5505 tokens
caching MPD file lego10019b1.ldr

Caching MPD subfile lego10019b1.ldr
Cached lego10019b1.ldr, used 332 tokens
caching MPD file lego10019b2.ldr

Caching MPD subfile lego10019b2.ldr
Cached lego10019b2.ldr, used 332 tokens
caching MPD file lego10019b3.ldr

Caching MPD subfile lego10019b3.ldr
Cached lego10019b3.ldr, used 415 tokens
caching MPD file lego10019b4.ldr

Caching MPD subfile lego10019b4.ldr
Cached lego10019b4.ldr, used 417 tokens
caching MPD file lego10019b5.ldr

Caching MPD subfile lego10019b5.ldr
Cached lego10019b5.ldr, used 137 tokens
caching MPD file lego10019b6.ldr

Caching MPD subfile lego10019b6.ldr
Cached lego10019b6.ldr, used 728 tokens
caching MPD file lego10019b7.ldr

Caching MPD subfile lego10019b7.ldr
Cached lego10019b7.ldr, used 70 tokens
caching MPD file lego10019b8.ldr

Caching MPD subfile lego10019b8.ldr
Cached lego10019b8.ldr, used 70 tokens
caching MPD file lego10019b9.ldr

Caching MPD subfile lego10019b9.ldr
Cached lego10019b9.ldr, used 418 tokens
caching MPD file lego10019b10.ldr

Caching MPD subfile lego10019b10.ldr
Cached lego10019b10.ldr, used 418 tokens
caching MPD file lego10019b11.ldr

Caching MPD subfile lego10019b11.ldr
Cached lego10019b11.ldr, used 121 tokens
caching MPD file lego10019b11a.ldr

Caching MPD subfile lego10019b11a.ldr
Cached lego10019b11a.ldr, used 86 tokens
caching MPD file lego10019c.ldr

Caching MPD subfile lego10019c.ldr
Cached lego10019c.ldr, used 4166 tokens
caching MPD file lego10019c1.ldr

Caching MPD subfile lego10019c1.ldr
Cached lego10019c1.ldr, used 188 tokens
caching MPD file lego10019c2.ldr

Caching MPD subfile lego10019c2.ldr
Cached lego10019c2.ldr, used 188 tokens
caching MPD file lego10019c3a.ldr

Caching MPD subfile lego10019c3a.ldr
Cached lego10019c3a.ldr, used 838 tokens
caching MPD file lego10019c3b.ldr

Caching MPD subfile lego10019c3b.ldr
Cached lego10019c3b.ldr, used 838 tokens
caching MPD file lego10019c3s.ldr

Caching MPD subfile lego10019c3s.ldr
Cached lego10019c3s.ldr, used 70 tokens
caching MPD file lego10019c3c.ldr

Caching MPD subfile lego10019c3c.ldr
Cached lego10019c3c.ldr, used 838 tokens
caching MPD file lego10019c3d.ldr

Caching MPD subfile lego10019c3d.ldr
Cached lego10019c3d.ldr, used 838 tokens
caching MPD file lego10019c4.ldr

Caching MPD subfile lego10019c4.ldr
Cached lego10019c4.ldr, used 607 tokens
caching MPD file lego10019z.ldr

Caching MPD subfile lego10019z.ldr
Cached lego10019z.ldr, used 156 tokens
caching MPD file lego10019z1.ldr

Caching MPD subfile lego10019z1.ldr
Cached lego10019z1.ldr, used 86 tokens
caching MPD file lego10019z1a.ldr

Caching MPD subfile lego10019z1a.ldr
Cached lego10019z1a.ldr, used 156 tokens
caching MPD file 30504.dat

Caching MPD subfile 30504.dat
Cached 30504.dat, used 1589 tokens
caching MPD file 2515.dat

Caching MPD subfile 2515.dat
Cached 2515.dat, used 1204 tokens
caching MPD file box45-2t.dat

Caching MPD subfile box45-2t.dat
Cached box45-2t.dat, used 109 tokens
caching MPD file s\2515s01.dat

Caching MPD subfile s\2515s01.dat
Cached s\2515s01.dat, used 2024 tokens
<- Please Support on Lego Ideas
Sweetness, can't wait to see this being used, in game. That looks to be a rather impressively sized model.

On a side note have you thought about how you want to handle bricks that are not part of LDraws base set? Will you have a way for users to dl them from the server and have the server dictate what bricks are allowed and similar?

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
TheStorm wrote:
Sweetness, can't wait to see this being used, in game. That looks to be a rather impressively sized model.

Ditto, I have a complement of large (you remember those $300+ LEGO collector models?) star wars vessels to use as test subjects.


TheStorm wrote:
On a side note have you thought about how you want to handle bricks that are not part of LDraws base set? Will you have a way for users to dl them from the server and have the server dictate what bricks are allowed and similar?

Obviously the server's brickset will have to be compared against the local computer, and any bricks that differ/are not present will have to be locally cached while connected to that server. I'll add an option to allow only temporary caching, or to bring the bricks into the main library. The more interesting question is setting up the directory search precedences in a user configurable manner, rather than the hard-coded yuckiness I have now, and appropriately scoping mpd models that use the same sub-model names instead of a global cache.

The most interesting question of course will be implementing primitive substitutions (to reduce poly-count), and model merging to create vehicles/player models.
<- Please Support on Lego Ideas
I can imagine permanent storing of cached server objects being abused, for instance, if someone were to fill their ldraw directory with phallic shapes of varying sizes...
DShiznit wrote:
I can imagine permanent storing of cached server objects being abused, for instance, if someone were to fill their ldraw directory with phallic shapes of varying sizes...


The caching wouldn't be permanent or in the main LDraw directory unless the user specifically chose to trust the server they were connecting to.
<- Please Support on Lego Ideas
That makes sense. But you could choose to store cached bricks after connecting to an untrusted server?
DShiznit wrote:
That makes sense. But you could choose to store cached bricks after connecting to an untrusted server?

Yes, but it wouldn't happen by default. Last night I documented everything that needs to be implemented on the LDraw side of things, including the brick/model search tree (and the priorities assigned to each search directory) and caching (both in memory, and on disk when connecting to other servers), as well as the mechanism by which a client/server pair determine when the server library doesn't match the local library and whether bricks will need to be synced.
<- Please Support on Lego Ideas
What if I decide to modify an existing ldraw component. How would the system handle that, or would it just be better to save the modified component as a new brick?

And what if a connected client has a really cool iGob made with parts the server doesn't have? A dialog asking the host if s/he'd like to cache the clients' parts?
DShiznit wrote:
What if I decide to modify an existing ldraw component. How would the system handle that, or would it just be better to save the modified component as a new brick?

And what if a connected client has a really cool iGob made with parts the server doesn't have? A dialog asking the host if s/he'd like to cache the clients' parts?
For the first part, it would have to be a new brick.

On the second one, that dialog wouldn't work for dedi's, my vote would just be to have the server decide at launch. Trying to have the server grab bricks from the client and then propagate them to the other clients is just asking for trouble. Brick should be able to go from server to client if needed but I'd rather not the other way around, its just to insecure and creates more issues than its worth. It will be up to the server admin on what brick sets they allow and want to be available to the users.

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
Oh security issues would be nightmarish, no question. I was just wondering if that option could be available for those who are willing to take the risk.
I'd say its just to risky period, and adds a huge amount of overhead and extra code. Its up to elf and swivel but I don't see a reason for them to enable any sort of uploading to the server other that to support the LDraw model system.

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
TheStorm wrote:
DShiznit wrote:
What if I decide to modify an existing ldraw component. How would the system handle that, or would it just be better to save the modified component as a new brick?
For the first part, it would have to be a new brick.

If it was being temporarily cached as server side data only, it really wouldn't matter. I'd recommend against modifying existing components and saving them with the same name though. There's no reason you can't do your own modeling - just save it with a non-colliding name. In the event that the user did want to save your update and use it in later models, it would be put aside in a part-store with higher priority than the official parts library, but would not overwrite the original files.


DShiznit wrote:
And what if a connected client has a really cool iGob made with parts the server doesn't have? A dialog asking the host if s/he'd like to cache the clients' parts?

Henceforth lets refer to "iGobs" in terms of "models" and submodels, since they'll be in an LDraw model format, and they are no longer associated with Gobbles.

TheStorm wrote:
On the second one, that dialog wouldn't work for dedi's, my vote would just be to have the server decide at launch. Trying to have the server grab bricks from the client and then propagate them to the other clients is just asking for trouble. Brick should be able to go from server to client if needed but I'd rather not the other way around, its just to insecure and creates more issues than its worth. It will be up to the server admin on what brick sets they allow and want to be available to the users.

As far as this go, client->server->client shouldn't be terrible. Receiving clients still do cache-only by default, with the option to save. A server could relatively easily be given the same options. It seems like it would make sense to display a warning to the user that their model might not display correctly (most LDraw modeling programs do this currently if you're missing pieces), but that they can request permission to transfer missing parts. If a super is unavailable to grant permission, then they would be unable to do so.

One thing that IS a good idea as far as security goes is to make sure that LDraw data stores are sandboxed independently of the game installation to prevent script files from being downloaded and executed.
<- Please Support on Lego Ideas
DShiznit wrote:
And what if a connected client has a really cool iGob made with parts the server doesn't have? A dialog asking the host if s/he'd like to cache the clients' parts?


Ah. Update.

A better way to handle this would be to just pack any unmatching files into an .mpd.
<- Please Support on Lego Ideas
Sounds great! I should note that right now Thomas is obsessing about not being able to run Freebuild on his girlfriend's computer, and is in fact postponing lunch in order to continue to try to solve the problems. Smile
Geopipe
Update
Eric has sent me an email clarifying that the demo editor shouldn't be distributed with FreeBuild, but is still freely available for download from the GarageGames website. This just means a little extra work for you in going to download it - no changes as far as what you can use it for.
<- Please Support on Lego Ideas
Sounds good. Will the demo editor come with it's own hardware requirements or will it scale to whatever Freebuild can use?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
FreeBuild Project continues under Torque 3D
» Goto page Previous  1, 2, 3, 4 ... 15, 16, 17  Next
» View previous topic :: View next topic  
Page 3 of 17
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement