Reply With QuoteThank you BazookaBear. Glad we inspired you. We will keep you all updated, so stay tuned!
I was reading the FM stats thread and I saw that people were speculating that FMEditor would bring some fresh blood. Well, The announcement definitely motivated me to begin writing and planning my first FM(s). I'm eagerly waiting for updates on this. Keep up the amazing work guys!
Thank you BazookaBear. Glad we inspired you. We will keep you all updated, so stay tuned!
Hi FolksOur very first developer update is now here!!!
Book your time, sit down and have a look on our work-in-progress editor in this 0,5h video:
Waiting for your comments/questions/feedback!
Konrad (me) & Juliusz (PinkDot)
Looks pretty rad, I gotta say. I never played with DromEd, but I might crack this one open when it's done.
Reminds me a lot of the old UnrealEd that shipped with Unreal and UT99, but with some more modern features.
This already looks too great! Looking forward to see how you do portalization and lightmapping passes - you can probably find some inspiration in the gtkradiant project - I remember being able to get the basic CSG concepts from that project when I tried doing a map compiler in perl aeons ago.
Do you guys have all the remaining data structures mapped out? PHYS chunk? I have some notes still on that if you'd like to have those.
Btw - Konrad - are you by any chance the dude that approached me a time ago on the openDarkEngine project? His name was also Konrad.
Thanks - portalization and lightmapping is still far ahead - in the first phase we'll rely on Dromed for processing the missions files.
Not all of them yet. For the reason mentioned above, physics chunks have not been fully reverse engineered yet. I'd be definitely happy to take any notes you might have!Do you guys have all the remaining data structures mapped out? PHYS chunk? I have some notes still on that if you'd like to have those.
Right now I'm finalizing the Objects System - getting every data structure correct down to every single byte is a bit of a pain now - I mean very tedious task. Especially dealing with Thief 1 and 2, where structs have changed, but not the versions of chunks. Very sloppy, LGS - if you read me - very sloppy...
Not going to answer for Konrad, but I have also approached you millenias ago - back in 2012, I think. I've been asking for WorldRep format, when I was writing my import script for 3dsmax. That kinda slowly started the process, so in a way, you have your contribution to this project, too!Btw - Konrad - are you by any chance the dude that approached me a time ago on the openDarkEngine project? His name was also Konrad.
Last edited by PinkDot; 11th May 2021 at 13:43.
No problem! You might've already seen this file as it is in the repo, but this should be most of what I was able to decypher https://github.com/volca02/openDarkE...EM/readphs.cpp There's still work to be done, notably around Phys contacts. What further complicates things for you is that this thing is generated not only from the object system, but also from the models - so you'll probably have to implement, at least rudimentary, support of loading BIN files (and probably .CAL files as well).Originally Posted by PinkDot
That's not a simple task. Especially some details around ACT/REACT as I remember were problematic.
Right now I'm finalizing the Objects System - getting every data structure correct down to every single byte is a bit of a pain now - I mean very tedious task. Especially dealing with Thief 1 and 2, where structs have changed, but not the versions of chunks. Very sloppy, LGS - if you read me - very sloppy...
Oh yes, I remember you! Glad you kept working on projects around Dark Engine.Not going to answer for Konrad, but I have also approached you millenias ago - back in 2012, I think. I've been asking for WorldRep format, when I was writing my import script for 3dsmax. That kinda slowly started the process, so in a way, you have your contribution to this project, too!
I hope at least my WorldRep work finds a way to be useful, but frankly in a few months we can get big parts of the dark engine source code from the NightDive guys (at least that's what has been promised) - so your work should get a tad easier then (but I hope it will spark new projects). Crossing fingers.
Thanks for the link - I'll have a deeper dive into it, when time comes.
Ah, yeah - we'll be obviously loading .bin files entirely for the editor anyway, so this should be covered, when it comes to building physics related chunks.What further complicates things for you is that this thing is generated not only from the object system, but also from the models - so you'll probably have to implement, at least rudimentary, support of loading BIN files (and probably .CAL files as well).
Oh, yes - parts of the structs are dynamic - I had to do some extra gymnastics to get it working. Now my focus is to get all the structs supported from all 3 games and their versions (NewDark or OldDark). This is just very... unattractive part of the project, so to speak.That's not a simple task. Especially some details around ACT/REACT as I remember were problematic.
I had been using your code for .bin mesh loading as well, not just worldrep - very useful!I hope at least my WorldRep work finds a way to be useful,
I'm not too familiar - are they releasing source code for SS2? Is it going to be different from the one that got already leaked?but frankly in a few months we can get big parts of the dark engine source code from the NightDive guys (at least that's what has been promised)
I'm happy to see your reply, Filip
Yes, It was me
Thanks for sharing this. Personally, I might eventually try to reach you in relatively mid-far future, as soon as I'll be going deeper into mission build process topic. For now, all that keeps me busy is editor GUI and 3D render itself
Hmmm. NightDive develop their SS in Unreal Engine. I wasn't aware of the fact this has something to do with original engine being released to public.
Oh how the turn tables!
No problem, I'm not sure if I still have enough knowledge in my head but I will try returning to the project to gather info for you, should you need my help.Thanks for sharing this. Personally, I might eventually try to reach you in relatively mid-far future, as soon as I'll be going deeper into mission build process topic. For now, all that keeps me busy is editor GUI and 3D render itself
Yea NightDive are preparing both SS1 and SS2 releaseses - SS1 is a remake, whereas SS2 is a remaster. They are teasing stuff on twitter constantly, but what I was referencing were messages dropped by Stephen Kick himself, lately they have been active on systemshock.org - he's mentioning the source code release there too.
I know about the leaked source code, but it is legally a grey area to work with so that is a no-go for an open source project. This would clear things up and open some doors, so I'm hopeful.
What I read on systemshock.org is the following:
From what I read I'm not sure if he's talking about "Remake" or "SS2:EE". I thought SS2:EE will only be a collection of mods and improvements/tweaks. Does SS2:EE deal with dark engine source code updates, too? If yes, release of it will be a huge boost to our project, too.
Yea they do have the source code and are porting it onto the KEX engine. From what I gather the source code release will be of what they got before they made it work on KEX. They are working on improved co-op and also VR support - things they need the source code for. I hope the source code will include Thief parts, it's quite hard to separate those two, in my opinion.
Then the questions are:
1. Will the new remaster support existing FMs?
2. If yes, what is the amount of effort to make the FMEditor remaster-compatible.
Most likely we need to wait until the release to be able to answer all of this.
How is this coming along? Very excited
Hi Ascobol. A new video is planned very soon.
I am curious what tools Night Dive will release with System Shock: VR.
Perhaps this all tools along with FMEditor we could use as KEX tools for no more hassle with newdark?
Hey Taffers. 2nd FMEditor video is now available:
In tonight's episode:
1. Face properties
2. N-sided shape brush inspector
3. Gimbal based rotation gizmo
4. Symmetry- and center-oriented drawing functions
5. Polygons, Cells and Solid World display!
6. WorldRep is now updated after portalization
Some great features there. I like the ability to edit a cylinder's parameters instead of having to rebuild it.
I know next to nothing about 3d graphics, but have you tried using Dromed's wr_export_obj command to help you translate the miss file data into UV coords? Would it even be feasible for your program to render the .obj file itself and treat it as a layer?
I have some other suggestions, assuming these aren't already on your list:
It would be very nice to have something that auto-rotates the texture to match the slope of a wedge brush. This would be especially useful when using beam/trim textures on the outside edges of stairs. This would be applicable for alignment modes 'Norma' and 'Extended'.
Another useful texture feature, which would help with the above but also be useful in it's own right, would be the ability for us to quickly change rotation by a preset amount, e.g. 45, 90 etc. Some trim textures run vertically, others horizontally, so an auto rotate tool would sometimes be out by 90, or maybe 180 etc.
Another one - a feature to set the correct sunlight direction for given celestial object. We can have three. Most of us will put the moon/sun in Celestial 1 but it would be wise to let the user choose which one to use, e.g. by putting the button in the dialog box for each of them. It would also be good to always keep them in synch, but that should be an option in case the user is implementing these things in an unconventional way.
I also think the brush orientation/size fields should show 3 or 4 decimal places, or the user should have the choice.
Last edited by R Soul; 26th Jun 2021 at 15:16.
As a matter of fact we did that and it had several downsides:
1. wr_export_obj creates a very inefficient material collection. Basically almost every wall is another material pass and this is not how you optimize render on GPU level. So if we would like to use it, we would need to parse and fix that.
2. Having an export, you loose the information of a brush corelated with each wall. Soon, we want to have clickable ability to choose the brush face on the render itself, just like in DromEd. And I think it's probably impossible to do it using the export iself.
Apart from that the export worked fine and in fact you can see it (with textures hidden) on our teaser video.
Thank you for your feedback. All suggestions make a total sense to me. I will put them on our list.I have some other suggestions, assuming these aren't already on your list:
To quickly change rotation by a preset amount, you have this round-shaped ui element in top toolbar, for rotation step. It affects the rotation step in degrees globally. So if you rotate a brush with rotation gizmo, it will "snap" to this rotation step "grid". It will work the same when you roll the middle mouse button in rotation text fields on the right side of the window.
The grid value works the same. Will affect both dragging using gizmo and middle mouse button on text fields.
Yes, you're right DromEd shows 3 decimal places, so we should consider showing 3 or 4, since we have place for it anyway.I also think the brush orientation/size fields should show 3 or 4 decimal places, or the user should have the choice.
Last edited by Marzec; 27th Jun 2021 at 02:00.
This is amazing work. You and your dev team are doing an incredible job with this project. I can't wait to see the finished project, and try it out myself!
Thank you Esse
This is fantastic news! Just restarted playing Thief 2 OM's and stockpiling like 100 Fanmissions. Then, through the 2020 FM stats thread, I found out about your project literally 1 hour ago. I am very excited!
About 20 years ago I had a good look into DromEd and then decided to DropIt. Too cumbersome for me. When I have something in front of my imaginary eyes (or even from dreams), I want to manifest it as fast and as smoothly as possible, as long as the impression is still fresh. That's when the essence of what I am feeling can be communicated (same with music).
Once this gets released, I might finally be able to build those levels that are spooking in my head for a long time now!
What will be the scope of manipulation with Python in the FMEditor? How can knowledge of Python be incorporated in level design?
Greetings, TJ
Hi Tom. Great to hear that
FMEditor will expose a Python API. And, similarily to DromEd command line, you will have a Python Console with a direct access to current editor objects and their APIs. This is still an early design idea, so that's all I can say.What will be the scope of manipulation with Python in the FMEditor? How can knowledge of Python be incorporated in level design?
Hi Tom,
I come from 3D animation backgrounds and have experience with such software as Maya or 3dsmax. In there, you have embedded Python editor, which allows you to execute any commands and query/edit any aspect of the scene interactively or run any Python script.
You can also build your own tools with GUI (dialogs), which can be integrated with the editor's GUI (e.g. adding menu and menu items). You can change applications' settings.
You can set up a start up script to execute certain commands or set up an environment for larger pipelines.
You can do some file I/O operations like loading and saving scenes and interact with operating system as well, etc...
Finally, you can share the scripts with others, so they can enjoy the same tools that you wrote.
I'd like to have the same for FMEditor.
This way you could write anything from simple scripts like 'set the texture of bottom face of all (or selected) cylinders to specific ID' to 'pre-release QC Checks of a mission' to creating your own fully procedural levels.
Up to you.
Last edited by PinkDot; 5th Jul 2021 at 17:23.
Wow, was away and it this community always surprises me when return. This is very exciting and will help immensely in certain areas of my mission! Thank you guys for working on this!
I do have one concern though; I haven't seen all the videos but on the first video, I saw moving chunks of brushes together, and even rotating a circle of window-sized brushes in place. Since this uses Dromed underneath, is this independent instructions to the brushes, or is it utilizing multibrushes? I hope they are purely using independent commands on each brush.
I worry about that micro fracturing issue as I call it, whereby if you move several brushes together as a multibrush group it doesn't actually care to snap to the grid correctly. Even if the brushes within the group were snapped and perfect distances from each other to start with, moving as a multibrush breaks them. You go and look afterward and see it snapped on .000004 of the grid. It would cause Portalization errors and the "find unsnapped" command cannot see such small values they're off by.
The way around this was to move the multibrush and then after closing group, "tease" each brush with a mouse move, to assure snapping into place.
Then, a wishlist item is for this editor to auto generate room brushes to fill out a detected air brush path, to help fill out odd shaped places all while not bleeding into near by room. Like how people have to create tessellating room brushes up ramps or in roofs. Perhaps only within an area you would first highlight before generating, so it doesn't unnecessarily room brush your whole mission.
Thanks!
Posting Permissions
