Jump to content

nonickch

Members
  • Posts

    66
  • Joined

  • Last visited

    Never

Everything posted by nonickch

  1. The remainder of your squads are always there afaik. The dead ones are replenished with new recruits and they're available for you on the next map. I think the presets don't use the same squads, but I always swap for them. If a squad is locked, you can just replace soldier for soldier. The allied campaign is using two different armies, so not everyone will be available on missions that use only one army. Don't forget to move your soldiers from obsolete units. I had campaigns where I used the exact same crew in various tanks in all the maps. 100 gunners/drivers make tanks and td's deathmachines.
  2. Yup, tracking them is pretty much the only way to get those beasts down with the given weapons. If it was just 1-2 of them it's pretty easy, you take 2-3 tanks and start running around them. Whomever they are trying to shoot runs in high radial velocity (full speed @sub50m), the other two shoot it low. But then it's the issue of those tigers (or was it panthers?) who come from the edge of the map and tend to object to you playing the rabbit.
  3. didn't mean to extend over the mapsize.
  4. Yes, I just run the numbers and I was indeed wrong. I put 2 squads, one standing up @150m and one kneeling @100m off a pak40 with a gunner of 60. Even tho the pak was shooting HE charges, ALL of the men died to the bullet effect. Accuracy of the pak was about ~50% (didn't count). Not a single crater close to the bodies, all shots landed far off. So that's 4/4 The pak was in very slightly elevated position (like .5-1m up)
  5. hell, I live in greece on an island and I got my copy today (ordered when I heard they're shipping). And I should be the last person on earth to get the item. Well mebbe mainland asia could proove slower. lol, the cheeky buggers put $5.00 value on the customs declaration XD
  6. from my experience non-playable parts of the map are exactly the same as the main playarea. The only difference is that you can't directly send your men in there, but you still can do so like you described or when a unit panicks and runs in there. I don't think there's a resource-based reason for the map limitation, since it acts as normal space but with clicking limitations. So It's safe to assume you can just expand the territory rect in your campaigns and finally have that long-range fun you wanted.
  7. where there any other stug's available in the next mission? If not, maybe they were filtered out. They should eventually show up as obsolete, unless someone forgot that part.
  8. the omni supersense the tanks have is only part of the problem. The other part that is present in at's is their uncanny ability to shoot through soldiers. That's right, 3/4 of my soldiers die to tanks/at's from the bullet effect. Not by the explosion, but by the shell going through even while ducking and running (I've had more than once a prone soldier get the bullet effect and the HE round land like 10-15m behind him). Now, put those two things together and you have the supertanks we see in the game. All seeing, never missing. Oh, and I believe tanks of WW2 took way more than two seconds to rotate the turret 180 degrees. Especially the heavy ones. I would not complain much about the sense of the AT's. It should be as much as a soldier, at least as long as the officer stands in clear view scouting things.
  9. I just checked it on the mission editor and it seems that there are only 4 placeholders for tanks in this mission. The Permissions list as USA SPG+TANK=9 while having only 4 placeholders for tanks and 3 for spg's. I expect if you take 4 spg's int this mission you'll also get a stranded spg too. So, it's all up to you how you want to go about solving this one, you either drop the limit to tanks=4 and spg=3 or add the proper placeholder. They are both pretty easy in the editor. MAKE A BACKUP BEFORE EDITING THE MAP. Changing the permissions: Open file, browse ALLY->St Lo On the upper right window expand "ArmyComposition" Expand Permission Delete "SPG/USA+Tanks/USA=9" Rightclick on Permission, Add filter Select Empty_filter and at the properties window below click on the "..." that becomes visible next to the "Filter[] Array" At the window that pops up, Click Add and then Classification=Tanks, Country=USA Click ok, and at the properties window Set Limit=4 Repeat the same for SPG's. That's way 1, you can limit yourself like this (or simply not take 5 tanks with you in unit setup ) Adding the placeholder: Expand placeholders, add placeholder (like adding the filter before) You will notice A new circle appearing on the map. Click the "Editmode: Units" button (2nd button from the right in the bar) and move the circle where you want the tank to appear (prefferably next to the other tanks) Select the new placeholder (should be naed [13]_ALL) and open up it's ClassificationList from the properties window (again like the filter). There just add, set Classification=Tanks. And that should be it. Don't forget that you need to re-start the mission from the campaign selection window for the changes to take effect. I didn't notice that bug since I usually go for quality armor than quantity. It's quite a good strategy since you have to face overwhelming tank odds. [ May 23, 2007, 01:29 PM: Message edited by: nonickch ]
  10. /me whimpers "scripting improvements!" Coding those little buggers to behave is way hotter than actually sending em to blow stuff up.
  11. I lost an entire squad trying to nade that AA from behind the wall. It was the only thing left on the map and I lost the game to it multiple times. In the end after lobbing endless grenades I managed to kill the gunner and my zooka guy could approach the vehicle without getting lazored @200m
  12. Whom do I have to beg so we can get an updated documentation on the scripting commands? It is quite obvious that there are a few undocumented features. For example creategroupbyrect is overloaded to accept UNIT as first param with int unit_ID as 2nd (instead of string). Compiler knows of this, we don't . Still haven't managed to figure out what it exactly does since I see no results. Also, any future in creating the missing basic commands? Oh, and everyone should be warned. There's no types for vars so you may accidentally pass a string where you're supposed to pass an int and the trigger compiler will never even warn you. If your map crashes, that's the bugger. This is obviously a bug, but probably a design one and I wouldn't expect it to be corrected.
  13. oooh, The mission after the failaise pocket as the allies needs exactly the same fix too. 4 detachments as placeholders, 2 detachments max allowed. Did anyone even test the missions?
  14. oooh, The mission after the failaise pocket as the allies needs exactly the same fix too. 4 detachments as placeholders, 2 detachments max allowed. Did anyone even test the missions?
  15. Not killing all the enemies should be pretty easy. I just took a quick look of the first MP mission in the retail version. You can see numerous GetNUnits in it's triggers. From what I remember all of em are compared to 0 in subsequent lines. Uniformingly changing that 0 value to something to your liking should do the trick (I have no way on testing MP missions so I can't make sure). Say... something like 10-20? For more complex cases, you will have get into scripting more. It's not that tough if you have some minor coding history. For example, capture the hill for 30 mins should be something like this (in the same 1st MP mission): * Apparently each client checks for everbody's win/loose conditions independently, so you have to do that in each client, hence: * Define a rectangle area on the mission with the name "Rect_Win" * Create a trigger named like "IsHillHolder(@win_rect) which does the following (out of the top of my head, logical and syntax errors are more than likely to be in here) ----- //Returns the current holder of the hill PARAM IN @win_rect PARAM IN @army PARAM IN @client_ID PARAM OUT @holder SET @holder = 0 SET @client_num = MP_GetClientNum ( ) SET @i = 0 SET @units=0 SET @alliance_num = MP_GetClientAlliance ( @client_ID ) //Check to see if the army has any units on the hill //If not, return false (0) SetWorkArmy ( ARMY , @army ) SET @units = GetNUnitsInArea( ARMY , @army , "HUMAN" , @win_rect , "CREW" ) IF ( @units = 0 ) THEN SET @holder = 0 RETURNPARAMS HALT ENDIF //Since the army has units on the hill, check if //any other hostile armies have units on the hill. //If not, then it's a win scenario (1). Otherwise //return fail (0) SET @holder = 1 LABEL FOR IF ( @i lessthan @num ) THEN SET @valid = MP_IsClientValid ( @i ) SET @testing_alliance = MP_GetClientAlliance ( @i ) IF ( @valid = "TRUE" && @ @alliance_num != @testing_alliance) THEN SET @hostile_army = MP_GetClientArmy ( @i ) SetWorkArmy ( @hostile_army ) SET @hostile_units = GetNUnitsInArea( ARMY , @hostile_army , "HUMAN" , @win_rect , "CREW" ) IF ( @hostile_units morethan 0 ) THEN SET @hodler=0 RETURNPARAMS HALT ENDIF ENDIF ADD ( @i , 1 ) GOTO FOR ENDIF RETURNPARAMS HALT ----- So this last bit of code is written so you don't have to change much of the default coding of the win default mission win/lose conditions. Repacing calls to GetNUnits with IsHillHolder should suffice (they're default checking to =0 for loose condition). * You STILL need to change the victory condition with something like the following snippet (pseudocode cause I'm in a hurry) --------- SET @winner = -1 WHILE (@winner = -1) (use the for looping like snippet) FOR.... <insert the same as snippet for looping all clients> IF (isHolder(@curent_client)) THEN FOR (i=0, i lessthan 10, i++) //10 is the num_mins to hold hill to win SET still_holder = isHolder(current_client) IF (still_holder=0) THEN BREAK (exit the timecounting loop, client lost hill) ENDFOR IF (still_holder = 1) THEN SET @winner=@current_client (timer expired and current checked client still has the hill. He pwns) ENDIF Delay(60000) (wait a min before checking hill holder again) ENDFOR ENDWHILE //following lines prolly dead wrong, but you get the point. MP_Client_win(@winner) Set @win_alliance = MP_GetClientAlliance(@winner) MP_AllianceWin(@win_alliance) --------- So what the previous psudocode does is to keep looping untill there is a winner (1st WHILE). The while loop continually goes through all the clients in the game and checks one after the other to see if he holds the hill (1st FOR). When a holder is found, it starts countdown by checking to see if the same client is still the holder after one minute, and will do so untill the 10 mins expire. If timer expires then we got a winner, otherwise go back to the looping to see who holds the hill now. Right, this was supposed to take 5 mins and took me well over30 mins. Dammit. [rant] OH SWEET JESUS MY EYES, WHO CODED THAT MISSION? Like seriously, lay off the goto's. using them to emulate for's is "so-so" at the current state of the language, but using em to jump in and out of your emulated "for" loops is logical suicide. I so wanna shoot me for copying those bits off the default mission btw, are those MP comments written in russian? [/rant] EDIT: oh, sorry, forum software ate the indentation. Good luck following those if's/while's [ May 21, 2007, 10:57 AM: Message edited by: nonickch ]
  16. any scripting language changes there moon? Like new commands? I don't wanna shoot me in the face when there's something workable around the corner.
  17. Geez, I don't see how a small ammo pack can carry 10 panzerfausts. That's like 51kg's
  18. Yes, storing the unitID's is one of the two possible ways that crossed my mind, but they are both tottaly inappropriate for my scope. The other one is making any triggers that require unitID's to run instantiated and be responsible for a single unit (therefore the unitID can be immediately passed as param). But, those would be an unacceptable workaround for a basic abstractions and a basic commands package. First it will make code maintenance a nightmare (and hence severely limit the possible size of the project) and ofc will place an extraordinary load upon anyone that might try to use the package. Such packages only make sense if there is a reasonable setup time and relative ease of use, and these workarounds would make a decent-size package tougher to learn than the scripting language itself. Imagine the hell of having to input triggercode for each unit you place on the map. Only up to 500 for each map... and that's just for enabling the package to handle units. Not mine or anyones happy place Oh, and a 43/41 for anyone making use of global vars too But if the state of the language is so miserable (or to be exact, the language's basic commands), I really don't think goto's and globals will make it much worse. EDIT: On a coding tip here. Some reasons for never using global vars are: 1) Maintainability. So if you choose to change the name of that global var, you have to go all over the code again 2) Don't even think on reading from a global on a threaded enviroment like this (many triggers running async). Two consecutive reads from the same global may give you different results because another trigger kicked in between the two calls and decided it don't like the value no more and changed it. This type of bug is arguably the toughest one to detect (and correct), mainly because it appears randomly (based on when the CPU decides to temporarily freeze one trigger in favor of another). A formalized approach to avoiding such problems are semaphores (try wikipedia). Something that may be coded in a package. 3) Testing. You have to compartmentalize code blocks in order to test them properly. Globals make your code randomly dependent on other parts of the code. Not good. 4) Reusability. You just can't reuse code snippets that use globals because the globals may not be there in your new program. What to do? pass variables. Lots of em. Propagate the information that would be stored in the global through parameters. Pass em again, and again, and again as deep your trigger-calling tree grows. A var that was passed between 5 triggers to reach it's final resting place is a happy var If you end up passing endless vars between triggers, you did something wrong. Rethink the structure of the triggers. [ May 19, 2007, 10:10 AM: Message edited by: nonickch ]
  19. EDITED: right... nvm, just wrote my seelow walkthrough. Need to get some sleep.
  20. my hair are falling off. Just spent another 3 hours to find a way to crew an empty artillery. You see, in staticland it's all ok. If you know the artillery unitID you can call RunCommand ( GROUP , @new_group_ID , IN_CREW , UNIT , <artillery_ID> ) But if you're from a general-script POV, you have to locate the art piece yourself. Easy enough, you can search the entire map for an empty piece of art BUT you can ONLY assign/know a groupnumber (via CreateGroupByRect with UnitNumber=1) Here's the hairy part: RunCommand will roll over and die if you try it with IN_CREW and GROUP+GROUP_ID like: RunCommand ( GROUP , @new_group_ID , IN_CREW , GROUP , @__temp_artillery_group ) Doc has the GROUP option there, but it's in red letters (as in: "I'll suck the life out of you if you try me"?) And ofc there is no way possible to either get unit id's (or even create new unit ID's, tried CreateGroupByRect with UNIT as 1st param). This one has effectively halted all my coding process. It is quite essential for most things I'm planning on doing. Can anyone help? Moon, can you forward this to someone who knows?
  21. I'm quite certain that in the sub 100m ranges AP rounds have an insane chance of shattering. I've fought quite a few toe to toe battles with panzers in villages, and I distinctly remember 4-5 T34's shooting a pz3 from 10-50 mt's and an that monster-tank from like 5 meters. Nothing happened. I was shooting it from all the possible angles, very few ricochet's and no damage. After like 3 minutes of non-stop shooting I had the tank that was shooting from behind to take some range and the pz3 went pop on the first round. On the good side, you can probably sucker-punch lone tigers by having a fast tank hug them, then circle around in a heavy hitter. So never expect to reach the penentration you get listed on 100m. EDIT: meh, I think tigers carry HEAT so you'll go pop very, very fast.
  22. GOTO is considered the bane of all that is coding. Readability and maintenance of the code becomes miserable with it. In a big chunks of code, bugs will start creeping up on you with extensive use. Admittedly Webwing has a point here, the lack of FOR/WHILE loops is crippling. There are 1-2 ways that popped into my mind to sensibly go around that without breaking proper coding. 1) Recursion, the way AI languages go about solving this problem. http://en.wikipedia.org/wiki/Recursion (follow the link for recursion in computer science) It is admittedly expensive, especially if the firing of a trigger ("function-call overhead" in the wiki article) is a resource-costly thing to do (I have no idea on the cost of anything, will have to run benchmarks to figure it out) 2) oh god damn, I forgot it. Lemme get high, if I get high I'll remember. ... funky town ... Ooh, I remembered. Exploit the inherent looping going on with triggers with a "while trigger" specifically coded for each case. For example, simple iteration: -------- PARAM IN @counter PARAM IN @limit IF ( @counter >= @limit) THEN Halt ENDIF // Here lies the loop code ADD ( @counter, 1 ) --------- A generalized while trigger would be possible if we could execute strings (like many other scripting languages can do). Pass a string parameter in representing the loop code. Unfortunatelly, I don't see how we could do this. Anyway, and now for some general ranting. Casting. Omg, there is NO typecasting. I was making a split_group trigger with an int representing how many units to move. Compiler kept slapping when I passed a var where it expected an int (i.e. CreateGroupByRect). Temporarily made a series of IF's for 1-4, but it can also be solved with recursions. It's the type of shortcomings in the language which we will have to pay with coding sweat and endless CPU cycles. Don't get me started on string operations... Oudy: I'm slowly starting to write a series of support triggers that can provide some sensible level of abstraction over the currently elementary commands available. I started with some group manipulation ones like splitting groups and fixing the hierarchy of groupings (a group can be member of multiple groups, usefull, but "ouch"). Moving units from one group to another etc... Even this level of abstraction is quite high, I'll probably have to write quite a few supporting trigs to be able to run this kind of operations. In other words: HELP! I'll post some bugly snippets of code along with my rants/problems later on. My current burning problem: Anyone found a way to get the unit ID's from a specific group? [ May 18, 2007, 11:52 PM: Message edited by: nonickch ]
  23. Webwing: I have not personally used instantiated triggers yet, but given the meaning of instancing in coding I can help there. If you weren't allowed to run multiple instances of a trigger, what would be the difference from asynch running em? You fire up each instance and differentiate it's behaviour by providing it with it's own params (now there wouldn't be much point all instances doing the same thing). For example, think of an elementary trigger that refreshes the current command of the unit in one of your local variables. You'd make the trigger as ------ Param IN: @unitID Param OUT: @current_command Delay(5000) @current_command = GetCurrentCommand("UNIT",@unitID) RETURNPARAMS ------ So, you fire up an instance for each unit you want to have this functionality. This is excellent when you want to have something like a table that keeps track of multiple things (let's say the table represents a grid of the map and the values the hostility of each grid). You can really go far with instances. Destroying instances is VERY important, as it is destroying objects in coding. You cannot have instances running around doing stuff when their job is done (i.e. the unit they're responsible for is dead). Not doing so will get you angry gamers screaming "memory leak!" after playing the game for a few hours straight Bringing us on the previous subject, destroying normal triggers. I can't imagine a well-designed situation that would need such a function, but it doesn't hurt to have it there as a last resort hack. Hell, even GOTO is in the language, but if anyone uses it, he needs to be shot (by a 43/41 at point blank range) Proper deaths of triggers should be the Halt command. Oh, and Webwing. I haven't understood your background in coding man. If you're well into all these stuff just say so, from the syntax of your question I thought you didn't know of instancing in general. [ May 18, 2007, 08:31 PM: Message edited by: nonickch ]
  24. they did elaborate. The engined is not the sturmovik one. Apparently it was only based on the Sturmovik one which really means they don't necessarily have much in common. From the replies in the previous thread, I don't see this feature happening anytime soon (if ever)
  25. Gunslingr3: Turn on the option in the game settings for the targetting indicator so you can see your running target order. You can switch the default targetting mode by clicking the 3 tick-dots in the "attack" button when the unit is selected. Upper-med(default)-lower targetting. It is quite frequent that only the upper or lower part of the target can be targetted. Ianc: Chances are your tanks can't depress their gun enough to shoot the russians while they can pretty much move their cannon high enough to shoot you. Try repositioning. In general, when you see your tanks aren't shooting, try changing targetting modes (give it 2-3 secs to understand the order). It is quite annoying, I agree, but as previously mentioned, it's getting fixed in the patch.
×
×
  • Create New...