Per-level changes to robots that are only spawned

[mike8887123]

Rbotedit forgets everything except for the texture changes. So I usually have to change the weapons, shield, etc (everything but textures) in DLE after importing the hxm. Normally, I would insert the robot, and then change the attributes in the per-level section for that robot under the object editor tab. This forgetfulness of rbotedit isn't a problem until I have a modified robot that will only be spawned by either a matcen or another robot (that is, none appear in the level until spawned). In that case, I have no way of changing the things rbotedit forgot to.

So normally I could insert one robot, change his attributes in DLE, and then all the other bots of that type reflect the change- even spawned ones. However, when there is no robot in DLE to click on and select, then I cannot change the attributes. I tried inserting one, changing the attributes, and then deleting him, but the spawned ones don't keep the change. If I don't delete the non-spawned one, then the subsequent spawned ones do keep the changes.

One of these changes could be that it spawns other robots. Say I make a modified green spider to be white, and I have him spawn modified white hornets, and they shoot white lasers (see the parallelism?). If the white spider is to appear only from a matcen, then he will spawn green hornets... unless I keep at least one white spider (with per-level attributes changed) in the level that isn't spawned.

So I'm guessing the best way to fix this is to either 1) settle for a non-spawned one (or more) in the level, 2) hide one in a secret inaccessible block far off to the side, or somehow get rbotedit to not forget.

I know that this is what the bots labeled 'clone' or 'spawn' are for (and this is mentioned on a recent thread I started RE the boarshead and BPER models). Still, I am unable to have the change stick without one in the level.

Anyway, I'm not too bruised by this problem. Settling for one in the level isn't that bad, but I still wonder how to get this resolved.

Why rbotedit forgets everything? Either I'm doing something wrong in rbotedit (it is very sensitive), or DLE is over-riding the changes back to default when the hxm is imported. By the way, when I change non-texture attributes, I click on "tools" -> "robot info."

How do you handle this problem?

[Sirius]

rbotedit doesn't work like most people think it does when they first use it. When you modify values etc, you aren't actually saving them anywhere until you explicitly export the robot into an HXM (File -> Save -> Hxm). It doesn't have the ability to overwrite anything already in the HXM file, so you usually need to either start from scratch each time or delete the robot from the HXM and re-add it.

If you want to edit robots in-place, it's probably best to use HAXMEDIT32 (or HAXMEDIT/DOS through DOSBox). The custom robot features available in DMB2/DLE are kind of a "dumbed-down" version of that.

[mike8887123]

