ONS-AbandonedCity-SedV1

I would like to change some things as I've previously mentioned but I don't want to do that right now and neither Lag nor Sedoy seem to be working on any edits so I sent it to TWC with minor changes.

Failed TWC because it was missing OnslaughtSpecials2_RNH.u. I tried to myLevel it and I got this...

Cmd: obj load file=OnslaughtSpecials2_RNH.u package=myLevel
Log: New File, Existing Package (Package myLevel, Package OnslaughtSpecials2_RNH)
Log: Bad UArrayProperty destruction: ArrayProperty myLevel.ONSPowerCoreSpecial.ForcedCloseActors
Log: Bad UArrayProperty destruction: ArrayProperty myLevel.ONSPowerCoreSpecial.ForcedCloseActors

Any ideas?

Try removing it completely then add it again. Remove it from your map, close the editor, and load it again.

https://wiki.beyondunreal.com/Legacy:Embedding_Code

Removing it would mean deleting all the cores/nodes, right? It does say on that page "Make sure that you're not already using that .u file externally in your map; in other words, make the .u file import the first step of using the actors defined in that .u file. If you already have added actors from that .u file in your map, cut them into the clipboard, save your map, and close UnrealEd.". I can also include it with the d/l but I was trying to make it easier on everyone by embedding it since it apparently is not already on the redirect.

You should just make it a downloadable file to make it easier for other mappers if they want to use this file. It's used throughout on CEONSS, I believe.

Originally Posted by Anonymous[Lolz]

You should just make it a downloadable file to make it easier for other mappers if they want to use this file. It's used throughout on CEONSS, I believe.

I was just about to send the file to TWC and ask if they would put it on the redirect but now I'm wondering if it is going to somehow affect all maps on the server that use the Specials cores/nodes. I doubt it but I want to be sure. Maybe Wormbo (or Pegasus) will see this and respond. I'm also not sure if they would want us to put something they made for the Euro server onto the Omni server without asking first. I think embedding it in a map would be fine but they might feel different about it being on the redirect.

I didn't read the whole thread but it appears that it shows node health on the radar map. I've seen this while playing at CEONSS and it's very cool.

http://www.ceonss.net/viewtopic.php?t=113

Btw, after deleting all the cores/nodes I was able to embed the file with no errors in the log (thanks Anon). I will have to re-add them though and maybe re-do the link set-up. I'll go ahead and do that but I'm gonna let it sit a while to see if Wormbo or Pegasus replies.

It will not affect the server because it's not a mutator (unless you create a mismatch). By embedding it, it will have to be downloaded multiple times if it's used in other maps, otherwise it's a one time download.

Hey there,

For anyone unaware and wondering, OnslaughtSpecials2_RNH is a micro-edit of Wormbo's OnslaughtSpecials2 (OS2) that, on top of OS[2]'s famed node labels and link beam catching functionality, allows a node health indicator to be displayed on players' minimaps (but not on their Map tab) over each node's icon, hence the RadarNodesHealth suffix. While I was responsible for stitching it together, OS2_RNH is a simple code addition based on the tweak _N_ did for his TreetopVillage map, so the substantive work in it is nothing I could legitimately lay any kinda claim to, or expect to have any say about its handling over Wormbo's wishes.
Beyond that, I can only restate my standing and unchanged principle that any map edit, mod or other work I've put out in the UT community is available for all to use n' remix as they please, without even having to ask me about it and whether I approve of it or not, as long as attribution comments are maintained in custom code and use remains within a non-profit and non-political context.

Specifically to recent questions raised here now, for one thing, no, putting OnslaughtSpecials2_RNH.u on the server redirect shouldn't have any effect at all on the operation of other maps there that depend either on the OS1 or OS2 .u package, as those are different, standalone resources.
As for applying OS2_RNH to a map, or upgrading along any other OS version in a new edit, the information here is useful and accurate, but perhaps this guide might help fill in some missing parts regarding properly renaming assets before reintroducing them to UEd when starting with stock objectives.

Whether embedding or including it in maps, OS2[_RNH] is a brilliant n' lean piece of usability expansion for players, so its adoption by more editors is definitely encouraged as part of what many have come to consider the modern ONS standard - along with use of the CustomWeaponLockers, while we're at it . Seeing as all OS versions are roughly 500KB in size, whichever way you include the code shouldn't make much of a difference with today's download speeds in mind (IIRC, the Omni redirect caps at ~100KB/sec). Feel free to ask for any further help or info you might need, either here or on the CEONSS msg. board, if you're still having trouble getting it to work.

Thank you Pegasus for that perfect reply. I will not embed the package but will instead include it with the d/l. For reference though when I did embed it I deleted all cores and nodes but not the link set-up. Instead of copying the items to the clipboard I opened up the unedited version of the map and then copied all the nodes and cores from it into my edit (adjusting for the 32uu offset). It worked fine, at least for offline play. Link set-ups were preserved. Doesn't matter though as I'm going to delete that version.

