Customizable placement of buildings

Comp1337 · Post by **Comp1337** » 23 Jun 2006, 11:23

Ah well.. Ill keep the bow there for motivational purposes.

Rayden · Post by **Rayden** » 23 Jun 2006, 12:17

As soon as i have holiday in 1 week, i will try to help you

Sean Mirrsen · Post by **Sean Mirrsen** » 23 Jun 2006, 13:02

Developer people, your code is weird.

Code: Select all

symb=originalMap[x/2 + y/2*xs/2];
def->yardmap[x + y*xs] = symb;
def->yardmap1[x + y*xs] = symb;
def->yardmap2[ys*(y+1)-(x+1)] = symb;
def->yardmap3[yardsize-(x + y*xs)-1] = symb;
def->yardmap4[yardsize-(ys*(y+1)-(x+1))-1] = symb;

How come the first four-five lines (this is the FOR loop in the CreateYardmap of UnitDefHandler) don't cause the slightest pause of the engine's operation, but the last line alone causes it to lock into an infinite loop at the start of the XTA mod? (it crashed before, not it just locks up) My Drones mod works perfectly... indeed, your code is weird.

note: all those short names and the "symb" thing are because I thought that it was just the amount of calculations that caused the starting 'pause' to be so long, so I shortened it up. Now I know it wasn't because of that. All yardmapX are declared and setup in exactly the same way (copypaste rulez), and the calculations have been tried, tested, and debugged, so they produce no out-of-scope numbers. Something weird is going on.

Sean Mirrsen · Post by **Sean Mirrsen** » 23 Jun 2006, 20:50

Okay sorry, my mistake. Somehow replaced xsize with ysize for my calculations... made non-square non-solid yardmaps bug out with -1 when y was 0 and x was maximum. Works like a charm. Now for the rest of the thing...

Sean Mirrsen · Post by **Sean Mirrsen** » 24 Jun 2006, 19:28

Well, the project had a moderate degree of success (in that I was able to place a few buildings with yardmaps facing sidewards), but a whole crapload of problems has appeared. I'll post them here, for no apparent reason, maybe just to relieve myself, or in hopes of getting assitance.

1) Unsurprisingly, the yardmap refuses to change itself unless it's changed before the unit gets cached. I'll have to devise a more complex way of doing things.

2) More importantly, I still can't get a firm grip on the code, and the exact sequence of events from UnitInit of Unit to Block of SolidObject still eludes me. I need severe help sorting this out.

3) Now, I found it very hard to understand how to rotate a model in DrawBuildingSample of UnitDrawer. Some kind of documentation on available commands would be very helpful.

This is it, more or less. I am really a rookie programmer, and wading through this kind of seemingly advanced code is too much for me. This does not, however, feel like it would be a difficult task for someone who wrote the thing - presuming such people still roam around these forums.

Basically, what needs to be done is replacing the yardmap and the xsize and ysize of a building before a construction unit begins its placement. Finding that spot just before the construction starts, and finding the relevant info that applies to the case (there are a few yardmaps and sizes scattered about the code) is the most problematic for me.

Post by **ILMTitan** » 24 Jun 2006, 22:56

I think changing the CUnit::heading value will change the direction the unit will display. I don't know if this is true for buildings as well.

heading give the direction in the x-z plane (in spring coordinates) by heading*Pi*2/(max value of short) in radians.

Caydr · Post by **Caydr** » 25 Jun 2006, 03:09

Once a direction has been set, it should stick that way for all buildings that are built, until a new direction is set. IMO.

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 08:34

Well, that was the plan. :) The real biggest problem is that I can't make the buildings rotate individually, so far only all instances of a building, and only if rotation was applied before the building was cached (that is, before the unit supposed to build it has been created). That's a rather low degree of success..

Gnomre · Post by **Gnomre** » 25 Jun 2006, 08:45

Implement a YardmapN, YardmapE, and YardmapW tag in the FBI and be done with it. We'll survive

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 13:15

