PDA

View Full Version : Chicken & egg script problem


mr_slippery
1st Dec 1999, 12:54 PM
I've coded myself into a corner and I'm trying to get around this. This is so common though that somebody must have a solution.

The problem is that I have two (2) classes and they are in two separate packages. They each have references to each other. When I compile (using ucc make), ucc complains that I have an undefined variable type. The one that it complains about is, of course, whatever is listed second in Unreal.ini. Any suggestions on how to get unreal to recognize both classes?

mr_slippery

Wanderer
1st Dec 1999, 04:02 PM
Can you import both of them at the same time and compile the script?

mr_slippery
2nd Dec 1999, 04:02 PM
The only way to make them work is to place all the code in the same directory, thereby making it all into a single package.

While this works, you can see that there might be all sorts of problems if you need to develop classes independently of one another - as was what happened. I was developing one package and the other team member was developing another.

Maybe this will be fixed in the rewrite of UnrealScript, that is, allow the user to make a forward declaration. Hear that Tim?

mr_slippery

Wanderer
2nd Dec 1999, 04:45 PM
Don't count on Tim hearing you. In fact if any of the Epic or DE crew stopped by I might **** a brick.

Now you said the scripts both had to be in the same package right? Ok, I'm not a coder and this is still a long shot. You send each other what you've got and get it combined into one package (or one of you sends the code to the other and they combine it and send it to you). This way both of you have something from the other guy and can test the code. Gotta remember to update each other though.

mr_slippery
2nd Dec 1999, 07:23 PM
Fortunately, this is a small project. If it were a real project, it would cause untold mayhem since my co-developer is nowhere near me and is, in fact, across town.

With Quake, we developers got a petition and a steady rapport with John C going. Quite a number of suggestions that we made seem to have made it into Q3. Is there something similar to that in the Unreal community? Perhaps that would be a Good Thing to do for Unreal, especially in view of T.Sweeney's announcement.

mr_slippery

Githianki
3rd Dec 1999, 02:59 AM
Actually Tim does communicate with a lot of scripters via e-mail about tech suggestions. You have an interesting problem but it would seem to be one of design and planning, not one of language.
Basically you are having problems with one class refering to another in a package you don't have(because someone else is working on it). Is this correct? (I do this to make sure I understand and to make it clear to others who might want to know the types of problems they might face making a mod).

If forward declarations were allowed you could have all sorts of holes in code when people are missing packages. This could be fixed in a language way, but the better solution would be to design a dummy class template together that you could refer to. Then one or both of you could simply override it. This way you have your references intact for builds and the code works when the packages are integrated, which they should be in the end (right?). The main thing is deciding how that class should be exposed, so that the actual coder of it has flexibilty beneath that interface, while you have a stable set of references.

Anyway it is an idea. Maybe it wouldn't work.

mr_slippery
3rd Dec 1999, 12:35 PM
I thought about that, creating a stubbed out version of the object that then all the real objects would inherit from and provide the real functionality thru polymorphism. However, that was precisely what my co-worker was supposed to provide. Also, this solution tends to mess up the object hierachies since now the objects need to implement their real characteristics and the stubbed out methods. Since there are no parameterized types (either through templates or implement clause) and no multiple inheritence is allow, the only solution was to create two objects and have them reference each other. Hence the two different packages, one of 'Real' Unreal objects and a second of the tracking objects.

I would solve it by allowing explicit naming like how java does to reference objects in other packages. Either that or have an implement clause like Java. I think that either of those routes would be easier to implement than templates and multiple inheritence (and safer too!)

mr_slippery

Githianki
3rd Dec 1999, 01:36 PM
Obviously you have a much better grasp of language features than I do. So look in your e-mail for a present. /~unreal/ubb/html/redface.gif