For some reason I'm not getting the node health icon in the radar map. I tried Sedoy's latest version (which I made no changes to) and they don't show. Is there something I need to do? I really like that feature and think it would be nice to have it in the map.

On another note, I noticed a weird glitch with the lamp posts. I think I know why but I need to look into that before sending this to TWC.

After spending some time with the version offered at the top of this thread, ONS-AbandonedCity-SedV1, it started becoming clear why you're having these problems. The map references OS2_RNH.u externally, but at the same time, when batchexporting its classes, one finds (most) OS2[_RNH] custom code in there as well.
Upon closer inspection, the embedded ONSPowerNodeSpecial.uc is missing the RNH code, so of course that functionality won't be available, but, strangely, ForceDirVolume.uc is nowhere to be found in the extracted classes, meaning the placed FDVs must be the only asset that's externally sourced by OS2_RNH, even though the custom volume's code has remained unchanged from OS2.
Long story short, the SedV1 variant goes through the trouble of referencing an updated external source to no practical effect (because the objectives are running off of embedded OS2 code), while having embedded an incomplete set of the previous version's code, necessitating the external source to also be present so as complement the missing feature (FDVs). If I had to guess the sequence of choices that caused all this, OS2 was probably embedded first, then OS2_RNH was attempted to be overlaid via external reference later on for its added features, all to poor effect.