That's not the problem, since I got the yardmap transformations all figured out already.

The quest for the True Path of The Build Command has led me deep into the Jungle of The Code where I got totally entangled. Who would have known that unitdef's xsize and ysize variables are used in so many occasions? Currently I'm trying to have all references to UnitDef->xsize and ysize plugged by having a bulky switchscript placed before them, checking for buildfacing parsed to relevant functions (which I have to change so that the param list can take the facing), and then I'll have to find and complete all references to said functions, adding the necessary facing variable to relevant places. And after THAT, I'll have to look into changing the facing of the unit models and buildque ghosts.... O_O >_< x_x

This all would have been unmeasurably simplier if the devs originally made the yardmap a twodimensional array instead of an UChar string. Then I'd just swap the yardmap, and the relevant info would have been read from something like ALEN or whatever's used in C++ to get the array size... although no, it would still be read from unitdef... *sigh*

Post by **jcnossen** » 25 Jun 2006, 13:19

I would say just make CUnit::XSize() and CUnit::YSize() functions?
Just wrap it..

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 13:35

I don't think I understand what would that do... I need to have a facing variable passed all the way from GUIHandler where the command takes shape, to all kinds of functions that use unitdef values, since those values are unit-independent, and I need to use the facing on everything, even on buildings that are just planned to be built.

Post by **jcnossen** » 25 Jun 2006, 13:51

Ah yes ofcourse, at that point there wouldn't yet be a CUnit
Can't help you much then.. it comes down to making lots of changes in any case

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 13:55

Finding the places for those changes, and making those changes without crashing or desynching the game is the main difficulty here.

Post by **Tim Blokdijk** » 25 Jun 2006, 18:01

We appreciate your effort!
If you ever ask yourself why you are doing this - think of us.

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 18:03

Ok, well, I seem to have made at least some of the needed changes, but the game now crashes. What is the best way to determine where the error lies? Normally, when you code, you can run an app from the IDE, and when it crashes, you can see where the execution stopped. Any way to do the same for Spring?

AF · Post by AF » 25 Jun 2006, 18:04

Compile in debug mode.

It'll run slower though, some people would say so slow you cant play it.

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 19:02

That's not a solution. Debug mode will not tell me where exactly, what line of the code is causing the error. I found a workaround though, I copied my Spring dir to the source Game dir where the executable is placed, that allowed me to run and debug the engine through the IDE. That way I finally found the sources of the crashes (first was the old stupid error of mine - forgot to initialize yardmaps, second was a more weird error with size things)and now at least I get correct checking of the yardmap when trying to build something (that is, the red/brown/green underlay of the building rotates at the press of the switch button). The problem now is that the c.params[3] that should contain the buildfacing isn't being sent correctly... for some reason. I get an error when I try to get a value from it. I've got the "c.pushBack(buildfacing)" or something of the kind in the relevant place, but it somehow doesn't get to the BuilderCAI...

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 19:05

Nevermind the multipost, SUCCEEEEESSSS!!!!!!! :D:D:D:D:D I was able to place several buildings with yardmaps facing in different directions. The only problem now is that my initial calculations for the four yardmaps processing were wrong, and the yardmaps turn out mangled, except the North and South variants.

And, of course, I still need to find a way to rotate the unit's ghost when placing it, and the unit's model when it's placed, but at least it's a start now!!

So as to prove this, here:

Those vehplants were queued up and built in one que.

Sean Mirrsen · Post by **Sean Mirrsen** » 25 Jun 2006, 20:40

Ok, yardmaps and qued building frames now correctly displayed. It seems yardmaps were the easy part. Now I have to find a way to rotate the four model instances: the ghost that moves as you choose the building location, the ghost that appears when a build order is made, the main building model, and the ghost that appears when the building's been scouted. Of these the third and fourth are probably the easier ones, but I still have no clue as to how it's done...

Spring RTS Engine

Customizable placement of buildings