164 replies to this topic

[GeN1e]

Yep, Ardanis_gen1e.

If your example is in an actor section than your dead wrong as you're giving trigger offsets....

Lol, seems I hit a wrong block to copy from

[Qwinn]

@Qwinn -- have you got a set of ITM macros that we could adjust for BG1?

Not sure what you mean. You mean adding items to areas? My area macros can do that.

Qwinn

[Sasha Al'Therin]

@Qwinn -- have you got a set of ITM macros that we could adjust for BG1?

Not sure what you mean. You mean adding items to areas? My area macros can do that.

Qwinn

No, I was thinking about itm files themselves. I know weidu ships with some but they are actually designed for spells and as such get a little confusing when trying to adapt to an item. Especially when you want to add a global/equipping effect rather than an ability effect...

I'm going to take a look at what Miloch pointed me to and see what is in there....

[Miloch]

I know weidu ships with some but they are actually designed for spells and as such get a little confusing when trying to adapt to an item. Especially when you want to add a global/equipping effect rather than an ability effect...

There is very little difference between .spl and .itm files, apart from the header size (which I think is also different in PS:T) but that's pretty trifling. In any case, WeiDU has separate macros for both, and what you want is ADD_ITEM_EQEFFECT. The usage is simple - just COPY_EXISTING the item you want to change, set the variables that aren't the default values and LAUNCH_PATCH_MACRO ADD_ITEM_EQEFFECT. If you need to pick apart the source code, it's still out there somewhere. (And my library has similar code only gives you more options if you need them.)

[Sasha Al'Therin]

I know weidu ships with some but they are actually designed for spells and as such get a little confusing when trying to adapt to an item. Especially when you want to add a global/equipping effect rather than an ability effect...

There is very little difference between .spl and .itm files, apart from the header size (which I think is also different in PS:T) but that's pretty trifling. In any case, WeiDU has separate macros for both, and what you want is ADD_ITEM_EQEFFECT. The usage is simple - just COPY_EXISTING the item you want to change, set the variables that aren't the default values and LAUNCH_PATCH_MACRO ADD_ITEM_EQEFFECT. If you need to pick apart the source code, it's still out there somewhere. (And my library has similar code only gives you more options if you need them.)

I picked yours apart (not really) and turned it into a patch function... I've got generic default values assigned inside the definition in case the user doesn't need or want to set something. Things like 100 for probability1; 2 for timing mode; 1 for target; 0-1 for opcode; everything else is 0 or ~~ I'm gonna test it in the fixpack after I re-work the area patches to use Qwinn's macros... If needed, I'll move any further discussion to the fixpack work room at G3.

@Qwinn -- I'll let ya know what happens after I do my first test use of the macros... Were you going to update the macro with the GAME_IS checks? If so, I'll swap out locally the SET Q_GAME = with the checks I posted earlier...

[Miloch]

I've got generic default values assigned inside the definition in case the user doesn't need or want to set something. Things like 100 for probability1; 2 for timing mode; 1 for target; 0-1 for opcode; everything else is 0 or ~~

Eh, but this is what the WeiDU macros do, so why not save yourself (and your users/downloaders) code and use them instead? Unless you need to do other things a little more complex (which is what the Free Action macros were for, to change something surgically inside an existing item effect etc.).

[Qwinn]

Yes, sorry Sasha, I'm a bit swamped on the home front atm, feel free to do the GAME_IS logic locally, I will change it in the main post ASAP.

Qwinn

[Miloch]

Examples of how I wrote to actor, trigger and vertex records are in post #4 of this thread. Sorry I don't have examples for any other sections, I've never needed to add any other records. (Well, actually, I did containers and items at some point, lemme know if anyone wants examples of those.)

I see no instances of you writing Q_NewOffset_Conta anywhere in any of your 3 mods. Have you even tested it? Has anyone? Because either I'm doing something wrong or it doesn't work.

COPY_EXISTING ~ar2900.are~ ~override~
  LAUNCH_PATCH_MACRO q_are_initvars
  LAUNCH_PATCH_MACRO q_areadd_initvars
  Q_New_Conta = 1
  Q_New_Vertx = 6
  LAUNCH_PATCH_MACRO q_areadd_process
  WRITE_ASCII Q_NewOffset_Conta ~Container 1~
  WRITE_SHORT (Q_NewOffset_Conta + 0x20) 4590 // locX
  WRITE_SHORT (Q_NewOffset_Conta + 0x22) 1525 // locY
  WRITE_SHORT (Q_NewOffset_Conta + 0x24) 8 //Type (nonvisible)
  WRITE_SHORT (Q_NewOffset_Conta + 0x26) 100 //Lock difficulty
  WRITE_SHORT (Q_NewOffset_Conta + 0x2e) 100 //Trap removal difficulty
  WRITE_SHORT (Q_NewOffset_Conta + 0x34) 4600 // Trap locX
  WRITE_SHORT (Q_NewOffset_Conta + 0x36) 1535 // Trap locY
  WRITE_SHORT (Q_NewOffset_Conta + 0x38) 4564 // Bound left
  WRITE_SHORT (Q_NewOffset_Conta + 0x3a) 1511 // Bound top
  WRITE_SHORT (Q_NewOffset_Conta + 0x3c) 4580 // Bound right
  WRITE_SHORT (Q_NewOffset_Conta + 0x3e) 1521 // Bound bottom
  WRITE_SHORT Q_NewOffset_Vertx 4558
  WRITE_SHORT (Q_NewOffset_Vertx + 2) 1519
  WRITE_SHORT (Q_NewOffset_Vertx + 4) 4564
  WRITE_SHORT (Q_NewOffset_Vertx + 6) 1511
  WRITE_SHORT (Q_NewOffset_Vertx + 8) 4576
  WRITE_SHORT (Q_NewOffset_Vertx + 0xa) 1509
  WRITE_SHORT (Q_NewOffset_Vertx + 0xc) 4588
  WRITE_SHORT (Q_NewOffset_Vertx + 0xe) 1511
  WRITE_SHORT (Q_NewOffset_Vertx + 0x10) 4580
  WRITE_SHORT (Q_NewOffset_Vertx + 0x12) 1521
  WRITE_SHORT (Q_NewOffset_Vertx + 0x14) 4564
  WRITE_SHORT (Q_NewOffset_Vertx + 0x16) 1525
BUT_ONLY

It runs successfully and even appears to add the new container if you look at it with an editor, but it is not selectable and will eventually crash the game or DLTCEP. Also, your method takes significantly longer - several seconds just for this one container whereas the method I originally used (post 11) did it almost instantaneously. Maybe your method isn't updating something correctly for non-PST (and yes, I set the game variable corrently) or maybe I left something out, but apart from the update macros, the write code is pretty much the same.

[GeN1e]

I don't see where you fill 0x50 (vert_index) and 0x54 (vert_count). Also values for bounding box don't correspond to real ones, though I can't say I know what the purpose of that box is.

PS While I'm here. Qwinn, may I deliberately steal some of your code to make a few macros for an addition to Weidu? Yours are fine, but they still are the tool for advanced users, who usually got a general understanding of how it works. While a conventional macro suggests only having to enter the desired values and let Weidu to handle the rest.

COPY_EXISTING ~area.are~ ~override~
SET par1 = 1
SET par2 = 2
SPRINT par3 ~idiot~
LAUNCH_PATCH_MACRO add_area_stuff

Edited by GeN1e, 08 June 2009 - 08:24 PM.

[Qwinn]

EDIT: Never mind. Miloch, see next post.

Qwinn

Edited by Qwinn, 08 June 2009 - 08:52 PM.

[Qwinn]

Okay, I see what's missing. From your first macro:

//Update vertex information for new container
  WRITE_LONG (ctnr_off + 0x50) insert_idx //First vertex index
  WRITE_LONG (ctnr_off + 0x54) vertex_new_num //Number of vertices

The vertexes got added to the end of the vertex list so there's no need to update the indexes for all existing vertexes, but, you do still have to link the new container to the new vertexes.

I'm thinking:

WRITE_LONG ("Q_NewOffset_Conta" + 0x50) (Q_Num_Vertx - 6)
WRITE_LONG ("Q_NewOffset_Conta" + 0x54) 6

should cover it.

Qwinn

Edited by Qwinn, 08 June 2009 - 08:51 PM.

[Qwinn]

Oh, as for me saying I added a container somewhere in my mods, sorry, I was wrong about that. I -had- added a container in my Expanded Deionarra's Truth mod, but eventually I wound up needing to use an existing container and the new container got yanked. Still, at one point in the development, it was used and worked fine.

As for why it should take "a few seconds", I'm not sure why it would. Maybe it's choking a bit due to the missing writes I just mentioned? I'd say fix that up and see if timing is still an issue, but the macros don't take any real time at all when installing my mods, least not that I could tell.

Qwinn

Edited by Qwinn, 08 June 2009 - 09:03 PM.

[Qwinn]

Gen1e:

PS While I'm here. Qwinn, may I deliberately steal some of your code to make a few macros for an addition to Weidu? Yours are fine, but they still are the tool for advanced users, who usually got a general understanding of how it works. While a conventional macro suggests only having to enter the desired values and let Weidu to handle the rest.
CODE
COPY_EXISTING ~area.are~ ~override~
SET par1 = 1
SET par2 = 2
SPRINT par3 ~idiot~
LAUNCH_PATCH_MACRO add_area_stuff

How is this different from my macros as they exist, other than your somehow avoiding the need to run the two InitVars macros? I personally like having them separate because quite often I want to run -just- the InitVars macros to give me variables with the proper offsets for the purpose of modifying existing area data, rather than adding or deleting, but if always prepping by running those two macros is considered "advanced", maybe we can still have those able to be run independently and have the Process macro run them automatically without somehow overwriting the parameters just set. (I'm still very nervous about eliminating the variable initialization, though, which would run the risk of having the settings from a previous run of the macros linger until an additional use).

Qwinn

[Miloch]

Also values for bounding box don't correspond to real ones, though I can't say I know what the purpose of that box is.

If you mean the values at 0x38, the IESDP describes it as the "Minimum bounding box of container polygon" whatever that means. Standard areas I looked at do not match the actual container vertices, so I don't really know what the purpose is either, but I'm pretty sure that rectangle still needs to be written for something.

As for why it should take "a few seconds", I'm not sure why it would. Maybe it's choking a bit due to the missing writes I just mentioned?

I don't think so. It appears to add it correctly now with those two extra WRITEs but still takes the same amount of time. In theory, READs and SETs shouldn't really take any time at all, but you're doing an awful lot of them, and it appears you do them redundantly somewhat - you run q_are_initvars both at the beginning and end of this process (since the q_areadd_process macro also invokes it when it finishes). And if I copied another area, that would occur again, etc., when in theory I should only need to do it at the beginning of each COPY). Maybe it's your long variable names, though they're not as long as some people's .

I ran my original patch several times and got an average of 1.95 runtime. Yours took 2-3 times as long. While it might not seem significant for this one container, I'm thinking it'd increase runtime dramatically if I added several in multiple areas. Since both macros appear to be working, I guess I'll stick with the original for now unless you can get that runtime down somehow. According to your WeiDU timings at the bottom of the .debug file, yours is spending at least half its time in eval_pe (whatever that means) when Ascension64's method has almost no time devoted to that. Parsing, loading, etc. is not significant for either - most of the remaining time for both ends up in "stuff not covered elsewhere" (again, whatever that means).

Edited by Miloch, 08 June 2009 - 09:44 PM.

[Mike1072]

PS While I'm here. Qwinn, may I deliberately steal some of your code to make a few macros for an addition to Weidu? Yours are fine, but they still are the tool for advanced users, who usually got a general understanding of how it works. While a conventional macro suggests only having to enter the desired values and let Weidu to handle the rest.
CODE
COPY_EXISTING ~area.are~ ~override~
SET par1 = 1
SET par2 = 2
SPRINT par3 ~idiot~
LAUNCH_PATCH_MACRO add_area_stuff

How is this different from my macros as they exist[...?]
Qwinn

I won't comment on the overall approach taken in designing your macros, but I do think something could be added with no drawbacks that would make your macros easier to use. The copy/paste blocks you advocate using to write new information to the different structures after adding them are basically scary-looking to users who want to keep things simple. If you set up functions for these, you can make it so the user won't have to write to each and every offset of the newly added structure(s) after using your macro, just the important ones. The benefits to this would be tidiness, less duplication of code*, and probably a lesser chance of screwups for users, advanced or otherwise.

* You can see why this is important if you imagine finding a WRITE_LONG/WRITE_SHORT error within one of the blocks users are supposed to copy/paste and modify, instead of within your macro.

[Qwinn]

Miloch, I dunno what to tell ya. My UB mod runs the ARE Process macro no less than 12 distinct times (and the Vertex macro once), and the entire installation time for the entire mod is 10.094 (and the total eval_pe is 0.658).

I don't see how that lines up with your findings, but at any rate, I don't see any way to improve the runtime of the macros as they exist. Sorry if that's a dealbreaker for you.

Qwinn

Edited by Qwinn, 08 June 2009 - 10:33 PM.

[Qwinn]

I won't comment on the overall approach taken in designing your macros, but I do think something could be added with no drawbacks that would make your macros easier to use.

I have to reject the notion that what is being suggested here impinges upon the ease-of-use of my macros. The WRITEs have to be done whether you're using my macros or not. My macros really have nothing to do with it.

The copy/paste blocks you advocate using to write new information to the different structures after adding them are basically scary-looking to users who want to keep things simple.

Imagine how much scarier it was when they had to do the WRITEs -and- readjust a ton of offsets and vertex indexes. I removed the scariness and difficulty of the offset adjustments. I did not create the need to do the WRITEs.

* You can see why this is important if you imagine finding a WRITE_LONG/WRITE_SHORT error within one of the blocks users are supposed to copy/paste and modify, instead of within your macro.

There are no writes within my macros to the blocks in question.

What is being suggested here, whether it be a Library Of Writes, or a function that lets you pass the fields as variable settings, is totally distinguishable from my macros. You could use such a Library Of Writes, or functions that do the same, without using my macros at all, and you can use my macros without using any such library of WRITE tools. There really isn't much of an overlap.

Now, that all said, well, to do the functions as you suggest rather than a Copy-Paste Library would require many hundreds of variables to be SET and recognized so they could be passed to the WRITE function as parameters. Probably 20-30x as many variables as I set within my macros. I think the effect on runtime would be negligible, as is the runtime of my own macros, but it seems to be a serious issue that needs to be addressed before we can say it would have no drawbacks.

Qwinn

Edited by Qwinn, 08 June 2009 - 11:24 PM.

[Mike1072]

Yes, what I'm suggesting is an addition to your macros that would share the same goal of making these things easier for modders. I suppose I should have said "this would make modding .are files [with your macros] easier" instead of "this would make it easier to use your macros", as that's what I meant. I'm all for abstracting away the menial bits, I'd just like it to go a little further (and then for people to stick another layer on top of that).

Now, that all said, well, to do the functions as you suggest rather than a Copy-Paste Library would require many hundreds of variables to be SET and recognized so they could be passed to the WRITE function as parameters. Probably 20-30x as many variables as I set within my macros. I think the effect on runtime would be negligible, as is the runtime of my own macros, but it seems to be a serious issue that needs to be addressed before we can say it would have no drawbacks.

I'm pretty sure this won't be a problem.

If some of these Library of Writes have been written (I know I've seen at least one), it should be fairly simple to turn them into functions and test them out. I'll see what I can do tomorrow.

[Miloch]

My UB mod runs the ARE Process macro no less than 12 distinct times (and the Vertex macro once), and the entire installation time for the entire mod is 10.094 (and the total eval_pe is 0.658).

I don't see how that lines up with your findings

You yourself said you don't add any containers... I don't know if that's what drives the eval_pe up (though as I said, it doesn't with A64's method).

I don't see any way to improve the runtime of the macros as they exist. Sorry if that's a dealbreaker for you.

It is . Why in Limbo would I want to increase my runtime 2x or 3x without any increase in functionality? I may use your macros for other things, but not adding containers unless it can be improved. And it can be improved, of course, or a method that does the same thing only faster wouldn't exist, but it does. You could start by dropping the redundant INCLUDE for starters, as I mentioned. If you always run it at the start of any macro action, there's no reason to always run it at the end as well, is there?

[Qwinn]

You yourself said you don't add any containers... I don't know if that's what drives the eval_pe up (though as I said, it doesn't with A64's method).

The methodology is exactly the same. As far as any programmatic solution could care, a container is identical to an actor is identical to a trigger. There is no distinguishable difference when it comes to adjusting offsets. A container is no more complex than any of the other sections.

EDIT: Come to think of it, the process should take longest with actors, which I add a ton of in UB. Why? Because actors are usually the first section, which means all other section offsets need to be adjusted. Containers are usually like the 5th or 6th section in an area, and thus the offsets of the first 4 sections don't need to be touched. That is about the only possible difference which specific section is getting added could make to runtime. We're still talking nanoseconds though. /end edit

If I had to guess, the longer run time is probably due to the compiling of my macros (and my macros use some features that I would guess would take an extra sec for the compiler to deal with), but once compiled, additional uses actually probably run -faster- than the method you're favoring. As you said, your macro took, what, 1.9 seconds? If you had to add another 11 containers all over, I suspect each additional container would take another 1.9 seconds, because none of your code would be reusable. Everything except my writes gets reused.

That's why I can run my process section 12 times in my UB mod, plus all the other moddy things my UB mod does, and still have the entire thing only take about 5x longer than your one single container add takes. (And, incidentally, some of my 12 uses of the macro in UB are far more complex than a single container/vertex add, adding multiple actors, triggers, vertexes, etc.)

You could start by dropping the redundant INCLUDE for starters, as I mentioned. If you always run it at the start of any macro action, there's no reason to always run it at the end as well, is there?

It is not redundant. Rerunning the InitVars macro at the end of the outer loop is absolutely required because the values need to be correct for any additional passes through that loop (such as adding another section type). Plus it insures that all the variables are correct after you run the Process macro, in case you want to use them during your writes, which you probably should.

Qwinn

Edited by Qwinn, 09 June 2009 - 02:27 AM.