In practical terms, there's two rational solutions one can suggest here: tear everything off and readd (via embed or include, as per aforementioned guide) all assets based on the latest OS version so that everything works as intended ...or nuke the whole thing from orbit and move on, which might be a bit of a shame, considering a decent amount of additional work seems to've been done atop what was present in the first-release V1 edit that my notes show went live back in April 2015.
While I did give the former option a quick try and soon managed to get RNH functionality to show, it bears mentioning that removing and re-adding the placed FDVs requires rebuilding geometry and lighting (atop of the paths rebuild that's needed for the objectives), which the map was very hostile about, turning about 5-10% of its BSP and st.meshes into invisible/HoM surfaces and almost completely unlit pieces of geometry respectively. Clearly then, this is doable, but pursuing it further will require patience and possibly a number of bug-squashing micro-adjustments, so it's up to you to decide how you'll move ahead.
Lastly, a third, hackish option might be to just leave this mess as tangled as it is for later, slip into the embedded ONSPowerNodeSpecial class the RNH functionality from within UEd and hope nothing else breaks while moving gingerly forward. Understandably, few have the patience or taste for this kind of, umm, mapping Jenga, but I'm just stating it here for completeness' sake.

Hope that helps your decisions.

Okay that makes sense. Thanks for looking into it. I really appreciate the help. This isn't my map, ofc, but I'm the one trying to get it on the server and I don't like to do things without doing them right. Gotta cross the tees and dot the eyes, . Seems like every time I go to make some simple changes to a map in turns into something that goes on for months. I hope I've learned my lesson.

I would prefer to continue on with the SedV1 version. My choice would be to remove all references to all OS versions and then re-add the RNH one. Other than the cores/nodes and the FDVs what else would I need to remove? Do you think if I remove all that then rebuild and close the editor that it would remove all of the OS code embedded in the map?

Rebuilding is, ofc, not a problem in itself as it only takes a minute or so and I wouldn't submit a map for the server without doing a full rebuild but the errors you're getting are troubling. I didn't notice them after my rebuilds but I didn't do a full walk-through of the map so I could have easily missed them. The only things I changed from SedV1 are fixing some broken zones and setting cleartofogcolor to true for all zones. Did you save that copy? If so will you look and give me the object name of a brush and SM that are broken so I can see what to look for (or take a screen shot with radar map showing location). I'm not asking for a list of all the ones you found. I just want to compare to my edit to see if I'm getting an error in the same place. I can then do a walk-through of the entire map.

As far as ForceDirVolume... "used to force UTVehicles [of a certain class if wanted] in a certain direction". Is that something you added in the RNH OS? Nice feature but I'm not sure if that's really needed for a UT2004 map. I could re-add them, though.

Originally Posted by Binger

[...]My choice would be to remove all references to all OS versions and then re-add the RNH one. Other than the cores/nodes and the FDVs what else would I need to remove?[...]

The ONSPowerLinkOfficialSetup placed actor, per the guide.

Originally Posted by Binger

[...]Do you think if I remove all that then rebuild and close the editor that it would remove all of the OS code embedded in the map?[...]

As long as you saved the gutted edit before closing, I know it will.

Originally Posted by Binger

[...]Rebuilding is, ofc, not a problem in itself as it only takes a minute or so and I wouldn't submit a map for the server without doing a full rebuild but the errors you're getting are troubling. I didn't notice them after my rebuilds but I didn't do a full walk-through of the map so I could have easily missed them. The only things I changed from SedV1 are fixing some broken zones and setting cleartofogcolor to true for all zones. Did you save that copy? If so will you look and give me the object name of a brush and SM that are broken so I can see what to look for (or take a screen shot with radar map showing location). I'm not asking for a list of all the ones you found. I just want to compare to my edit to see if I'm getting an error in the same place. I can then do a walk-through of the entire map.[...]

My test involved removing/cutting nodes, cores, the link setup actor and all FDVs from the SedV1 edit supplied at the first post of this thread, then rebuilding paths, followed by geometry (optimal setting) n' lighting (RGB) too, and, lastly, saving the modified map in preparation for reintroducing OS2_RNH and pasting the assets back in. It's at the point of saving, closing UEd and reloading the map that I noticed during a quick ingame preview a portion of geometry right outside the red core to be exhibiting the aforementioned badly lit and/or HoM behaviour, but it was plain enough to see and quite prevalent around the area. I didn't keep any saved copies after I realized how fragile the situation was in terms of rebuilding because my main focus was determining whether OS2_RNH functionality could be added (restored?) to the edit, which was indeed the case.

Originally Posted by Binger

[...]As far as ForceDirVolume... "used to force UTVehicles [of a certain class if wanted] in a certain direction". Is that something you added in the RNH OS? Nice feature but I'm not sure if that's really needed for a UT2004 map. I could re-add them, though.

The ForceDirVolume class was added to OS2 by Wormbo and simply left unaltered in OS2_RNH. Its purpose is to mostly prevent flyers coming to an unexpected, and usually quite painful, stop when their pilots happen to discover the map border's blocking volumes, so as an alternative to that, FDVs will gradually decrease chosen class actors' velocities once inside them down to zero and then towards the direction defined in their properties.
While FDV analysis is a bit beyond the scope of this reply, the custom volume does have its uses in ONS maps, usually to pose a more graceful alternative to blocking volumes. Still, as an avid pilot, I sometimes tend to count on the rough bang upon hitting a border-aligned blocking volume to adjust my direction in an expected manner so as to avoid an incoming homing rocket, something which the FDV is liable to foil by just leading the flyer back right into the missile. In other words, there are situational cost n' benefit tradeoffs to its adoption over BVs.

Originally Posted by Pegasus

The ONSPowerLinkOfficialSetup placed actor, per the guide.

Okay, I remembered that one. No supplement in the map so I got everything.

Originally Posted by Pegasus

As long as you saved the gutted edit before closing, I know it will.

Done. Thanks.

Originally Posted by Pegasus

My test involved removing/cutting nodes, cores, the link setup actor and all FDVs from the SedV1 edit supplied at the first post of this thread, then rebuilding paths, followed by geometry (optimal setting) n' lighting (RGB) too, and, lastly, saving the modified map in preparation for reintroducing OS2_RNH and pasting the assets back in. It's at the point of saving, closing UEd and reloading the map that I noticed during a quick ingame preview a portion of geometry right outside the red core to be exhibiting the aforementioned badly lit and/or HoM behaviour, but it was plain enough to see and quite prevalent around the area. I didn't keep any saved copies after I realized how fragile the situation was in terms of rebuilding because my main focus was determining whether OS2_RNH functionality could be added (restored?) to the edit, which was indeed the case.

Okay, I'll just check the map carefully when I'm done. I'm not too worried about lighting errors (unless it's extreme), there's no ambient brightness anyway, but HOM is a no-go. I was getting HOM when zooming with the LG but changing cleartofogcolor fixed that. I also get a lot of HOM in the editor on this map but I get that in some other maps also. The only reason I can think of for why you are getting HOM in this case is because of the order of brushes or maybe because none of the brushes are snapped to the grid.

Any reason why you rebuild separately instead of all at once?

Originally Posted by Pegasus

The ForceDirVolume class was added to OS2 by Wormbo and simply left unaltered in OS2_RNH. Its purpose is to mostly prevent flyers coming to an unexpected, and usually quite painful, stop when their pilots happen to discover the map border's blocking volumes, so as an alternative to that, FDVs will gradually decrease chosen class actors' velocities once inside them down to zero and then towards the direction defined in their properties.
While FDV analysis is a bit beyond the scope of this reply, the custom volume does have its uses in ONS maps, usually to pose a more graceful alternative to blocking volumes. Still, as an avid pilot, I sometimes tend to count on the rough bang upon hitting a border-aligned blocking volume to adjust my direction in an expected manner so as to avoid an incoming homing rocket, something which the FDV is liable to foil by just leading the flyer back right into the missile. In other words, there are situational cost n' benefit tradeoffs to its adoption over BVs.

