map2diff -- anyone else working on this?

#1 I have worked on it a bit in regards to getting QuArK maps to read correctly. Have done some preliminary investigation into the mirrorSubobject stuff. Also, am looking at the translucentSubobject code (or lack of). I'd interested in any code you have.

#2 Having a working editor whether it's Worldcraft or QuarK would no doubt be one of the most useable "features" that could be added. This problem is of particular interest because even the crappy freeware engines got this whipped and given the skill of programmers here it could be done. (Kindof like the better interface for Linux ;) Anyway, this engine kicks ass but the lack of a full featured editor is what seems to make it incomplete in many peoples' opinions. A fix to these incomplete features noted above could turn the tide dramatically. This is pro sh*t though, and unfortunately i'm not qualified. I'll test the hell out of it though :)

Scott

#3 ok ill continue that research till ive fixed it ..
:)

#4 Badguy, I was working on the doors and paths. The parsing from the map file really isnt a problem, its typing the code into the engine thats the issue.

I initially thought that I'd simply make the doors and moving platforms in the same way as a forcefield, as I thought forcefields already worked.

What we need to find, is a way to seperate different parts of a diff file into different sets of brushes. So that the door brush would be its own interior (effectively) and so that it can be moved (much as you can move an interior in the editor).

Something just occurred to me. When I move an interior instance in the editor, it becomes non-collidable. Wonder what happens if I make it so that it remains collidable when I move it.

Phil.

#5 Phil
hmm ive not had that i can move the interior's in the editor they still collide fine?
EDIT: do you mean the way the collision is apparently disabled briefly during the move?


the doors are already broken off into thier own interior pieces already :)
as are the forcefields ..
thus allowing them to use the PathFollower data to "follow the path" laid out in the worldcraft editor.

the issue with the forcefields is like the doors im sure ..
honestly ive not looked to deep as to why the doors dont make the export as im still trying to fix the forcefields ..
shouldn't be too much longer ill work on it again later today
but from the code in the map2diff the door is an interior just like the one being exported ..
as is the forcefield the forcefield now makes the export here but wont show in the engine even with the code ive added as the surfaces were never validated
so once I fix the surface thing the forcefields should work leading me next to doors ..

#6 @Badguy
--I don't think the issue is with map2dif--all the ents that were originally available can be exported from QuArK or WorldCraft with map2dif. In other words, I think they do make the export but there's nothing on the engine side to "read" them. What's your take on this Phil?

@Scott
--I don't understand what you're saying...both QuArK and WorldCraft __ARE__ fully functional editors. QuArK does a great job for me. I'm sure others using WorldCraft say the same about that editor. True, some of the ents are broken, but that's not at the editor side of things; and as I said above, I don't think it's all with map2dif either. There are some issues I have with map2dif--like getting floating point coordinates, fixing the mirrors and translucent objects, etc.

Once Phil fixing the doors, they should then be accessible from the editor of your choice.

#7 wow desmond ..
you mean you have a map2diff that exports
elevators/doors, ai nodes, triggers, pathfollowers and forcefields into the diff?
....
as the engine code is disabled like the map2diff code that I have ..
1_1_1

#8 @Desmond... That's actually what I meant :) I know the editors work fine (unlike a lot of people I like Worldcraft :). The way I worded my statement above was unclear, my bad! I meant the transluscents, transparents, mirrors, doors, elevators, etc....

You know, editor-type stuff ;)

Scott

#9 Ok.
Forcefields are working on my end now ..
still no data block to create them in the editor but
now I feel with my exp. with the map2diff that wont be much trouble..
so I can export them with an interior

now onto doors and other sub objects.

these look like another matter :)
ive gotten them to export into the diff after some painfull debugging
so now to get the engine to make us of the sub object

ill make this all available as a package when im done..
hopefully it can be put into the engine code as it is quite a painfull amount of little things to do to get it all working..

#10 My take on the doors and stuff was that it was an issue parsing them out of the diff file and reading them into valid "engine" entities.

The Door code was all commented. But the parsing of the map file as far as i could tell went fine and created the objects it was supposed to (i.e. it parsed into the diff ok)

It was getting from diff->engine that I saw the problems.

I was basically going to use the forcefield code to do the doors. Figuring its basically a pathable forcefield (one that wont let you pass :))

Of course, that involved getting pathing to read correctly, and I got kind of bogged down in adding my new pathing code in (paths from WC are basically linear interpolations of paths between nodes, I was adding in spline paths and quaternion rotations for objects into that initially).

I'd be interested to see what you got baddie.. maybe I can offer some help with the other bits.

Phil.

#11 Phil:
the door code was commented cause it was broken ..
and just uncommenting lead to crash no export

the door never meet the export neither did the forcefield or the pathfollower data..

all the engine code to handle this stuff is there and just unplugged for example the InteriorResource::read
function has all the data being parsed of what has made it into diff but noone dips into that data anytime
so with some changes to the ForceField class to get it working I plugged it into the InteriorInstance where it can access its data at this time I notice that the mInteriorSubObjects in this InteriorInstance class is used to hold the actual interior? .. so im a little mislead on where to start with the door ..
gonna derive a class from InteriorSubObject but it looks like a mess :)

I dont recommend using the forcefield code for the door as the door is actually capable of everything an interior is capable of far exceeding that of the ForceField..
so

Ive fixed the pathing problems regarding the pathfollower .. more commmented out code missing a class I wrote Plus there is still an issue regarding the nodes ..
as ive had to go into the map file and change the name of the following nodes after the start .. I cant get worldcraft to just make one path_start node and then name the others path_node ..
so this that and the other thing they work..
so now using the current engine code to realize these paths .. and maybe make use of the pathmanager would be the next step in that direction .. but first im gonna get the door in there to render

Ok Edit here:

Doors are now rendering colliding textured via the InteriorMoving class ive added ..
with the myriad of problems repaired regarding the commented code to enable the doors and thier relative parts in both the engine and the map2diff doors are now ready to use the ready path information provided so..
this leads me to the next step .. writing the code in
to allow the InteriorMoving to use the InteriorPathFollower code with the InteriorPath..

umm ..
I plan to take out a new head release and apply this code to it documenting each change preparing for a resource post..
question :
should I go ahead and write the path following code before or after this resource post?
would anyone like to help with the path following stuff?

heh I fear its gonna take me a couple weeks to get the InteriorMoving to use the path as I want..

im looking forward to finishing this so I can add the exciting new code I have planned
"Mount Points for interiors"
allowing things such as sitting laying playing serving...
bla bla bla

any takers?

#12 Ouch ..
does this mean noone wants or needs doors?
are you aware this expands to trains, planes, birds..
and anything else that will follow a path?

umm ..
ok ill complete the pathfollowing myself no trouble
and ill post when it is complete

im reminded of an old story .. something about a loaf of bread a couple kittens and .. an ugly duck

#13 I'm really interested in that forcefield code.

#14 yea?
..
they dont collide yet as I havent added thier convex to the interiors list..
I will be providing that info
when I do the post on this other stuff

#15 Dude, please! I'm way into you getting doors working but lack the skills necessary to be an asset. I will, however, be one of your biggest fans. It's been a real honor and a pleasure to be in the presence of a true cross platform game-programming wizard. Your time spent on this is very much apprec........

Is this enough support? :)

Seriously though, WE WANT DOORS! Well, I do anyway...

Scott

#16 I believe what my esteemed colleageue is trying to say, in Tribes terms, is "Hurry up with that station!" ;-)

#17 I'd LOVE to see doors, force fields AND path following, packed into a cute, lovely resource... :-) Sounds great, badguy!