Topic: Is it possible to randomize the guarding points of the enemies?
so each time the game experience will be different.
Like RTCW Single Player but together ! | Currently there is nobody on 7 available servers. (While there are 3 private servers running)
You are not logged in. Please login or register.
so each time the game experience will be different.
Yes in theory, but currently it is not. It would take many months to script. I rather spend time on making new maps. And randomising does not work everywhere, eg. Corridors.
If you play with respawning enemies, you already get fairly random once they have spotted you.
Maybe one day it might happen, never know.
thats one of the things that I wanted to implement, but it would take a lot of time, so I'm afraid this will not happen in the near future
Yes. But it totally depends on what to do. If we want to select between 2-3 spawn locations its not that much. Half of the ais cannot be random anyway. But if we want the whole map and all actions be random it is close to impossible. I have implemented some random locations in my maps. But it is hard to change overall impression. But ofc it is good if you cant aim all by memory. We have all the tools we need but its lot of work.
Some tools might make it fairly fast I can see. Spawn all AIs with one command. Print ainames ingame over their head. Dumping ai_marker with targetname. Extra spawn event eg firstspawn that only execute at real first spawn of an ai or a command to ensure this is executed once only. These would cut tons of time of developing. It would be less work than adding the reinforcements.
Then just dump markers and copypaste the triggers. Also first of the random spawn is ofc blank because it is where it is now.
The only real work if even, is to find a way how to parse all available guarding points- that would probably fall on a mapper.. Rest is just in g_InitGame (map load) by parsing all available guarding points for that map, randomizing them (rand()) and then intercepting those new spawns at G_CallSpawn function. No rocket science, just some thinking and then tweaking it..
That would additionally mean that until map is (re)loaded guarding points stay the same..which means that, if a typical map_restart is introduced later on rather then map load (on failed mission) guarding points would stay the same till different map or new map is reloaded..so in that case, regulars would quite quickly figure out that if they fail to finish the map they'll have it somewhat easier the next try as they know where they should expect AI patrolling..so it's a "little" helper if going gets too though etc.
We can make it with random accum, then it is always random. Mapper would place the markers. Your coding idea would probably be less work, but it would only limit to spawning. Cannot do easily random crouch, run, throw nade etc. At start.
Hmm. Maybe it is not so bad idea. I have used accum random and then used teleport targetname. But if I did not need to do this it would save half of the dev time.
What if the new approach is: if not markers present ignore. Check for each ai separately targetname ainame_rs1 and ainame_rs2 and one random is empty (default point). Then teleport to the markers. Mapper would add markers with the tools I presented above.
So in word of example
Following ai_markers are added nazi1_rs1 and nazi2_rs2 in ents.
Random 1 nazi1 stays same
Random 2 nazi1 will teleport to nazi1_rs1
Random 3 nazi1 will teleport to nazi1_rs2
If we want to do random actions or such other things, we can just use the old way with accum random. Now all is needed to run ingame dumping markers to apply. Do not make other random than individually for each ai.
Also I can tell by experience that you will run out of space and time if you have more than 3 random.
Edit.
This would cut the need for firstspawn. But still each ai script would have to be checked that nothing gets ruined. If there is any actions this cannot be used. Also possibly ai_marker count limit might need to be raised. Maybe if I get the tools I want I can make a run.
The way I imagine is that mapper would export list of available entities (soldiers) and list of available zones. Owner would then etc select few zones and pass entities and zones to the game by etc config, game would grab both of that lists and then randomly put X amount of entities (soldiers) at available random spots.
That way mapper would have full control over which entities (ai wise) should be left intact since they're wired to a trigger/action and simply add more ai's that aren't tied to any special function and aren't trigger depended to any action..they're just random AI's that spawn at one of available locations that was randomly selected from list of (available) parsed zones and injected at load time as virtually created game script that's just additional layer on top of existing script etc.
So basically full control and map options are what mapper decides and owner only works with list of available options that mapper pre-set and are allowed to be randomized so in that way, owner nor game can't mess with base line of how mapper envisioned the game flow.
That's the simplest, fastest and most elegant solution (at least in theory) I can think of currently. In practice it would probably mean that location would be passed as vectors (YXZ + angle) so that would mean that maps without a source would be painful to sort as one would have to go in game and establish 4 vectors by using /where command as spectator to form a square from vectors which would then be passed to a game as location and random value of X ai's would spawn in it. For maps with source it's easier since you can get vectors directly from map editor etc.
I want to explain my idea.
For example, zone A, there're three valued points for guarding. I rather put two guards to defend and they may change their positions each time. So there should be three strategic combinations.
If there're several possible zone for randomizing, the game should be pretty different each time and not only hard to memorize but also it is more challenging.
It's clear what's your idea, it's how in theory it could be implemented that's bit of a challenge.
I really don't like the idea using XYZ vectors. I doubt anyone will want to implement those coordinates. The combinations are so much, height differences are many and the chances of screwing up is massive. Then we want to remember tons of details placed in there, other entities, Ai's etc. Besides the amount of space really does not do justice to this. Anyone who would look at the most inside places with reinforce 2 can see that almost all possible places to spawn someone has been already taken. Type XYZ wrong, AI dissapear etc.. I just see so much work and result in so much problems unless we do each spot individually. I think dumping markers is faster to do anyway.
However some bit I found from your idea useful.
1. List of randomiseable AI's zoned in x amount of zones.
2. New marker entity without any individual name. Categorise these markers into zones. eg. key "zone" "1" etc.
"classname" "spawn_marker"
"origin" "0 1 2"
"angle" "5"
"zone" "1"
"classname" "spawn_marker"
"origin" "100 1000 200"
"angle" "90"
"zone" "1"
etc.
Ofc remember to use the original location as a possible spawn location too!
3. Then dump these entities ingame with a /command.
4. Then randomly place these AI's into the zones markers in code.
There's not much difference between both methods, yours is just more sane since it leaves less space for errors on the end user. But you're right, instead of passing coordinates, mapper could sort those places and simply pass list of those markers.
In fact, that stuff could reside in an a separate script for which would then server on map load time simply check if it's there and if it is, grab the stuff and randomize and populate values. That would mean mapper would control it all so any error could only be done on that side and easily fixed by deleting marker from the script by owner so that value would never be populated - solves the longevity support as end users aren't depended of mappers if/when they wont be around.
Additionally this method would give owner a chance to run default game (by removing the script) or a randomized one etc.
EDIT: Nah, ignore default locations..those should be reserved for persistent ai's..ones that are by default expected to be there..albeit nothing is stopping you to add a marker near it..and for the record - 1 marker would = 1 spawn. Function would count the sum of all markers and then take half (rounded up) or third of them that would be used to spawn AI's in..that could easily be skill depended so at lower skills it spawns less random players then at high where etc 60% of available markers would be occupied (in use)..naturally needs some more math but just to give an idea.
I am ok with new file for random markers and configureable using. A cvar should be there to be able define % or disable it. Dont want the user edit any files unless it is a must.
Point of using default locations was to save 1/3 of the work. Do mind that only the Ai whose default location it is should use it. 1/3 chance it simply would not teleport. This is simply to cut on work, ofc it is more random if not used.
But maybe if dumping markers would be as fast as I demonstrated it would not matter. Binded to a key and nothing else needed to do, nothing to fix manually. One key for each zone. Just run around bashing buttons. I can do this if I get the tools I need. The amount of random markers could be just about anything then.
Maybe if you want to evolve the vector idea (to extra random) there could be a code that makes the ai walk 1 sec to a random direction from the marker, stop and facetargetangles with the last marker. Maybe this could be when the random is set to >80% by admin. But truth is that most ais you meet are navigating on their own and that is very random. Because one shot and they have their own will. The Ais you see first are the only that really matter.
It's less work to add new stuff then deal with potential bugs it would cause when modifying existing stuff and yeah, it's simple to add markers but you have to be spec if using /where command as otherwise it gives wrong coordinates. One thing to note is that there probably wont go over occupying 20 or so slots..as there are game limits etc.
But yeah, I'll see if I can squeeze this in my schedule this week and sort it out. FYI: You don't need to do anything for the moment as I can hardcode markers for local testing and all depends when I'll have time.
No. Why do you insist on making everything hard? Hardcode, why on earth? Slots... Huh? Markers should affect game entitity limit that is 1024, see /entitylist. Never needed /where fyi.
/dumprandommarker zone 1
just like /dumpcoopspawnpoint. As an allied. Give exact origin and angle of your aiming direction. And a zone key. Automatically added to ents file (or new file). Should not need where or type anything!
You don't need to do anything for the moment as I can hardcode markers for local testing..)
Emphasising on local.
Okey, good luck.