Cool. I noticed they were mostly in places only flyers could reach. I might put them back in but probably not. I rarely run into blocking volumes. I think most people learn maps well enough to know where they are.

I found 6 more zone portals (four zones) that were not working. I've fixed that so now I'll work on putting the cores/nodes back in with OS2_RNH. Thanks for the help Pegasus.

I embedded OS2_RNH and got all the nodes, cores, and link set-up back in. Then while looking into the FDV thing I noticed places where I could get outside of the playing area. Sigh. Those will have to be fixed because if I found them then WMD40 will too for sure.

I really like the FDVs after testing them on SedV1 but now that I've deleted them all and re-added OS2_RNH I no longer have the FDV option when adding a volume. Grrr. Either I screwed something up or the FDVs are not working for OS2_RNH. I'll try it in another map, something simple just to see if I get the option for FDVs. I suppose it's also possible my copy of OS2_RNH is the problem now but I'm sure I extracted it from cache after playing on CEONSS.

Originally Posted by Binger

I really like the FDVs after testing them on SedV1 but now that I've deleted them all and re-added OS2_RNH I no longer have the FDV option when adding a volume. Grrr. Either I screwed something up or the FDVs are not working for OS2_RNH. I'll try it in another map, something simple just to see if I get the option for FDVs. I suppose it's also possible my copy of OS2_RNH is the problem now but I'm sure I extracted it from cache after playing on CEONSS.

With both OS2 and OS2_RNH if you close the editor without adding an FDV then that option will not be there the next time you open the editor even if you added OS cores/nodes. Fuck. There is no way I'm going back and re-doing everything I just did. If I embed OS2_RNH in another map and then add an FDV I can copy that into this map and then close the editor and when I re-open the map I have the option for adding FDVs. Do you think that will be okay, Pegasus? Or after already embedding OS2_RNH into the map what would happen if I just load it into the editor to get the FDV option? Maybe I should just start over and not embed the file. Sigh.

Edit. I'm being stupid. It's late. Not thinking clearly. Gonna start over tomorrow without embedding the file.

The editor strives for space-saving efficiency in any kind of external resource used in a map, be that a texture pack, a st.mesh pack, a .uax, a .ukx, or indeed a .u package. This means that, while packages can contain a big array of assets within them, only those used in a saved map will be referenced and, later, seemingly available. To offer a very basic example, one of the texture assets that Torlan references is AbaddonTerrain.utx, and if you go to the tex browser, you might be led to believe this pack only contains 2 textures. If, however, you manually choose to reload that particular pack, you'll see you're now offered its entire, true contents. Storage efficiency through limiting resources to only what's actually used!

In other words,

Originally Posted by Binger

[...]Or after already embedding OS2_RNH into the map what would happen if I just load it into the editor to get the FDV option?[...]

...this, but without the overthinking it . If you've referenced the pack - any pack - externally and only used some of its features (thereby making it look like the rest aren't available anymore), simply reload it and the full complement will now be offered ...until you don't use some of it, save and close, which will prompt UEd to only remember what matters again. If you've embedded/myLeveled your custom assets instead, while I haven't actually done this, reason suggests repeating the standard package.u** myLeveling action should do no harm to what's already in the map, and allow you to use the rest of the pack's assets too.

Clear your head, try that tomorrow, report if you accidentally arranged nodes in a pentagram and summoned an Elder God from the nether realm.

Originally Posted by Pegasus

Clear your head, try that tomorrow, report if you accidentally arranged nodes in a pentagram and summoned an Elder God from the nether realm.

*snicker*

The Gods don't answer me anymore. I think they screen my calls.

I've seen that a map will only load what it needs from a texture and SM package but I was thinking that it would keep everything available from a system file embedded in the map. There is no "Load Entire Package" option in the actor browser. Good info. Thanks.

I read that it's not good to embed something twice so I was thinking that might also apply to loading something after it's been embedded.

I'm not sure why I was so intent on embedding the OS2_RNH. I went back to an earlier save that was after I had deleted all the OS stuff but before I had re-added it and I worked from there without embedding the file. I will just include it with the d/l. I had to re-add all the cores and nodes and do the link set-up but I got it done. Now I need to fix the blocking volumes where I can get outside the map then look into adding FDVs.

So far no HOM that I've found.

All the lampposts where set to block things but there was no collision on the mesh so it was causing the camera to jump when I drove through them. There is a version of that mesh on Urban that has collision but for some reason the one in this map is a myLeveled version with no collision (I've seen the same thing on other maps). I don't think they should block things anyway, especially since there are over 200 of them in the map so instead of replacing them with the ones from Urban I just set all collision options to false.

Sent to TWC.

I already patched 3 holes in this map and now WMD40 has found several more, plus a few other issues. I'm done working on it. If anyone else wants to fix those things I will forward his email to you.

Edit: PM not email.

Btw. Thanks for all the help, Pegasus.