Obsidian Conflict Bugtracker

View Issue Details Jump to Notes ] Wiki ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000158Obsidian Conflict[All Projects] Feature-Requestpublic17.03.2013 05:1317.03.2013 19:19
Assigned To 
PlatformOSOS Version
Product Version0.1.3.5Product Build 
Target VersionFixed in Version 
Summary0000158: @entity-scripts: add hammerID{} and ModelID{} hooking

(this post is for worfox, please read it if you find time :D )

As the title says, i beg you to simply add support in the OC code
to hook entites by their HammerID or ModelID (_modify script). Why ? Because hooking them by Origin{} is super dangerous and bigger map changes will always break the map / make it unplayable. Im just changing the Return_to_city17 series to be as challenging as outhouse and i broke the 1st map like 4 times, because entities just have the SAME coordinates. Some sprite was stuck inside another entity and moving it deleted a crucial trigger ... or deleting an ammo box deleted the shelf instead ... since the fewest ents got names, coordinates must be used VERY often but are no unique attribute. This is very depressing :/

- I wanna rewrite the oc_modify_generator.exe if we get HammerID support to create a more reliable tool / +with better brush-ent modding.
- I wanna create _modify scripts for the whole BM-campaign to be playable and a challenge in OC if thats possible (must look into it how many ents need to get replaced)

I know, since the new (source) Hammer verison its not that easy to find out HammerIDs on objetcs in decompiled maps, because hammer isnt showing them anymore. But for decompiles you should use the new modify generator then. ingame you can find out hammerID and brush-modelID very easy with "ent_text" and "ent_dump !picker"

Why did i gave this "high" prio ? Because i think it would be great to have a reliable modify option and / or generator tool - after there arent many active mappers working on projects and players got so bored about most of the maps, players get even more bored because there wont be many new maps thus the mappers arent very enthusiastic in making new maps because players interest is dropping and so on and so forth. Having a tool of such we could just spice up some of those maps with wonderful landscape and hours of brush-work but lack of challenge (like the c17 series ^^) and that would produce tons of "new" playable content with kinda little work. I mean beeing able to change all entites is SO powerful.

So i suggest adding HammerID{} because EVERY entity simply got a HammerID and cant be missed. So you can even MOVE some entites around without having to delete them from an old position and Add{}ing them at the new position lol.
About ModelID{}. I am talking about the "model" = "*128" attribute from BRUSH-entities. Since the only secure way of playing around with brush-entites is using their modelID. YOu can do everything: take a func_breakable and make a trigger out of it... take a trigger_once and make a trigger_multiple out of it with other Outputs ... just everything besides changing the shape of the BSP subtrees referenced by the modelIDs.

