Removing a Unit from the map

[onehand]

I'm looking for a way to 'disappear' a given unit or structure from the map entirely.  Looking at HFL, it seems like UnitEx.DoPoof() should do this, but it doesn't work for me.  Has anyone gotten this method to work?

From the doc:

DoPoof causes a unit to disappear, or 'poof' from the map immediately.

void DoPoof();

DoPoof will cause a minor graphics glitch. (The unit graphics will not disappear until the map viewport is moved). It is best to take the unit to the edge of the map before poofing it.

Even if I move the viewport, it doesn't disappear my units.  For instance, here's some code I'm trying just as a test:

Code: [Select]

SCRIPT_API void CheckEarthworker()
{
	UnitEx unit;
	PlayerVehicleEnum enum1(0);
	while(enum1.GetNext(unit)) {
		if(unit.IsVehicle()) {

			if(unit.GetType() == mapEarthworker) {
				TethysGame::AddMessage(1248, 576, "Earthworker found!", -1, 89);
				unit.DoPoof();
			}
		}
	}
}

I get the message above, but no poof.

[Hooman]

Off the top of my head, I don't know what's going on here.

Would you be able to check in the project to SVN. There is a folder "outpost2/LevelsAndMods/trunk/BugReproducer/" which is meant to contain projects with minimal code to reproduce odd behavior and bugs. That would allow other people to compile and run your example themselves, which can help in understanding what is happening.

[onehand]

Alrighty, got SVN access and uploaded my test project "Ravine" there. Apologies in advance for the bunches of comments in the Main class-- I was messing around with different things in the SDK there, but the main trigger where doPoof() is called is in "CheckEarthworker".

[Hooman]

Ahh, excellent. Downloading the source now.

It's taking a while though, since you've checked in some large binary files. I'd recommend setting a global ignore for some of them.
TortoiseSVN->Settings->General->Ignore Pattern
Append the following to the ignore pattern: *.user *.suo *.sdf ipch/ Debug/ Release/

In general, you don't want to check in any compiler output files. They can be regenerated by simply compiling again. Hence no Debug folder, no Release folder, none of the .obj files, and not the compiled DLL. The only exception is for a project where the source code is lost and you're doing mods directly to the EXE or DLL files themselves (such as in the game download). There are also a few Visual Studio related files in the project root that don't need to be checked in, as they contain user specific settings.

I've deleted the files that I think don't need to be there. The project still builds without them.

[Hooman]

I did a bit of work updating the project files for the SDK (Software Development Kit). This was largely motivated by getting your code to compile using the existing projects, rather than using a copy of the source files. I then updated your project to depend on the existing SDK projects, and removed the duplicated code. This makes for a much cleaner project, and is now much easier to see what code is yours.

I've also added a Post-Build Event that copies the compiled level DLL to the game folder. (I removed your project settings that placed the DLL file in the project root).

To make testing easier, you can set the Debugging Command to point to Outpost2.exe, which lets you run Outpost2 from Visual Studio. Just press Ctrl+F5 to run (or just F5 to debug, which means run with a debugger attached).
Project -> Properties -> Configuration Properties -> Debugging -> Command: ../../../../GameDownload/Outpost2/trunk/Outpost2.exe
(Assuming you want to run your code using the copy of the game in SVN, which is quite convenient for development).

I would have added the debugging command to the project file in SVN, but I found out it's a user specific option, and user specific files usually aren't checked in. I currently have a global SVN ignore for such files. I'll have to think about this a little more, since that used to be set in the old Visual Studio 6 project files.


I haven't actually played around with the Earthworker problem yet. I'd like to "reduce" (gut) your project until it has the minimum amount of code needed to reproduce the issue. It might be nice if you took a look at it in it's current form, before being gutted. I'd like your feedback on the current project organization. I'd like to know if you find it clear and easy to work with.

Also, I would encourage you to actively develop your project with the code stored in SVN. A more suitable place for actual level development (as opposed to bug hunting) would be in the "Levels" folder. (outpost2/LevelsAndMods/trunk/Levels/Ravine). This would be a great chance to practice an "SVN copy". What you can do, is run an SVN update to download my changes, check it out, see if you like them, and if so, you can right-click drag the Ravine folder from the BugReproducer folder over to the Levels folder. When you let go of the right mouse button, a menu will pop-up, and you can select "SVN Copy versioned items here". Then you just commit from the new location, and add a log message. (The copy means the repository doesn't need to store a second copy of the files, it will just refer to the already committed ones).

[onehand]

Wow! This project is so much more organized now. I like it. Thanks Hooman. 

This was more of a first test map for me, so I may hold off on adding it to /Levels just yet, and I don't think it really deserves that title. [Although I am working on another map that I may end up adding to /Levels because I wanted to get some feedback from folks on it]

EDIT: That said, would it make sense if I renamed this particular folder to something like "doPoof-testing" instead of "Ravine" to be more self-explanatory?  I wasn't sure if renaming generally causes any issues with people using the SVN and when the Update function is leveraged.

[Hooman]

You may certainly rename the project. Make sure to do an SVN rename, rather than a simple folder rename. If you do a folder rename, it will do a delete, and then a re-add of new code, which breaks history, and also causes bloat in the repository since the change is not marked as a simple copy or diff from the previous version. It also means a much smaller update for other people to download.

As for adding it to Levels, I'd say just go ahead and do it. Levels isn't meant for finished polished code. It's meant for works in progress. It is a version control system after all. If for some reason the project fails or gets abandoned, it can always be deleted later. Or the project can be forked and continued on by someone else who took an interest in it.

[onehand]

I just figured this one out. I wasn't calling HFLInit() in my InitProc().

D'oh...

I did get to learn a lot about SVN through this exercise though.

[Hooman]

Gah! I was right about to say that.

I set a debug breaking in the CommandPacket processing in Outpost2.exe, and it wasn't firing. I looked at the HFL function DoPoof and saw it could return early if you don't init the library first. Duh!

I also came up with an alternate solution that doesn't use HFL. Call unit.DoDeath() instead. That might cause self destruct damage to nearby units though.


I still think you should put your project in the Levels folder.

[Hooman]

I'm minimized your bug example. (Read: I gutted your project). This makes the demonstration of the problem much easier to understand.

If you want to work on your project in SVN, which I think you should, you can copy the previous revision to the Levels folder. You can find the previous revision using SVN -> Log, and look for the version before I gutted it, or before your rename, it doesn't really matter.

SVN -> Log, select revision 976 (just before you renamed the project folder), right-click -> Browse repository, selected the Ravine folder, right-click -> Copy to ... (or Copy to working copy), select the Levels folder, click ok, enter a commit message.

If you use "Copy to ...", the operation will work right on the repository, so it will be faster. You may need to run SVN -> Update afterwards to download the changes.

[onehand]

Thanks again Hooman.  Looks a ton better. I've been working on another mission recently that I will commit to the SVN in /Levels as I need some help with it (much more ambitious). So I don't think I'll add anymore to this particular mission right now, but I've incorporated the organizational standards, removed the deprecated calls, etc. we've looked at in this project into the new one. Post to come.

[Hooman]

So any progress on this?