Create Native Entity Tools

Started by wallworm, May 08, 2013, 10:34:00 AM

Previous topic - Next topic

wallworm

As many of you know, WW has limited capabilities to create entities. Many WW functions will automatically generate entities for VMF export time (such as exporting proxies and WWMT helpers as prop_static, etc). But to generate all the more complex entities for Source in Max, you currently need Convexity.

Unfortunately, as it stands, development on Convexity is at a standstill. Worse, the entity functions in Convexity currently crash Max 2014. Since I have already moved my own projects to 2014 and need entities, I have started the ground work for entity creation in WW. Stay tuned for updates.

Neil

Whoa! This is absolutely incredible  :D Thanks man!

If I recall your other post, you mentioned that Convexity might get an update (although you were still unsure). Would this still happen if they do release an update? Probably not but just wondering. Forgive my silly questions  :)

wallworm

I do have word that the developer of Convexity is looking into the problems with Max 2014. But there is no ETA.

So I have already finished building entity functions in WW. I'm testing them now and will release them later this week. The main thing is keeping backward compatibility with all the things I've built so far in WW. But in my tests, all things are exporting well. Anyone who wants to test is free to ask for a beta... but since this is completely new territory for me, I can't promise stability yet... I think it's good to go but still testing.

Neil

I have a couple hundred models that still need exporting lol... I've been too lazy to export them one by one so I've been holding off on Source mapping for a while. I can test a couple of models and see if they export if you need any testers.

wallworm

If they are all in separate files, you'll have to wait for me to write a batch tool... but if in one file then you can use WW to send them all out at once.

In terms of this thread, I have now completed the integration of entities into WW. I will likely load it in a couple days after I've done some more experimentation. What is cool is that Entity I/O is now completely handled per entity in the Max UI like any other native Max object. I finally started learning how to implement MAXScript Custom Attributes... oh how I wish I had learned about them when I started building Wall Worm... it would all be a lot easier to maintain and improve.

Anyway... the new WW is coming soon.

Neil

At this rate, I will never have to open up that buggy Hammer Editor ever again! How awesome this whole thing is. There are thousands upon thousands of props and environments on TurboSquid and elsewhere on the internet. Heck, I can even design maps on UDK and export it to 3ds max, and then export from Max to Source with WWMT.

And Jesus, all this is free too :) I feel like you should start making lite and pro editions of WWMT (you're going to disagree, I know). Lite is free, and for pro, you can charge a small amount of money. I honestly think you should because you put so much effort into this, and thus should be rewarded financially.

Would I be able to compile and test a map right off Wall Worm (without Convexity)? If all the models export (which they do currently), and you have custom entity attributes with MSCustAttribDef instances, you can export them all to a VMF keyvalue file fairly easily. Back when I was screwing around with the Source SDK, I used to write tutorials on how to hack in new features into an "antiquated" engine (EDIT: I use that term loosely-- the Source engine is quite powerful). Around that time, I learned a lot about the actual dynamic runtime process of entity generation, where I applied similar concepts to a game whose source code I did not possess and ended up adding an entire scripting engine which could network video across clients (the least of it). Moreover, during all that time, I messed around a lot with keyvalue systems, both SQL database KVs and file-based Valve KVs, and ended up writing a KV parser if you want it. The actual structure of the Valve KV is fairly simple, so given a bunch of entity attributes, it's somewhat easy to export a VMF and send it to the compiler for compilation.

wallworm

It would be more effort than it's worth. I'd get a few people to pay but not enough to merit a distinction. I'm pretty sure about this from a decade+ of experience in software development.

If anything, I may make a "premium" section to the forums that only premium users get access to... where I will answer questions in a timely fashion.

In terms of an Indie game... I would be interested in a spin on either Battlefield 2142 or Hidden:Source. Both games really interest me in their originality and gameplay... and I'd consider developing offshoot ideas.

As for a KV parser... if you have the time to help develop a generic .NET OR MAXScript implementation for reading/writing I'd be very interested. I've already written specific case parsers for reading FGD and writing VMF... but a generic KV parser/writer is something I'd like. Hit me up if you could contribute.

wallworm


Neil

Hidden:Source's concept seems too much like Crysis IMO... If we do decide to work on an indie game, I have at least 2 friends (experienced mappers) who would love to join. I'll be thinking of some golden ideas in the meanwhile. Add me on Steam please when you have the time :)