That's how I'm doing it. Its just that DLE seems to not be using all the changes in the hxm file once its imported (except for textures). I save the robots, one by one, while in rbotedit (I don't use 'n' or 'p' until after saving that bot individually). I use "tools -> robot info" to change the attributes. Then when I'm done saving all modified bots one by one, I open DLE and import the hxm file. But none of the changes (except for textures) are there until I use the DLE interface to change them a 2nd time.

This happens when I change multiple bots. I save for each bot before moving to the next.

Maybe I'm doing it wrong: when you modify multiple bots in rbotedit, do you save each one to a separate hxm file and import all of them? Or do you save them all to the same hxm file (one by one)? I'm saving them all to one hxm file.

[Sirius]

HXMs are per-level, so you do have to combine them at some point, yes. I would also say whether it works in-game is more important than whether you can see the changes in DLE. It has its own weird representation of robot stats using a bunch of sliders (dates back to DMB2) which may be pretty easy to break.

[mike8887123]

I noticed lately that levels with heavily modded HXM files (several robots modified) have a glitch where the robots' masses change on their own. They turn real light so that when you hit them, they fling around like a feather. Then I check the mass in DLE and its like 14. The hulk is supposed to be 262144, and the e-bandit and diamonds are supposed to be 65536000, but they change to 14 on their own every time I edit something. I have to change them back every time I want to test-run the level. The bots that tend to change masses are the hulks, diamonds, and e-bandits. Its usually the modified ones- especially when I put textures on a cloaked one and uncloak him.

Also, my spawned bots, especially the hornets, but many other bots, like to automatically kick onto snipe and start opening doors. Some bots, like omegas, should never be on snipe, but they go into it anyway. I've never seen an omega change to snipe before in another campaign. Its seriously debilitating to have omegas go to snipe. I really don't want to start compromising my levels.

What would you do in a situation like this?

[mike8887123]

Okay, now its a problem. Resetting the mass in DLE only works the first time you play the level. Subsequent game plays (even without messing with DLE at all) reintroduces the mass problem where heavy robots fling around like feathers.

So the mass is changed back to normal in DLE, I save, move the files into the game directory, start rebirth, and the first time the level is played is fine. Then I freespace to restart it, and the problem occurs. This means its a problem. Its not just a matter of resetting it in DLE. The problem is written into the file after saving.

So I need to ditch rbotedit and use haxmedit to modify robots?

Man, I was supposed to send one of you that file with the segment problem. Why don't I go ahead and send a few?

So the question: can I ditch rbotedit and use haxmedit instead? Do you guys have these problems using haxmedit to modify robots?

It seems as if this problem occurs only in levels where I modify a cloaked robot to have actual textures and then uncloak him in DLE (because rbotedit didn't uncloak him).

Overall, after seeing the problem I have with the AI (omegas and lifters on snipe), and the mass problem, and rbotedit forgetting settings, I think its time I stop relying on rbotedit.

[Sirius]

Rbotedit is mostly useful if you are making custom models for robots, in which case it's basically indispensable (because animating robots by trial and error is very, very slow and painful). Otherwise, I would use HAXMEDIT - basically it will avoid all these problems because it does what you expect it to.

[mike8887123]

I just spent a little while experimenting around with haxmedit32. Its not as confusing to me as it was the first time when I looked it (and its tutorial) over. I just created a blank hxm file, imported the medium hulk element from descent2.ham (I'm guessing it got it from descent2.ham anyway), and I changed his weapon to player laser 1 (as just a test). I saved to the hxm, not the ham file. And when I imported it into DLE, it worked! It remembered the weapon change. The weapon change is one of the main things rbotedit seemed to have forgotten after I would import the hxm. It looks like haxmedit32 is going to be a great thing.

I just fear saving over descent2.ham. Just how easy is it to accidentally do anyway?

And I just wanna add-- thanks much to everybody, especially Sirius, for helping out.

*edit* Can you change textures in haxmedit?

[Sirius]

Umm... I think haxmedit tries to prevent you from modifying descent2.ham actually - because of the so-called "multiplayer cheating" thing. I don't believe it will stop you modifying a copy though...

You can change textures in haxmedit by adding the object bitmaps yourself. It's not the easiest thing to figure out, which is why most people use rbotedit for that, but you do have the option of using that first, then haxmedit for any subsequent modifications.

[mike8887123]

I was looking at OBJECT_BITMAP and its very cryptic. So you're saying I can do all the textures in rbotedit, and then import that HXM into haxmedit just like I did the 'test' hxm I mentioned above. This should be self-explanatory, so I don't see any problems here. Plus rbotedit never forgets the textures for me.

What I do need to ask: in haxmedit, when I double-click an object_type, it brings up a list of attributes including shield, weapon, etc. The behavior attribute says "129." I'm guessing this is the AI, so what is 129? And from there, how would I change AI or behavior in haxmedit32? Is it simply a coding system where 129 maps to, say, snipe, whereas other numbers map to other common AI's? But this sounds a little odd because I know there aren't 129+ behaviors... unless the 129 means something else, not "one hundred and twenty nine."

So what does the number under behavior mean?

Thanks

**edit**
I just used haxmedit to open the HXM file I was using for the level with the robot-mass problem, and all the models that were screwing up had 0 as the mass. This hxm file was first created by rbotedit, and it then didn't work right. Then I opened it in haxmedit to see the masses at 0. This indicates that rbotedit didn't properly write out the mass when I created it the very first time (or I didn't do it right, but I can't see how I screwed something up if its just a window with data fields). However, it looks like haxmedit is the cure.

Let me now add one more question. Its the same question I asked about behavior above except its with the contains_id field. How do I know which numeric codes map to which power ups and robots?

Thanks again...

***edit edit***
I just noticed that, in terms of contains_id, the robot codes are just the element number that I already see in haxmedit (or is it called the slot number-- you know, there are 66 of them). I still gotta figure out the behavior and power-up codes though.

***edit edit edit***
New note: Regarding what I explained above (me making an hxm file with haxmedit32 for the first time), I just played the level with that hxm file. All is fine except the smelters are texture-less white. Its not a white texture. Its a non-texture. It looks more like I put the flare texture on him (but I didn't). Not sure what happened here because I don't have a smelter in the hxm file at all. I only modified a red hulk, cloaked hulk, and the 700P BPER. The smelter is 'stock' or 'OEM' in this level.

My work-around was to just simply use the smelter clone instead as his textures are still intact. Not a huge problem, but hmm... I wonder what happened.

I know there's a lot of stuff in this post with all the edits.

[Sirius]

I seem to recall HAXMEDIT has a picker that tells you what robot/powerup each ID maps to. Might be a button that appears at the right-hand side of the field when you click on it. Failing that, yeah, you can just look them up.

The behavior thing seems a little strange. I believe it's just codes. DLE has a table in the code for these:
AIB_STILL 0x80
AIB_NORMAL 0x81
AIB_GET_BEHIND 0x82
AIB_RUN_FROM 0x83
AIB_SNIPE 0x84
AIB_STATION 0x85
AIB_FOLLOW_PATH 0x86

That's in hexadecimal notation, so the first one is 128, and the last one is 134. I don't know why they start at 128 - maybe the top bit was originally going to be some kind of flag.

[mike8887123]

Okay, I gotcha on that. Thanks. The worst case is that I would have to experiment and 'try' each number for the power-ups manually.

Note that I edited my prior post before I noticed your most recent post, Sirius. My bad. I would have done a new post if I would have noticed in time. So in case you think its out of order, that's why.

Thanks again.

[mike8887123]

In haxmedit32, Is it possible to import robots from an hxm file instead of from the descent2.ham? Say I have some modded bots in an hxm file, and I want to add one more. Also realize that I have to use rbotedit for textures because I don't yet know how to do it in haxmedit32. So if I wanted to add another bot to the hxm file with modified textures, then can I make the single modified bot in rbotedit, save him in a 2nd hxm, and then import this hxm into the original hxm? This would allow me to add a bot easily by modifying an already-existing hxm file rather than making it all over again for one bot.

Also, it makes me think about Vertigo: how do you import those models into haxmedit32? Perhaps I have to use one of the polymodel programs? I'm not really ready for vertigo bots yet, but it makes me further think its possible to import from other hams besides descent2.ham.

[Sirius]

I'm not absolutely certain there's a straightforward "import from HXM" function in HAXMEDIT - it'd be under the File menu, probably, if there is - but there are ways to do that. If you have to, you can open a .HXM normally, export all the elements inside (as .ROB, .POL, .JOI, .OBM), and import them into the other .HXM. I forget whether you then have to re-assign the IDs... it might just add them as element #0 if you don't, which will require some editing to fix. HAXMEDIT's UI is not terribly quick for doing this - that's probably my main gripe with the program, it is awkward for bulk editing - but you can at least do it.

You can use a similar approach for most of the Vertigo robots, I think; export them from d2x.ham, import them into another .HXM as something else. You would probably have to re-assign some of the weapons though, since a few of them don't exist outside of Vertigo. I think that also applies for the textures, come to think of it... I forget how easy that is to fix. Might require some tweaking in rbotedit. I believe all the textures they use are present in vanilla D2, it's just that the object bitmaps (.OBMs, which is how rbotedit lets you change textures) they use to reference them aren't.
Edit: There is also a possibility rbotedit isn't enough by itself; you may have to reset the start texture for the polymodel to something in-range for non-Vertigo Descent 2. You can do this in HAXMEDIT, but again you won't be able to see what you're doing; if you have the PolView tool (also from the RCK) this is usually a reasonably effective tool for the purpose. I recommend against using Polytron on Parallax-produced robots under any circumstances though; it tends to break them.

[TSXMike]

Hi guys,
I was the one who started this thread a long time ago (under mike8887123). At one point, I could never remember my password, so I created TSXMike as my new name. So that's why I'm reviving this old thread. I hope it is okay.

I just started messing with haxmedit32 again. My question is that if I change a robot's textures in robotedit, it shows up in the game. But if I change another attribute like his weapon, it does not show up in the game unless I edit it in DLE again. I tried opening that same hxm file in haxmedit32 and changing the weapon. The weapon change shows up in the editor but not in run time - unless I again change it in DLE.

I'm just testing it out for now. I want to be able to have a robot that is spawned to have the change.

I know its the same problem I had back when I opened this thread. I guess I'm still trying to figure this out.

[Sirius]

Have you heard of Descent 2 Workshop? I'm wondering if it's an easier way to go about this. https://github.com/InsanityBringer/Descent2Workshop
Not sure where the binaries are though, I'll have to check in on that...

[Alter-Fox]

I'm just gonna spout the solution here that was too simple for anyone else to consider for more than a second...
If nothing works and your map doesn't reach the cube cap, you could insert a couple segments, disconnect them from the rest of the level, and place the robots in there. Just because the game might need to see the robots for the changes to work properly doesn't mean the player has to.

To be fair, this may have been brought up way back in the original post -- but it doesn't seem to have been brought up again. It's a good idea though, because it's simple, and it takes advantage of the way you already know the game's systems work. That means you know it will work without causing more problems.
A lot of games even these days have little boxes like this somewhere under or over the map where players can't see. They're probably there for similar reasons.

[TSXMike]

I think I will have to do something like Alter-Fox is saying. The player will see it though - once they get the full map. Still, it is a 99.999% problem-free solution and definitely suffices. Thanks for the input.

Sirius - that sounds interesting. I should try it. Thank you.

I found that you can add custom textures to robots with a pair of HXM and POG files. If you replace a level texture via POG, and then put that same texture on the robot using rbotedit, the custom texture will show up on the robot in game (and in the editor). The hard part was that I had to replicate the robot's texture which involved experimenting (guess-test-revise) until I got it right. It would be much easier to just find a way to export the textures in the HOG file (the ones that show up in rbotedit) to external BMP files. Then I could modify them and re-import them via POG for this purpose. Do you guys know if you can export the robot textures somehow? I know you can do it in DLE, but those are the level textures only. I still can't find a way to get the robot textures exported for modification.

[Sirius]

Yeah, you can do that in DLE too, just need to change the filters.

It looks like I managed to break the animated frame list in 1.12.32 (or maybe earlier) for the robot textures, though. It's splitting them up into different entries. Probably still possible to edit, once you get past that...

One last thing - I got a link to a recent D2 Workshop build, if you'll excuse the relatively anonymous location

[Alter-Fox]

The player will see it though - once they get the full map.

True, but I'm pretty sure there were some spots even in the D2 campaign where you could see a segment or two on the automap that was impossible to actually get to. It's nothing new.

I'll have to give that D2 workshop a look too, Sirius, just for curiosity...

[TSXMike]

Sirius, that is awesome. I didn't know it was that easy! So I'm guessing you can import to a robot's texture too. I'll have to test this out - nice! thanks