For now you needed to do this:
Remove { Origin { "453453 23432 3242" {} } }
Add { Origin {
 "453453 23432 3242" {
 model "*128"
 classname "trigger_multiple"
 blabla ....
} }
and thats very insecure and a bit confusing :D. After you could do this:
Modify { ModelID {
"*128" {
 "classname" "trigger_multiple"
 "add an output what ever...."

One MORE reason to get away from the dirty Origin{} method:
Its even inaccurate ! eg. for point entites beeing stuck inside a prop it just randomly deletes what it wants lol. i deleted an ammo box from a pos like
-9000 8000 325 and it deleted the shelf instead ingame from
-9000 8000 301 ... thats an offset by 24 units Lool !? does it even take care of the z-value ?

aaah and BTW ... the entity parsing algorithm should always IGNORE newly added / "modified" info_nodes and stuff because they cant be changed after beeing baked into the map's node-file. just for security reasons - most of the tie you'll hit some other entity with it because they dont exist in the map anymore.

 Well thanks for listening. Hope to read from you ... and happy coding :D
greetings, Rei

PS: btw if nobody cares about supports / suggestions anymore because nobody will ever read them or the project is frozen ... just tell me and i can stop writing all that stuff
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
Rei (reporter)
17.03.2013 06:02

Ah wait i forgot something important - for those who say now: "hey what? putting _modify scripts for some official maps on our/any server ? maybe some people wont like the modifications? no thanks."

What about adding official support to load different or even NO _modify script ? like after/before the map loads. lets say oc_sewers - a vote pops up with the _modify versions the server found in the map/cfg folder:

[1] oc_sewers (no mod)
[2] oc_sewers (Rei edition)
[3] oc_sewers (worfox edition)
[4] oc_sewers (hardcore edition)

And clients press 1,2,3,4 before the map finally loads (or vote after it loaded?)

I mean, seriously - we lack a bit of exciting new content ... most of the time just "lobby-maps" get overplayed and people quit OC because they say they have played every map to often :( I really love this game its the best team FPS i ever played and i want it to be played a loooong time by many people :)

I mean ... just imagine ... somebody voted (again^^) oc_wildfire or starship-troopers, and some people are just like - wtf im bored i leave. but then they see a popup and surprisingly somebody created a modify out of the blue:

[3] oc_wildfire (nightmare edition)

And they all shout OMG cool all vote 3 !!! Lets beat the unbeatable ^^. Well, at least i can imagine that as an ultra cool feature. MUCH new possibilities to play around on server. much new content / modes to play ... user contributed _modify scripts installed on the server (the good ones)
ofc we need an easy and solid way to modify. i mean. having the entity data inside extra text files is not THAT odd ... it looks kinda same inside the map files. so why uploading 4 different map versions to the server

for example - again regarding return_to_city17: for now i added a very challenging fight around the power-relay, limited lives and nice climbing puzzles / crate stacking puzzles (at the cliffs) which need to be solved to complete the map ... and some surprises :D ah and nicer fog+dynamic shadows and stuff

sleep well ... byebye, Rei

PS: just dont take me wrong .. i love you ... the game ... the maps ... i just want to create new content and possibilities out of nearly no work. reasons for replaying maps. because mapping is much work. you want new content - make the creation of new content easy. and please dont be that skeptically now im just trying to help
User avatar (0000277)
TESLA-X4 (developer)
17.03.2013 07:58
edited on: 17.03.2013 08:00

The issue you mention where origin modifications are unreliable and typically end up affecting neighboring entities has already been partially, if not completely resolved in both SVN and Hotfix 4 (which hasn't been publicly released yet).

The reason for the strange behavior was that the code was searching for an entity near the specified origin, within a radius of 0.1 units. This may seem small, but when multiple entities overlap the origin, the entity with the smallest entity index will be operated on, leading to the perception that the MapAdd system is buggy and unreliable. This has been changed so that strict origin checks are enforced, only falling back to the older behavior if no entities were found to have their origins match the given one exactly (to clarify: if any entities are found to satisfy the strict origin check, then the old behavior that potentially affects surrounding entities is NOT invoked. The old behavior is essentially a fallback now). Origin-based modification and deletion should be possible on any entity that exists in-game (so cubemaps and other similar entities cannot be modified as they have already been removed from the map during the compilation process), with the exception of physics entities (which always seem to have been simulated and moved by the time our code gets executed).

And regarding the use of ModelIDs, while it is possible to support those, their uniqueness cannot be guaranteed as there exist some server plugins (e.g. Stripper: Source) to make changes directly to the entity lump even before our own code gets executed. Such plugins are able to make their changes without our code being able to detect said changes. This means that searching by ModelID can become unreliable if the server plugin injects new brushes with duplicate ModelIDs (all unmodified BSPs will never contain duplicate ModelIDs even if the brushes are identical copies). With that said, it is still possible to use it if due care is taken.

Neico, can we have an alternate theme with brighter colors? It gets hard to read this text as the contrast between it and the background is rather low.

Rei (reporter)
17.03.2013 19:19

Hey Tesla !

Nice to hear. Didnt knew you implemented some improvements already. :)

I didnt knew about the addons messing around with model-IDs. So what do you think about the hammerID hooking ? Isnt that an ultimate unique key ? And will be super powerful in combination with oc_modify_generator 2.0 written by my in Java if nobody else does. i guess implementing support for HammerID{} Should not be very hard i guess ?

And what about the "on map-change _modify vote popup" ? :) but ok - thats a completely separate topic. we dont need to discuss this here ;)

greetings, Rei

Copyright © 2000 - 2024 MantisBT Team
Time: 0.0788 seconds.
memory usage: 8,364 KB
Powered by Mantis Bugtracker