Remnantmods

New version out 2.1.5 build 3396. Adds Sound Scenery to BSP viewer, collapses unused meta editor reflexives and some other jazz.

xzodia wrote:It would be great if objective scenary moved with the objectives...

Just the flag bases you mean? Being that it doesn't have to be there it could cause problems on edited maps and more difficult to implement as they are not directly tied together. Anyways, it just takes one extra click.

Troy Mcclure is correct, it is more important to add features that are hard for the user to do themselves then to code in features that are just redundant and can be performed by the user in a matter of seconds. I will download this version and try to test all of its features and report back any bugs that I find.

In that case it would be better to simply have a 3D cursor to place things!

Because moving objects with the keys isn't very fast and precise

i mean this:

This version cant open onyx maps in visual editor.

Onyx is useless it isn't even gonna get updated anymore...

Well i have found more use for it then most people i guess, and now thanx to Demonic i have a working, system linking onyx made map.

Add that to the fact that i can edit any map with onyx, makes it useful.
I could stretch boxs, crates, and stuff the old fashion way but it takes 3 times as long.

Back to the topic: Troy If u can add scaling to the visual editor some how, that would be great, but it would have to adjust the scale in scrn meta to work properly.

The only feasible way that he could add scale into the BSP viewer, would be to use the scale value and the scenario meta, and that only works for scaling the visual mash. Which would only be useful for scenery and things that cannot use collision or physical collision.

i was going to add scaling, but it's done in so many different places. I have all the SCNR scale values loaded in the BSP viewer, but then there are the MODE scales and more. Also, I figured DirectX would have a scale option, but couldn't find one. So it's not high priority ATM.

As for Onyx maps not loading, if you post a patch for one into my folder on the MISC server, I will see where it's getting stuck at.
I assume that you are talking about build 3396 as it fixed some loading issues.

neodos wrote:In that case it would be better to simply have a 3D cursor to place things!

Because moving objects with the keys isn't very fast and precise

i mean this:

So do you just want the lines/arrows implemented for every object?
Not sure what's so unprecise about the keys? I am going to change the X,Y,Z,Rotations to text boxes so they can be manually entered as well. On th to-do list

JacksonCougar wrote:The only feasible way that he could add scale into the BSP viewer, would be to use the scale value and the scenario meta, and that only works for scaling the visual mash. Which would only be useful for scenery and things that cannot use collision or physical collision.

So you havnt tried to scale anything in scrn lately have you. :p

Time does not change the outcome.

well i would like to prove my point but it dosnt work lol.
But ask twin reaper how he resized his plasma doors in one of his conversions, he told me it worked and i tested it. He was right, the scale function worked like it was suposed to.
Ill have to see what plugin it was, but i just tested preys scrn and it only scales model.

Well sence this isnt working, i guess my request is to link shit up right in the plugin so that it will work, at least with the simple objects, (6 sided) or cube objects.

Its unnecessary.

Your right, but it would be nice to have an App for quick scaling. Maybe an aplet would be just as good.

The scale value in the placements of the scenario only scale visual mesh and bullet collision.
Physical collision will be untouched.

my mistake i thought it had been fixed to edit the phmo.

Ogrish wrote:Testing now.
bsp faces option dont work.

I know this post is a little old, but is this still the case? And why do you have an ERA POSTION instead of a camera position??

Here is something to note, that drove me nuts for an hour. Entity doesn't read SIDs correctly. You need to make sure it checks the length too.
No the length is not a short. Now the reason you must make sure stringid[Index].Length = Length is because if you don't, any value that is between 0 and the SID count is considered a SID to entity. Since there are a few values like that in the spas tag, entity had be believing that there was a sid there, when there really wasent.

Grimdoomer wrote:Here is something to note, that drove me nuts for an hour. Entity doesn't read SIDs correctly. You need to make sure it checks the length too.

Code: Select all

public struct StringID
{
   short Index;
   byte Null;
   byte Length;
}

No the length is not a short. Now the reason you must make sure stringid[Index].Length = Length is because if you don't, any value that is between 0 and the SID count is considered a SID to entity. Since there are a few values like that in the spas tag, entity had be believing that there was a sid there, when there really wasent.

Noted.
Although I don't believe I've come across this code at all in my travels through Entity's code. what unit is it contained in?
So, would I be correct in assuming by looking above that the length is actually 16 bits in size and someone just assumed that the 8 bits before were always null, when in fact they are part of the string length?

Entity should already think of SIDs as being 16bits long, however in reading the SIDs it would seem that is chooses to ignore checking the length of the SID reference to the length of the string, so many false positives are being shown in the Entity Meta Viewer because of this failure. It should be checked to see if the index leads to a valid StringID string, and whether the length of the string is the same as the length in the value. If not then it should output some error message to lets however is messing up the plugin that it is probably not a SID reference at all

I'm not sure if this is what Ogrish was getting at, but it would be great if the BSP viewer could scale the models (values in the mode tag) of parallelepipeds. Once the user has them sized and positioned as desired in the viewer, then it could apply the model dimensions to the phmo and coll (parallelepipeds have uniquely simple properties in H2 that make their mode, phmo and coll trivially easy to resize). If this were possible, we could build entire maps within the BSP viewer, without the slow process of changing all the dimensions manually and verifying on the Xbox.

We have crude tools to do this right now. It's something like trying to solve Rubik's Cube in a completely dark room, where the lights come on for 1 second once every couple of minutes. This would be like turning on the lights.

I know this is basically what Onyx was made for, but I think it would be faster this way, and it seems more in line with your goals for Entity. I'd certainly make more maps with it.

Getting proper rotations was a huge step forward, by the way.

Seriously a bad idea...

Since you have provided no reasons, I cannot understand what you mean.

This is what Troy has said:

troymac1ure wrote:I am trying to make the BSP viewer very in depth so that you do not need to use the Meta editor so much.

...My main focus is on improving the BSP editor to a very advanced level.

My suggestion is in line with his intentions, and it would make custom map creation much faster and easier. I see no downside.

It's a specific function aimed at a specific niche of modding, that cannot be easily coded into a application without simply breaking other models. It's all around a bad idea because it is a feature that can break other tags, is not really needed, and is entirely improper. I wouldn't mind if it scanned the map-file for changes and showed those changes, so another application can edit the map concurrently, but beyond that, it's a bad idea.

JacksonCougar wrote:It's a specific function aimed at a specific niche of modding, that cannot be easily coded into a application without simply breaking other models. It's all around a bad idea because it is a feature that can break other tags, is not really needed, and is entirely improper. I wouldn't mind if it scanned the map-file for changes and showed those changes, so another application can edit the map concurrently, but beyond that, it's a bad idea.

If it just changed the MODE scale value it wouldn't hurt anything. If untouched, it would just stay at 1. If someone wanted to bugger with it, eh...

As for the scanning, if you meant in the BSP Viewer, it would have to be implemented through a button as real-time I think would take a toll on the viewer. As for the Editor, it probably would be okay. Which were you thinking? (Not that it's needed since Entity can do everything )

Troy and I fixed the sbsp viwer, it now works on windows xp 64 bits!! probbly on vista and win7 too :p the fixed build was not posted yet though.