And sure, I would love to help with the KV parser. It's coded in c++, so converting the parser to .NET should be trivial, but remember that would create a dependence on Windows (since .NET is for Windows... unless you compile with Mono or something). If you want your code to be cross-platform, stick to native c++ and the Max SDK. I haven't really gotten into the Max SDK yet, but there are a bunch of samples. This sample explains how to use custom attributes, so perhaps one can just loop through all the entities' attributes and export to a VMF. A slower (but better) generic idea would be to create a c++ MaxScript extension that wraps the parser; then one can read/write VMF, VMT, and other Valve KV files from MaxScript without having to sacrifice speed. That way, you get full control of what to do with the parser in MaxScript, and since the parser's core will be compiled c++ code, the speed will be significantly faster than equivalent MaxScript code.

wallworm

I'll add you on Steam soon.

Regarding the custom attributes... I took time to learn and use them in this latest release. The new entity functions utilize them. And WW already has a VMF exporter ... which now includes the internal entities (and actually has exported Convexity-generated entities for quite a while).

The main challenge is a generic KV class. Whether in C++ or C# or other really doesn't matter to me personally so long as there is a hook for WW. That .NET is tied to Windows is also not really a concern of mine personally... as I only use Windows and 3ds Max only runs on Windows (A large aspect of the internal functions in Max are all .NET... so as long as all of my focus is in Max that is really a non issue--and I am so passionate about Max that it's unlikely to change ever).

ANyway, a generic KV class would make it easier to work with any arbitrary "new" format Valve decides to do things (like making a DMX exporter). I have not even bothered looking at DMX support in the exporters yet because of a reputable source who explained that the development of the DMX spec is currently in flux. But I may look into that if/when it seems necessary or advantageous--and again a generic KV class would help. I did tip my toe into some freely available KV projects in C++/C# last year but didn't have the time to really delve into it.

Neil

You are basically asking for a LL(1) stack parser or some kind of pushdown automaton. Such automata are generally preferred for block code analysis over simpler finite state machine algorithms. That is the best you can do for unanticipated code and "forward" compatibility. Moreover, if coded properly, automatons can lexically analyze data pretty quickly. I haven't written a KV parsing automaton, but I'll see what I can do for a "generic" parsing class when I have time. Currently taking summer classes for school, so I don't have too much time.

Take note, generic automata-based classes/functions usually involve much more "setting up" on the end of the programmer. If I were to code a KV parsing automaton, you'd end up writing many maxscript definition tables which may not be too fun to set up :) However, once set up, it's definitely much easier to maintain.

For our route, however, I think a binary tree tokenizing algorithm is much more efficient (in terms of speed) than some kind of generic future-compatible automaton. Thinking logically, the DMX system (KeyValues2) is unlikely to be radically different from KeyValues1. Therefore, I think we should prioritize on speed instead of future compatibility.

onur89tr

I making a prop_door_rotating but it's not saving spawnflags. It's printing file "spawnflags" "formattedPrint()" to VMF map file. It can be develop more.

wallworm

Thanks for reporting. I'll fix it.

wallworm

So I just did tests and spawnflags worked as expected here. You'll need to send me a Max scene with the entity (and nothing else) to test if there is something wrong with the object itself.

onur89tr

Quote from: wallworm on January 20, 2016, 09:58:27 PM
So I just did tests and spawnflags worked as expected here. You'll need to send me a Max scene with the entity (and nothing else) to test if there is something wrong with the object itself.
I clicked Append to Current, but it's only applying spawn flags to proxies.

SMF spam blocked by CleanTalk